3:49 a.m.
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.
--
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
http://www.math-info.univ-paris5.fr/~patte
10:20 a.m.
On Sun, 26 May 2019 10:49:00 +0200
François Patte <francois.patte(a)mi.parisdescartes.fr> 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.
12:04 p.m.
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 <francois.patte(a)mi.parisdescartes.fr> 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 -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
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/users@lists.fedoraproject.o...
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]$
12:14 a.m.
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 <francois.patte(a)mi.parisdescartes.fr> 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 -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> 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...
The browser answer is: Not found
Things that may be relevant:
1. Fresh install not an upgrade
I update my f29 system
2. No separate /boot partition
I have a separate boot partition
3. EFI boot of install media - hence EFI installation
My install is not an EFI one
4. No logical volumes anywhere on the SSD
I use lvm
5. 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...
--
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
http://www.math-info.univ-paris5.fr/~patte
1:08 a.m.
On Mon, 27 May 2019 07:14:03 +0200
François Patte <francois.patte(a)mi.parisdescartes.fr> 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/users@lists.fedoraproject.o...
That should be
https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault
> 5. 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.
1:32 a.m.
On 5/26/19 11:08 PM, stan via users wrote:
On Mon, 27 May 2019 07:14:03 +0200
François Patte <francois.patte(a)mi.parisdescartes.fr> 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/users@lists.fedoraproject.o...
That should be
https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault
>> 5. 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.
2:03 a.m.
On Sun, 26 May 2019 23:32:35 -0700
Samuel Sieb <samuel(a)sieb.net> 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. :-)
11:56 p.m.
On Sun, May 26, 2019 at 11:14 PM François Patte
<francois.patte(a)mi.parisdescartes.fr> wrote:
> 5. 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
--
Chris Murphy
11:26 a.m.
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.
1788
days inactive
1790
days old
9 comments
7 participants
participants (7)
-
Berend De Schouwer -
Chris Murphy -
François Patte -
ja -
Patrick O'Callaghan -
Samuel Sieb -
stan