Bug 581204

dracut-005-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/dracut-005-2.fc12

dracut-005-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/dracut-005-2.fc12

I appreciate your taking the time to add the btrfs module to the above update (dracut-005-2.fc12), but it did not fix the problem. I installed it, recreated the initram, rebooted, and when I tried mounting a btrfs raid filesystem, it gave me the same error as before.

After reading the changelog in the package, I think there may be some confusion here. This bug is _not_ about loading the btrfs module. Dracut already takes care of this. This bug is about using btrfsctl (btrfs control) to scan for devices, specifically for multi-devices (raid). Single devices take care of themselves.

When I say btrfs "raid," I am actually referring to btrfs multi-devices which are just btrfs filesystems using either mirroring and/or striping of data to multiple devices, exclusive of dmraid, lvm, or other methods. They are self contained.

You can refer to the btrfs wiki for more about btrfs multi-devices (raid).

https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices#Finding_and_Listing_Multi-device_Filesystems

I'll just say it's confusing. I don't know of another filesystem that works fine with single devices, but then requires a scan for filesystems using more than one device. It's usually one or the other.

Eventually they will fix it, according to the mailing list. For now we'll have to use this fix.

Here is an explanation of the fixes for 90btrfs, in both btrfsctl.git (git patch for upstream against commit 7f0066987 "nfs: fixed nsswitch.conf parsing") and updated 0005-add-module-btrfs.patch (for rpm):

1. Don't call 'btrfs' (a binary that does not exist) in the check, install, and udev files of 90btrfs. This should be btrfsctl. I got the udev info from http://article.gmane.org/gmane.comp.file-systems.btrfs/3589/match=btrfsctl+raid.

2. Changed the comment about "dmraid" in check. Probably just left in there, but still don't want to confuse the users and have dmraid get bug reports about btrfs.


Other things that still need fixing:

1. Both of the files 'check' and 'install' are getting the wrong perms of 644. The patch says they should be 755 (which is right), but installing and/or opening the dracut-005-2.fc12 rpm above shows 644.

2. The changelog in dracut.spec should show that this change is in reference to btrfsctl. Like,

 - Added btrfsctl scan for btrfs multi-devices (raid)

Created attachment 407008 [details]
0005-add-btrfs-module.patch with btrfsctl changes

Created attachment 407009 [details]
Git patch for upstream

$ rpm -qf /sbin/btrfs
btrfs-progs-0.19-12.fc13.x86_64

$ /sbin/btrfs
Usage:
....
	btrfs device scan [<device> [<device>..]
		Scan all device for or the passed device for a btrfs
		filesystem.
....

dracut-005-2.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update dracut'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/dracut-005-2.fc12

It doesn't work.

Permissions of 90btrfs/check and 90btrfs/install are still 644 in the F12 and F13 rpms posted 2010-04-16 23:17:59 and 2010-04-16 23:19:17.

Trying it out on a F12 machine, I installed btrfs-progs 0.19-12 from Fedora 13 on Fedora 12, since the version for 12 does not include 'btrfs'. Then I installed the dracut update. Had to chmod the check and install files to 755 to get dracut to run the module. Recreated the initram, and rebooted.

Did about the same on F13.

It seems that the btrfs module is not being loaded properly, or is too late? I used my a script instead of udev (I don't know udev, and for me a script is easier to work with), and it gave the error "Cannot find /dev/btrfs-control. Unable to load filesystems" for each btrfs partition (5 in my case). But it doesn't make sense since the btrfs module is already loaded for this machine. It has a btrfs single root, and I was trying to get it to load a btrfs raid10 at /mnt/btrfs.

Using the scan script (instead of a udev file),

90btrfs/install:
#!/bin/sh
dracut_install btrfs
inst_hook mount 90 "$moddir/scan-btrfs.sh"

90btrfs/scan-btrfs.sh:
#!/bin/sh
if [ -n "$root" -a -z "${root%%block:*}" ]; then
  modprobe btrfs
  btrfs device scan
fi

That worked (remove 'modprobe btrfs' and it errors/fails with "Cannot find /dev/btrfs-control"). But we shouldn't have to reload the module. And it's strange that I do not have to do this on my current F12 system. Perhaps there was a change in the btrfs? Loading at the the wrong time? I'll have to look more into it later, or maybe some else knows. I'll post a debug later.


As far as the btrfs vs btrfsctl goes, yes, the 'btrfs' binary is in Fedora 13 and btrfs git, but not in the current Fedora 12 (btrfs-progs-19-9.fc12). A search for btrfs on the above updates page only shows updated rpm versions for Fedora 13. Will we get an updated version in 12?

I see no difference between btrfs and btrfsctl, except for their syntax. btrfs was commited only a month ago, and while it is useful, it's new and may have some bugs. And the commit made it sound like it was for 'ease of use'. There is a possibility of a syntax change, or of finding a bug. btrfsctl and btrfs may get merged.

But if you still would like to use it, that fine. I just want to make sure the pros and cons are stated.

Created attachment 409585 [details]
dmesg logs of different dracut btrfs modules on same system.

Contains three logs of tests done on Fedora 13, with root as a multi-device btrfs, and one at /mnt/new. In each test I substituted btrfsctl instead on btrfs only because it gave errors where btrfs was failing silently. I used scripts in the ones that worked, but only to get it up and going. It would be much better to get udev to scan and load the devices, as that would be both dynamic and fast.


btrfs_current_udev: Current dracut-005-2.fc13.noarch rpm, with chmod changes and using btrfsctl. This fails to boot, with either btrfsctl or btrfs.

btrfs_btrfsctl_only: Used 'btrfsctl -a' instead of udev, as is in the attachment 'Module for dracut to scan for btrfs'. System booted fine, but from the log it appears that first it failed to mount root, and then succeeded.

btrfs_modprobe_and_btrfsctl
: Same as above, except issued a 'modprobe btrfs' before the 'btrfsctl -a'. No errors.


Here's information on the system. If you need more info, or for me to try out something, let me know.


# Kernel command line for all three
ro root=UUID=8c224778-7427-423d-85bf-66ebca9cc0ae LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us vga=789 rdshell rdinitdebug


# /etc/fstab
UUID=8c224778-7427-423d-85bf-66ebca9cc0ae /          btrfs   defaults,compress        1 1
UUID=6c74eb99-aee6-4fcf-b3fb-3d118f730264 /boot      ext3    defaults        1 2
UUID=aef3df53-289f-420c-8ed1-a30413f27e9f /mnt/new   btrfs   defaults        1 2


# dmsetup ls --tree
No devices found


# blkid
/dev/sda1: UUID="6c74eb99-aee6-4fcf-b3fb-3d118f730264" TYPE="ext3" 
/dev/sdb1: UUID="aef3df53-289f-420c-8ed1-a30413f27e9f" UUID_SUB="65c80282-671f-42bd-bd32-3c9a90ed123b" TYPE="btrfs" LABEL="data_raid1" 
/dev/loop0: UUID="e92e4684-4731-4839-8b0f-6e3631d1f299" TYPE="swap" 
/dev/sda2: UUID="8c224778-7427-423d-85bf-66ebca9cc0ae" UUID_SUB="99043a48-b840-48cc-a2df-a74e66cbd62a" TYPE="btrfs" 
/dev/sdc1: UUID="8c224778-7427-423d-85bf-66ebca9cc0ae" UUID_SUB="10f54067-5832-44ac-a565-271175b040c7" TYPE="btrfs" 
/dev/sdd1: LABEL="data_raid1" UUID="aef3df53-289f-420c-8ed1-a30413f27e9f" UUID_SUB="6b3af8ff-d9e5-416d-be60-ed8071b29fdc" TYPE="btrfs" 


# blkid -o udev
ID_FS_UUID=6c74eb99-aee6-4fcf-b3fb-3d118f730264
ID_FS_UUID_ENC=6c74eb99-aee6-4fcf-b3fb-3d118f730264
ID_FS_TYPE=ext3
ID_FS_UUID=aef3df53-289f-420c-8ed1-a30413f27e9f
ID_FS_UUID_ENC=aef3df53-289f-420c-8ed1-a30413f27e9f
ID_FS_UUID_SUB=65c80282-671f-42bd-bd32-3c9a90ed123b
ID_FS_UUID_SUB_ENC=65c80282-671f-42bd-bd32-3c9a90ed123b
ID_FS_TYPE=btrfs
ID_FS_LABEL=data_raid1
ID_FS_LABEL_ENC=data_raid1
ID_FS_UUID=e92e4684-4731-4839-8b0f-6e3631d1f299
ID_FS_UUID_ENC=e92e4684-4731-4839-8b0f-6e3631d1f299
ID_FS_TYPE=swap
ID_FS_UUID=8c224778-7427-423d-85bf-66ebca9cc0ae
ID_FS_UUID_ENC=8c224778-7427-423d-85bf-66ebca9cc0ae
ID_FS_UUID_SUB=99043a48-b840-48cc-a2df-a74e66cbd62a
ID_FS_UUID_SUB_ENC=99043a48-b840-48cc-a2df-a74e66cbd62a
ID_FS_TYPE=btrfs
ID_FS_UUID=8c224778-7427-423d-85bf-66ebca9cc0ae
ID_FS_UUID_ENC=8c224778-7427-423d-85bf-66ebca9cc0ae
ID_FS_UUID_SUB=10f54067-5832-44ac-a565-271175b040c7
ID_FS_UUID_SUB_ENC=10f54067-5832-44ac-a565-271175b040c7
ID_FS_TYPE=btrfs
ID_FS_LABEL=data_raid1
ID_FS_LABEL_ENC=data_raid1
ID_FS_UUID=aef3df53-289f-420c-8ed1-a30413f27e9f
ID_FS_UUID_ENC=aef3df53-289f-420c-8ed1-a30413f27e9f
ID_FS_UUID_SUB=6b3af8ff-d9e5-416d-be60-ed8071b29fdc
ID_FS_UUID_SUB_ENC=6b3af8ff-d9e5-416d-be60-ed8071b29fdc
ID_FS_TYPE=btrfs


# brtfs-show (both are raid1)
Label: none  uuid: 8c224778-7427-423d-85bf-66ebca9cc0ae
	Total devices 2 FS bytes used 1.76GB
	devid    1 size 7.23GB used 3.49GB path /dev/sda2
	devid    2 size 7.36GB used 3.47GB path /dev/sdc1

Label: data_raid1  uuid: aef3df53-289f-420c-8ed1-a30413f27e9f
	Total devices 2 FS bytes used 28.00KB
	devid    1 size 2.00GB used 1.83GB path /dev/sdb1
	devid    2 size 2.00GB used 1.81GB path /dev/sdd1

Btrfs Btrfs v0.19


Versions:
 btrfs-progs-0.19-12.fc13.i686
 udev-151-8.fc13.i686
 dracut-005-2.fc13.noarch

dracut-005-2.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.