Raspberry-pi : convert to 64 bit installation? (manual way : reinstall, convert to btrfs)

Support
12

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 :slight_smile:

So here is what I did:

  • make Yunohost backup
  • backup some config files (bash_aliases, /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.
    Alternativement, use 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 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:

    • mount the boot partition in boot/: sudo mount /dev/sda1 boot/.
    • edit /boot/firmware/cmdline.txt
      • Change rootfstype=ext4 to rootfstype=btrfs
      • change 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)
      • remove 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)
      • in /etc/default/raspberrypi-kernel uncomment INITRD=Yes
      • 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)
      • chroot: sudo chroot chroot_mnt_point/
      • then 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 ! :tada:

  • 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 !!!
2 Likes