[systemd-devel] timed out waiting for device dev-disk-by\x2duuid

Lennart Poettering lennart at poettering.net
Thu May 15 11:16:18 PDT 2014


On Thu, 15.05.14 19:29, Lennart Poettering (lennart at poettering.net) wrote:

> On Mon, 12.05.14 20:48, Chris Murphy (lists at colorremedies.com) wrote:
> 
> > Two device Btrfs volume, with one device missing (simulated) will not
> > boot, even with rootflags=degraded set which is currently required to
> > enable Btrfs degraded mounts. Upon reaching a dracut shell after
> > basic.target fails with time out, I can mount -o subvol=root,degraded
> > and exit and continue boot normally with just the single device.
> > 
> > The problem seems to be that systemd (udev?) is not finding the volume
> > by uuid for some reason, and therefore not attempting to mount it. But
> > I don't know why it can't find it, or even how the find by uuid
> > mechanism works this early in boot. So I'm not sure if this is a
> > systemd or udev bug, or a dracut, or kernel bug.
> > 
> > The problem happens with systemd 208-9.fc20 with kernel
> > 3.11.10-301.fc20, and systemd 212-4.fc21 and kernel
> > 3.15.0-0.rc5.git0.1.fc21.
> 
> As soon as btrfs reports that a file system is ready, systemd will pick
> it up. This is handled with the "btrfs" udev built-in, and invoked via
> /usr/lib/udev/rules.d/64-btrfs.rules. rootflags has no influence on
> that, as at that point it is not clear whether the block device will be
> the once that carries the root file system, or any other file system.
> 
> Not sure what we should be doing about this. Maybe introduce a new
> btrfs=degraded switch that acts globally, and influences the udev built-in?
> 
> Kay?

So, as it turns out there's no kernel APi available to check whether a
btrfs raid array is now complete enough for degraded mode to
succeed. There's only a way to check whether it is fully complete.

And even if we had an API for this, how would this even work at all? I
mean, just having a catchall switch to boot in degraded mode is really
dangerous if people have more than one array and we might end up
mounting an fs in degraded mode that actually is fully available if we
just waited 50ms longer...

I mean this is even the problem with just one array: if you have
redundancy of 3 disks, when do you start mounting the thing when
degraded mode is requested on the kernel command line? as soon as
degrdaded mounting is possible (thus fucking up possible all 3 disks
that happened to show up last), or later?

I have no idea how this all should work really, it's a giant mess. There
probably needs to be some btrfs userspace daemon thing that watches
btrfs arrays and does some magic if they timeout.

But for now I am pretty sure we should just leave everything in fully
manual mode, that's the safest thing to do...

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list