Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

No layout recreation code generated for btrfs fs on Debian testing #408

Closed
ypid opened this issue May 5, 2014 · 13 comments
Closed

No layout recreation code generated for btrfs fs on Debian testing #408

ypid opened this issue May 5, 2014 · 13 comments
Assignees
@gdha @jsmeix
Labels
bug The code does not do what it is meant to do enhancement Adaptions and new features fixed / solved / done

Comments

@ypid
Copy link
Contributor

ypid commented May 5, 2014

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
@ypid ypid mentioned this issue May 5, 2014
Merged
@ypid ypid changed the title No layout recreation code generated for btrfs fs on Debina testing No layout recreation code generated for btrfs fs on Debian testing May 5, 2014
@gdha
Copy link
Member

gdha commented May 22, 2014

@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
Copy link
Contributor Author

ypid commented May 22, 2014

Hi

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

@gdha
Copy link
Member

gdha commented May 23, 2014

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 gdha added the bug label May 23, 2014
@gdha gdha self-assigned this May 23, 2014
@gdha
Copy link
Member

gdha commented May 27, 2014

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

@ypid
Copy link
Contributor Author

ypid commented May 28, 2014

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
Copy link
Member

gdha commented May 28, 2014

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

gdha added a commit that referenced this issue May 28, 2014
@gdha
23_filesystem_layout.sh: fix btrfs uuid grabbing
dd20fc8 
see issue #408
gdha added a commit that referenced this issue Jun 2, 2014
@gdha
adding -f option to mkfs.btrfs - see issue #415; appended : to uuid g…
32c4c0a 
…rep (issue #408)
@ypid
Copy link
Contributor Author

ypid commented Jun 9, 2014

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

@gdha
Copy link
Member

gdha commented Jun 25, 2014

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

@ypid
Copy link
Contributor Author

ypid commented Jun 25, 2014

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

@ypid
Copy link
Contributor Author

ypid commented Jul 3, 2014

I added the layout files generated during recover.

@gdha gdha mentioned this issue Dec 2, 2014
Closed
gdha added a commit that referenced this issue Dec 10, 2014
@gdha
added usr/share/rear/layout/prepare/GNU/Linux/SUSE_LINUX/14_include_m…
8412fc0 
…ount_filesystem_code.sh script

to override the mount_fs function (therefore we start with number 14 instead of 13 so we are sure it gets read after the default mount_fs() function defined in usr/share/rear/layout/prepare/GNU/Linux/13_include_mount_filesystem_code.sh)

This code is coming from J Meixner (see issue #497) read116 fork from SuSe. We are just moving the code from Johannes back into the main stream of rear, but now we extracted the btrfs mount code away from 13_include_filesystem_code.sh into a specific script for SUSE_LINUX called 14_include_mount_filesystem_code.sh;

The purpose is to get one script in the future that could handle all types of btrfs (which I doubt). We also need to think on a Debian specific script to (but that is for later - see issue #408)

Issues #233, #497 and #408
@gdha
Copy link
Member

gdha commented Jun 3, 2015

@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
Copy link
Contributor Author

ypid commented Jun 3, 2015

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

@jsmeix jsmeix added enhancement Adaptions and new features fixed / solved / done and removed waiting for info labels Sep 21, 2016
@jsmeix jsmeix self-assigned this Sep 21, 2016
@jsmeix
Copy link
Member

jsmeix commented Sep 21, 2016

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.

@jsmeix jsmeix closed this as completed Sep 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@gdha gdha

@jsmeix jsmeix

Labels
bug The code does not do what it is meant to do enhancement Adaptions and new features fixed / solved / done
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@gdha @ypid @jsmeix