Re: Unable to remove grub menuentry for kernel 5.9

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux