Kodi 18 - 'cannot save setting' for backup location on usb

[Nachteule]

@jakenl, Update2:

Good news, found and fixed the issue, and backup of image and home to external exFAT disk ran without any problems while watching Live-TV with Kodi on same Device (SD-channel).

Configuration used:
Pi3B+, ZFS root fs on iSCSI target, Wlan connection, slow stone old external 20GB USB disk, exFAT formatted

Tomorrow I'll commit fix, now I'm too tired. Fix is then in new xbian-package-config-shell

[jakenl]

(21st Mar, 2019 06:53 AM)Nachteule Wrote:  @jakenl, Update:

Testing with an exFAT partition, and I'm getting same issue. It depends on exFAT but exFAT is not the culprit. The problem is that XBian-config GUI sends wrong filename, no idea why, nothing changed for years [1]

Will have to investigate what's going on, being quite confused

[1] Filename for example is /media/exFAT/$\(hostname\)_xbian_image_$\(date\ +%F\).img for example, '(' and ' ' character is escaped and this is the problem

Glad you found what is causig this strange behaviour. I guess I have been lucky in the past where I backed up to a USB-drive as well, but that one was formatted in NTFS, since I used it in Windows before.

Hopefully you can find the root cause. In the mean time, could I manually update the xbian-snap file if only the GUI messes the file (location) up? I guess not, since I see nothing wrong in the file location in this file:
IMGDEST="/media/128gb_ultra/xbmc/backup/$(hostname)_xbian_image_$(date +%F).img"

[Nachteule]

(21st Mar, 2019 08:43 AM)jakenl Wrote:  IMGDEST="/media/128gb_ultra/xbmc/backup/$(hostname)_xbian_image_$(date +%F).img"

Looks ok, thats mine

Code:

IMGDEST="/media/exFAT/$(hostname)_xbian_image_$(date +%F).img"

If backup fails, I suppose you have another issue. On that 128gb_ultra card, backup is used only, right. rootfs is on different device, correct?

[Nachteule]

@jakenl, Update3:

New xbian-package-config-shell online, but unfortunately this version still have an issue when starting backup manually from XBian-config GUI. If starting from cron job, everything is ok now.

New version will be build tonight with fixed issue noted above

[jakenl]

Although i didn't find an update today yet, I checked my backup folder: home is being backed up now for 3 days, system since yesterday, but that can be 2 days as well since it only has 1 to keep. I will now have to change that number directly in the file as well to increase the amount of backups. The GUI doesn't allow me to change that either. Looking forward for the patch.

[Nachteule]

(22nd Mar, 2019 08:43 AM)jakenl Wrote:  Although i didn't find an update today yet, I checked my backup folder: home is being backed up now for 3 days, system since yesterday, but that can be 2 days as well since it only has 1 to keep. I will now have to change that number directly in the file as well to increase the amount of backups. The GUI doesn't allow me to change that either. Looking forward for the patch.

Yeah, that's weird. Package was built 17:13 yesterday and uploaded (saw it in the log) to apt server, but never arrived
Very strange.

Built again incl. latest patch, and now it IS online

Maybe Jenkins knew that there was still one issue in

[jakenl]

At the end I got it working.

In the GUI I didn't see the updates that I was looking for. Only a whole bunch of PHP7.3 (that I need to run a webpage) updates. In xbian-config on the commandline I found the ones that we were looking for.

After a reboot, a black screen, not even a cursor blinking.
I flashed yesterdays image on the stick from the other USB stick, but that didn't boot either.
Than I checked the cmdline.txt from the SD-card, it gave a root=dev/sda1, while I was pretty sure I renamed it to root=LABEL=xbian-copy
Changing it to the default SD-card location made it boot from the SD-card altogether.
With lsblk I figured out what drive indication the OS-USB stick was: /dev/sda1 for xbian-boot and /dev/sda2 for xbian-copy (both generated by the available option in xbian-config to make a copy from SD-card to USB.
Only when I updated the cmdline.txt to root=/dev/sda2 my system booted again. Very weird, since I would say that A: shouldn't it boot from the /dev/sda1? B: /dev/sda2 should be equal to LABEL=xbian-copy (which I thought to be more robust than a possible changing designation of drive letter or changing UUID when I replace the OS-USB stick.

Anyway, handling backup through the GUI works fine now. I was glad that 'behind the screens' it worked already before, since I could use it today. Although, at the end I changed on the SD-card the cmdline.txt, which was saved last on March 4th, therefore not changed by the updates. Very strange that I had to modify from /dev/sda1 to /dev/sda2.

[Nachteule]

(23rd Mar, 2019 07:32 AM)jakenl Wrote:  At the end I got it working.

Congratulations

Quote:Anyway, handling backup through the GUI works fine now. I was glad that 'behind the screens' it worked already before, since I could use it today. Although, at the end I changed on the SD-card the cmdline.txt, which was saved last on March 4th, therefore not changed by the updates. Very strange that I had to modify from /dev/sda1 to /dev/sda2.

The explanation is simple:
If you reflash your stick from an image backup, you will get /boot partition (at /dev/sdX1) and your root partition (at /dev/sdX2). That's why you have to change the root= assignment in /boot/cmdline.txt

[Nachteule]

Ah, I forgot, thanks for confirming that your issue has been solved

[jakenl]

(23rd Mar, 2019 10:02 AM)Nachteule Wrote:  Ah, I forgot, thanks for confirming that your issue has been solved

All thanks to you for your time looking into this issue and the quick solution. I doubt whether there is any commercial company around that would do a better job here.

[jakenl]

While having issues with the latest updates I decided to update just those packages that were not likely to be the cause of 'not-outputting-HDMI'. I have to do that one by one. So, after a while these packages were OK and a reboot worked fine. I decided to do a manual backup of the system partition, by going into the menu of Xbian / backup /system. The backup starts and runs for a while, but ends with this text:
Cloning root/@, 1075752240 of 1120575251, 96% done (last one with a lot of predecessors with lower percentages)
Cloning subvolume root snapshot @ failed
Operation failed with error E_COPY_DATA

The automatic updates work fine, I had to use the latest backup to get the system back up and running again. For now, I will just wait for the weekly automatic backup before I try to installed the suspected packages.