Updating bootloader on raspberry / Debian : kernel panic and so?

General Discussions
1

Our fleet of devices are using Raspbian with a mix of raspberry pi 3 and 3b+.
We would like to update raspbian to Bullseye but it seems that it cannot be done without updating the bootloader that mender do not handle.
We are trying to update the bootloader via a custom state script : ArtifactInstall_Leave_00_update-firware (below).
The script if executed but the update is not going well :

  • either we get kernel panic
  • either we do not have any LAN working

Do you know which files need to be updated and from which source, i can get them.
Thanks

#!/bin/sh

# sync firmware files to /boot folder
set -e

current=$(/sbin/fw_printenv mender_boot_part | awk -F = '{ print $2 }')

if [ $current = "2" ]; then
    newroot=/dev/mmcblk0p2
elif [ $current = "3" ]; then
    newroot=/dev/mmcblk0p3
else
    echo "Unexpected current root: $current" >&2
    exit 1
fi

mkdir -p /mnt/inactive_part
mount -o ro $newroot /mnt/inactive_part

ls -la /mnt/inactive_part/ >&2

# Copy 'core' firmware files first
cp -vf /mnt/inactive_part/firmware_update/*.dtb /uboot
cp -vf /mnt/inactive_part/firmware_update/bootcode.bin /uboot
cp -vf /mnt/inactive_part/firmware_update/cmdline.txt /uboot
cp -vf /mnt/inactive_part/firmware_update/config.txt /uboot
cp -vf /mnt/inactive_part/firmware_update/fixup.dat /uboot
cp -vf /mnt/inactive_part/firmware_update/kernel.img /uboot
cp -vf /mnt/inactive_part/firmware_update/kernel7.img /uboot
cp -vf /mnt/inactive_part/firmware_update/start.elf /uboot

# Synchronize before trying to copy the rest of the files
sync

# Copy overlays
cp -vf /mnt/inactive_part/firmware_update/overlays/* /uboot/overlays

# Synchronize to ensure all files are written before leaving the ArtifactInstall state
sync

umount $newroot

exit 0
2

I would suggest a different route. Instead of trying to pick out exactly which files you need from the rootfs, get it working first with a newly flashed .img on a development board, and then put the whole /uboot partition in a tarball and put it somewhere on the rootfs in the artifact. Then extract it using the state script instead of the single files.

3

You might also want to compare the difference between the boot environment (fw_printenv) between the board being upgraded, and the newly flashed board. This is stored in raw partition space, and won’t be included in the boot partition dump. Maybe you need to adjust a few entries in the state script.

4

wouaahh. Thanks for your help.
I’ll give this a try today.
Is is usefull to sync /boot partition too between “newly flashed” and “upgraded” (it contains merely symlinks).

5

It worked. Huge thanks to you @kacf.
There was not much difference between fw_printenv output from old and new version.

You confirm that there is not need to handle /boot folder (which contains merely symlinks). Only /uboot folder is important. Right ? Regarding my tests, we do not need to sync it (it seems that it’s created “on the fly”.

For those interested, here is my script. Feedback welcome.

#!/bin/sh

# sync firmware files to /boot folder
set -e

if grep -q "bullseye" /data/firmware_version
then
    exit 0
fi

current=$(/sbin/fw_printenv mender_boot_part | awk -F = '{ print $2 }')

if [ $current = "2" ]; then
    newroot=/dev/mmcblk0p2
elif [ $current = "3" ]; then
    newroot=/dev/mmcblk0p3
else
    echo "Unexpected current root: $current" >&2
    exit 1
fi

# backup existing /uboot folder
if [ ! -d /data/old_boot ]
then
     mkdir /data/old_boot

rsync -avh --delete-after --no-perms --no-owner --no-group /uboot/ /data/old_uboot >&2

# sync new firmware files to new partition /uboot folder
mkdir -p /mnt/inactive_part
mount -o ro $newroot /mnt/inactive_part

rsync -avh --delete-after --no-perms --no-owner --no-group /mnt/inactive_part/firmware_update/uboot/ /uboot >&2
echo "bullseye" > /data/firmware_version
sync

umount $newroot

exit 0
1 Like
6

Glad to hear it!

Correct. When using Mender, /boot is just a folder in the root filesystem, and not a separate mount. It’s more correct to read the boot name as referring to “files needed to boot this rootfs”, not “boot partition”.