On Thu, May 9, 2019 at 12:00 AM Panu Matilainen <pmatilai@xxxxxxxxxx> wrote: > > On 5/9/19 12:55 AM, Chris Murphy wrote: > > > > > > On Wed, May 8, 2019, 4:50 AM Panu Matilainen <pmatilai@xxxxxxxxxx > > <mailto:pmatilai@xxxxxxxxxx>> wrote: > > > > > > > > Nicolas' point is that the rescue boot entry only works in a limited > > number of scenarios. > > > > > > I'm not sure which of three 'rescue' options is being discussed. > > > > grub rescue appears when normal.mod can't be loaded, and means the menu > > can't be displayed. This thread's bug results in this rescue. > > Okay, I've no idea what that is, unless it simply means the grub prompt. Oops, I confused myself. This thread's bug doesn't result in a grub rescue prompt, but just the usual grub prompt. > > > Since circa Fedora 19, there is a GRUB menu entry 'Rescue' option which > > boots a "no host only" initramfs. If you see the option, you don't have > > the bug under discussion. > > AIUI this was the rescue mode that was being "critisized" here, in that > it only works in limited scenarios. I for one have never found any use > for it, but of course that doesn't mean a thing, it's nice that it's there. The idea is with a 'no host only' initramfs, it should be able to boot no matter what hardware is connected. In the case where hardware changes, add or replace, the default "host only" initramfs might not contain a necessary kernel module to boot the system, and boot will fail. The rescue boot option does nothing else, no fsck, no additional debuging - it's just using a giant initramfs with a bunch of modules baked into it. > > That would be super tedious to track down. And interestingly, would > > potentially be masked by always updating the bootloader between major > > upgrades (makes bootloader a moving Target). But if no one ever tracks > > it down, which includes the even more tedious requirement of localy > > building GRUB from source and reproducing the bug (because Fedora's GRUB > > is so substantially modified from upstream that upstream will always > > reject Fedora bugs), it won't get fixed. > > Sure. I don't know what the rebooting loop was, but clearly it was > related to "this bug" because the bootloader has been working fine for > years until it got completely broken by the upgrade to F30. I've never > seen anything like that, ever. And certainly it was affected by "this > bug" too because of the ages old boot loader. > > I guess we'll never find out because I wouldn't know the exact steps to > reproduce it even if I wanted to. Yeah I'm not sure. It may be that the conditions for this bug can lead to a different bug. Frankly I'm surprised we haven't run into a lot more bootloader related problems, as stale as it can become on BIOS systems. > > To me, rescue image means install media with Rescue boot option i.e. > > anaconda inst.rescue. > > Indeed, and without it I would've been lost on a few occasions, > including this. I dont think there's an actual disagreement anywhere in > here, just a side-track related to the awareness of thees various rescue > modes and their relative powers of rescue, or lack of thereof. Understood. My take away from the conversation is: The Common Bugs steps to avoid and get out from under the bug, and various rescue methods available, are all appropriate and necessary, and all parties did the best they could under the circumstances. But they are inadequate ways of addressing BIOS GRUB staleness. Major version upgrades need to handle this case in the best interest of most users, even if it means inconveniencing some multibooters. -- 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
