On 3/29/25 12:01 AM, Felix Miata wrote:
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 /boot
Hidden 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.
My initial understanding was that they would follow updating the kernel.
Simple enough to do the manual step.
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>?
Didn't understand that <filter> was just the partition label.
<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.
The /dev/xxxx form of a label still works very well. Then complication
enter with fedora and btrfs or lvm
Something picks up the names on the new kernel in an update.
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/.
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.
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?
Just that it is understood.
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
emacs dired in edit mode makes the updating of the /initramfs and
/vimlinuz symlink entries very easy.
Booting 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.
agreed
--
_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
