Full backup image with vero4k

Hello everyone,
I recently become a proud owner of the Vero4k. Until now I’m more confirmed with the rpi and now I’m asking if there is a possibility on Vero4k to make a complete backup image.
Only the userdata folder wouldn’t be sufficient for me because I installed some other things like polipo. Is there a possibility to backup the whole emmc?
I’m asking because I want to test kodi nightly builts from gmc (kodi 18) but I’m hesitating because I don’t want to do the whole configurations every time something isn’t working anymore because of the alpha stadium of kodi 18 (sorry for my bad english :slight_smile: )

Greets Axel

It’s not trivial to do that due to the structure of the partitions.

As long as you keep a copy of your .kodi/ folder you always can downgrade if you run into issues

Wow, that was fast.
Thank you. Then I will give kodi 18 a try!!!


1 Like

Which currently means you need also to upgrade to Debian Stretch which is something that would come tomorrow with the regular update but which also could collide with stuff that you have installed so suggest to check that carefully

Yes I know. I think i wait for the official update and then go to kodi 18.
I’m also using Brians Hornsby’s vpn script. Hopefully the stretch update will keep that alive but I will see…

Thanks for your very fast replies!

You can back up the whole filesystem with this: [How to] Make periodic backups of whole OSMC system

Restoring is currently a bit clumpy on vero but you can easily burn a new image and copy across any conf files and the like from the backup.

could you please explain what the procedure of restoring on a vero (2) would be?

I don’t have a vero2 so I’ve never tried it, but I’m guessing it’s the same as vero4k. The script osmc-restore makes a tarball of the backed-up filesystem on your SD card. Then you have to get a copy of dtb.img and kernel.img from a recent system image on the downloads page and copy those onto the card. Boot from that card and the filesystem is copied back onto emmc.

1 Like

i will try that. for some reason the osmc-restore script fails. can’t i just manually create the tarball with “tar -cvf filesystem.tar.xz /backupdirectory” and then copy it on the sd-card?

yes, where backupdirectory = …/system/*

does not seem to work, i think the folderstrukture in the tar file might be the problem. when i extract the tarball, the full original backup-path is created. what path-structure inside filesystem.tar.xz is expected by vero on install? Is ist “/system” or “/”?

tried both, but no luck so far:

the tar seems to be “corrupted” (?).
taring command finished fine and without error.

Thu Jan 1 00:00:05 1970 Starting OSMC installer
Thu Jan 1 00:00:10 1970 Detecting device we are running on
Thu Jan 1 00:00:10 1970 Mounting boot filesystem
Thu Jan 1 00:00:10 1970 Trying to mount to MNT_BOOT (/mnt/boot)
Thu Jan 1 00:00:10 1970 Using device->boot: /dev/mmcblk0p1 and FS: fat32
Thu Jan 1 00:00:10 1970 No preseed file was found
Thu Jan 1 00:01:17 1970 Creating root partition
Thu Jan 1 00:01:18 1970 Calling fmtpart for partition /dev/vero-nand/root and fstype ext4
Thu Jan 1 00:01:29 1970 Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=2 blocks, Stripe width=1024 blocks
334560 inodes, 1337344 blocks
66867 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1371537408
41 block groups
32768 blocks per group, 32768 fragments per group
8160 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736

Allocating group tables: 0/4135/41 done
Writing inode tables: 0/41 done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: 0/41 done

Thu Jan 1 00:01:29 1970 From a root partition of /dev/vero-nand/root, I have deduced a base device of /dev/vero-nand/roo
Thu Jan 1 00:01:29 1970 Mounting root
Thu Jan 1 00:01:29 1970 Trying to mount to MNT_ROOT (/mnt/root)
Thu Jan 1 00:01:29 1970 Using device->root: /dev/vero-nand/root
Thu Jan 1 00:01:29 1970 Extracting files to root filesystem
Thu Jan 1 00:01:29 1970 Starting extract progress…
Thu Jan 1 00:01:29 1970 Halting Install. Error message was: tar: corrupted data
Thu Jan 1 00:01:29 1970 Halting Install. Error message was: tar: short read
Thu Jan 1 00:01:30 1970 Extraction of root filesystem completed
Thu Jan 1 00:01:30 1970 Configuring bootloader
Thu Jan 1 00:01:30 1970 Configuring bootloader: moving /boot to appropriate boot partition
Thu Jan 1 00:01:30 1970 Configuring boot cmdline
Thu Jan 1 00:01:30 1970 Configuring /etc/fstab
Thu Jan 1 00:01:30 1970 Successful installation. Dumping log and rebooting system

“/” is expected.

“Halting install” followed by “Successful installation” seems odd. Only @sam_nazarko would know what’s going on there.

when i untar manually everything seems to extract just fine …

however booting up the system after this “sucessful install” gives mi this:

Are you sure you are using a kernel.img from a vero2 image?

How big is your filesystem tar? I wonder if busybox tar/xz can’t handle it. If so, you could try using the --exclude option to not tar big directories that are not needed for booting (eg media files).

yes, redownloaded it to be sure - same result!

in order to launch the installer at boot i have to rename the kernel.img to recovery.img. not sure if that makes any difference in the installation process.

and presumably you are using the toothpick (if that applies to vero2)?


final idea from me: how old is the back-up? You could try using dtb.img and kernel.img from a system image of similar age. They do change I think.

backup is from february 2019.
the dtb.img does not apply to vero 2 apparantly, since it is not part of the downloadable image.