Move Armbian-Stretch-based Yunohost to amd64-based Proxmox (LXC or KVM)

Hi all,

I have a couple of Yunohosts in the house running on different Orange Pi (mostly Zero’s) and Raspberry Pi.

For my birthday I got a set of hardware to build myself a NAS, and I put Proxmox on it.

Now I’d like to virtualize some of the Yunohosts so that the ARM boards come free for another purpose.

Do you have experience moving an installation to a container (LXC) or KVM? Taking in account ARM <> Intel and Stretch <> Buster more or less rules out LXC, though that would have my preference.

If rebuilding the Yunohosts is the most straightforward option, how would I go about transferring configuration and user data?

Edit: in case of rebuilding, should I be able to use a backup as explained in the help, even though the backup is from ARM and restore on amd64?

LXC, or Debian, is more flexible than I’d anticipated: starting a Stretch container on a 5.x kernel ‘just works’.

Yunohost is being installed in a non-privileged container under Stretch. Another night will see backups restored :slight_smile:

I can’t imagine I get everything right at once, but so far I am happy with the progress :slight_smile:

1 Like

Hi there,
Did the backup / restore worked ?
Have a nice day !

Hi Charly,

Thanks for your interest!

TL;DR: backup to external location no-go due to no sshfs / missing fuse module. Repair brought down the system, fixed in the end by clearing /boot and restoring it later on

Still working on it, got a setback from an unexpected corner: no sshfs due to missing modules.

My kernel is 4.19.42-v7+, but there are no modules:

# uname -a 
Linux 4.19.42-v7+ #1219 SMP Tue May 14 21:20:58 BST 2019 armv7l GNU/Linux
# pwd
# ls 
4.14.66+  4.14.66-v7+  4.19.66+  4.19.66-v7+

There is no kernel 4.19.66, apt can not install it due some dependency.
I tried symlinking 4.19.42 to 4.19.66, in the vain hope nothing had changed. Did not work of course.

Online I was not able to find a source with modules for 4.19.42-v7+, so copying was out.
Next I tried downgrading to 4.9.0; that was out because /boot is a mere 44MB, and apt complains about lack of space.

I first moved kernel.img (ostensibly for RPi 4) to a safe place to make space, that was not enough.
Now I just broke the system in this way:

  • Move all contents of /boot to /boot_bak; there already was a (system made?) boot.bak which might come in handy;
  • Run apt install linux-image-4.9.0-6-rpi2/oldstable
  • Now there is enough space, but the process seems to stop early:

(I have some trouble with the editor; if I take this line away, the text is not preformatted anymore , so I’ll camouflage it as some useless text between brackets)

# apt install linux-image-4.9.0-6-rpi2/oldstable
Reading package lists... Done
Building dependency tree       
Reading state information... Done
linux-image-4.9.0-6-rpi2 is already the newest version (4.9.82-1+deb9u3+rpi1).
Selected version '4.9.82-1+deb9u3+rpi1' (Raspbian:oldstable [armhf]) for 'linux-image-4.9.0-6-rpi2'
0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] 
Setting up linux-image-4.9.0-6-rpi2 (4.9.82-1+deb9u3+rpi1) ...
No diversion 'diversion of /boot/vmlinuz-4.9.0-6-rpi2 by rpikernelhack', none removed.
No diversion 'diversion of /boot/config-4.9.0-6-rpi2 by rpikernelhack', none removed.
No diversion 'diversion of /boot/ by rpikernelhack', none removed.
update-initramfs: Generating /boot/initrd.img-4.9.0-6-rpi2
W: APT had planned for dpkg to do more than it reported back (0 vs 4).
   Affected packages: linux-image-4.9.0-6-rpi2:armhf

The reason may be the the lack other files that I moved aside.

After that I copied a selection of files back from /boot_bak to /boot, but found out (after a ssh timeout) that I skipped kernel7.img…

Well, the SD card is in my computer now, taking the opportunity to make a copy of all the files in case the intended transfer via the Yunohost backups stalls in some unforseen way. It took about 30 minutes for some 20G from a 32GB Sandisk A1 card.

Ok, the RPi boots again. Presumably the system is not fool-proof against removing the kernel :stuck_out_tongue:

Funnily enough, I do have kernel 4.19.66-v7+ running now, WITH fuse :slight_smile: Haha, that was a well spent night in the end :wink:

Feeling a bit uncomfortable though, that I can’t explain when kernel 4.19.66 arrived; all files backed up in /boot_bak are from 20190930, a month ago, except for the 4.9.0-related files, which are from two hours ago. No mention of 4.19.66.

Up next: symlinking /home/yunohost.backup/archives to an sshfs-mountpoint; story for another night.

Have a nice day as well!

Jeeze, that’s impressive !
Thanks for this long but nevertheless interesting answer !

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.