On 3/29/25 12:01 AM, Felix Miata wrote:
My initial understanding was that they would follow updating the kernel. Simple enough to do the manual step.Robert McBroom composed on 2025-03-28 22:48 (UTC-0400):Felix Miata wrote:...menuentry "Fedora 40 defkernel 3 on P18" { load_video set gfxpayload=keep search --no-floppy --set=root --hint-baremetal=ahci0,gpt18 --label <filter> linux /boot/vmlinuz root=LABEL=<filter> noresume audit=0 ipv6.disable=1 net.ifnames=0 consoleblank=0 preempt=full mitigations=off video=1440x900@60 3 initrd /boot/initrd }menu presented, followed by those from auto-generated entries in grub.cfg.40_custom or a copy of it renamed could be used as initial template instead, to contain the custom stanzas instead of using a custom.cfg file (AIUI).see also: <https://forums.opensuse.org/t/how-to-have-a-custom-uefi-grub-menu-for-a-multiboot-system/133541>There is much hidden. Symlinks don't track to the changes that an update does to /bootHidden from what? Track what? The symlinks live in /boot/. For distros that don't automatically create them, like Fedora, it's the admin's job to see to their creation.
Didn't understand that <filter> was just the partition label.menuentry "Fedora 40 defkernel 3 on P18" { load_video set gfxpayload=keep search --no-floppy --set=root --hint-baremetal=ahci0,gpt18 --label <filter> linux /boot/vmlinuz root=LABEL=<filter> noresume audit=0 ipv6.disable=1 net.ifnames=0 consoleblank=0 preempt=full mitigations=off video=1440x900@60 3 initrd /boot/initrd }What activity goes on in <filter>?
The /dev/xxxx form of a label still works very well. Then complication enter with fedora and btrfs or lvm<filter> is a placeholder/sustitute for information that needn't be shared on a mailing list or forever archived on the WWW. LABELs are filesystem labels, unique strings determined by an admin, which an admin can determine, and more easily manage than 36 character UUIDs.
Something picks up the names on the new kernel in an update.
Looked at Debian and Suse in virtual machines to see how they were using the symlinks. While they created the symlink entries they used the explicit /boot entries in the boots.Depends on whether distro normally creates kernel/initrd symlinks as a matter of course. When it does, there's "no picking up" to do. Debian and various of its derivatives create them in the boot filesystem's /; openSUSE and Mageia e.g. create them in /boot/.
Just that it is understood.You are naming the partitions by labels in your own scheme which can be understood and mapped to your custom.cfg. Every admin has that opportunity. Your point?
emacs dired in edit mode makes the updating of the /initramfs and /vimlinuz symlink entries very easy.Something then has to pick up the /boot/initramfs... of a new upgrade and cycle it into the rotation in the storage space of /disks/f39/boot/...The example is from a real multiboot system with non-booted installations' / filesystems mounted or not in /disks/*. There's nothing to be attended to in the out of support F39 example's filesystem.Can see how all can be done with extensive editing but not easily.No custom.cfg or 07_custom editing is indicated except when a new distro is added or an old one removed or renamed. The only normally required activity is when new??? kernel is installed and the distro does not automatically create kernel and initrd symlinks, or a newly installed kernel fails, admin removes it, and the prior one didn't/doesn't have its own, requiring minor retro activity. Here, the last symlink creation is in root's bash history, so trivial to run against latest kernel, after renaming or deleting the prior symlink pair (e.g. mv /boot/vmlinuz /boot/vmlinuzp && mv /boot/initrd /boot/initrdp): cd /boot ln -s /initramfs-6...<tab> /initrd && ln -s /vmlinuz-6...<tab> /vmlinuz
agreedBooting a prior kernel based upon the e.g. above would simply be either by striking the E key at the Grub menu's normal stanza for that distro and appending a p in two places, or, selecting an alternate stanza that already includes those p's, or whatever other suffix admin has determined appropriate.
-- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
