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. 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. 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@xxxxxxxxxxxxxxxxxxxxxxx
