Tuesday, February 18, 2020

[fedora-arm] Re: Latest Fedora update leaves aarch64 unbootable RPi V3.

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@WittsEnd.com
/\/\|=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!

No comments:

Post a Comment