On Tue, 18 Feb 2020, Michael H. Warfield wrote: > On Tue, 2020-02-18 at 16:53 -0500, Michael H. Warfield wrote: >> On Tue, 2020-02-18 at 15:55 -0500, Michael H. Warfield wrote: >>> Hey all, >>> I have a fair number of Raspberry Pi V3 B/B+ and Raspberry Pi V2 B >>> systems running Fedora 31 (and a V4 I would like to get on Fedora - >>> still waiting). I have Fedora 31 aarch64 installed on most of the >>> V3 >>> and armv7l/armhfp on the V2 systems. Running dnf updating today, >>> updated to the 5.4.19 kernel and the update of the aarch64 images >>> seemed to hang while running the kernel-core script for over an >>> hour. Looking from another terminal and running top (running dnf >>> upgrade remotely over ssh), looks like grubby is hung burning CPU >>> time >>> and eating memory (and I have lots of cache). Couple machines >>> eventually crashed, and I killed grubby on a couple of others, and >>> the >>> dnf eventually ran to completion on the later 2. In all cases (5 - >>> aarch64 systems) I was left with totally unbootable systems. The >>> ones >>> with screens go straight to the U-Boot prompt or trying to reboot >>> over >>> and over again looking for storage and then looking at eth0 and >>> then >>> rebooting and never show the kernel selection prompt. The few >>> armv7l/armhfp systems haven't seem to have gotten that the 5.4.19 >>> upgrade yet. I've still got two booted and running aarch64 systems >>> running (haven't rebooted) and I'm going to try and roll that >>> update >>> back. >>> Any thoughts to were to go from here? Not sure what to report this >>> under in Bugzilla. > >> Looks like it's grubby that doing the damage. Leaving me something >> like this (vastly shortened, sorry for the length) in >> /boot/efi/EFI/fedora/grub.cfg : > > Trimming the following to save us all some pain... > >> -- >> set default_kernelopts="root=UUID=92567a3e-b3d2-494a-b4ec- >> ebb4687d6b40=UUID=92567a3e-b3d2-494a-b4ec-ebb4687d6b40=92567a3e-b3d2- >> -- > >> That was just a SMALL sample of the line. And it doesn't get fixed >> by >> uninstalling. > > I'm confirming this. Using another system, I manually repaired that > "set default_kernelopts=" back to what was in the original Fedora > image. Back to the original (my rpi-test system) the card immediately > booted the system up AND it had the CORRECT new system up, 5.4.19. > > So the problem is in grubby. This had to have happened in just the > last week. The update to 5.4.18 did not result in this carnage. So, > whatever happened with grubby happened recently. > > Strangely, the /boot/efi/EFI/fedora/grub.cfg file is in the aarch64 > image but not in the arm7l image. :-? > > I just gotta pry a couple of cards out of a couple of cases now. :-P > > Mike > >> Some how this does not look encouraging. >> >> -- >> [root@rpi-devel mhw]# ls -l /boot/efi/EFI/fedora/grub.cfg >> -rwx------. 1 root root 841768 Feb 18 10:55 >> /boot/efi/EFI/fedora/grub.cfg >> -- >> >> An 840K grub.cfg??? It would probably be easier to regenerate the grub.cfg file eg. grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg though you might want to write that to a temporary file first to check it. Also grubby is optional in Fedora 31, as it isn't needed if BLS is enabled, ie. if you have GRUB_ENABLE_BLSCFG=true in /etc/default/grub and a grub.cfg file built with that configuration, which should include the lines insmod blscfg blscfg and also configuration files in /boot/loader/entries/ for each kernel. I have updated my Pi3B to 5.4.19-200.fc31.aarch64 without problems, though I don't think grubby was ever installed on it. Michael Young _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx
