[systemd-devel] timed out waiting for device dev-disk-by\x2duuid
Chris Murphy
lists at colorremedies.com
Thu May 15 14:54:05 PDT 2014
On May 15, 2014, at 2:57 PM, Goffredo Baroncelli <kreijack at libero.it> wrote:
> On 05/15/2014 08:16 PM, Lennart Poettering wrote:
>> 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:
>>>
> [...]
>>
>> 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?
>
> In what this should be different than the normal RAID system ?
I think it's because with md, the array assembly is separate from fs mount. I don't know what timeout it uses, but it does do automatic degraded assembly eventually. Once assembled (degraded or normal) then the md device is "ready" and that's when udev rules start to apply and systemd will try to mount root fs.
However on Btrfs, the degraded assembly and fs mount concepts are combined. So without degraded assembly first, it sounds like udev+systemd don't even try to mount the fs.
At least that's my rudimentary understanding.
The udev rule right now is asking if all Btrfs member devices are present and it sounds like that answer is no with a missing device; so a mount isn't even attempted by systemd rather than attempting a degraded mount specifically for the root=UUID device(s).
What is parsing the boot parameters ro, root=, and rootflags=? Are those recognized by the kernel or systemd?
>
> In both case there are two timeout: the first one is for waiting the full system, the second one is for the minimal set of disks to a degraded mode. If even the second timeout is passed, then we should consider the filesystem not build-able.
> How it is handle for the RAID system ? Knowing that we should consider to apply the same strategies fro btrfs (may be we need some userspace tool to do that)
Well that sounds like a user space tool to be in the initramfs so it can do this logic before systemd even attempt to mount rootfs. Or it's done by kernel code if it's possible for it to parse root=UUID and only care about the member devices for that volume.
Chris Murphy
More information about the systemd-devel
mailing list