Bonjour,
I sent several messages about kernel updates and grubby.
Once upon a time I made 4 partitions on a ssd drive where the system is installed. I use raid1+lvm
on sda1 and sdb1 I put the a /boot partition (raid1) for a debian install on sda3 and sdb3 I also put /boot partition (raid1) for a fedora install
on sda2 and sdb2 I put a / partition (raid1+lvm) with label "debian-racine" (at that time I had a debian install) on sda4 and sdb4 I put a / partition (raid1+lvm) with label "fedora-racine" for a fedora install.
So I had two linux installs: one was debian the other was fedora.
I abandonned debian and used the debian partition to install a fedora version. I wanted to keep two different partitions: on one partition fedora-n on the other fedora-(n+1).
Then appears the "dnf system upgrade" and I disabled the my sda3-sda4 partitions and only used sda1-sda2 partitions (with label "debian-racine") for my system.
Everything was ok untill grubby replaced grub2-mkconfig: when there is a kernel update, grubby uses the disabled sda3-sda4 partitions as the / parttion in the /boot/grub2/grub.cfg file.
I have now destroyed these partitions but grubby still uses them and writes a faulty /boot/grub2/grub.cfg file.
Where does it find that these partitions still exist?
I can't upgrade my system now because I fear that the boot config file will refer to a partition wich no longer exists on my system.
Please help me!
On 6/15/19 2:23 PM, François Patte wrote:
Everything was ok untill grubby replaced grub2-mkconfig: when there is a kernel update, grubby uses the disabled sda3-sda4 partitions as the / parttion in the /boot/grub2/grub.cfg file.
grubby has never replaced grub2-mkconfig. They are independent. grub2-mkconfig is never run, except maybe on the initial install. Upgrades up to F30 have always used grubby.
I have now destroyed these partitions but grubby still uses them and writes a faulty /boot/grub2/grub.cfg file.
Where does it find that these partitions still exist?
grubby only copies the information from the previous kernel in the grub.cfg file.
I can't upgrade my system now because I fear that the boot config file will refer to a partition wich no longer exists on my system.
You don't mention which Fedora version you are using. Starting with F30, grub uses BLS by default and grubby is no longer used. A system-upgrade will convert the installed system to use BLS. I don't know if it converts the existing grub.cfg or if it creates all new entries.
Le 16/06/2019 à 01:45, Samuel Sieb a écrit :
On 6/15/19 2:23 PM, François Patte wrote:
Everything was ok untill grubby replaced grub2-mkconfig: when there is a kernel update, grubby uses the disabled sda3-sda4 partitions as the / parttion in the /boot/grub2/grub.cfg file.
grubby has never replaced grub2-mkconfig. They are independent. grub2-mkconfig is never run, except maybe on the initial install. Upgrades up to F30 have always used grubby.
So what has changed in grubby? Because all my kernel updates went correctly upto, say last december. After that grubby writes a wrong grub.cfg file referring to a disabled device as the / partition of my system. And, as I said in my previous mail, this deive no more exists.
I have now destroyed these partitions but grubby still uses them and writes a faulty /boot/grub2/grub.cfg file.
Where does it find that these partitions still exist?
grubby only copies the information from the previous kernel in the grub.cfg file.
I would say that this is not right, here are the two first menu-entries in my gub.cfg after the last kernel update:
<--------------------------------------------- menuentry 'Fedora (5.1.8-200.fc29.x86_64) 29 (Twenty Nine)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-5.0.19-200.fc29.x86_64-advanced-98c1a7d2-d497-44b1-b48d-78544fe08c79' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod part_msdos insmod diskfilter insmod mdraid09 insmod ext2 set root='mduuid/eb8b5efe5a8f9369e940a0f383d63ad1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint='mduuid/eb8b5efe5a8f9369e940a0f383d63ad1' 595e9373-6e40-425b-8041-07aca776a98b else search --no-floppy --fs-uuid --set=root 595e9373-6e40-425b-8041-07aca776a98b fi linux /vmlinuz-5.1.8-200.fc29.x86_64 root=/dev/mapper/fedora-racine ro rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 rd.md.uuid=95c11201:1509169a:860a8b84:c49f865c rd.lvm.lv=debian/deb-racine rd.md.uuid=eb8b5efe:5a8f9369:e940a0f3:83d63ad1 rd.md.uuid=4a28174a:f38b4938:233f85f7:6ce585a8 rd.lvm.lv=systeme/swap quiet LANG=fr_FR.UTF-8 initrd /initramfs-5.1.8-200.fc29.x86_64.img } menuentry 'Fedora (5.0.19-200.fc29.x86_64) 29 (Twenty Nine)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-5.0.19-200.fc29.x86_64-advanced-98c1a7d2-d497-44b1-b48d-78544fe08c79' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod part_msdos insmod diskfilter insmod mdraid09 insmod ext2 set root='mduuid/eb8b5efe5a8f9369e940a0f383d63ad1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint='mduuid/eb8b5efe5a8f9369e940a0f383d63ad1' 595e9373-6e40-425b-8041-07aca776a98b else search --no-floppy --fs-uuid --set=root 595e9373-6e40-425b-8041-07aca776a98b fi linux /vmlinuz-5.0.19-200.fc29.x86_64 root=/dev/mapper/debian-deb--racine ro rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 rd.md.uuid=95c11201:1509169a:860a8b84:c49f865c rd.lvm.lv=debian/deb-racine rd.md.uuid=eb8b5efe:5a8f9369:e940a0f3:83d63ad1 rd.md.uuid=4a28174a:f38b4938:233f85f7:6ce585a8 rd.lvm.lv=systeme/swap quiet initrd /initramfs-5.0.19-200.fc29.x86_64.img } <--------------------------------------
As you can see the root partition for kernel 5.1.8 is root=/dev/mapper/fedora-racine while for kernel 5.0.19 it is: root=/dev/mapper/debian-deb--racine
Running manualy grub2-mkconfig corrects this mistake.
Moreover /dev/mapper/fedora-racine does not exist:
ls -l /dev/mapper: lrwxrwxrwx. 1 root root 7 16 juin 10:02 annexes-data -> ../dm-4 lrwxrwxrwx. 1 root root 7 16 juin 10:02 annexes-sauvegardes -> ../dm-5 crw-------. 1 root root 10, 236 16 juin 10:02 control lrwxrwxrwx. 1 root root 7 16 juin 10:02 data-home -> ../dm-7 lrwxrwxrwx. 1 root root 7 16 juin 10:02 debian-deb--opt -> ../dm-6 lrwxrwxrwx. 1 root root 7 16 juin 10:02 debian-deb--racine -> ../dm-0 lrwxrwxrwx. 1 root root 7 16 juin 10:02 systeme-chiffre -> ../dm-3 lrwxrwxrwx. 1 root root 7 16 juin 10:02 systeme-swap -> ../dm-1 lrwxrwxrwx. 1 root root 7 16 juin 10:02 systeme-var -> ../dm-2
I can't upgrade my system now because I fear that the boot config file will refer to a partition wich no longer exists on my system.
You don't mention which Fedora version you are using.
f29 and I want to upgrade to f30 using dnf system upgrade but I want to solve this mystery before because I fear to get an unbootable system after upgrade.
Starting with F30, grub uses BLS by default
I don't know BLS is....
Thank you for any help.
On Sat, 15 Jun 2019 23:23:36 +0200 François Patte francois.patte@mi.parisdescartes.fr wrote:
I have now destroyed these partitions but grubby still uses them and writes a faulty /boot/grub2/grub.cfg file.
Where does it find that these partitions still exist?
Posted by Tom Horsley, from another thread. """ No doubt the "default" boot is set in the grub environment file. Investigate the grub2-editenv tool to list and edit the environment. Here's what "list" shows for me:
zooty> sudo grub2-editenv - list kernelopts=root=UUID=fb156e65-9621-4242-b334-0994a1301b04 ro selinux=0 audit=0 net.ifnames=0 biosdevname=0 saved_entry=gnulinux-5.0.9-301.fc30.x86_64-advanced-fb156e65-9621-4242-b334-0994a1301b04 menu_auto_hide=0 boot_success=1 boot_indeterminate=0
That saved_entry is probably the one it is stuck on. """
Maybe it points you to the problem.
Le 16/06/2019 à 19:17, stan via users a écrit :
On Sat, 15 Jun 2019 23:23:36 +0200 François Patte francois.patte@mi.parisdescartes.fr wrote:
I have now destroyed these partitions but grubby still uses them and writes a faulty /boot/grub2/grub.cfg file.
Where does it find that these partitions still exist?
Posted by Tom Horsley, from another thread. """ No doubt the "default" boot is set in the grub environment file. Investigate the grub2-editenv tool to list and edit the environment. Here's what "list" shows for me:
zooty> sudo grub2-editenv - list
So: ]# grub2-editenv - list
saved_entry=Fedora (4.10.8-200.fc25.x86_64) 25 (Twenty Five) boot_success=1 boot_indeterminate=1
What does it mean?
f25 is over since years now, why this reference?
I recall that my problem occurs since f29 and when I upgraded to f29 kernel updates had not this problem, it occurs only since a few months.
On Mon, 17 Jun 2019 07:34:43 +0200 François Patte francois.patte@mi.parisdescartes.fr wrote:
]# grub2-editenv - list
saved_entry=Fedora (4.10.8-200.fc25.x86_64) 25 (Twenty Five) boot_success=1 boot_indeterminate=1
What does it mean?
I think it means that your last booted kernel is not saved.
f25 is over since years now, why this reference?
Because of a setting in /etc/default/grub.
What's in there?
I recall that my problem occurs since f29 and when I upgraded to f29 kernel updates had not this problem, it occurs only since a few months.
Can't speak to this, I wonder if it was kernel version shift from 5.0 to 5.1, but don't know.
Try adding this to /etc/default/grub GRUB_DEFAULT=saved GRUB_SAVEDEFAULT=true And of course removing any other directives like this.
Run grub2-mkconfig -o grub.cfg in /boot/grub2 to generate a new grub.cfg with the changes. Then reboot and select the kernel you want to run.
Then edit /etc/default/grub and remove GRUB_SAVEDEFAULT=true
Then run again grub2-mkconfig -o grub.cfg in /boot/grub2 to generate a new grub.cfg with the change.
From now on, you should default to the kernel you selected. I think. I haven't had this problem, so I can't be sure.
On Mon, 17 Jun 2019 07:34:43 +0200 François Patte francois.patte@mi.parisdescartes.fr wrote:
I recall that my problem occurs since f29 and when I upgraded to f29 kernel updates had not this problem, it occurs only since a few months.
There is some more information about setting the default here.
Le 15/06/2019 à 23:23, François Patte a écrit :
Bonjour,
I sent several messages about kernel updates and grubby.
Once upon a time I made 4 partitions on a ssd drive where the system is installed. I use raid1+lvm
on sda1 and sdb1 I put the a /boot partition (raid1) for a debian install on sda3 and sdb3 I also put /boot partition (raid1) for a fedora install
on sda2 and sdb2 I put a / partition (raid1+lvm) with label "debian-racine" (at that time I had a debian install) on sda4 and sdb4 I put a / partition (raid1+lvm) with label "fedora-racine" for a fedora install.
So I had two linux installs: one was debian the other was fedora.
I abandonned debian and used the debian partition to install a fedora version. I wanted to keep two different partitions: on one partition fedora-n on the other fedora-(n+1).
Then appears the "dnf system upgrade" and I disabled the my sda3-sda4 partitions and only used sda1-sda2 partitions (with label "debian-racine") for my system.
Everything was ok untill grubby replaced grub2-mkconfig: when there is a kernel update, grubby uses the disabled sda3-sda4 partitions as the / parttion in the /boot/grub2/grub.cfg file.
I have now destroyed these partitions but grubby still uses them and writes a faulty /boot/grub2/grub.cfg file.
Where does it find that these partitions still exist?
I found the culprit: fstab: this line in my fstab: /dev/mapper/fedora-racine / ext4 noatime,discard,errors=remount-ro 1 1
This file was created by Anaconda 2 years ago... At that time, maybe the / partition was that one. I don't know why it has not been modified by a next install.
So we can say that the kernel update scriptlet takes some informtion from the fstab and not only from the current grub.cfg.....
Mysteries remain.
Mystery 1: Why the /dev/mapper/fedora-racine was not mounted in spite of the fact that it was mentionned in the fstab?
Mystery 2: Why the /dev/mapper/debian-deb--racine (which is the right / partition) was mounted in spite of the fact that it was not mentionned in the fstab? (Only in the grub.cfg after running grub2-mkconfig).
Mystery 3: Why grub2-mkconfig has found the right / partition and the kernel update scriptlet did not.
Mystery 4: When I discovered this line in the fstab, I commented it and reboot. The result was that the / partition (/dev/mapper/debian-deb--racine) was mounted read-only. And when I added this line: /dev/mapper/debian-deb--racine / ext4 noatime,discard,errors=remount-ro 1 1 the / partition was mounted read-write.
Thank you for any lights...
On Sun, Jun 16, 2019 at 2:34 AM François Patte francois.patte@mi.parisdescartes.fr wrote:
Running manualy grub2-mkconfig corrects this mistake.
Fedora 29 grubby has not changed since August 2018 according to koji https://koji.fedoraproject.org/koji/packageinfo?packageID=8562
grubby-8.40-18.fc29
It's a bit misleading with fc30 and fc31 versions of the grubby package, because it looks like it's being maintained but the real grubby binary is pretty much on life support in Fedora. What you'll find in the newer versions of the package is grubby is a wrapper script for managing the new bootloaderspec method of configuration files, but with a command line tool that grubby users are familiar with. The real grubby is actually grubby-deprecated.
Anyway, my advice
1. F29, get in the habit of running grub2-mkconfig after any kernel update to make sure the grub.cfg is not malformed 2. F29, convert to the new bootloaderspec using grub2-switch-to-blscfg script and now you no longer need to run grub2-mkconfig and you don't need to worry about grubby anymore, the bootloader config files in /boot/loader/entries are created by kernel package scripts. 3. Upgrade to F30
Before you do 2. or 3. you should run grub2-mkconfig to make sure the grub.cfg is not malformed, prior to be converted to the bls way. https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault
I mean, you could also try to file a bug against grubby and maybe it'll get fixed? *shrug*
On Sat, Jun 15, 2019 at 3:24 PM François Patte francois.patte@mi.parisdescartes.fr wrote:
parttion in the /boot/grub2/grub.cfg file
That location tells me this is BIOS GRUB (not UEFI GRUB). I also suggest making sure the pre-boot GRUB binaries are up to date before you convert to BLS or upgrade to Fedora 30, by using 'grub2-install /dev/' pointed at the proper boot device (whole block device, not partition).
If you're multibooting another distribution, only you can know if there's a risk of stepping on the existing bootloader.
The reason is particularly old pre-boot GRUB binaries can run into trouble with BLS. It's sufficient to run 'grub2-install' from Fedora 29 to avoid that trouble.
-
Chris Murphy -
François Patte -
Samuel Sieb -
stan