# Raspberry Pi OS 64 Bit conversion **URL:** \ **Category:** Debian family\ **Created:** [May 2, 2022, 9:23pm UTC](https://hub.mender.io/t/raspberry-pi-os-64-bit-conversion/4919 "2022-05-02T21:23:30Z")\ **Posts on this page:** 5\ **Page:** 2
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [February 27, 2025, 5:15pm UTC](https://hub.mender.io/t/raspberry-pi-os-64-bit-conversion/4919/22 "2025-02-27T17:15:54Z")
@jjsteele well take one step back? [mender-convert/configs/raspberrypi/uboot/debian at master · mendersoftware/mender-convert · GitHub](https://github.com/mendersoftware/mender-convert/tree/master/configs/raspberrypi/uboot/debian) Note, not tested on the CM5 yet as I’m having hardware issues there. Greetz, Josef ---
**Author:** ![Pedro-Jesus-Fuentes](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/pedro-jesus-fuentes/32/1898_2.png) [@Pedro-Jesus-Fuentes](https://hub.mender.io/u/Pedro-Jesus-Fuentes)\ **Post date:** [June 26, 2025, 1:36pm UTC](https://hub.mender.io/t/raspberry-pi-os-64-bit-conversion/4919/23 "2025-06-26T13:36:55Z")
Hi Josef, I have several Raspberry Pi 4 devices currently running arm32 Debian Bookworm images in standalone mode. In the past, we had to use arm32 because `mender-convert` didn’t support arm64. Now that arm64 is supported, I need to upgrade these devices from arm32 to arm64 using a golden image. I created the artifact from a golden arm64 device and installed it successfully. I also remapped the `/uboot` mount point to `/boot/firmware` to match the new layout, and the update process itself went smoothly. However, I’m running into issues with the U-Boot environment variables. The arm32 and arm64 configurations use different variables, and simply switching the root filesystem isn’t enough. To address this, I used `dd` to extract the U-Boot environment sectors from the arm64 device—specifically from offsets `0x400000` (size `0x4000`) and `0x800000` (size `0x4000`)—and wrote them to the same locations on the target devices. With this, the device boots successfully into the arm64 system and the new partition. The issue is that these U-Boot variables include some device-specific values, such as the MAC address. When I overwrite these sectors, I also overwrite those identifiers, which is problematic. Is there a way to trigger a regeneration of the U-Boot environment variables in a similar way to how they are initially created when the system boots for the first time from a fresh image? That way, I could avoid overwriting device-specific data like the MAC address, while still applying the correct layout and boot configuration for arm64. Thanks in advance! ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [June 27, 2025, 11:34am UTC](https://hub.mender.io/t/raspberry-pi-os-64-bit-conversion/4919/24 "2025-06-27T11:34:54Z")
Hi @Pedro-Jesus-Fuentes, Thanks for reaching out, that’s an interesting use case! It certainly can be done with some custom scripting, but there’s a number of things to watch out for: - all of the following probably is best put into a state script, preferably in the ArtifactInstall\_Leave stage. - please be aware that this introduces a number of single points of failure - you can adjust specific variables in the 'u-boot`environment using the`fw\_printenv` command - only adjusting the live environment works well for the happy path, but it will fail if for whatever reason the environment is corrupted, and falls back to the default which is baked into the `u-boot` binary. - as far as I can tell, there are variables in `config.txt` which also affect 32bit vs. 64bit. Takeaway therefore is: - be aware that this is a possible destructive, no-rollback, single point of failure operation - put the logic for modification into a state script which runs at the latest point in time before final reboot, and still error out if needed. Greetz, Josef ---
**Author:** ![Pedro-Jesus-Fuentes](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/pedro-jesus-fuentes/32/1898_2.png) [@Pedro-Jesus-Fuentes](https://hub.mender.io/u/Pedro-Jesus-Fuentes)\ **Post date:** [June 27, 2025, 12:46pm UTC](https://hub.mender.io/t/raspberry-pi-os-64-bit-conversion/4919/25 "2025-06-27T12:46:33Z")
Hi Josef, Thanks for your quick reply! I understand this type of update is risky and difficult to roll back. For now, I’m using an `ArtifactInstall_Leave` script to back up both the U-Boot environment sectors and the boot partition. The boot partition and its `config.txt` are not a problem, since I completely wipe and overwrite them with the arm64 boot files during the update. What I discovered is that if I clear the U-Boot environment sectors by zeroing them out using `dd`, and then reboot the system, U-Boot automatically resets the environment to its default values — including critical ones like `ethaddr`. However, in the parts of the system I’ve tested so far, this reset doesn’t appear to cause any major issues. The only problem I’ve encountered is that `mender_boot_part` and `mender_boot_part_hex` also revert to their default values, which breaks Mender’s partition logic. To handle this, I found that during the `ArtifactInstall_Leave` phase, I can retrieve the currently active Mender boot partition, and then — after clearing the environment — set that specific value. The system retains this new value while all other variables are safely reset to defaults, which seems to be a workable solution. I’ve tested this entire flow on an arm64 device, and so far it appears to work correctly. Now I plan to test the same process on an arm32 device as part of the migration to arm64. I believe this approach is on the right track. In the worst case, I can connect to the devices via OTG and recover them manually, so the update is not too critical. I’ll stay in touch and share further updates as I make progress. Thanks again for your help! ---
**Author:** ![user706](https://avatars.discourse-cdn.com/v4/letter/u/ba9def/32.png) [@user706](https://hub.mender.io/u/user706)\ **Post date:** [December 2, 2025, 7:55am UTC](https://hub.mender.io/t/raspberry-pi-os-64-bit-conversion/4919/26 "2025-12-02T07:55:05Z")
> [@Pedro-Jesus-Fuentes](#): > > I need to upgrade these devices from arm32 to arm64 […] Hi Pedro, we also have devices (raspberry pi 4 using _debian bullseye 32 bit_) and are really struggling to update to _debian trixie 64 bit_ (see [here](https://hub.mender.io/t/update-from-bullseye-32bit-to-trixie-64bit/8116)) You posts look promising. Could you provide some details into the steps you used to do the conversion? (so things like where you write “_I also remapped the `/uboot` mount point to `/boot/firmware`_”, etc. which commands did you use and did you do this via mender-scripted-mechanisms of manually; etc. …) Thank you. [Previous page](https://hub.mender.io/t/raspberry-pi-os-64-bit-conversion/4919.md?page=1)