[PROBLEM] xbiancopy fails after upgrading - Printable Version +- Forum (http://forum.xbian.org) +-- Forum: Software (/forum-6.html) +--- Forum: Configuration (/forum-17.html) +--- Thread: [PROBLEM] xbiancopy fails after upgrading (/thread-2360.html) |
xbiancopy fails after upgrading - jyviko - 21st Jun, 2014 08:17 PM Hi all, First of all I would like to thank all the contributors for building this amazing package. Problem description: I used to utilize the xbian-copier from xbian-config to backup my xbian to an .img file, but after upgrading I am running into an error. I have tried also using Terminal btrfs-auto-snapshot xbiancopy --img /dev/root /media/backup/file.img Any thoughts? Is my filesystem corrupted? Best, Iraklis Software XBian version: XBian v1.0RC2 XBMC version: 13.1 Git:20140604-84725b0 Overclock settings: arm_freq=840, core_freq=275, sdram_freq=400, over_voltage=0 RE: xbiancopy fails after upgrading - IriDium - 22nd Jun, 2014 04:38 AM If it is an external drive, I would unplug it and run some tests on it. Also what is it formatted as? FAT and sometimes FAT32 will cause problems. Can you post the output of dmesg after a bad run if the above doesn't fix the issue. RE: xbiancopy fails after upgrading - mk01 - 22nd Jun, 2014 08:50 AM that indeed looks like it can't prealocate needed space (either hitting limits on FAT or other dump filesystem without trunc support or ... i don't know). RE: xbiancopy fails after upgrading - jyviko - 22nd Jun, 2014 06:11 PM (22nd Jun, 2014 08:50 AM)mk01 Wrote: that indeed looks like it can't prealocate needed space (either hitting limits on FAT or other dump filesystem without trunc support or ... i don't know). IriDium and mk01, Thank you for your reply. I am using a cifs share mount to backup. I can access the share mount with rw access from xbian where there is plenty of disk space. The fstab entry is: Code: //192.168.1.109/OpenShare/Backup/xbian /media/backup cifs guest,uid=1000,iocharset=utf8 0 0 The dmesg that I get after running the command is the following: Code: btrfs: device label xbian-beta2 devid 1 transid 29377 /dev/mmcblk0p2 What I don't understand is that I used to perform successful backups and somehow after a couple of months it stopped working. Any other thoughts? How can I check percolated needed space? Best, JIK (22nd Jun, 2014 06:11 PM)jyviko Wrote:(22nd Jun, 2014 08:50 AM)mk01 Wrote: that indeed looks like it can't prealocate needed space (either hitting limits on FAT or other dump filesystem without trunc support or ... i don't know). UPDATE: I have just changed the fstab and replaced "guest" with a cfis user that has full access, using the following entry: Code: //192.168.1.109/OpenShare/Backup/xbian /media/backup cifs credentials=/root/.smbcredentials,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0 After remounting, I tried once more and although I am getting the same result I got a more detailed error message as shown in the attached image ([attachment=330]). I have checked the dmesg and I now get the following: Code: [ 208.630210] FS-Cache: Netfs 'cifs' registered for caching Any ideas? JIK< RE: xbiancopy fails after upgrading - mk01 - 22nd Jun, 2014 09:22 PM @jyviko if you get loop module loaded, that means space prealocation on created empty file is ok. there are two options when looking at your new screen shot. the error is displaying block device /dev/mapper/p1. but it should have been /dev/mapper/loopXp1 (where X is 0-9). two reasons are coming to my mind: 1) bug of some kind causing not proper detection of used loop device - be sure you run last available xbian-package-config-shell which is 2.1.7-5 at STABLE repo. 2) cifs doesn't support all fs ioctl calls as required by loop and mapper modules. for the 2) you could check manually like this: Code: sudo -i if still ok, create partitions on that loop device and try to format them : Code: losetup -d /dev/loopX RE: xbiancopy fails after upgrading - jyviko - 22nd Jun, 2014 09:53 PM (22nd Jun, 2014 09:22 PM)mk01 Wrote: @jyviko Hi mk01, First of all I had upgraded the version of xbian-package-config-shell to 2.1.7-5 from 2.1.7-4. Then I tried what you suggested and I was able to create a 5Gb and then I successfully created the partitions and formatted them. When looking inside /dev/mapper I can see two loop1p1 and loop1p2. It seems that I am able to create those properly. I tried once more with the xbiancopier and I cannot see loop device inside /dev/mapper. Maybe the script is somewhere broken? Thank you for your support! Best, JIK RE: xbiancopy fails after upgrading - mk01 - 22nd Jun, 2014 10:08 PM somewhere around 2.1.7-3 or -4 I was changing the way how .img size is auto-calculated. maybe that broke something. although I tested without issues for some scenarios. let's try with manually specified img size, then the new calculation is not used and we will see if this is the problem. (also if you can report back - how big is the .img file after the process fails - when started via xbian-config as before)? Code: sudo -i will try to create 2G img without auto calculation. RE: xbiancopy fails after upgrading - jyviko - 23rd Jun, 2014 03:08 AM (22nd Jun, 2014 10:08 PM)mk01 Wrote: somewhere around 2.1.7-3 or -4 I was changing the way how .img size is auto-calculated. maybe that broke something. although I tested without issues for some scenarios. @mk01 This worked and the process moved on. The only problem is that it seems that I have a corrupted folder and I get "NFS Stale File Handle" (which is another issue). Tried to delete it with no luck. I am guessing that I cannot avoid reinstalling xbian from scratch Too bad I cannot backup first. Is there a way that I can make a clean snapshot excluding that offensive folder and continue from there? Best, JIK RE: xbiancopy fails after upgrading - mk01 - 25th Jun, 2014 04:59 AM @jyviko NFS Stale Handle should be caused when snapshot is created, it is being send with btrfs send command but the data are not yet on filesystem itself. That's why btrfs fi sync was added after each btrfs sub snap operation. Strange is that now fresh docs are proposing standard "sync" instead. open /usr/sbin/btrfs-auto-snapshot in any editor (as root) and go searching for "btrfs fi sync". first relevant should be around line 650+. feel free to update the code similar as you see there so try adding after each "btrfs fi sync" one "sync", like this: Code: btrfs sub snap -r "XXXX" "YYY" && btrfs fi sync "YYYY" && sync it will be there maybe on two different places (where "sub snap" operation will be found - although the risky ones should be just those where "btrfs send" follows on the snapshot we just created). please report back. still, we have to fix that autosize calculation anyhow. I will try to reproduce. btw: this is not any rocket science and if you consider you setup important, you can go around those steps manually (what will slow down tempo of transactions and you could be successful). manually simply means like this. also for the poor slow RPI as last resort I would prefer plain partition as destination, not .img file going through loop & mapper etc. let;s say you have USB stick a /dev/sda1. Code: sudo -i and of course iterate the second block for "root" and "modules". the /dev/sda1 filesystem should be bootable the way as your source - meaning rootflags=subvol=root/@,....... root=/dev/sda1 rootfstype=btrfs RE: xbiancopy fails after upgrading - jyviko - 25th Jun, 2014 05:27 AM @mk01 Hi, thank you for your reply. I have changed line 657 and added && sync as follows: Code: btrfs sub snap -r "/tmp/btrfs-source/$v/$s" "/tmp/btrfs-source/$v/$s.ro" && btrfs fi sync "/tmp/btrfs-source/$v/$s.ro" && sync I ran again the xbiancopier and I am still getting the NFS Stale Handle. My guess is that the problem derives from an earlier snapshot and it carried on. I had isolated the problem before by renaming that specific folder and copying a working version. It is the following folder "/usr/share/zoneinfo.old/posix/America" that contains the corrupted files. I cannot even stat them. Any idea would be appreciated. JIK< RE: xbiancopy fails after upgrading - mk01 - 2nd Jul, 2014 10:07 AM (25th Jun, 2014 05:27 AM)jyviko Wrote: I ran again the xbiancopier and I am still getting the NFS Stale Handle. (in between) today I committed slightly modified btrfs-autosnapshot (xbian-package-config-shell package) with those syncs and a bit more checking for failed commands during the script. I cloned (with autosize - so just xbian-config from ssh and specified dest part) 5GB installation to USB stick with no issues. (this doesn't automatically assume I'm right user wrong - just currently I run out of possibilities what can be reason for you to fail. ok for you maybe this historical discrepancies, but I have just read from Iridium that on Cubox-i it is not working at all). Of course try after you clear the problems on fs and report back. BTW: before you try, please DOUBLE CHECK if the destination partition is mounted or not. Should not be. The script is trying to umount it if mounted, but if it is being accessed script can continue without being able to format/mount it and (unfortunately) it is btrfs so any operation like multimounts etc is working so result != 0 is not there for you: be sure you have btrfs-tools higher than 3.14xbian and updated initramfs. if you have keyboard reboot into it, if you don't, modify cmdline.txt as follows: Code: ip=dhcp telnet rescue as you reboot your initramfs shell will be available via telnet. from telnet run btrfs check /dev/XXX (you can first wthout --repair - dry-run) ((when you telnet into it, take over console "busybox conspy -f". after you are done just do exit and boot will continue - but the exit needs to be put from console (you took over))). |