Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1695701
Summary: | f29->f30 lost fedora entries from grub.cfg | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dr. David Alan Gilbert <rh> | ||||||||||
Component: | grub2 | Assignee: | Peter Jones <pjones> | ||||||||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||
Priority: | unspecified | ||||||||||||
Version: | 30 | CC: | adrian, eloranta, fmartine, goodmirek, lkundrak, pjones, sixpack13 | ||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | Unspecified | ||||||||||||
OS: | Unspecified | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2019-04-15 16:28:51 UTC | Type: | Bug | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Attachments: |
|
Description
Dr. David Alan Gilbert
2019-04-03 15:50:53 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. Created attachment 1551437 [details]
grubenv
Created attachment 1551438 [details]
grub.cfg.bad
The grub.cfg generated by the upgrade
Created attachment 1551440 [details]
The old (working) grub.cfg
Created attachment 1551441 [details]
A tar of /boot/loader/entries
[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. 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). (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??) 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. (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. (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). 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 :-( (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 ) (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. 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'. (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 ? (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. 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? (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. (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> (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. 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 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, ... !!!!! (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 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... 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 (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). okay, thx for info and support ! - wondering what caused my problem - *** This bug has been marked as a duplicate of bug 1652806 *** |