Btrfs devel - Mar 2012 - "Invalid argument" when mounting a btrfs raid1 filesystem

Hello,

I''m trying to install current Debian testing (=kernel version 3.2) with
btrfs as the root file system.  There is also a small ext3 /boot
partition.

I create a btrfs raid1 file system with the command

mkfs.btrfs -d raid1 /dev/sda2 /dev/sdb2

Then I can mount it and finish the installation successfully.  Booting
doesn''t work, however: initrd complains that it cannot mount /dev/sda2:
"Invalid argument".

The funny thing is, that in the initrd console I can mount /dev/sdb2!
So I changed the kernel parameter in grub.cfg to mount /dev/sdb2
instead, but the problem persists: Now I can mount /dev/sda2 in the
initrd console!

In fact, when I boot a rescue system from a thumbdrive, the same thing
happens:

# mount -t btrfs /dev/sda2 /mnt
mount: mounting /dev/sda2 on /mnt failed: Invalid argument
# mount -t btrfs /dev/sdb2 /mnt
#

When I keep trying to mount the same device, it keeps failing.  When I
start mounting /dev/sdb2, it works for /dev/sda2...

Isn''t this very weird?  Any ideas?

thanks,
Christoph

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Christoph Groth wrote (ao):
> I''m trying to install current Debian testing (=kernel version 3.2)
with
> btrfs as the root file system.  There is also a small ext3 /boot
> partition.
> 
> I create a btrfs raid1 file system with the command
> 
> mkfs.btrfs -d raid1 /dev/sda2 /dev/sdb2
> 
> Then I can mount it and finish the installation successfully.  Booting
> doesn''t work, however: initrd complains that it cannot mount
/dev/sda2:
> "Invalid argument".
> 
> The funny thing is, that in the initrd console I can mount /dev/sdb2!
> So I changed the kernel parameter in grub.cfg to mount /dev/sdb2
> instead, but the problem persists: Now I can mount /dev/sda2 in the
> initrd console!
> 
> In fact, when I boot a rescue system from a thumbdrive, the same thing
> happens:
> 
> # mount -t btrfs /dev/sda2 /mnt
> mount: mounting /dev/sda2 on /mnt failed: Invalid argument
> # mount -t btrfs /dev/sdb2 /mnt
> #
> 
> When I keep trying to mount the same device, it keeps failing.  When I
> start mounting /dev/sdb2, it works for /dev/sda2...
> 
> Isn''t this very weird?  Any ideas?
You might need ''btrfs device scan'' before you can mount a
multi-device
filesystem.

	Sander

-- 
Humilis IT Services and Solutions
http://www.humilis.net
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Sat, Mar 24, 2012 at 06:40:27PM +0100, Christoph Groth
wrote:
> Hello,
> 
> I''m trying to install current Debian testing (=kernel version 3.2)
with
> btrfs as the root file system.  There is also a small ext3 /boot
> partition.
> 
> I create a btrfs raid1 file system with the command
> 
> mkfs.btrfs -d raid1 /dev/sda2 /dev/sdb2
> 
> Then I can mount it and finish the installation successfully.  Booting
> doesn''t work, however: initrd complains that it cannot mount
/dev/sda2:
> "Invalid argument".
> 
> The funny thing is, that in the initrd console I can mount /dev/sdb2!
> So I changed the kernel parameter in grub.cfg to mount /dev/sdb2
> instead, but the problem persists: Now I can mount /dev/sda2 in the
> initrd console!
> 
> In fact, when I boot a rescue system from a thumbdrive, the same thing
> happens:
> 
> # mount -t btrfs /dev/sda2 /mnt
> mount: mounting /dev/sda2 on /mnt failed: Invalid argument
> # mount -t btrfs /dev/sdb2 /mnt
> #
> 
> When I keep trying to mount the same device, it keeps failing.  When I
> start mounting /dev/sdb2, it works for /dev/sda2...
> 
> Isn''t this very weird?  Any ideas?
   As Sadner says, you have to run "btrfs dev scan" before you try to
mount the FS. If you have root on btrfs, this will have to go in an
initrd; otherwise, it can go in your initscripts anywhere before the
non-root filesystem mounts.

   Basically, the kernel needs to know which devices hold which btrfs
filesystems (organised by UUID) before it tries to mount them. So,
there''s an ioctl that is used for sending that data to the kernel, and
a userspace tool (btrfs dev scan) that enumerates all of the block
devices it can see, looks for a btrfs superblock on them, and tells
the kernel.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ==  PGP
key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
        --- Have found Lost City of Atlantis.  High Priest is ---        
                           winning at quoits.

Hugo Mills <hugo <at> carfax.org.uk> writes:

>    Basically, the kernel needs to know which devices hold which btrfs
> filesystems (organised by UUID) before it tries to mount them. So,
> there''s an ioctl that is used for sending that data to the kernel,
and
> a userspace tool (btrfs dev scan) that enumerates all of the block
> devices it can see, looks for a btrfs superblock on them, and tells
> the kernel.
> 
>    Hugo.
> 
If you install the package btrfs-tools (currently dated 5 November 2011 in
unstable), it''ll set up the necessary.


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

>>    Basically, the kernel needs to know which devices hold which btrfs
>> filesystems (organised by UUID) before it tries to mount them. So,
>> there''s an ioctl that is used for sending that data to the
kernel,
>> and a userspace tool (btrfs dev scan) that enumerates all of the
>> block devices it can see, looks for a btrfs superblock on them, and
>> tells the kernel.
>> 
>>    Hugo.
Thanks for the quick help!  I guess that error message ("Invalid
argument") could be made more to the point...

Alex <alex@bpmit.com> writes:
> If you install the package btrfs-tools (currently dated 5 November
> 2011 in unstable), it''ll set up the necessary.
The proper btrfs-tools package was already installed by debian-installer
(currently the version in testing is the same as in unstable).
Apparently the initrd.img put in place by the installer was not doing
what it should.  (I''m not sure whether initrd.img is built during
installation or whether just some common one is installed.)

I did the following to get a system that boots:

(1) Use the rescue mode of the installation medium to get a shell with
    /dev/sda2 mounted as root.

(2) Run "update-initramfs -u" to update initrd.img

(3) Run "update-grub" (Not sure whether this was necessary)

(4) Modify /etc/fstab such that the line for the root FS ends with "0
0"
    and not with "0 1".  This is to make the system bootable even when
    there is no btrfs.fsck.

After a reboot, things started working properly.

Christoph

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Sat, Mar 24, 2012 at 06:21:05PM +0000, Hugo Mills
wrote:
>    As Sadner says, you have to run "btrfs dev scan" before you
try to
> mount the FS. If you have root on btrfs, this will have to go in an
> initrd; otherwise, it can go in your initscripts anywhere before the
> non-root filesystem mounts.
> 
>    Basically, the kernel needs to know which devices hold which btrfs
> filesystems (organised by UUID) before it tries to mount them. So,
> there''s an ioctl that is used for sending that data to the kernel,
and
> a userspace tool (btrfs dev scan) that enumerates all of the block
> devices it can see, looks for a btrfs superblock on them, and tells
> the kernel.
 Please, move all this logic to udev rules where we already scans all
 devices. It''s really bad to scan all device more than once. We spent
 years to fix this problem for LVM, I don''t think that btrfs has to
 repeat the same mistakes.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, 2012-03-26 at 10:51 +0200, Karel Zak wrote:
> On Sat, Mar 24, 2012 at 06:21:05PM +0000, Hugo Mills wrote:
> >    As Sadner says, you have to run "btrfs dev scan" before
you try to
> > mount the FS. If you have root on btrfs, this will have to go in an
> > initrd; otherwise, it can go in your initscripts anywhere before the
> > non-root filesystem mounts.
> > 
> >    Basically, the kernel needs to know which devices hold which btrfs
> > filesystems (organised by UUID) before it tries to mount them. So,
> > there''s an ioctl that is used for sending that data to the
kernel, and
> > a userspace tool (btrfs dev scan) that enumerates all of the block
> > devices it can see, looks for a btrfs superblock on them, and tells
> > the kernel.
> 
>  Please, move all this logic to udev rules where we already scans all
>  devices. It''s really bad to scan all device more than once. We
spent
>  years to fix this problem for LVM, I don''t think that btrfs has
to
>  repeat the same mistakes.
Oh, this is already possible to do with udev rules, quite easily. In
fact, dracut ships with the appropriate udev rules, which it uses to
initialize btrfs filesystems in the initramfs:

http://git.kernel.org/?p=boot/dracut/dracut.git;a=blob;f=modules.d/90btrfs/80-btrfs.rules;hb=HEAD

which would be suitable with minor modifications for use in a system
udev installation as well.

-- 
Calvin Walton <calvin.walton@kepstin.ca>

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Am Montag, 26. März 2012 schrieb Calvin Walton:
> On Mon, 2012-03-26 at 10:51 +0200, Karel Zak wrote:
> > On Sat, Mar 24, 2012 at 06:21:05PM +0000, Hugo Mills wrote:
> > >    As Sadner says, you have to run "btrfs dev scan"
before you try
> > >    to
> > > 
> > > mount the FS. If you have root on btrfs, this will have to go in
an
> > > initrd; otherwise, it can go in your initscripts anywhere before
> > > the non-root filesystem mounts.
> > > 
> > >    Basically, the kernel needs to know which devices hold which
> > >    btrfs
> > > 
> > > filesystems (organised by UUID) before it tries to mount them.
So,
> > > there''s an ioctl that is used for sending that data to
the kernel,
> > > and a userspace tool (btrfs dev scan) that enumerates all of the
> > > block devices it can see, looks for a btrfs superblock on them,
> > > and tells the kernel.
> >  
> >  Please, move all this logic to udev rules where we already scans all
> >  devices. It''s really bad to scan all device more than once.
We spent
> >  years to fix this problem for LVM, I don''t think that btrfs
has to
> >  repeat the same mistakes.
> 
> Oh, this is already possible to do with udev rules, quite easily. In
> fact, dracut ships with the appropriate udev rules, which it uses to
> initialize btrfs filesystems in the initramfs:
> 
> http://git.kernel.org/?p=boot/dracut/dracut.git;a=blob;f=modules.d/90bt
> rfs/80-btrfs.rules;hb=HEAD
> 
> which would be suitable with minor modifications for use in a system
> udev installation as well.
I reported this for Debian long time ago as:

please support raid configurations automatically
http://bugs.debian.org/bug=634658

I will be forwarding your mail to the bug report as to suggest this udev 
based solution.

I has also been reported as:

btrfs-tools: add initramfs boot and hook scripts
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559710

please provide non-initramfs-tools integration
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585568

Thanks,
-- 
Martin ''Helios'' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html