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??? > > Ok... Maybe I can fix these manually. Maybe not. > > Regards, > Mike -- Michael H. Warfield (AI4NB) | (o) +1 706 850-8773 | mhw@xxxxxxxxxxxx /\/\|=mhw=|\/\/ | (c) +1 678 463-0932 | http://www.wittsend.com/mhw/ ARIN whois: MHW9-ARIN | An optimist believes we live in the best of all PGP Key: 0xC0EB9675674627FF | possible worlds. A pessimist is sure of it!
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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
