Hello,
Is there anyone with experience in migrating a Raspberry Pi (4) from 32bit raspbian to 64 bit ?
In particular, I’m searching for a way to convert the system without reinstalling, for several reason but the main one is : I don’t want to reinstall and reconfigure all customs tools I installed and configured on this 4 years old installation…
(Yes, it’s mainly for Nextcloud ≥26 versions)
Any good tutorial or tips to share ?
Thanks !
I have the same problem pending, since nextcloud has no more updates for 32 bit.
My way will be an update of the 32-bit machine with the regular function in the webadmin, not to forget downloading it somewhere, where I can access it after the 32-bit system is overwritten,
then a new installation in 64 bit with only minimal additions like the same primary user as in 32bit,
and then copy the backup back to the new /home/yunohost.backup/archives/ and the playing the complete update back to that 64bit machine.
I really hope, this will work, since I allready was lucky some time ago with a raspi 4 that way.
Good luck for all followers
Bruno
Hello, I am in the same boat with my Raspberry 3 (which I think supports 64bits?) and the Nextcloud 25 update.
Depending of the complexity of the 32 to 64bits upgrade I am wondering if it’s not better to to take this opportunity to switch to a Raspberry 4 (or maybe even wait for an eventual Raspberry 5?)
So I am also interested in any kind of tutorial for doing this upgrade.
Thanks!
It does until version 25, you can upgrade to v25.0.2, and all next 25.x versions (until October 2023 if I remember well).
Version 26 will end 32 support.
It does.
Installing a new Yunohost system and restoring backups there will work fine.
In my case, I also want to migrate all utilities and config files I changed during… years, and I can’t even remember all of them so it’s not the way to go for me 
For all posters: Is your hardware even x64 compatible? If it’s not, it can’t be done. From terminal / ssh:
lscpu
First item in output (Architecture) will give your answer.
If the Hardware is x64, you do must reinstall because the kernel, packages, libraries are all x64 and you can’t just convert them from x32 - but the good news is you can back up & restore your configurations post-install, as those are not hardware dependent.
Use a USB drive, or rsync, or scp to backup config files (research this) and the /var/lib/mysql database. Use a USB drive to boot from on your Rasp-Pi to install fresh Yunohost x64, then restore the configs / data. You could use PXE booted tftp + http to achieve this as well, but that’s another discussion 
Ok thanks, so effectively I didn’t check, the processor on my Raspberry 3 is an armv7l which is 32 bits so it settles it for me. It seems I need to think about switching to a new hardware next year.
Hi Lanky,
armv7l sounds a bit more like the used firmware-system and not the hardware.
Use lscpu in a root-terminal as intended above.
If for example your raspi 3 is a 3B then the first line after lscpu should be:
Architecture: aarch64
and you should be happy
Hi brunogiscoat, thanks for your answer,
My Raspberry is indeed a 3B, lscpu give me this, but searching further I have read that it reports an armv7 and not an armv8 because the OS is 32 bits. The ARM Cortex A53 has an armv8 64bits architecture.
Architecture: armv7l
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Vendor ID: ARM
Model: 4
Model name: Cortex-A53
Stepping: r0p4
CPU max MHz: 1200.0000
CPU min MHz: 600.0000
BogoMIPS: 38.40
Flags: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idi
vt vfpd32 lpae evtstrm crc32
Sorry for my optimism, that a command like lscpu does not list the data about the cpu but about the used system-software.
You are absolutely right and armv7l is only the actual system-software.
But: now you know, that you have a 3B and can change to arm64. Use a really quick card!
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.
Ok, so I found no way to convert it, and decided to do a full resinstall (as painful as it can be) because I needed to convert it to a proper @ and @home btrfs (filesystem) setup to use timeshift (goal : have very regular instant automated “backups” of the whole system).
I also create a dedicated subvolume for snapshots.
NB: dumping here the list of operations, not sourced not explained correctly, at least as a beginning, mainly to remember it for next time and in the hope it will help someone else… don’t trust me 100% and don’t trust this not to be outdated
So here is what I did:
bash_aliases, /root/.config/htop, list of installed packaged…)btrfs-progs (unless it won’t boot with btrfs. Not needed if you don’t use it) and zstd package if you want zstd compression.btrfs-convert and then move folder in appropriate subvolumes (created later ↓).btrfs/, a directory that you create first) : sudo mount /dev/sda3 btrfs/./dev/sda3 (it should be the third one, but on a different sdX or whatever depending on what kind of device interface you use).sudo btrfs subvolume create btrfs/@sudo btrfs subvolume create btrfs/@homesudo btrfs subvolume create btrfs/@/@snapshots - optionalext4/, a directory that you create first) : sudo mount /dev/sda2 ext4/.sudo rsync -avhP ext4/ btrfs/@/ to copy everything from root (in ext4) to @ (root) subvolumesudo cp -a btrfs/@/home/. btrfs/@home/ migrate home content to @home subvolume (making a copy just in case)sudo rm -r btrfs/@/home/ (cleaning the mess)sudo sync && sync to make sure everything is written to disksudo umount ext4 : it’s no longer needed./etc/fstab to boot with the new setup:
ls -l /dev/disk/by-uuid/ (can be done graphically in gparted too).fstab file:proc /proc proc defaults 0 0
PARTUUID=SomeShortUUID /boot vfat defaults 0 2
PARTUUID=SomeVeryLongUUID / btrfs defaults,subvol=@,compress-force=zstd:2,discard=async,relatime 0 1
PARTUUID=SomeVeryLongUUID /home btrfs defaults,subvol=@home,compress-force=zstd:2,discard=async,relatime 0 2
PARTUUID=SomeVeryLongUUID /@snapshots btrfs defaults,subvol=@snapshots,compress-force=zstd:2,discard=async,relatime 0 2
Only the subvol= option is mandatory, the rest are settings to enable compression (with a pretty balanced compression vs CPU overhead setting) and speed/writing optimisation for SSDs.
In order to boot (it won’t work straight away with btrfs), we need to change the kernel parameters in /boot/firmware/cmdline.txt:
boot/: sudo mount /dev/sda1 boot/./boot/firmware/cmdline.txt
rootfstype=ext4 to rootfstype=btrfs
root=PARTUUID=SomeShortUUID to the right UUID. You can use label or /dev/… if you prefer, as in the fstab file. And rootflags=subvol=@ (it will mount the root subvolume)fsck.repair should be equal to no, it doesn’t work with btrfs (btrfs as its own repair mechanism)quiet if you wish (more logs provided)echo "btrfs" >> btrfs/etc/initramfs-tools/modules
/etc/default/raspberrypi-kernel uncomment INITRD=Yes
sudo mount -o subvol=@ /dev/sda3 chroot_mnt_point/ (create chroot_mnt_point directory first)mount /dev/sda1 chroot_mount_pt/@/boot/
for i in /dev /dev/pts /proc /sys /run /lib; do sudo mount --bind $i chroot_mnt_point$i; done (note the lack of / because already contained in $i)sudo chroot chroot_mnt_point/
update-initramfs -c -k all - it should be generating stuff Generating /boot/initrd.img-KernelNumber. You should then see it/them in chroot_mnt_point/boot (and not in you main /boot, that would mean you didn’t chroot and affected your computer, not your raspberry pi…).mkinitramfs -o /boot/initramfs-btrfs.gz $(uname -r) as a way to generate a working btrfs kernel image (I guess ?) in /boot. And in /boot/config.txt at the end I instead add initramfs initramfs-btrfs.gz Now after booting into the old ext4 filesystem (I kept a copy) to check, dmesg | grep -i trfs (note the lack of “b”, because in my case it was uppercase) gives me the information that btrfs is loaded !
/bin/bash exec() error, which seems to be related to the fact I’m using an x86 computer to chroot into ARM environnement ?)./boot/cmdline.txt first, but booted the Rasberry Pi, connected with ssh, and then did the chroot, cmdline.txt and initramfs modules changes and ran update-initramfs -c -k all and the mkinitramfs stuff shown above.Reboot. It should work and be still accessible by SSH and so on.
Restore your backups.
And… nothing to report in my case ! 
Enjoy ! (Install Yunohost as usual and so on…)
Also documenting here these commands, to be edited later on to include them (it’s for btrfs-convert scenario):
sudo cp -P lib @/lib
sudo cp -P sbin @/sbin
sudo cp -P sbin @/sbin
sudo mv home/* @home/ && sudo rm -r home/ # not /home !!!
for i in var boot etc opt media mnt srv tmp usr root ; do sudo mv $i @/$i; done # Be very careful not to point to **/**dev, /somethingElse… because it would be you current PC system !!!
I migrated from an Odroid XU4 (32 bit) to Odroid N2+ (64 bit). It was as simple as doing a backup, installing yunohost on the new hardware, and restoring the backup. I have many apps (Nextcloud, multiple Wordpress, Gitea, Dokuwiki…) but with almost no custom configuration. No issue whatsoever.
Yes, same for me here. Doing a resintall is very simple on the Yunohost side (backup / install / restore). Switching from 32 bits to 64 bits wasn’t an issue in my case.
I tried to avoid doing a reinstall because of all my custom config that I had to remake.
Because of the lack of solution, I decided to reinstall anyway, and document how it was done with the migration to btrfs