#408 Issue `closed`: No layout recreation code generated for btrfs fs on Debian testing¶

Labels: enhancement, bug, fixed / solved / done

ypid opened issue at 2014-05-05 10:47:¶

Hi

During migration with ReaR I noticed that there was not layout generation code for my root filesystem which is btrfs. Also, because of the disk dependency system of ReaR, /boot was also not created (which I could fix by commenting out my root fs from the disklayout.conf file).

I am not sure what the problem is. When I need to migrate (or restore) once again in the future I will further investigate this issue. For now I could fix it by writing the section for the root fs myself.

Also I noticed that ReaR was not able to handle a swap partition, which is encrypted (and created) with a random key on each start. ReaR would have to do nothing more than to create a partition (which is then setup by dm-crypt on startup). The creation (mkswap) is not needed. Maybe possible to add a test for this.

https://github.com/rear/rear/blob/master/usr/share/rear/layout/prepare/GNU/Linux/13_include_filesystem_code.sh

disk /dev/sda 120034123776 msdos
part /dev/sda 499122176 1048576 primary boot /dev/sda1
part /dev/sda 1999634432 500170752 primary none /dev/sda2
part /dev/sda 117533835264 2499805184 primary none /dev/sda3
fs /dev/dm-0 / btrfs uuid=3a5e7bfe-1f80-4843-93f4-48c8670b840c
    devid1size109.46GiBused109.46GiBpath/dev/disk/by-uuid/3a5e7bfe-1f80-4843-93f4-48c8670b840c label= options=rw,noatime,nodiratime,space_cache
fs /dev/sda1 /boot ext4 uuid=308700cb-7c8f-4cec-9d21-dbc77ab3858d label= blocksize=1024 reserved_blocks=4% max_mounts=-1 check_interval=0d bytes_per_inode=4093 default_mount_options=user_xattr,acl options=rw,nosuid,nodev,noexec,noatime,nodiratime,data=ordered
swap /dev/mapper/sda2_crypt uuid=2fb8c04e-9338-4f31-96da-cd6c91968578 label=
crypt /dev/mapper/sda3_crypt /dev/sda3 cipher=aes mode=xts-plain64 hash=sha1 uuid=2be2e1ec-c91f-464f-a296-28ff54c49a77

gdha commented at 2014-05-22 13:01:¶

@ypid interesting. The file for / in disklayout.conf was missing? Perhaps it would be nice to run rear -vdD savelayout so we can see why??

ypid commented at 2014-05-22 16:36:¶

Hi

I hope this helps: https://github.com/ypid/rear_issue_408

gdha commented at 2014-05-23 08:44:¶

ok thanks - I noticed in . /usr/share/rear/layout/save/GNU/Linux/23_filesystem_layout.sh script

2014-05-22 18:31:24.124867867 Mapping /dev/disk/by-uuid/4a453c89-84ba-4426-acbc-459b2afb6abc to /dev/dm-0
++ device=/dev/dm-0
++ echo -n 'fs /dev/dm-0 / btrfs '
++ case "$fstype" in
+++ btrfs filesystem show /dev/dm-0
+++ grep -i uuid
+++ cut -d: -f 3
+++ tr -d ' '
++ uuid='4a453c89-84ba-4426-acbc-459b2afb6abc
    devid1size202.59GiBused202.59GiBpath/dev/disk/by-uuid/4a453c89-84ba-4426-acbc-459b2afb6abc'
+++ btrfs filesystem show /dev/dm-0

the UUID is a bit malformed...

gdha commented at 2014-05-27 13:13:¶

@ypid could you paste the output of the command btrfs filesystem show /dev/dm-0 please?

ypid commented at 2014-05-28 13:20:¶

Sure:

Label: none  uuid: 4a453c89-84ba-4426-acbc-459b2afb6abc
        Total devices 1 FS bytes used 196.08GiB
        devid    1 size 202.59GiB used 202.59GiB path /dev/disk/by-uuid/4a453c89-84ba-4426-acbc-459b2afb6abc

Btrfs v3.14.1

gdha commented at 2014-05-28 13:34:¶

Ok, thanks it is indeed different then on my test system:

# btrfs filesystem show /dev/vda3
Label: rhel_btrfs  uuid: 2c149868-7613-4e0b-b089-21ca4ce05811
        Total devices 1 FS bytes used 877.55MiB
        devid    1 size 10.53GiB used 3.04GiB path /dev/vda3

Btrfs v3.12

ypid commented at 2014-06-09 13:15:¶

I can confirm that the problem still exists with b19c28e883836188a220ae55eb44c0ea44086fdb although the uuid is now correctly extracted.

gdha commented at 2014-06-25 14:32:¶

@ypid how does the disklayout file looks now? And were does it block for you (during recover)?

ypid commented at 2014-06-25 19:21:¶

I added debug logs using the current version. Not sure when I find the time to test a restore again.

ypid commented at 2014-07-03 21:51:¶

I added the layout files generated during recover.

gdha commented at 2015-06-03 11:04:¶

@ypid Were you able to test rear-1.17.0 already on Debian with btrfs? Does it work now or is it still an issue?

ypid commented at 2015-06-03 11:21:¶

I might be able to test this in a few months as I don’t have rear setup currently.

jsmeix commented at 2016-09-21 13:09:¶

No further feedback sinde more than one year and
meanwhile I implemented generic support for btrfs
so that it should basically work (at least it works
for the relatively comlicated SLES btrfs structure).

I think we can close it as "fixed".
If needed it can be reopened.

[Export of Github issue for rear/rear.]

#408 Issue closed: No layout recreation code generated for btrfs fs on Debian testing¶