is grubby a dumb software?

[François Patte]

Bonjour,

For a long time now grubby has replaced grub2-mkconfig to update the
grub.cfg file. From this time, I have to correct the kernel update
manualy with grub2-mkconfig because every time grubby chooses a wrong
partition as the / partition.

The choosen partition is not mounted, it is empty, with no boot flag....

Why grubby chooses this partition? It is so stupide that I am wondering
what is the way followed by grubby to to this?

Thank you for any light.

[stan]

On Sun, 26 May 2019 10:49:00 +0200
François Patte  wrote:
> Bonjour,
>
> For a long time now grubby has replaced grub2-mkconfig to update the
> grub.cfg file. From this time, I have to correct the kernel update
> manualy with grub2-mkconfig because every time grubby chooses a wrong
> partition as the / partition.
>
> The choosen partition is not mounted, it is empty, with no boot
> flag....
>
> Why grubby chooses this partition? It is so stupide that I am
> wondering what is the way followed by grubby to to this?

As far as I know, grubby used to merely copy the previous first entry in
the grub.cfg file and replace the old kernel with the new kernel.
So, that would imply that there is something wrong with the grub.cfg
file. Of course, grubby could have a bug, but as you say it has worked
fine for a long time.

And, there is the new setup in F30, where it seems instead of a config
file there are scriptlets that emulate a config file.  I have no first
hand experience with that, but I've seen people having trouble with it
on this list. You might be running into that.

[Berend De Schouwer]

On Sun, 2019-05-26 at 10:49 +0200, François Patte wrote:
> Bonjour,
>
> For a long time now grubby has replaced grub2-mkconfig to update the
> grub.cfg file. From this time, I have to correct the kernel update
> manualy with grub2-mkconfig because every time grubby chooses a wrong
> partition as the / partition.
>
> The choosen partition is not mounted, it is empty, with no boot
> flag....
>
> Why grubby chooses this partition? It is so stupide that I am
> wondering
> what is the way followed by grubby to to this?

I hit a similar problem on 1 of 3 F29->F30 upgrades.

Something (dnf?) overwrote /etc/default/grub and changed
GRUB_CMDLINE_LINUX.  The root LVM changed from the working one to
"rd.lvm.lv=fedora/root", despite there being no LVM by that name.

It caused the machine to fail to boot.

I have no idea why that happened on this one machine, and not on the
other two.

[ja]

On Sun, 2019-05-26 at 08:20 -0700, stan via users wrote:
> On Sun, 26 May 2019 10:49:00 +0200
> François Patte  wrote:
> > Bonjour,
> >
> > For a long time now grubby has replaced grub2-mkconfig to update the
> > grub.cfg file. From this time, I have to correct the kernel update
> > manualy with grub2-mkconfig because every time grubby chooses a wrong
> > partition as the / partition.
> >
> > The choosen partition is not mounted, it is empty, with no boot
> > flag....
> >
> > Why grubby chooses this partition? It is so stupide that I am
> > wondering what is the way followed by grubby to to this?
>
> As far as I know, grubby used to merely copy the previous first entry in
> the grub.cfg file and replace the old kernel with the new kernel.
> So, that would imply that there is something wrong with the grub.cfg
> file. Of course, grubby could have a bug, but as you say it has worked
> fine for a long time.
>
> And, there is the new setup in F30, where it seems instead of a config
> file there are scriptlets that emulate a config file.  I have no first
> hand experience with that, but I've seen people having trouble with it
> on this list. You might be running into that.
> _______________________________________________
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:

My understanding is that grubby has been replaced for a standard install
https://lists.fedoraproject.org/archives/list/[e-mail]...

Things that may be relevant:
1. Fresh install not an upgrade
2. No separate /boot partition
3. EFI boot of install media - hence EFI installation
4. No logical volumes anywhere on the SSD
5. BLS installation by default !?

I carried out a clean install of F30, it may well be different for an upgrade.

In my case the F30 boot using BLS was successful.

However, other F28/F29 installations on the same SSD were not detected.
This was because grub2-mkconfig uses os-prober which has problems.

As I am not interested in booting other OS than Fedora the
addition of the other Fedora to the boot menu is manageable.

Approach 1 - Older Approach
Generate a /etc/grub.d/40_custom file of the form
[root@naxos:/boot/efi/EFI/fedora]$ cat /etc/grub.d/40_custom
#!/usr/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
    menuentry 'ja 29 custom ' {
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root 1a9ccef1-af1c-4c26-8e4d-64a25bc56fcc
        linux /boot/vmlinuz-5.0.16-200.fc29.x86_64 root=UUID=1a9ccef1-af1c-4c26-8e4d-64a25bc56fcc
        initrd /boot/initramfs-5.0.16-200.fc29.x86_64.img
    }

Run grub2-mkconfig -o test and check things are looking good
replace /boot/efi/EFI/fedora/grub.cfg with this file if you are feeling confident!
//---------------------------------------------------
Approach 2 - Try Using BLS approach
This should be safer than option 1 as no existing files are touched

Create a BLS file of the form
[root@naxos:/boot/efi/EFI/fedora]$ cat /boot/loader/entries/ja_77d7a92bb0374635a7212709d7339559-5.0.17-
300.fc30.x86_64.conf
title Fedora 5.0.17-300.fc30.x86_64
version 5.0.17-300.fc30.x86_64
linux /boot/fc30/vmlinuz-5.0.17-300.fc30.x86_64
initrd /boot/fc30/initramfs-5.0.17-300.fc30.x86_64.img
options root=UUID=32524647-c8e8-49cb-9c6f-ae25b663fa54
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel
architecture    x64
[root@naxos:/boot/efi/EFI/fedora]$

Copy the correct kernel&initramfs files to the location shown in the file above
//---------------------------------------------------
The two options are not mutually exclusive - at least, not on my system!

I attach a very crude script that carries out Option 2 above

There is absolutely no warranty with this script!!
It may give some food for thought.

Again on my new F30 install, I do not think that grub2-mkconfig is not run when a kernel
upgrade is installed.
Only a new config file is installed in the /boot/loader/entries directory.
(and the new kernel/initramfs [stored in /boot not a subdirectory]).

I have successfully run the script on "other partition" to root (/)
with a version of Fedora F27 or F29 installed on the particular partitions.

I have also run it on the booted root (/) partition.

mount |grep " / "[root@naxos:/etc/grub.d]$ mount |grep " / "
/dev/nvme0n1p8 on / type ext4 (rw,relatime,seclabel)

[root@naxos:/etc/grub.d]$ /home/ja/bin/part_scan.sh /dev/nvme0n1p8
32524647-c8e8-49cb-9c6f-ae25b663fa54
Machine ID = 77d7a92bb0374635a7212709d7339559
vmlinuz-5.0.17-300.fc30.x86_64
initramfs-5.0.17-300.fc30.x86_64.img
5.0.17-300
5.0.17-300.fc30.x86_64
fc30
/boot/loader/entries/ja_77d7a92bb0374635a7212709d7339559-5.0.17-300.fc30.x86_64.conf
[root@naxos:/etc/grub.d]$

[root@naxos:/etc/grub.d]$ ltr /boot/fc30
total 31140
-rwxr-xr-x. 1 root root  8863944 May 26 17:54 vmlinuz-5.0.17-300.fc30.x86_64
-rw-------. 1 root root 23017597 May 26 17:54 initramfs-5.0.17-300.fc30.x86_64.img
[root@naxos:/etc/grub.d]$

[root@naxos:/etc/grub.d]$ cat /boot/loader/entries/ja_77d7a92bb0374635a7212709d7339559-5.0.17-
300.fc30.x86_64.conf 
title naxos.jaa.org.uk /dev/nvme0n1p8 5.0.17-300.fc30.x86_64
version 5.0.17-300.fc30.x86_64
linux /boot/fc30/vmlinuz-5.0.17-300.fc30.x86_64
initrd /boot/fc30/initramfs-5.0.17-300.fc30.x86_64.img
options root=UUID=32524647-c8e8-49cb-9c6f-ae25b663fa54
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel
architecture    x64
[root@naxos:/etc/grub.d]$

[Patrick O'Callaghan]

On Sun, 2019-05-26 at 18:04 +0100, ja wrote:
> In my case the F30 boot using BLS was successful.

Basic Life Support?
Boston Latin School?
Bureau of Labor Statistics?
Bare Lymphocyte Syndrome?
...

poc

[François Patte]

Le 26/05/2019 à 19:04, ja a écrit :
> On Sun, 2019-05-26 at 08:20 -0700, stan via users wrote:
> > On Sun, 26 May 2019 10:49:00 +0200
> > François Patte  wrote:
> > > Bonjour,
> > >
> > > For a long time now grubby has replaced grub2-mkconfig to update the
> > > grub.cfg file. From this time, I have to correct the kernel update
> > > manualy with grub2-mkconfig because every time grubby chooses a wrong
> > > partition as the / partition.
> > >
> > > The choosen partition is not mounted, it is empty, with no boot
> > > flag....
> > >
> > > Why grubby chooses this partition? It is so stupide that I am
> > > wondering what is the way followed by grubby to to this?
> >
> > As far as I know, grubby used to merely copy the previous first entry in
> > the grub.cfg file and replace the old kernel with the new kernel.
> > So, that would imply that there is something wrong with the grub.cfg
> > file. Of course, grubby could have a bug, but as you say it has worked
> > fine for a long time.
> >
> > And, there is the new setup in F30, where it seems instead of a config
> > file there are scriptlets that emulate a config file.  I have no first
> > hand experience with that, but I've seen people having trouble with it
> > on this list. You might be running into that.
> > _______________________________________________
> > users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
>
> My understanding is that grubby has been replaced for a standard install

I don't understant what you mean here...
> https://lists.fedoraproject.org/archives/list/[e-mail]...

The browser answer is: Not found
> Things that may be relevant:
> Fresh install not an upgrade

I update my f29 system
> No separate /boot partition

I have a separate boot partition
> EFI boot of install media - hence EFI installation

My install is not an EFI one
> No logical volumes anywhere on the SSD

I use lvm
> BLS installation by default !?

???

Moreover my system uses raid-1 + lvm

Do you mean that grubby --- which seems to be the grub configuration
tool chosen by fedora --- cannot handle my installation? What can I do:
change to another distrib?

another answer to my post says:
> As far as I know, grubby used to merely copy the previous first entry in
> the grub.cfg file

I can say: no! If this was the case there will not be any problem...

My GRUB_CMDLINE_LINUX in /etc/default/grub point to the right partition
but it seems that grubby does not care...

[stan]

On Mon, 27 May 2019 07:14:03 +0200
François Patte  wrote:
> > My understanding is that grubby has been replaced for a standard
> > install
>
> I don't understant what you mean here...
> > https://lists.fedoraproject.org/archives/list/[e-mail]...

That should be

https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault
> > BLS installation by default !?
>
> ???

I think he means btr filesystem
> Moreover my system uses raid-1 + lvm
>
> Do you mean that grubby --- which seems to be the grub configuration
> tool chosen by fedora --- cannot handle my installation? What can I
> do: change to another distrib?
>
> another answer to my post says:
> > As far as I know, grubby used to merely copy the previous first
> > entry in the grub.cfg file
>
> I can say: no! If this was the case there will not be any problem...

I think that grubby has been bypassed with the new method of booting in
F30.  Note the 'used to' in my comment.

[Samuel Sieb]

On 5/26/19 11:08 PM, stan via users wrote:
> On Mon, 27 May 2019 07:14:03 +0200
> François Patte  wrote:
> > > My understanding is that grubby has been replaced for a standard
> > > install
> >
> > I don't understant what you mean here...
> > > https://lists.fedoraproject.org/archives/list/[e-mail]...
>
> That should be
>
> https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault
> > > BLS installation by default !?
> >
> > ???
>
> I think he means btr filesystem

From that URL, BLS = Boot Loader Specification.
Instead of having a monolithic grub config file, there are individual 
files describing each boot option.

[stan]

On Sun, 26 May 2019 23:32:35 -0700
Samuel Sieb  wrote:
> From that URL, BLS = Boot Loader Specification.
> Instead of having a monolithic grub config file, there are individual 
> files describing each boot option.

Thanks, I just came back to correct my answer, and see that you have
done that for me.  :-)

[Chris Murphy]

On Sun, May 26, 2019 at 11:14 PM François Patte
 wrote:
> > BLS installation by default !?

https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault
> ???
>
> Moreover my system uses raid-1 + lvm
>
> Do you mean that grubby --- which seems to be the grub configuration
> tool chosen by fedora --- cannot handle my installation? What can I do:
> change to another distrib?

Fedora 30, both new installations and upgrades from Fedora 28/29, has
GRUB bootloaderspec enabled by default.

grubby isn't used during kernel upgrades anymore, there are scripts in
the kernel package that create a bootloader file for that kernel and
is dropped into /boot/loader/entries - and then a GRUB blscfg.mod
module parses the drop-in scripts in /boot/loader/entries to create
the GRUB menu. This means the grub.cfg is static, is no longer either
recreated or modified.

And it should support raid1 + LVM. If it's not, it's a bug and should be fixed.

Anyway, you can include the following information. Ideally attach it
all to a detailed bug report describing the problem, but you can use
fpaste, pastebine, Google Drive, or Nextcloud URL for your files:

# blkid
# efibootmgr -v
# rpm -qa | grep grub2
# fdisk -l /dev/sdX    ##where X is the device node for boot & root partitions

Include these files:
/etc/fstab
/etc/default/grub
/boot/efi/EFI/fedora/grub.cfg or /boot/grub2/grub.cfg
/boot/efi/EFI/fedora/grubenv or /boot/grub2/grubenv
/boot/loader/entries/*   ## all of them