Bug 1695701 - f29->f30 lost fedora entries from grub.cfg
Summary: f29->f30 lost fedora entries from grub.cfg
Keywords:
Status: CLOSED DUPLICATE of bug 1652806
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 30
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-03 15:50 UTC by Dr. David Alan Gilbert
Modified: 2019-04-28 21:27 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-15 16:28:51 UTC
Type: Bug


Attachments (Terms of Use)
grubenv (1.00 KB, text/plain)
2019-04-03 16:51 UTC, Dr. David Alan Gilbert
no flags Details
grub.cfg.bad (24.49 KB, text/plain)
2019-04-03 16:52 UTC, Dr. David Alan Gilbert
no flags Details
The old (working) grub.cfg (26.05 KB, text/plain)
2019-04-03 16:52 UTC, Dr. David Alan Gilbert
no flags Details
A tar of /boot/loader/entries (501 bytes, application/gzip)
2019-04-03 16:53 UTC, Dr. David Alan Gilbert
no flags Details

Description Dr. David Alan Gilbert 2019-04-03 15:50:53 UTC
Description of problem:
Upgrading my desktop from f29->f30 I find it's not got any fedora entries in it's grub any more.
I recovered by copying the grub.cfg.rpmsave back in.
Rerunnng grub2-mkconfig still doesn't find them; the 10_linux section has no boot entries.

Version-Release number of selected component (if applicable):
grub2-pc-modules-2.02-75.fc30.noarch
grub2-tools-minimal-2.02-75.fc30.x86_64
grubby-8.40-30.fc30.x86_64
grub2-tools-extra-2.02-75.fc30.x86_64
grub2-tools-2.02-75.fc30.x86_64
grub2-tools-efi-2.02-75.fc30.x86_64
grub2-pc-2.02-75.fc30.x86_64
grub2-common-2.02-75.fc30.noarch


How reproducible:
Rerunning grub2-mkconfig still isn't finding them.

Steps to Reproduce:
1. I used dnf to do an upgrade; the machine was originally installed on f20 and has been upgraded through lots of versions
2.
3.

Actual results:
No fedora entries in the boot menu (It did find my other disk and add the other entries in os-prober)

Expected results:
Happy fedora entries

Additional info:

NAME                 MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                    8:0    0 931.5G  0 disk 
├─sda1                 8:1    0  95.4G  0 part /discs/spinnyroot
├─sda2                 8:2    0   250M  0 part 
└─sda3                 8:3    0 834.2G  0 part 
  ├─main-crypt       253:0    0    10G  0 lvm  
  ├─main-more        253:1    0   400G  0 lvm  /discs/more
  ├─main-Quantal     253:2    0     6G  0 lvm  
  ├─main-Precise2    253:3    0     6G  0 lvm  
  ├─main-spinnyswap  253:5    0    24G  0 lvm  [SWAP]
  ├─main-ubuntu16.04 253:6    0    30G  0 lvm  
  ├─main-debian9     253:7    0    40G  0 lvm  
  ├─main-fedora28a   253:8    0    40G  0 lvm  
  └─main-archlinux   253:9    0    60G  0 lvm  
sdb                    8:16   0 111.8G  0 disk 
├─sdb1                 8:17   0   250M  0 part /boot
└─sdb2                 8:18   0 111.6G  0 part 
  └─main-root        253:4    0 110.8G  0 lvm  /
sdc                    8:32   1  29.1G  0 disk 
└─sdc1                 8:33   1  29.1G  0 part 
sr0                   11:0    1  1024M  0 rom  

The fedora root is the main-root on lvm.
[root@major grub2]# grub2-mkconfig >/dev/null
Generating grub configuration file ...
Found Ubuntu quantal (development branch) (12.10) on /dev/sda1
done
[root@major grub2]# 

### BEGIN /etc/grub.d/10_linux ###
insmod part_msdos
insmod ext2
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1  abebee4b-b709-4e63-aa2a-41530f785544
else
  search --no-floppy --fs-uuid --set=root abebee4b-b709-4e63-aa2a-41530f785544
fi
insmod part_msdos
insmod ext2
set boot='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=boot --hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1  abebee4b-b709-4e63-aa2a-41530f785544
else
  search --no-floppy --fs-uuid --set=boot abebee4b-b709-4e63-aa2a-41530f785544
fi

# This section was generated by a script. Do not modify the generated file - all changes
# will be lost the next time file is regenerated. Instead edit the BootLoaderSpec files.
#
# The blscfg command parses the BootLoaderSpec files stored in /boot/loader/entries and
# populates the boot menu. Please refer to the Boot Loader Specification documentation
# for the files format: https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/.

set default_kernelopts="root=/dev/mapper/main-root ro nointremap vconsole.font=latarcyrheb-sun16  "

insmod blscfg
blscfg
if [ -s $prefix/grubenv ]; then
  load_env
fi
### END /etc/grub.d/10_linux ###

Comment 1 Javier Martinez Canillas 2019-04-03 16:01:39 UTC
Hi,

Can you please provide the following files:

- /boot/grub2/grub.cfg
- /boot/grub2/grubenv
- /boot/loader/entries/*.conf

And also the output of blkid.

Comment 2 Dr. David Alan Gilbert 2019-04-03 16:51:53 UTC
Created attachment 1551437 [details]
grubenv

Comment 3 Dr. David Alan Gilbert 2019-04-03 16:52:21 UTC
Created attachment 1551438 [details]
grub.cfg.bad

The grub.cfg generated by the upgrade

Comment 4 Dr. David Alan Gilbert 2019-04-03 16:52:44 UTC
Created attachment 1551440 [details]
The old (working) grub.cfg

Comment 5 Dr. David Alan Gilbert 2019-04-03 16:53:48 UTC
Created attachment 1551441 [details]
A tar of /boot/loader/entries

Comment 6 Dr. David Alan Gilbert 2019-04-03 16:57:40 UTC
[root@major togo]# blkid
/dev/sda1: LABEL="spinnyroot" UUID="d8314979-8ace-401c-88df-728ad6b89cb5" TYPE="ext4" PARTUUID="000caf9a-01"
/dev/sda2: LABEL="fedoraboot" UUID="6374398e-cc8d-4230-b423-3dc043115abf" TYPE="ext4" PTTYPE="dos" PARTUUID="000caf9a-02"
/dev/sda3: UUID="oFAwO8-WRQK-Qhse-VPuS-b6RW-nP2N-aJDNCy" TYPE="LVM2_member" PARTUUID="000caf9a-03"
/dev/sdb1: LABEL="ssd-boot" UUID="abebee4b-b709-4e63-aa2a-41530f785544" TYPE="ext4" PARTUUID="000435d5-01"
/dev/sdb2: UUID="FGc0rb-g2Bm-tl04-kz1P-u5qq-tGwP-wHguZe" TYPE="LVM2_member" PARTUUID="000435d5-02"
/dev/sdc1: LABEL="Music30GBa" UUID="4cff6531-3aff-401e-bbc6-bf3f2540e3d9" TYPE="ext4"
/dev/mapper/main-crypt: UUID="0af33ca5-b8f5-4f9b-9431-371a43459e7b" TYPE="crypto_LUKS"
/dev/mapper/main-more: LABEL="more" UUID="1bc920db-d852-493a-9959-89006e4b58f3" TYPE="ext4"
/dev/mapper/main-Quantal: PTUUID="00026849" PTTYPE="dos"
/dev/mapper/main-Precise2: PTUUID="0009514f" PTTYPE="dos"
/dev/mapper/main-root: LABEL="fedoranative-roo" UUID="bb6a7a92-e770-4170-8d69-5a499814fdec" TYPE="ext4"
/dev/mapper/main-spinnyswap: UUID="0aa5f4f5-2560-47a6-a8d8-e56db66b1fab" TYPE="swap"
/dev/mapper/main-ubuntu16.04: PTUUID="62ab4c6b" PTTYPE="dos"
/dev/mapper/main-debian9: PTUUID="80b0af64" PTTYPE="dos"
/dev/mapper/main-fedora28a: PTUUID="f1d122ab" PTTYPE="dos"
/dev/mapper/main-archlinux: PTUUID="03fe3215" PTTYPE="dos"

The host has two disks:
  a) /dev/sda a spinny hard drive
  b) /dev/sdb an ssd that was added later (but a few years/upgrades ago!)

A lot of the /dev/mapper/main-* entries are images for VMs, except for crypt,more,root,spinnyswap.

Comment 7 Javier Martinez Canillas 2019-04-03 17:11:01 UTC
Thanks for the information. I don't see anything wrong with the files.

You could try loading the BLS files from the GRUB prompt, i.e:

grub> blscfg (hd1,msdos1)/loader/entries

or an individual entry with:

grub> blscfg (hd1,msdos1)/loader/entries/7725dfc225d14958a625ddaaaea5962b-5.0.5-300.fc30.x86_64.conf

And also getting debug output with

grub> set debug=blscfg

Before executing these commands.

Finally, you can try to update your GRUB core with:

$ grub2-install /dev/sdb (if the GRUB first and second stages are installed there).

Comment 8 Dr. David Alan Gilbert 2019-04-03 17:34:00 UTC
(In reply to Javier Martinez Canillas from comment #7)
> Thanks for the information. I don't see anything wrong with the files.
> 
> You could try loading the BLS files from the GRUB prompt, i.e:
> 
> grub> blscfg (hd1,msdos1)/loader/entries

ok, that's actually (hd0,msdos1) for me; and that gives a 'can't find command `blscfg`

> or an individual entry with:
> 
> grub> blscfg
> (hd1,msdos1)/loader/entries/7725dfc225d14958a625ddaaaea5962b-5.0.5-300.fc30.
> x86_64.conf
> 
> And also getting debug output with
> 
> grub> set debug=blscfg
> 
> Before executing these commands.
> 
> Finally, you can try to update your GRUB core with:
> 
> $ grub2-install /dev/sdb (if the GRUB first and second stages are installed
> there).

That fixes the problem; having done that, then both the blscfg command and switching to the generated
grub.cfg work fine.

So it looks like something somewhere forgot to upgrade grub (or updated the wrong disk??)

Comment 9 Jussi Eloranta 2019-04-04 19:32:17 UTC
I ended up in the same situation with my desktop (bios based system). No entries in the grub.cfg. By copying the rpmsave made the system bootable again. My system has only one hard drive.

Comment 10 Javier Martinez Canillas 2019-04-05 08:38:57 UTC
(In reply to Dr. David Alan Gilbert from comment #8)
> (In reply to Javier Martinez Canillas from comment #7)
> > Thanks for the information. I don't see anything wrong with the files.
> > 
> > You could try loading the BLS files from the GRUB prompt, i.e:
> > 
> > grub> blscfg (hd1,msdos1)/loader/entries
> 
> ok, that's actually (hd0,msdos1) for me; and that gives a 'can't find
> command `blscfg`
>


Interesting, so the blscfg command should had been copied to the /boot/grub2/i386-pc directory. Is /dev/sdb1 mounted in /boot ?
 
> > or an individual entry with:
> > 
> > grub> blscfg
> > (hd1,msdos1)/loader/entries/7725dfc225d14958a625ddaaaea5962b-5.0.5-300.fc30.
> > x86_64.conf
> > 
> > And also getting debug output with
> > 
> > grub> set debug=blscfg
> > 
> > Before executing these commands.
> > 
> > Finally, you can try to update your GRUB core with:
> > 
> > $ grub2-install /dev/sdb (if the GRUB first and second stages are installed
> > there).
> 
> That fixes the problem; having done that, then both the blscfg command and
> switching to the generated
> grub.cfg work fine.
> 
> So it looks like something somewhere forgot to upgrade grub (or updated the
> wrong disk??)

Yes, it seems that the blscfg module was not correctly copied to /boot/grub2/i386-pc for GRUB core to find it.

Comment 11 Javier Martinez Canillas 2019-04-05 08:41:43 UTC
(In reply to Jussi Eloranta from comment #9)
> I ended up in the same situation with my desktop (bios based system). No
> entries in the grub.cfg. By copying the rpmsave made the system bootable
> again. My system has only one hard drive.

Can you please provide the files mentioned in Comment 1 (if you already replaced the grub.cfg, you can generate again the same that was generated on upgrade using grub2-mkconfig -o grub.cfg).

Comment 12 Jussi Eloranta 2019-04-05 20:18:58 UTC
I regenerated grub.cfg with grub2-mkconfig and the system now boots OK. Unfortunately, I don't have any more the faulty one that was created during upgrade :-(

Comment 13 Dr. David Alan Gilbert 2019-04-06 23:35:05 UTC
(In reply to Javier Martinez Canillas from comment #10)
> (In reply to Dr. David Alan Gilbert from comment #8)
> > (In reply to Javier Martinez Canillas from comment #7)
> > > Thanks for the information. I don't see anything wrong with the files.
> > > 
> > > You could try loading the BLS files from the GRUB prompt, i.e:
> > > 
> > > grub> blscfg (hd1,msdos1)/loader/entries
> > 
> > ok, that's actually (hd0,msdos1) for me; and that gives a 'can't find
> > command `blscfg`
> >
> 
> 
> Interesting, so the blscfg command should had been copied to the
> /boot/grub2/i386-pc directory. Is /dev/sdb1 mounted in /boot ?

Yes it is:

[dg@major ~]$ df
....
/dev/mapper/main-root 114256488  75166064  33915604  69% /
tmpfs                   4077972      1604   4076368   1% /tmp
/dev/sdb1                243823    190472     36455  84% /boot
...

> > > or an individual entry with:
> > > 
> > > grub> blscfg
> > > (hd1,msdos1)/loader/entries/7725dfc225d14958a625ddaaaea5962b-5.0.5-300.fc30.
> > > x86_64.conf
> > > 
> > > And also getting debug output with
> > > 
> > > grub> set debug=blscfg
> > > 
> > > Before executing these commands.
> > > 
> > > Finally, you can try to update your GRUB core with:
> > > 
> > > $ grub2-install /dev/sdb (if the GRUB first and second stages are installed
> > > there).
> > 
> > That fixes the problem; having done that, then both the blscfg command and
> > switching to the generated
> > grub.cfg work fine.
> > 
> > So it looks like something somewhere forgot to upgrade grub (or updated the
> > wrong disk??)
> 
> Yes, it seems that the blscfg module was not correctly copied to
> /boot/grub2/i386-pc for GRUB core to find it.

What was supposed to ensure that it got copied? Something in the f29->f30 upgrade? I've got a journalctl
log of the upgrade (f29-f30upgrade.log )

Comment 14 Javier Martinez Canillas 2019-04-08 07:42:30 UTC
(In reply to Dr. David Alan Gilbert from comment #13)
> (In reply to Javier Martinez Canillas from comment #10)

[snip]

> > > 
> > > So it looks like something somewhere forgot to upgrade grub (or updated the
> > > wrong disk??)
> > 
> > Yes, it seems that the blscfg module was not correctly copied to
> > /boot/grub2/i386-pc for GRUB core to find it.
> 
> What was supposed to ensure that it got copied? Something in the f29->f30
> upgrade? I've got a journalctl
> log of the upgrade (f29-f30upgrade.log )

On grub2 package upgrade, the grub2-switch-to-blscfg script is executed and this copies the blscfg module from /usr/lib/grub/i386-pc/blscfg.mod to the /boot/grub2/i386-pc/ directory.

Comment 15 Adrian Reber 2019-04-08 09:50:17 UTC
Upgrading from F29 to F30 my system also was switched to BLS (GRUB_ENABLE_BLSCFG=true). It also made my system unbootable as grub.cfg did not have any entries besides 'System setup'.

Comment 16 Javier Martinez Canillas 2019-04-08 09:52:27 UTC
(In reply to Adrian Reber from comment #15)
> Upgrading from F29 to F30 my system also was switched to BLS
> (GRUB_ENABLE_BLSCFG=true). It also made my system unbootable as grub.cfg did
> not have any entries besides 'System setup'.

I assume your system was also a legacy BIOS installation like the original issue reported here and also that the blscfg.mod was not present in /boot/grub2/i386-pc ?

Comment 17 Adrian Reber 2019-04-08 12:22:07 UTC
(In reply to Javier Martinez Canillas from comment #16)
> (In reply to Adrian Reber from comment #15)
> > Upgrading from F29 to F30 my system also was switched to BLS
> > (GRUB_ENABLE_BLSCFG=true). It also made my system unbootable as grub.cfg did
> > not have any entries besides 'System setup'.
> 
> I assume your system was also a legacy BIOS installation like the original
> issue reported here and also that the blscfg.mod was not present in
> /boot/grub2/i386-pc ?

Correct. It was a BIOS installation and then I switched to EFI at some point. I used to have /boot/grub2/x86_64-efi which includes a blscfg.mod, but right now I have nothing in /boot/grub2, except grubenv (link to ../efi/EFI/fedora/grubenv).

Hard to tell how the original /boot partition looked like, because trying to fix the non-booting system I change (too) many things.

Comment 18 Dr. David Alan Gilbert 2019-04-08 14:42:43 UTC
Is it possible that an old grub install is incompatible with the newer
blscfg ?
I tried booting an old f20 vm, and copied in the new blscfg:

grub> insmod blscfg
grub> blscfg
error: ../../grub-core/commands/blscfg.c.
grub> 

now I hadn't done any of the other setup etc - but seems worth the question?

Comment 19 Javier Martinez Canillas 2019-04-08 21:30:24 UTC
(In reply to Dr. David Alan Gilbert from comment #18)
> Is it possible that an old grub install is incompatible with the newer
> blscfg ?

That may be possible indeed.

> I tried booting an old f20 vm, and copied in the new blscfg:
> 
> grub> insmod blscfg
> grub> blscfg
> error: ../../grub-core/commands/blscfg.c.
> grub> 
> 
> now I hadn't done any of the other setup etc - but seems worth the question?

Yes, thanks about that. Could you please try to run the blscfg command with:

grub> set debug=blscfg
grub> insmod blscfg
grub> blscfg

That should give us more information about why the blscfg command is failing with the old GRUB.

Comment 20 Dr. David Alan Gilbert 2019-04-09 09:27:51 UTC
(In reply to Javier Martinez Canillas from comment #19)
> (In reply to Dr. David Alan Gilbert from comment #18)
> > Is it possible that an old grub install is incompatible with the newer
> > blscfg ?
> 
> That may be possible indeed.
> 
> > I tried booting an old f20 vm, and copied in the new blscfg:
> > 
> > grub> insmod blscfg
> > grub> blscfg
> > error: ../../grub-core/commands/blscfg.c.
> > grub> 
> > 
> > now I hadn't done any of the other setup etc - but seems worth the question?
> 
> Yes, thanks about that. Could you please try to run the blscfg command with:
> 
> grub> set debug=blscfg
> grub> insmod blscfg
> grub> blscfg
> 
> That should give us more information about why the blscfg command is failing
> with the old GRUB.

Doesn't look like it wants to cooperate:
grub> set debug=blscfg
grub> insmod blscfg
commands/blscfg.c:1080: grub_mod_init got here
grub> blscfg
error: ../../grub-core/commands/blscfg.c.
grub>

Comment 21 Javier Martinez Canillas 2019-04-09 09:31:22 UTC
(In reply to Dr. David Alan Gilbert from comment #20)
> (In reply to Javier Martinez Canillas from comment #19)
> > (In reply to Dr. David Alan Gilbert from comment #18)
> > > Is it possible that an old grub install is incompatible with the newer
> > > blscfg ?
> > 
> > That may be possible indeed.
> > 
> > > I tried booting an old f20 vm, and copied in the new blscfg:
> > > 
> > > grub> insmod blscfg
> > > grub> blscfg
> > > error: ../../grub-core/commands/blscfg.c.
> > > grub> 
> > > 
> > > now I hadn't done any of the other setup etc - but seems worth the question?
> > 
> > Yes, thanks about that. Could you please try to run the blscfg command with:
> > 
> > grub> set debug=blscfg
> > grub> insmod blscfg
> > grub> blscfg
> > 
> > That should give us more information about why the blscfg command is failing
> > with the old GRUB.
> 
> Doesn't look like it wants to cooperate:
> grub> set debug=blscfg
> grub> insmod blscfg
> commands/blscfg.c:1080: grub_mod_init got here
> grub> blscfg
> error: ../../grub-core/commands/blscfg.c.
> grub>

Ok, thanks. I'll try to install a F20 an figure out what's wrong here.

In the meantime you can do a grub2-install on that machine too to make sure that the GRUB core is also updated.

Comment 22 sixpack13 2019-04-11 21:35:52 UTC
run in this sort of bug yesterday (NON-UEFI box). 

Problem: 
boot menue doesn't get updated anymore after grub2-mkconfig -o /boot/grub2/grub.cfg or even the error free kernel update from 5.0.6 to 5.0.7.

boot menue only showed 5.0.6 and no 5.0.7 !
- crtl-e'ed the boot menue and exchanged 5.0.6 with 5.0.7 box booted without errors -


Problem is now fixed with "cp /usr/lib/grub/i386-pc/blscfg.mod /boot/grub2/i386-pc/blscfg.mod" and a following grub2-mkconfig as you mentioned.


looking in /boot/grub2/i386-pc/ turns out that blscfg.mod and all other files still remaining from F29 (install date 09.02.2019).
A bugfree upgrade to F30 was last week or so  !


Question: 
aren't the files under /boot/grub2/i386-pc/ get updated/upgraded during upgrade F29 => F30 even if /usr/lib/grub/i386-pc/blscfg.mod (date 28.03.2019) and /boot/grub2/i386-pc/blscfg.mod differ  ?


your comment in #14 mentions this, but it's not the case: it seems /boot/grub2/i386-pc is complete untouched during upgrade F29 => F30


rpm -qa| grep grub:

grub2-pc-modules-2.02-75.fc30.noarch
grub2-tools-minimal-2.02-75.fc30.x86_64
grubby-8.40-30.fc30.x86_64
grub2-tools-extra-2.02-75.fc30.x86_64
grub2-tools-2.02-75.fc30.x86_64
grub2-common-2.02-75.fc30.noarch
grub2-tools-efi-2.02-75.fc30.x86_64
grub2-pc-2.02-75.fc30.x86_64

Comment 23 sixpack13 2019-04-11 23:09:31 UTC
I was to quick and too blind :-(


comment #14 is CORRECT !!!!!
my bad, sorry !!!!!


/boot/grub2/i386-pc/blscfg.mod and /boot/grub2/i386-pc/increment.mod are both from 01.04.2019.

ONLY the OTHER files in /boot/grub2/i386-pc/ are from 09.02.2019 (F29 box install date)



anyhow:

a "diff /usr/lib/grub/i386-pc/blscfg.mod /boot/grub2/i386-pc/blscfg.mod" told a differ, so I was mislead by this and didn't double-check that particular file again even while the cp command fixed my problem ...

my bad, sorry, sorry, sorry, ... !!!!!

Comment 24 Javier Martinez Canillas 2019-04-12 10:41:24 UTC

(In reply to sixpack13 from comment #23)
> I was to quick and too blind :-(
> 
>

Sorry I'm confused now about what your problem was. If the blscfg module was not copied correctly or if it was copied but didn't work. What was the Fedora release originally installed on that machine?

> comment #14 is CORRECT !!!!!
> my bad, sorry !!!!!
> 
> 

To elaborate a little bit on this, there is a postinstall scriptlet that calls to grub2-switch-to-blscfg:

# rpm -q --scripts grub2-tools
...
postinstall scriptlet (using /bin/sh):

if [ "$1" = 2 ]; then
    ! grep -q '^GRUB_ENABLE_BLSCFG=false' /etc/default/grub && \
      /sbin/grub2-switch-to-blscfg --backup-suffix=.rpmsave &>/dev/null || :
fi

And in the grub2-switch-to-blscfg script there is the following that copies the blscfg and increment GRUB modules:

if [ $arch = "x86_64" ] && [ ! -d /sys/firmware/efi ]; then
    mod_dir="i386-pc"
elif [ $arch = "ppc64" -o $arch = "ppc64le" ] && [ ! -d /sys/firmware/opal ]; then
    mod_dir="powerpc-ieee1275"
fi

if [ -n "${mod_dir}" ]; then
    for mod in blscfg increment; do
        cp ${prefix}/lib/grub/${mod_dir}/${mod}.mod ${grubdir}/$mod_dir/ || exit 1
    done
fi

So yes, only those two modules are updated on a system upgrade to F30 and all the others in /boot/grub2/i386-pc are not.

I'm not able to reproduce this issue when testing a F28 -> F30 and F29 -> F30 system upgrades. I see that the blscfg module is correctly copied and the GRUB menu is populated:

F28 -> F30

# sha256sum /usr/lib/grub/i386-pc/blscfg.mod /boot/grub2/i386-pc/blscfg.mod 
12813d88bb4d479501286e2e63d9739b52d443f70a432e05a96f589aafd41809  /usr/lib/grub/i386-pc/blscfg.mod
12813d88bb4d479501286e2e63d9739b52d443f70a432e05a96f589aafd41809  /boot/grub2/i386-pc/blscfg.mod

F29 -> F30

# sha256sum /usr/lib/grub/i386-pc/blscfg.mod /boot/grub2/i386-pc/blscfg.mod 
12813d88bb4d479501286e2e63d9739b52d443f70a432e05a96f589aafd41809  /usr/lib/grub/i386-pc/blscfg.mod
12813d88bb4d479501286e2e63d9739b52d443f70a432e05a96f589aafd41809  /boot/grub2/i386-pc/blscfg.mod

Comment 25 sixpack13 2019-04-12 13:37:03 UTC
I'm confused too.

thanks for the checksum, turns out for my backup'ed blscfg.mod (the bad one) :

53274998a486739ae35c3317829a00b1d68a96653b20c27185c64925a12fe8fd  /run/media/ron/BackupHD/BACKUP/boot/grub2/i386-pc/blscfg.mod

-rw-r--r--. 1 root root 14016  1. Apr 19:05 /run/media/ron/BackupHD/BACKUP/boot/grub2/i386-pc/blscfg.mod
-rw-r--r--. 1 root root 14012 11. Apr 19:29 /boot/grub2/i386-pc/blscfg.mod

as you can see checksum and size differ !
the second one is the copy from /usr/lib/grub/i386-pc/blscfg.mod


and to make the confusion complete: 

my box was working since updgrade (I guess it was at 01.04.2019) until yesterday with that blscfg.mod.

My problem was that the boot menue wasn't updates anymore suddenly yesterday.


I only touch files under /boot during in- and de-installing home-brewed kernels:

install goes like this: 
sudo make modules_install && sudo make install && sudo rm -rf /boot/{System.map,vmlinuz} && sudo /sbin/grub2-mkconfig -o /boot/grub2/grub.cfg


de-install goes like this: 
sudo rm -rfv /boot/loader/entries/*MY*;
sudo rm -rfv /boot/*MY* /lib/modules/*MY* && sudo grub2-mkconfig -o /boot/grub2/grub.cfg;

all my kernels are named like this "/boot/vmlinuz-5.0.7_MY", with "_MY" as appendix to distinguish from distro kernels.


that all I do under /boot !

why and how the blscfg.mod was modified and why is was working until yesterday: DON'T know !!!



wait, got a VM with F30 installed from dvd (not 100 % sure but I guess Fedora-Workstation-Live-x86_64-30_Beta-1.8.iso) 

-rw-r--r--. 1 root root 14016  5. Apr 22:13 /boot/grub2/i386-pc/blscfg.mod

53274998a486739ae35c3317829a00b1d68a96653b20c27185c64925a12fe8fd  /boot/grub2/i386-pc/blscfg.mod


size and checksum are identical what I'm having on my backup disk, the bad blscfg.mod.

VM was created for radicale tests only, NO home-brewed kernel install or the like, so I never touched something under /boot/ myself !


bad, I got a shortage of time now.
I'm willing to install a new VM from DVD and report some hours later, maybe tonight...

Comment 26 sixpack13 2019-04-12 15:34:50 UTC
a fresh VM install with 

Fedora-Workstation-Live-x86_64-30_Beta-1.8.iso

e7bfcf674cf3318202804a777a990a125f6dd8cdef20f6a10818199ca2854d0f  Fedora-Workstation-Live-x86_64-30_Beta-1.8.iso 


and un-updated shows

sha256sum /usr/lib/grub/i386-pc/blscfg.mod /boot/grub2/i386-pc/blscfg.mod

53274998a486739ae35c3317829a00b1d68a96653b20c27185c64925a12fe8fd  /usr/lib/grub/i386-pc/blscfg.mod
53274998a486739ae35c3317829a00b1d68a96653b20c27185c64925a12fe8fd  /boot/grub2/i386-pc/blscfg.mod

ll /boot/grub2/i386-pc/blscfg.mod
-rw-r--r--. 1 root root 14016 Apr 12 17:09 /boot/grub2/i386-pc/blscfg.mod


and after an dnf update:

sha256sum /usr/lib/grub/i386-pc/blscfg.mod /boot/grub2/i386-pc/blscfg.mod

12813d88bb4d479501286e2e63d9739b52d443f70a432e05a96f589aafd41809  /usr/lib/grub/i386-pc/blscfg.mod
53274998a486739ae35c3317829a00b1d68a96653b20c27185c64925a12fe8fd  /boot/grub2/i386-pc/blscfg.mod


ll /boot/grub2/i386-pc/blscfg.mod /usr/lib/grub/i386-pc/blscfg.mod
-rw-r--r--. 1 root root 14016 Apr 12 17:09 /boot/grub2/i386-pc/blscfg.mod
-rw-r--r--. 1 root root 14012 Mar 28 17:29 /usr/lib/grub/i386-pc/blscfg.mod

Comment 27 Javier Martinez Canillas 2019-04-12 15:38:58 UTC
(In reply to sixpack13 from comment #26)
> a fresh VM install with 
> 
> Fedora-Workstation-Live-x86_64-30_Beta-1.8.iso
> 
> e7bfcf674cf3318202804a777a990a125f6dd8cdef20f6a10818199ca2854d0f 
> Fedora-Workstation-Live-x86_64-30_Beta-1.8.iso 
> 
> 
> and un-updated shows
> 
> sha256sum /usr/lib/grub/i386-pc/blscfg.mod /boot/grub2/i386-pc/blscfg.mod
> 
> 53274998a486739ae35c3317829a00b1d68a96653b20c27185c64925a12fe8fd 
> /usr/lib/grub/i386-pc/blscfg.mod
> 53274998a486739ae35c3317829a00b1d68a96653b20c27185c64925a12fe8fd 
> /boot/grub2/i386-pc/blscfg.mod
> 
> ll /boot/grub2/i386-pc/blscfg.mod
> -rw-r--r--. 1 root root 14016 Apr 12 17:09 /boot/grub2/i386-pc/blscfg.mod
> 
> 
> and after an dnf update:
> 
> sha256sum /usr/lib/grub/i386-pc/blscfg.mod /boot/grub2/i386-pc/blscfg.mod
> 
> 12813d88bb4d479501286e2e63d9739b52d443f70a432e05a96f589aafd41809 
> /usr/lib/grub/i386-pc/blscfg.mod
> 53274998a486739ae35c3317829a00b1d68a96653b20c27185c64925a12fe8fd 
> /boot/grub2/i386-pc/blscfg.mod
> 
> 
> ll /boot/grub2/i386-pc/blscfg.mod /usr/lib/grub/i386-pc/blscfg.mod
> -rw-r--r--. 1 root root 14016 Apr 12 17:09 /boot/grub2/i386-pc/blscfg.mod
> -rw-r--r--. 1 root root 14012 Mar 28 17:29 /usr/lib/grub/i386-pc/blscfg.mod

Yes, that's expected because the grub2-switch-to-blscfg script is the one that copies the blscfg module when switching to a BLS configuration. But since on an F30 install, the BLS is enabled on installation the the blscfg module is not updated.

The idea is to allow older installations to have the blscfg module, not to update the module on each install (since we didn't update GRUB core and modules before).

Comment 28 sixpack13 2019-04-12 16:17:06 UTC
okay, thx for info and support !

- wondering what caused my problem -

Comment 29 Javier Martinez Canillas 2019-04-15 16:28:51 UTC

*** This bug has been marked as a duplicate of bug 1652806 ***


Note You need to log in before you can comment on or make changes to this bug.