On Fri, 2020-10-16 at 19:02 +0200, Michał Zegan wrote:
> As a workaround I am almost sure you can instruct dracut to include
> the file, can't you?
Hi Michal,
Yes you are right. I've got it working reliably by doing:
$ sudo dracut --add btrfs --force
Thank you for the prompt!
Cheers, Dan
On Fri, 2020-10-16 at 15:16 +0200, Lennart Poettering wrote:
> So the btrfs ready ioctl is called and the device considered by the
> kernel btrfs implementation to be ready
> (i.e. assembled from all component devices) with this line:
>
> [ 27.804250] systemd-udevd[712]: sde:
>
16.10.2020 18:51, Lennart Poettering пишет:
>>
>> Ths btrfs udev rule file appears to be missing in the initrd. The
>> block devices with the btrfs file systems on them will thus be marked
>> ready in systemd instantly instead of being delayed until all other
>> devices of the same btrfs fs have
As a workaround I am almost sure you can instruct dracut to include the
file, can't you?
W dniu 16.10.2020 o 17:45, Lennart Poettering pisze:
> On Fr, 16.10.20 16:26, Daniel J. R. May (daniel@danieljrmay.com) wrote:
>
>> On Fri, 2020-10-16 at 15:16 +0200, Lennart Poettering wrote:
>>> So the
On Mon, 12 Oct 2020 14:42:18 -0600 Chris Murphy wrote:
> I'll have him retry with udev.log_priority=debug and if I get a moment
> I'll try to reproduce. The difficulty is reproducing truly missing
> devices is easy and appears to work, whereas in this case they are
> merely late being scanned for
On Fr, 16.10.20 17:45, Lennart Poettering (lenn...@poettering.net) wrote:
> > 2. Debugging with "rd.udev.debug systemd.log_level=debug":
> > The same 10 HDD BTRFS volume with 4 drives connected to the motherboard
> > and 6 drives connected to the HBA *fails* to mount automatically at boot
> >
On Fr, 16.10.20 16:26, Daniel J. R. May (daniel@danieljrmay.com) wrote:
> On Fri, 2020-10-16 at 15:16 +0200, Lennart Poettering wrote:
> > So the btrfs ready ioctl is called and the device considered by the
> > kernel btrfs implementation to be ready
> > (i.e. assembled from all component
On Mo, 12.10.20 14:42, Chris Murphy (li...@colorremedies.com) wrote:
> > When precisely it returns success or failure is entirely up to the btrfs
> > kernel
> > code. systemd/udev doesn't have any control on that. The udev btrfs
> > builtin is too trivial for that: it just calls the ioctl and
On Fr, 16.10.20 13:21, Daniel J. R. May (daniel@danieljrmay.com) wrote:
> Log available here:
> https://drive.google.com/file/d/1-x26JS5gcZxwZx7zWoKduEg9ycwUHKqO/view?usp=sharing
So the btrfs ready ioctl is called and the device considered by the
kernel btrfs implementation to be ready
On Mon, Oct 12, 2020 at 1:33 AM Lennart Poettering
wrote:
>
> On So, 11.10.20 14:57, Chris Murphy (li...@colorremedies.com) wrote:
>
> > Hi,
> >
> > A Fedora 32 (systemd-245.8-2.fc32) user has a 10-drive Btrfs raid1 set
> > to mount in /etc/fstab:
> >
> > UUID=f89f0a16- /srv btrfs
On Sun, Oct 11, 2020 at 11:56 PM Andrei Borzenkov wrote:
>
> 11.10.2020 23:57, Chris Murphy пишет:
> > Hi,
> >
> > A Fedora 32 (systemd-245.8-2.fc32) user has a 10-drive Btrfs raid1 set
> > to mount in /etc/fstab:
> >
> > UUID=f89f0a16- /srv btrfs defaults,nofail,x-systemd.requires=/
> > 0
On So, 11.10.20 14:57, Chris Murphy (li...@colorremedies.com) wrote:
> Hi,
>
> A Fedora 32 (systemd-245.8-2.fc32) user has a 10-drive Btrfs raid1 set
> to mount in /etc/fstab:
>
> UUID=f89f0a16- /srv btrfs defaults,nofail,x-systemd.requires=/
> 0 0
>
> For some reason, systemd is trying to
11.10.2020 23:57, Chris Murphy пишет:
> Hi,
>
> A Fedora 32 (systemd-245.8-2.fc32) user has a 10-drive Btrfs raid1 set
> to mount in /etc/fstab:
>
> UUID=f89f0a16- /srv btrfs defaults,nofail,x-systemd.requires=/
> 0 0
>
> For some reason, systemd is trying to mount this file system before
Hi,
A Fedora 32 (systemd-245.8-2.fc32) user has a 10-drive Btrfs raid1 set
to mount in /etc/fstab:
UUID=f89f0a16- /srv btrfs defaults,nofail,x-systemd.requires=/ 0 0
For some reason, systemd is trying to mount this file system before
all ten devices are ready. Supposedly this rule applies:
14 matches
Mail list logo
