http://bugzilla.opensuse.org/show_bug.cgi?id=908854 --- Comment #1 from Johannes Meixner --- I will try to implement a generic way how to deal with btrfs subvolume structures for the current rear master on GitHub -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=908854 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS --- Comment #3 from Johannes Meixner --- For a first tentative implementation of generic btrfs support see the home:jsmeix/rear1161btrfs in OBS: https://build.opensuse.org/package/show/home:jsmeix/rear1161btrfs It is based on rear-1.16.1-git201412031625.tar.gz and all my changes are in rear-1.16.1-git201412031625.btrfs_generic.diff Currently I have tested it only on SLES12 with btrfs plus an additional harddisk /dev/sdb also with btrfs and with some additional btrfs subvolumes. At least for me "rear recover" seems to have worked (but I did not check all details in the recovered system). In general regarding my "home:jsmeix" project read https://build.opensuse.org/project/show/home:jsmeix I assume there is at least one issue in my tentative implementation: It should fail if there are "weaved btrfs subvolume mounts" which means - a subvolume sv1 on a btrfs on /dev/sdXn is mounted at a mountpoint directory that belongs to a btrfs on /dev/sdYm and - a subvolume sv2 on a btrfs on /dev/sdYm is mounted at a mountpoint directory that belongs to a btrfs on /dev/sdXn in particular when the mountpoint directories are no plain directories but also subvolumes sv3 and sv4 on any of the btrfs filesystems. I will try to address "weaved btrfs subvolume mounts" in 2015. For now: Merry Christmas and a happy New Year! -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=908854 --- Comment #5 from Johannes Meixner --- Meanwhile I have also tested it only on openSUSE13.2 with default btrfs. It works but I found a minor issue: During "rear recover" one gets the following warning: --------------------------------------------------------------------------- btrfsmountedsubvolume entry with empty subvolume_mountpoint or subvolume_mount_options or subvolume_path for /dev/sdXn may indicate an error. --------------------------------------------------------------------------- which is a false-positive in this case (because the subvolume_path gets empty when it is actually '/' but this one is already mounted so that it is correct when it is not mounted again). I fixed it (plus some other minor things) in rear-1.16.1-git201412031625.btrfs_generic.diff which I have in an additional separated source project home:jsmeix/rear1161btrfs2 in OBS: https://build.opensuse.org/package/show/home:jsmeix/rear1161btrfs2 that also builds rear1161btrfs-1.16.1.a-*.noarch RPMs (i.e. same name for the binary RPMs but different source projects). Additionally in home:jsmeix/rear1161btrfs2 there is a new simplified SUSE-btrfs-example.conf which should work both for SLE12 and openSUSE13.2 with btrfs. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=908854 --- Comment #7 from Johannes Meixner --- Hello Gratien, very many thanks for all your efforts to integrate my patch into the mainstream of rear and for your testing! Regaring Fedora: Your current fix for Fedora in 13_include_mount_subvolumes_code.sh via ----------------------------------------------------------------------- if test "$subvolume_path" = "root" ; then ... fi ----------------------------------------------------------------------- is o.k. as band-aid workaround for now to make it work on Fedora but I will try to change it into a generic solution. Assume a non-Fedora admin uses a btrfs subvolume "root" (e.g. he may like to have his /root directory as btrfs subvolume), then your Fedora-specific code may falsely apply. I need to understand what is different in Fedora's btrfs setup that my code which is intended to be generic support for btrfs currently does not work on Fedora. This will taks some time - first and foremost because currently I have to work on issues that are related to SUSE customers and furthermore because I am not yet an experienced Fedora user. Of course my further work will be based on the mainstream of rear. Stay tuned... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=908854 --- Comment #9 from Johannes Meixner --- I implemented generic btrfs support for Fedora in rear-1.16.1-git201501071534.btrfs_generic_fedora.diff which I have in the separated source project home:jsmeix/rear1161git201501071534btrfsFedora in OBS: https://build.opensuse.org/package/show/home:jsmeix/rear1161git201501071534b... It builds rear1161btrfs-1.16.1.fedora-N.M.noarch.rpm RPMs e.g. at http://download.opensuse.org/repositories/home:/jsmeix/openSUSE_Factory/noar... Regardless that it is officially built for openSUSE_Factory I used that RPM for my testing on Fedora 21. See also https://github.com/rear/rear/issues/497 https://github.com/rear/rear/issues/531 https://github.com/rear/rear/issues/532 I don't think that the issues https://github.com/rear/rear/issues/531 https://github.com/rear/rear/issues/532 are caused by my RPM that was officially built for openSUSE_Factory because all RPMs should contain exactly the same bash scripts. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=908854 --- Comment #11 from Johannes Meixner --- Furthermore on openSUSE 13.2 with rear-1.16.1-git201501071534.tar.gz in the current OBS home:jsmeix rear1161git201501071534btrfsFedora there is the new issue https://github.com/rear/rear/issues/533 (the '/sbin/udevadm settle --timeout=20' processes hang). This had worked with rear-1.16.1-git201412031625.tar.gz before in OBS home:jsmeix rear1161btrfs2 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=908854 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #13 from Johannes Meixner --- The issue should be fixed in rear 1.17.0 See http://relax-and-recover.org/documentation/release-notes-1-17 rear 1.17.0 is available in the openSUSE build service for various Linux distributions, see http://relax-and-recover.org/download/ E.g. in the Archiving:Backup:Rear project as source package named rear-1.17.0 and binary (noarch) RPM named "rear" for many Linux distributions e.g. for direct download from http://download.opensuse.org/repositories/Archiving:/Backup:/Rear/ Especially for openSUSE:Factory the development project is Archiving therein the source and binary (noarch) package named "rear" for direct download for several openSUSE and SLE versions from http://download.opensuse.org/repositories/Archiving/ Archiving/rear is submitted to openSUSE:Factory as (currently pending) submitrequest 290978. -- You are receiving this mail because: You are on the CC list for the bug.