After installing updates my rasp pi 2 will not boot.

[Nikita790]

Hello, earlier today I installed updates via

Code: Select all

pacman -Syu

, and then i ran reboot.
After the reboot my pi will not boot up, it shows a red LED when i try to boot.
The machine is headless but I can put the microsd card in my computer and edit files, I am not sure what other info to give,
- thank you

[m040601]

Exactly the same problem here.

It turns on the red LED, indicating the power is ON.
The green LED does not turn ON or blink at all. No sign of reading activity on the micro SD card.

My RPI2 was also headless.

Tried connecting it to a HDMI monitor.
Nothing comes out on the screen. Zero. Nada.

Tried checking the micro SD card with fsck on a Arch Linux x86 machine. No errors detected.

Not sure how to proceed from here.
How to chroot ? arch-chroot into arm from x86 ?

[Nikita790]

good to know im not alone, I think it has something to do with the bootloader update.

[graysky]

Seems like an upstream problem: https://www.raspberrypi.org/forums/view ... 9#p1779839

AFAIK you cannot chroot from x86_64. Only from armv7h. It's possible something in the bootloader is to blame. You will need another uSD card or another armv7h system for a chroot/package downgrade. Alternatively, you can manually extract the previous version of the bootloader package to your sd card.

Code: Select all

% pacman -Ql raspberrypi-bootloader
raspberrypi-bootloader /boot/
raspberrypi-bootloader /boot/bootcode.bin
raspberrypi-bootloader /boot/fixup.dat
raspberrypi-bootloader /boot/fixup4.dat
raspberrypi-bootloader /boot/fixup4cd.dat
raspberrypi-bootloader /boot/fixup4db.dat
raspberrypi-bootloader /boot/fixup_cd.dat
raspberrypi-bootloader /boot/fixup_db.dat
raspberrypi-bootloader /boot/start.elf
raspberrypi-bootloader /boot/start4.elf
raspberrypi-bootloader /boot/start4cd.elf
raspberrypi-bootloader /boot/start4db.elf
raspberrypi-bootloader /boot/start_cd.elf
raspberrypi-bootloader /boot/start_db.elf


And

Code: Select all

% pacman -Ql raspberrypi-bootloader-x
raspberrypi-bootloader-x /boot/
raspberrypi-bootloader-x /boot/fixup4x.dat
raspberrypi-bootloader-x /boot/fixup_x.dat
raspberrypi-bootloader-x /boot/start4x.elf
raspberrypi-bootloader-x /boot/start_x.elf


[m040601]

Seems like an upstream problem

Yeap. It seems they messed a lot with those .dat .elf files in the last hours. And also the bootcode.bin, https://github.com/raspberrypi/firmware ... aster/boot

Alternatively, you can manually extract the previous version of the bootloader package to your sd card.

Yes this is kind of what I did for a quick test.
I mounted the micro sd card FAT boot partition on my x86.
I backed up it's content to a to "boot_december_disaster".


At https://archlinuxarm.org/platforms/armv ... berry-pi-2
it seems the last available image http://os.archlinuxarm.org/os/ArchLinux ... est.tar.gz is from August 2020. Correct me if I'm wrong.


On my x86 PC:
wget http://os.archlinuxarm.org/os/ArchLinux ... est.tar.gz
bsdtar -xpf ArchLinuxARM-rpi-2-latest.tar.gz -C root_august_2020

I copied all the files in the root_august_2020/boot to the boot partition on the micro sd card.
It seems they date back to August 2020.

The system then booted.
But, I dont trust this salad of old and new.

So, I'm gonna try now replacing only the files that belong to "raspberrypi-bootloader" and "raspberrypi-bootloader-x"

[Nikita790]

So we should wait for a fixed bootloader to be pushed and then manually replace the files on SD card once its out?
sorry im pretty much a noob.

[m040601]

So, I'm gonna try now replacing only the files that belong to "raspberrypi-bootloader" and "raspberrypi-bootloader-x"

I can now confirm that replacing only the files that belong to "raspberrypi-bootloader" and "raspberrypi-bootloader-x" packages seems to work.

At least the system boots, and I cant seem to see any abnormal behaviour.

Big thanks to @graysky for the prompt advice.

I still dont trust this big mess of having old and new mixed together. All those .elf .dat and the bootcode.bin files from August 2020 cocktailed in a system that was updated in December 2020.


So what would you recommend ?

Is it safe to keep the system running this way ?

Should I just keep it this way (with the old bootloader files) and wait for the next updates and then forget the all thing ?

I'm thinking the best is to just backup the important stuff, and dont update any thing in the next few days. Just wait to see what comes up from the Raspberry Pi foundation firmware package, and/or a new fresh ArchlinuxARM image (http://os.archlinuxarm.org/os/ArchLinux ... est.tar.gz) for December or January. A fresh system reinstall them, seems to be the wise thing to do.


----

RANT:

Really unhappy with the sloppy kernel and boot updates on ARM this year. It's not that I blame the ArchlinuxARM release team. But the problem does seem to come from upstream.

This happened a couple of times both on the Raspberry Pi and the Samsung Chromebook. Many times had to rollback the kernel updates to the previous version. It seems things dont get tested before being released ? Lesson learned, dont rush for "pacman -Syu" on ARM.

In more than 10 years using Arch x86 I always laughed at those people who say Arch isnt "stable for production" systems because it's a rolling realese system. But I'm kind of rethinking this for Arch ARM. At least for the case of releasing a robust product for the average user based on it.

On the other end, strangely, issues that seem to affect the average Raspbian/Raspberry professional complainer dont seem to affect me. Example, the" supposed" inferiority/unreliabilty of running a system from a micro sd card.

After almost 5 years running on the same micro sd card and rpi2 board, I never, ever had an sd card physical corruption problem. No matter how many times the power went off, or I "pushed" the system too much. When it boots, and if nothing else changes, Arch Arm will run like a tank forever

[bbeaudoin]

Not just the Raspberry Pi 2, Raspberry Pi Zero W is also affected. Once packages are updated, the Pi refuses to boot. I reimaged my SD card, thinking I had unplugged it too soon after shutdown and the issue was repeatable.

I'm happy to see there's an general resolution (being "don't update the bootloader") but I'm rather surprised by this. Assumption is the new bootloader for the Raspberry Pi 4 is unaffected (though I'm afraid to update mine to test, lest it not boot) but I'm surprised this wasn't tested with hardware using the older bootloader before this package was released.

[Nikita790]

I feel like there should be a warning somewhere, about this update breaking boot. Maybe in the Announcements section of the forum.

[m040601]

By the way, apropos chrooting into different architectures. And emulating the raspberry on a x86 PC.

graysky » Tue Dec 15, 2020 2:53 am

AFAIK you cannot chroot from x86_64. Only from armv7h.

I've been trying this year to learn how to accomplish this (and also cross compiling ) with the help of Qemu, losetup loop devices, binfmt, qemu-arm and company.

I googled a lot and tried a lot. Arch Wiki x86 has some, and also found some Debian Arm guides. And a lot of confusing (to me) guides for learning and understanding this, that assume you already some how have some implicit knowledge on the matter. A lot of installing AUR packages qemu-arm-xyz, qemu-user-xyz.

But it just isnt' for my level yet. Or at least I cant seem to find well written tutorials on this, that make me see the big picture starting from small steps.


But it sure is a usefull tool/competence to acquire for cases like this and for the future. It would really be a nice addition for the Arch ARM wiki (and x86)

Do you happen to have any pointers, links or advice on this ?