I want to have two different cmdlines, one for linux66 and another for linux613.
But update-grub always ate my changes in grub.cfg after a kernel update.
Does anyone know how to configure GRUB to retain separate cmdlines for each kernel?
you cant have different lines on boot kernel for each kernel,
may be in manual chain
You don’t edit that file directly.
It even says so at the top of the file.
You edit /etc/default/grub - and update-grub is used to re-generate grub.cfg
(/boot/grub/grub.cfg)
However, I’m not aware of an option to use different command line parameters for different kernels.
You can edit /boot/grub/grub.cfg it directly - but as soon as you use update-grub, this will be rewritten.
There is a way (or ways) to use a custom config file in /etc/default/grub.d/ - but I only read about it and cannot be more specific - zero experience …
Thanks for your response. I haven’t found a simple solution. GRUB kernel update is a issue.
Is there another bootloader that simply keeps my cmdlines without eating them after any update?
section 4 - the link goes there
This is what I meant with custom configuration file.
There are posts about it here in the forum and elsewhere on the interwebs.
I know of no other way.
In fact: I don’t even know whether what you want is possible this way.
I’ve already looked into that, but this is not a simplified solution. Why can’t it simply keep the changed cmdline without requiring complex rewrites from /etc/grub.d/
It will keep the changed command line - just not two versions of it.
On second thought:
perhaps it is possible to “abuse” the
GRUB_CMDLINE_LINUX_DEFAULT=
and
GRUB_CMDLINE_LINUX=
for this purpose? - I don’t know.
I have tried both GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX, but they are merged into a single cmdline for all kernels, which is not what I expected.
I’m looking into other bootloaders. I don’t know if systemd-boot or rEFInd can deal with this issue?
I don’t know either - never had a need to boot different kernels with different options.
And I have never used rEFInd.
You can have different cmdlines with systemd-boot.
Normal boot:
title Arch Linux
linux /vmlinuz-linux
initrd /intel-ucode.img
initrd /initramfs-linux.img
options root=UUID=026beb90-16a1-44dd-8a05-ee8ba6f94c99 rw net.ifnames=0 nowatchdog sysrq_always_enabled audit=0 loglevel=3 amdgpu.gpu_recovery=1 systemd.ssh_auto=no
sort-key 01
Fallback:
title Arch Linux - Fallback
linux /vmlinuz-linux
initrd /initramfs-linux-fallback.img
options root=UUID=026beb90-16a1-44dd-8a05-ee8ba6f94c99 rw net.ifnames=0 sysrq_always_enabled audit=0 loglevel=3 systemd.ssh_auto=no
sort-key 02
Disclaimer: I also use dracut to generate my initramfs; I don’t even remember how mkinitcpio generated images:
-rwx------ 1 root root 91984900 Mar 14 00:27 initramfs-linux-fallback.img
-rwx------ 1 root root 43326679 Mar 14 00:27 initramfs-linux.img
I have added all my custom grub entries to /etc/grub.d/40_custom.
The entries are preserved in case of a grub update and are used by grub without modification.
I use it to have both Nouveau and Properitery Nvidia drivers installed and be able to choose between them.
menuentry 'Manjaro Linux nouveau' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-9dc4ed12-cf8e-41b5-a31c-9de5f50e8dc6-nouveau' {
savedefault
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1 9dc4ed12-cf8e-41b5-a31c-9de5f50e8dc6
else
search --no-floppy --fs-uuid --set=root 9dc4ed12-cf8e-41b5-a31c-9de5f50e8dc6
fi
linux /boot/vmlinuz-6.12-x86_64 root=UUID=9dc4ed12-cf8e-41b5-a31c-9de5f50e8dc6 rw resume=UUID=9dc4ed12-cf8e-41b5-a31c-9de5f50e8dc6 resume_offset=30074880 apparmor=1 security=apparmor udev.log_priority=3 sysrq_always_enabled=1 modprobe.blacklist=nvidia,nvidia_modeset,nvidia_uvm,nvidia_drm systemd.setenv=GPUMOD=nouveau nouveau.config=NvBios=PRAMIN nouveau.config=NvGspRm=1 nowatchdog intel_iommu=on iommu=pt
initrd /boot/initramfs_nouveau-6.12-x86_64.img
}
For example, I use an environment variable (GPUMOD) that is set to “nouveau” by
systemd.setenv=GPUMOD=nouveau. Depending on this, further actions are then executed by systemd.
2 Likes
Does an automatic update of systemdboot keep different cmdlines for different kernels without fallback?
Thanks for the suggestion. I’ve noticed two things I don’t like.
First, it adds an entry at the bottom of the GRUB boot menu. How can I move it to the top?
Second, I have two duplicate kernel 6.13 entries, each with a different cmdline. If I remove one, it comes back after a random GRUB update. How can I permanently remove it, regardless of updates?
1 Like
The following is not very helpful perhaps, because I can’t link you to a specific post.
But:
I read a lot here - and I, very recently, saw a post where exactly this was discussed and described.
I’d like to be more specific - I’d have to look for it.
I’ll leave that to you though.
Your chances of finding it are probably better when you use google, rather than the forum search. (my experience and opinion)
I have not tried it myself, but you should be able to set the first menu entry with the help of GRUB_TOP_LEVEL="path_to_kernel" in /etc/default/grub. (see Archwiki - Generate the main configuration file or GNU GRUB Manual 2.12)
Or you could write a small shell script to manipulate the /boot/grub/grub.cfg generated by grub-mkconfig afterwards. Basically, grub-mkconfig is also just a shell script.
Although, this shouldn’t be necessary if /etc/default/grub is properly set to default to the last booted menu entry.
nearly…
Last booted ensures that the last menu item used is selected again. i also use it and i find it sufficient.
@Persie was referring to the sorting of the menu items, what GRUB_TOP_LEVEL should be for. But the more I read through the documentation, I think this only refers to the sorting within a submenu.
Yes, I’m aware of what the OP was asking.
I maintain that what the OP is asking for shouldn’t be necessary; at least, not for the sake of aesthetics.
Most EFI Bootloaders tend to display boot options as detected;
rEFInd is no exception.
I find rEFInd is most useful as an intermediary bootloader to effectively chanload other bootloaders present; which means Grub would ideally still need to be present also. I’ve personally used this basic premise for many years in multi-boot scenarios.
That said, rEFInd is also capable of booting a kernel stub directly (bypassing Grub) which is sometimes useful. I would not depend on rEFInd as a sole bootloader for a system.
Regards.
1 Like
What about Limine? Just copy a boot entry and change its command line in limine.conf, no hassle. This is great for user friendliness, IMO.
The conf files under /boot/loader/entries are not changed with sdboot upgrades/updates.
This didn’t fix it for me. My entry is still showing up lower down. GRUB config is terrible.
U didn’t answer me if rEFInd can keep cmdline changes after random updates.
Limine is pretty unknown to me. No go for me
Thanks, I’ll check out it.