On Tue, Dec 1, 2020 at 1:13 PM Tim via users <users@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 2020-12-01 at 20:52 +0530, Sreyan Chakravarty wrote: > > What am I doing wrong? > > I suppose some questions are: How did you install kernels, in the > first place. And have you been manually altering grub menus, too? > > I've been using Fedora since it used to be Red Hat Linux, and had > always let yum or dnf install new kernels as it found them, and remove > old kernels along the way, and it's never got that wrong. And I've > never had to manually intervene to change GRUB menus regarding this. > I've even had dual-boot systems (Windows, other Linuxes), where the > dnf/yum kernel install and remove procedures simply work as they're > supposed to. > > Over the years I've simply removed parameters like quiet, rhgb, splash, > so I can see what's going on while a system is booting, and I haven't > fouled up the automatic processes for the GRUB menus in doing so, nor > had to go around madly regenerating things to make my changes. > > Some people seem to be endlessly horsing around with grub-install, or > grub2-mkconfig, etc., and I do not know why. Maybe you need to make some customizations to boot parameters, which should happen in /etc/default/grub, and then grub2-mkconfig. Because grub.cfg shouldn't be directly modified. Can you? *shrug* yes you can but upstreams has since forever said please don't. The grub.cfg even includes such text. On Fedora ~30 to 32 a macro was used for bootparameters, saving them in grubenv, which grub2-mkconfig would write to. GRUB reads grub.cfg which says load grubenv, then blscfg (module) which then also goes out to read the BLS snippets. The snippets have $kernelopts reference to the bootparameters found in grubenv. This is all very Rube Goldberg machine-like. Fedora 33 does away with the macro, the BLS snippets have the boot parameters in them. Which now means grub2-mkconfig rewrites the BLS snippets (whether or not you use -o). The grub.cfg does still contain an explicit entry for Windows, and on UEFI systems there's also an entry to get to the firmware's setup. And for many years now, grub2-install should only be used on BIOS systems. It's not ever automatically updated during upgrades, so that's left as an exercise for the user to do manually. If not done we do sometimes see problems because the stage2 bootloader (the core.img) can contain code that's not necessarily compatible with newer modules like blscfg.mod. *shrug* pretty esoteric stuff, and is one of the things bootupd project wants to solve. Meanwhile on UEFI grub-install should not be used. The EFI OSLoader binary is updated as part of the grub rpm package updates, on traditional installations of Fedora. On rpm-ostree this update doesn't happen, either BIOS or UEFI, and again hence bootupd project. As mad as this all sounds, and is, because of this work we're very close to being able to support dual boot Fedoras. Right now we only explicitly support Windows or macOS plus one Fedora. Two Fedoras, is a nope. This is the draft test case for that: https://fedoraproject.org/wiki/User:Sumantrom/Draft/dualboot_f33_btrfs The gist is you do an automatic default installation first. Then for the second installation, reuse /boot/efi, /boot, do not reformat. Also reuse /home if you want. And then you need to create a new / (it's required you can't use an existing "root" and assign it to /) mount point. So now you have two "root" subvolumes (different names of course) containing the two different Fedoras but they share a /boot. You might see some confusion if one Fedora deletes a kernel that the other one depends on, but there you have it. And there is also this bug to watch out for: https://bugzilla.redhat.com/show_bug.cgi?id=1874724 But otherwise, it works. For the adventurous bold and brave, you can even build bees and dedup. I expect a significant ability to dedup the same version OS because the binaries will be identical. That is, Workstation 33 and KDE 33 will share a lot of the same binaries. Same for Workstation 33 and Silverblue 33. You could have a very low footprint for having multiple Fedoras on the same Btrfs file system. -- Chris Murphy _______________________________________________ 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
