Bugzilla bug report has been submitted. On Tue, 2020-02-18 at 17:19 -0500, 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??? > > > > 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
