clr-boot-manager doesn't keep extra loader configurations

[lebensterben]

Description

Suppose /mnt/boot is the mount point of the boot partition, and /mnt/boot/loader/loader.conf
is the loader configuration file.

Manually adding any options to loader.conf won't persist after system auto-updates its
kernel, or the user invokes clr-boot-manager update.

To Reproduce

1. Mount the boot partition at, say, /mnt/boot
2. Edit /mnt/boot/loader/loader.conf. For exampling appending a line console-mode max
3. Call clr-boot-manager update
4. cat /mnt/boot/loader/loader.conf and you will find the options you just added disappeared.

Additional Information

According to man 5 loader.conf, most default options seems to be reasonable. But I found
console-mode defaults to keep, which keep the resolution selected by the firmware. This causes some annoyances when I'm working in a rescue.target for example.

To fix the resolution, I need to set console-mode to max. So at least I think clr-boot-manager
either make max as default for console-modd, or respect the choices of users.

[GabeAl]

Same (or similar) issue. I just want to add some boot flags and have them persist across boots. This is trivial with other distros and bootloaders like GRUB

[fenrus75]

adding kernel command lines options that persist is actually easy and documented in the man page yes it's somewhat different than other distros but quite consistent and elegant

…

On Sat, Sep 3, 2022, 13:14 Gabriel Al-Ghalith ***@***.***> wrote: Same (or similar) issue. I just want to add some boot flags and have them persist across boots. This is trivial with other distros and bootloaders like GRUB — Reply to this email directly, view it on GitHub <#241 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ54FJPJICSNUEXXJ5DPYTV4OWSRANCNFSM4PRBRLMQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[GabeAl]

Well, you might be right, if this is what you're referring to:

CONFIGURATION
       clr-boot-manager takes into account the following paths to modify its behavior:

       /etc/kernel/cmdline.d/*.conf
           A set of files that will be used to modify the kernel commandline. The files can also be used to mask the  vendor  cmdline
           if  the  filename  matches  a  vendor  configuration  file  and is linked to /dev/null. The vendor configuration files are
           /usr/lib/kernel/cmdline-* and /usr/share/kernel/cmdline.d/*.conf.

           The files should be in plain text format and each line will be appended directly to the kernel commandline.

But claims of elegance aside, it still confuses me a bit.

If I understand correctly, to add a flag like "mitigations=off" to an offline server's kernel flags, I need to create a hierarchy of folders and files that don't currently exist and populate them correctly from scratch (or else I risk system breakage). This is one of the major dangers of a "stateless" architecture -- you're never really sure whether directories don't exist because of they're actively repressed by "statelessness" or whether you really shouldn't be mucking around in there because it's the totally wrong place or thing to do. I've broken Clear Linux filesystems by trying to make folders and files where I thought they should go and how I thought they should be written, only they weren't really supposed to go there or be written like that.

So to help me out a little, is this right?

• Create a new folder in /etc/kernel called "cmdline.d".
• Create a new text file in /etc/kernel/cmdline.d/ with an arbitrary name ending in ".conf"
• Simply write "mitigations=off" in that text file and close it.

Now all subsequent boots will append this to the kernel string? No section headers or "APPEND" tags or anything? No telling it where to look for the files or how to use them?

Thanks!

[edit] Nope, still isn't in there. Maybe I have to trigger a "rebuild" with the update command or something? It's not clear in the docs -- a couple lines of text explaining how to actually go about using the things in the man page would be helpful for folks like me without preexisting knowledge of how it works. 👍

[fenrus75]

one more step, run clr-boot-manager update but otherwise yes

…

On Sat, Sep 3, 2022, 16:21 Gabriel Al-Ghalith ***@***.***> wrote: Well, you might be right, if this is what you're referring to: CONFIGURATION clr-boot-manager takes into account the following paths to modify its behavior: /etc/kernel/cmdline.d/*.conf A set of files that will be used to modify the kernel commandline. The files can also be used to mask the vendor cmdline if the filename matches a vendor configuration file and is linked to /dev/null. The vendor configuration files are /usr/lib/kernel/cmdline-* and /usr/share/kernel/cmdline.d/*.conf. The files should be in plain text format and each line will be appended directly to the kernel commandline. But claims of elegance aside, it still confuses me a bit. If I understand correctly, to add a flag like "mitigations=off" to an offline server's kernel flags, I need to create a hierarchy of folders and files that don't currently exist and populate them correctly from scratch (or else I risk system breakage). This is one of the major dangers of a "stateless" architecture -- you're never really sure whether directories don't exist because of they're actively repressed by "statelessness" or whether you really shouldn't be mucking around in there because it's the totally wrong place or thing to do. I've broken Clear Linux filesystems by trying to make folders and files where I thought they should go and how I thought they should be written, only they weren't really supposed to go there or be written like that. So to help me out a little, is this right? - Create a new folder in /etc/kernel called "cmdline.d". - Create a new text file in /etc/kernel/cmdline.d/ with an arbitrary name ending in ".conf" - Simply write "mitigations=off" in that text file and close it. Now all subsequent boots will append this to the kernel string? No section headers or "APPEND" tags or anything? No telling it where to look for the files or how to use them? Thanks! — Reply to this email directly, view it on GitHub <#241 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ54FJF6PMVTABBUKW6YA3V4PMQZANCNFSM4PRBRLMQ> . You are receiving this because you commented.Message ID: ***@***.***>

[GabeAl]

Works. Done. This should DEFINITELY make its way into the Clear Linux online documentation for dual booting as well.