On Saturday, May 4, 2019 1:43:56 PM EDT Chris Murphy wrote: > On Sat, May 4, 2019 at 8:55 AM Steve Grubb <sgrubb@xxxxxxxxxx> wrote: > > > > > > > On Saturday, May 4, 2019 10:29:18 AM EDT Tom Hughes wrote: > > > > > On 04/05/2019 15:24, Steve Grubb wrote: > > > > > > > I upgraded from a fully updated F29 to F30 today. Upon reboot I see > > > > > > > > > > > > > > > > grub> > > > > > > > > > > > > > > > > This seems like a pretty major bug in some component somewhere. I > > > > don't > > > > think this is a recoverable bug for most people, meaning they would > > > > have > > > > to reinstall and possibly lose everything. > > > > > > > > > > > > > > > > What component is at fault? I'd like to report this bug and have it > > > > fixed > > > > asap before other people experience a non-working system after > > > > upgrade. > > > > No idea how to recover the system at this point. It does have > > > > valuable > > > > work related code and docs on it. > > > > > > > > > > > > https://fedoraproject.org/wiki/Common_F30_bugs#blscfg-fail > > > > > > > > Thanks. It's nice that there is a writeup. But are non-technical people > > expected to do this fix? (This is a rhetorical question to all of > > fedora- > > devel.) Could dnf system-upgrade detect that it's running on a system > > that will fail? Could it warn people beforehand or even apply the grub > > upgrade first? > > > Currently, there is no way to determine who owns the bootloader on a > BIOS computer, and therefore to avoid stepping on a bootloader that we > don't own, we never update it. I would imagine it is trivial to examine the files to see that there is only one system installed and handle that case. Multi-boot is more complicated. > But that means, we never update a > bootloader we do own as well. I've never been happy with this, but I > don't know if it's an upstream problem or a distribution problem. > > I think the problem stems from a stale GRUB core.img (the part that's > embedded in either the MBR gap, or GPT's BIOSboot partition), but I'm > not 100% confident that's true. It could be a stale normal.mod which > is found in /boot/grub2/i386/ and like all other modules, these are > replaced with a 'grub2-install' invocation. But if it were true that > the problem stems only from modules, it's possible to copy them from > /usr to /boot, and script that. grub rescue> set prefix=(hd0,1)/grub2 grub rescue> set root=(hd0,1) grub rescue> insmod normal error: symbol 'grub_file_progress_hook' not found. Hmm...OK...let's try it from /usr as you said. grub rescue> set prefix=(hd0,5)/usr/lib/grub grub rescue> insmod normal error: symbol 'grub_file_progress_hook' not found. Hmm. On my main (working) system: cd /usr/lib/grub/i386-pc/ # grep grub_file_progress_hook * Binary file hfspluscomp.mod matches Binary file kernel.exec matches Binary file kernel.img matches Binary file net.mod matches Binary file ntfscomp.mod matches Binary file ntfs.mod matches Binary file progress.mod matches # readelf -s hfspluscomp.mod | grep progress 11: 00000000 0 NOTYPE GLOBAL DEFAULT UND grub_file_progress_hook # readelf -s net.mod | grep progress 17: 00000000 0 NOTYPE GLOBAL DEFAULT UND grub_file_progress_hook # readelf -s ntfscomp.mod | grep progress 11: 00000000 0 NOTYPE GLOBAL DEFAULT UND grub_file_progress_hook # readelf -s ntfs.mod | grep progress 11: 00000000 0 NOTYPE GLOBAL DEFAULT UND grub_file_progress_hook # readelf -s progress.mod | grep progress 12: 00000000 0 NOTYPE GLOBAL DEFAULT UND grub_file_progress_hook # readelf -s kernel.exec | grep progress 218: 0001cbe8 4 OBJECT GLOBAL DEFAULT 5 grub_file_progress_hook # readelf -s kernel.img | grep progress # readelf -s net.mod | grep progress 17: 00000000 0 NOTYPE GLOBAL DEFAULT UND grub_file_progress_hook It appears to be defined in kernel.exec Wonder if there is a stale kernel.exec and if so, how to get it loaded so symbols are defined. -Steve > But unfortunately I think the core.img > probably needs updating, and that core.img is distribution specific. > So if we just replace it, we could be breaking the user's other > installed distributions. > > *shrug* > > If you take the point of view that multi-boot Linux (2+ linux distros, > as contrasted to dual-boot Fedora+macOS or Fedora+Windows) is > inherently technical, it's possible we could have a policy change > whereby we update the bootloader on Fedora upgrades. That would help > the non-technical, at the expense of certainly breaking the multi-boot > case. > > > > > > Anyways...following the instruction on that page...when > > configfile /grub2/grub.cfg.rpmsave > > is run, it immediately shows me the menu and boot commences as it did. > > It > > then says: "execute the grub2-install /dev/X command (where X is the > > boot > > device, i.e sda) to update the GRUB core and the module" > > > > > > > > This is what happens: > > > > > > > > # mount | grep boot > > /dev/sda1 on /boot type ext4 (rw,relatime,seclabel) > > [root ~]# grub2-install /dev/sda1 > > Installing for i386-pc platform. > > grub2-install: warning: File system `ext2' doesn't support embedding. > > grub2-install: warning: Embedding is not possible. GRUB can only be > > installed in this setup by using blocklists. However, blocklists are > > UNRELIABLE and their use is discouraged.. > > grub2-install: error: will not proceed with blocklists. > > > It should be /dev/sda not /dev/sda1 - the advice note says /dev/sdX > where X is the boot device, not the boot device partition. So you did > it wrong. But you raise a valid point that this is obscure and > esoteric knowledge, and we're asking non-technical users to know such > things. > > Maybe the wikie entry can be updated to make this more clear. > > > -- > Chris Murphy > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxx > g _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
