# Updating bootloader on raspberry / Debian : kernel panic and so?
**URL:** https://hub.mender.io/t/updating-bootloader-on-raspberry-debian-kernel-panic-and-so/4319
**Category:** General Discussions
**Created:** [November 20, 2021, 4:10pm UTC](https://hub.mender.io/t/updating-bootloader-on-raspberry-debian-kernel-panic-and-so/4319 "2021-11-20T16:10:33Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Jerry](https://hub.mender.io/u/Jerry)
#### Post date: [November 20, 2021, 4:10pm UTC](https://hub.mender.io/t/updating-bootloader-on-raspberry-debian-kernel-panic-and-so/4319/1 "2021-11-20T16:10:33Z")
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
```auto
#!/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
```
---
### Author:  [@kacf](https://hub.mender.io/u/kacf)
#### Post date: [November 22, 2021, 8:15am UTC](https://hub.mender.io/t/updating-bootloader-on-raspberry-debian-kernel-panic-and-so/4319/2 "2021-11-22T08:15:31Z")
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.
---
### Author:  [@kacf](https://hub.mender.io/u/kacf)
#### Post date: [November 22, 2021, 8:17am UTC](https://hub.mender.io/t/updating-bootloader-on-raspberry-debian-kernel-panic-and-so/4319/3 "2021-11-22T08:17:30Z")
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.
---
### Author:  [@Jerry](https://hub.mender.io/u/Jerry)
#### Post date: [November 22, 2021, 8:48am UTC](https://hub.mender.io/t/updating-bootloader-on-raspberry-debian-kernel-panic-and-so/4319/4 "2021-11-22T08:48:41Z")
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).
---
### Author:  [@Jerry](https://hub.mender.io/u/Jerry)
#### Post date: [November 22, 2021, 4:12pm UTC](https://hub.mender.io/t/updating-bootloader-on-raspberry-debian-kernel-panic-and-so/4319/5 "2021-11-22T16:12:26Z")
> [@kacf](#):
>
> 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.
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.
```auto
#!/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
```
---
### Author:  [@kacf](https://hub.mender.io/u/kacf)
#### Post date: [November 23, 2021, 9:41am UTC](https://hub.mender.io/t/updating-bootloader-on-raspberry-debian-kernel-panic-and-so/4319/6 "2021-11-23T09:41:19Z")
> [@Jerry](#):
>
> It worked. Huge thanks to you @kacf.
Glad to hear it!
> [@Jerry](#):
>
> You confirm that there is not need to handle /boot folder (which contains merely symlinks). Only /uboot folder is important. Right ?
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”.