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 ?
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
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.
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.
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:
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.
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:
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.
Byte Order: Little Endian
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Vendor ID: ARM
Model name: Cortex-A53
CPU max MHz: 1200.0000
CPU min MHz: 600.0000
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
@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:
- make Yunohost backup
- backup some config files (
/root/.config/htop, list of installed packaged…)
- flash this 64bit Yunohost image to the Raspberry Pi Installer YunoHost | Yunohost Documentation. The partition setup is boot + / (ext4 filesystem).
- boot a first time with it. Update it. Install
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.
- in the additional space, create a btrfs partition.
btrfs-convert and then move folder in appropriate subvolumes (created later ↓).
- create appropriate subvolumes :
- mount btrfs partition (let’s say in
btrfs/, a directory that you create first) :
sudo mount /dev/sda3 btrfs/.
In my case it’s was partition
/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/@home
sudo btrfs subvolume create btrfs/@/@snapshots - optional
- copy ext4 partition to btrfs one
- mount ext4 partition (let’s say in
ext4/, 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) subvolume
sudo 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 disk
sudo umount ext4 : it’s no longer needed.
- change the
/etc/fstab to boot with the new setup:
- get the btrfs new partition UUID :
ls -l /dev/disk/by-uuid/ (can be done graphically in gparted too).
- change your
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
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
- mount the boot partition in
sudo mount /dev/sda1 boot/.
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)
- add initramfs btrfs module (at startup)
echo "btrfs" >> btrfs/etc/initramfs-tools/modules
- you need to update the initramfs image to reflect these changes ! We will need to chroot in the filesystem (make it like it was your main system, do run this without chrooting first)
- Mount it
sudo mount -o subvol=@ /dev/sda3 chroot_mnt_point/ (create chroot_mnt_point directory first)
- Mount /boot in the root folder :
mount /dev/sda1 chroot_mount_pt/@/boot/
- mount for future chroot:
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…).
- In my case this doesn’t seem to work correctly.
Alternatively, I followed boot - btrfs root filesystem on raspbian - Raspberry Pi Stack Exchange and btrfs support in kernel, yes or maybe? - Raspberry Pi Forums and found
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 !
- TODO : find a way to execute this after each kernel update, unless… will it break or just ignore the upgrade ?
- In my case I couldn’t make the chroot work (because of a
/bin/bash exec() error, which seems to be related to the fact I’m using an x86 computer to chroot into ARM environnement ?).
So I did not touch
/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