btw. this odd installation routine (copying files from card to internal disk) might be my reason to drop the vero entirely.
on the pi its so much easier to make backups and restore etc… just wanted to let you know …
its really frustrating having a full backup of the system an not having a single way to restore from it …
looking at the timestamps of the file-extraction leads to the assumption, that nothing at all is being extracted (all in the same second). could there still be a misstake in how the tar-file was created?
i use the command:
sudo tar -cvzf filesystem.tar.xz -C /backup_path/system ./
Wheras in omsc-restore this command is used (i don’t fully understand it):
tar -I “xz -0v” -cf “$BACKUPDIR/filesystem.tar.xz” *
The tar command should result in roughly the same archive. I’m just invoking xz explicitly so I can specify the compression level (-0) in an attempt to speed things up.
I suspect tar and/or xz doesn’t set the file timestamps until the whole archive has been processed, so if the untar fails, the timestamps won’t be right.
It’s not an official OSMC backup/restore method, just something I developed from the one I did for RPi. It has always worked for me on Vero4k but TBH I’ve never needed it to recover from storage failures like on the Pi since emmc is so much more reliable than SD card.
You didn’t say why you wanted to restore a previous image, but if you don’t have too much customisation, you could restore your system with the latest (December) image, then copy across any config files (.kodi/ mainly) from the backup. That’s the reason I prefer file by file backups instead of messing with dd.
thanx for your clarifying things.
I know, i am refering to the official method of installing osmc on the vero.
I have lots of changes on my system (kodi is just one of many things i use the vero for) , that is why i do frequent backups. however, as there seems to be ABSOLUTLEY no way of getting the backup back on the device, i will ditch the vero and replace it with pi3 now.
thx for your support
I don’t know about that. I said at the beginning I’ve no idea whether vero 2 installation works the same as vero 4k. But I wouldn’t expect issues with the untarring. I hope @sam_nazarko can shed some light.
i am looking for a possibilty to restore from backups for years now. also by asking for help in the forum.
i lost hope!
We have been through this in detail several times.
What specific things are you trying to restore as a backup?
In theory you can do a complete dd of the LVM volume from the initramfs and restore it.
From the error above, your tarball looks corrupted.
yes we have … and we never solved it 
full system (it was my only goal from the beginning)
had too much theory about this. looking for real solutions now or going to ditch it.
thats what i though. but (as already explained) the tar is perfectly fine! can extract it manually without error. i also tried various tars with different compression.
We extract with tar -xjf
my apologies: i tested again with your exact tar-paramters and was able to restore the backup just fine.
sudo tar -I “xz -0v” -cf filesystem.tar.xz -C /backup_path/system ./
apparently the osmc_installer seems to be picky about method of compression.
cheers and thank you for your effort
bendsch
It expects xz compression. I didn’t spot you were using gzip at first.
ok, everything seems to be working fine. everything but ssh. not able to login via ssh at all (connection reset). it seems to be installed, but its not working. in appstore it appears under „service“ as „stopped“. not able to uninstall (and reinstall) it. also system-updates seem to be not fetched properly.
any idea what the problem could be?
Can you connect a keyboard?
yes, i am able to open console.
there seems to be a problem with user-rights …
any idea how to solve this?
cheers
Can you ls -l /usr/bin/sudo?
Hmm. And does ls -n /usr/bin/sudo show the owner as uid 0?
This could be Catch 22. Are you able to get a root console with su? If so, chmod u+s /usr/bin/sudo should set the setuid bit.
Indeed. You need root’s password and there isn’t one. I’m struggling to understand what’s happened, here. If you examine the backup files, does sudo have the setuid bit set in that? It should look something like
-rwsr-xr-x 1 root root 149080 Jan 18 2018 /usr/bin/sudo
If it does, the problem is in the restore. If not, you could run sudo chmod u+s ..../system/usr/bin/sudo on the machine which hosts the backup files and restore again.
ok, will try that.
its probably worth mentioning, that the backup was written to a nfs mount.
could that have messed up permissions of the entire system-backup?
