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 -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
