grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #39591] grub-mkconfig fails on btrfs raid


From: Andrei Borzenkov
Subject: Re: [bug #39591] grub-mkconfig fails on btrfs raid
Date: Sun, 2 Aug 2015 17:59:16 +0300

В Sat, 1 Aug 2015 08:35:53 -0700
Konstantin Svist <address@hidden> пишет:

> On 08/01/2015 01:01 AM, Andrei Borzenkov wrote:
> > В Fri, 31 Jul 2015 23:41:44 -0700
> > Konstantin Svist <address@hidden> пишет:
> >
> >> On 07/31/2015 11:12 PM, Andrei Borzenkov wrote:
> >>> [Adding grub-devel for wider discussion]
> >>>
> >>> В Fri, 31 Jul 2015 07:13:03 +0000
> >>> Konstantin Svist <address@hidden> пишет:
> >>>
> >>>> Follow-up Comment #3, bug #39591 (project grub):
> >>>>
> >>>> GRUB_DISABLE_LINUX_UUID=true
> >>>>
> >>>> For some reason I preferred not using UUIDs when setting it up, can't 
> >>>> remember
> >>>> why exactly..
> >>>>
> >>> Is it really possible to mount btrfs if only a single device is given? As 
> >>> I understand how multi-device btrfs works, to mount it you need to inform 
> >>> kernel about all (or at least enough) components. Today this is normally 
> >>> done by scanning each device during boot, feeding it to kernel and asking 
> >>> kernel "are there enough devices to attempt mount". This works only with 
> >>> UUID due to the way it is implemented in user space (udev+systemd+dracut).
> >>>
> >>> Passing single individual device as root= will defeat this logic - as 
> >>> soon as device is present user space will believe everything is OK and 
> >>> will try to mount it and likely fails.
> >>>
> >>> IOW - multi-device btrfs must use UUID, at least until something is 
> >>> changed in Linux boot device detection logic.
> >>>
> >>> So the only question for me is - should we fail grub-mkconfig in your 
> >>> case or ignore GRUB_DISABLE_LINUX_UUID and continue? I tend to fail it 
> >>> with clear message.
> >>>
> >>
> >> Excerpt from
> >> https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices:
> >>
> >> Once you create a multi-device filesystem, you can use any device in the
> >> FS for the mount command:
> >>
> >> mkfs.btrfs /dev/sdb /dev/sdc /dev/sde
> > At which point kernel of course knows all devices that are part of new
> > filesystem.
> >
> >> mount /dev/sde /mnt
> >>
> > address@hidden:~/src/systemd> sudo ln -sf /dev/null 
> > /run/udev/rules.d/64-btrfs.rules
> > address@hidden:~/src/systemd> sudo rmmod btrfs
> > rmmod: ERROR: Module btrfs is not currently loaded
> > address@hidden:~/src/systemd> sudo losetup --show -f /tmp/loop0
> > /dev/loop0
> > address@hidden:~/src/systemd> sudo losetup --show -f /tmp/loop1
> > /dev/loop1
> > address@hidden:~/src/systemd> sudo blkid
> > ...
> > /dev/loop0: UUID="9e0de080-b2a0-47a8-b9a0-5a3e12fedee2" 
> > UUID_SUB="d6f072bb-ce32-4d7b-8cc3-31ef4d15a3d8" TYPE="btrfs" 
> > /dev/loop1: UUID="9e0de080-b2a0-47a8-b9a0-5a3e12fedee2" 
> > UUID_SUB="e2fb510e-56ed-4a2f-bce4-e53c1387c8b8" TYPE="btrfs" 
> > address@hidden:~/src/systemd> sudo mount -t btrfs /dev/loop0 /mnt
> > mount: wrong fs type, bad option, bad superblock on /dev/loop0,
> >        missing codepage or helper program, or other error
> >
> >        In some cases useful info is found in syslog - try
> >        dmesg | tail or so.
> > address@hidden:~/src/systemd> sudo mount -t btrfs /dev/loop1 /mnt
> > address@hidden:~/src/systemd> 
> >
> >> IOW, this is normal operation for Btrfs. Maybe not for other RAIDs...
> >>
> > Mounting multi-device btrfs requires explicit cooperation from user
> > space. There is no magic kernel can use to know all other devices.
> >
> 
> 
> What about
> https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices#Device_scanning
> ?

What about it?

You told initrd to wait for one device only; as soon as this device is
present systemd will attempt to mount. If you are lucky and other
devices had been scanned at this point, mount succeeds; if not, mount
fails. This is inherent race condition.

If using UUID, mount will be attempted only after enough devices have
been seen.

It all depends on initrd implementation, but we have no idea about it.
So we should use conservative defaults.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]