Am Wed, 6 Jul 2016 06:26:03 +0200
schrieb Lennart Poettering <lenn...@poettering.net>:
> On Tue, 05.07.16 14:00, Chris Murphy (li...@colorremedies.com) wrote:
>
> > On Tue, Jul 5, 2016 at 12:45 PM, Chris Murphy
> > <li...@colorremedies.com> wrote:
> > > OK it must be this.
> > >
> > > :/# cat /usr/lib/udev/rules.d/64-btrfs.rules
> > > # do not edit this file, it will be overwritten on update
> > >
> > > SUBSYSTEM!="block", GOTO="btrfs_end"
> > > ACTION=="remove", GOTO="btrfs_end"
> > > ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_end"
> > >
> > > # let the kernel know about this btrfs filesystem, and check if
> > > it is complete IMPORT{builtin}="btrfs ready $devnode"
> > >
> > > # mark the device as not ready to be used by the system
> > > ENV{ID_BTRFS_READY}=="0", ENV{SYSTEMD_READY}="0"
> > >
> > > LABEL="btrfs_end"
> >
> > Yep.
> > https://lists.freedesktop.org/archives/systemd-commits/2012-September/002503.html
> >
> > The problem is that with rootflags=degraded it still indefinitely
> > hangs. And even without the degraded option, I don't think the
> > indefinite hang waiting for missing devices is the best way to find
> > out there's been device failures. I think it's better to fail to
> > mount, and end up at a dracut shell.
>
> I figure it would be OK to merge a patch that makes the udev rules
> above set SYSTEMD_READY immediately if the device popped up in case
> some new kernel command line option is set.
>
> Hooking up rootflags=degraded with this is unlikely to work I fear, as
> by the time the udev rules run we have no idea yet what systemd wants
> to make from the device in the end. That means knowing this early the
> fact that system wants to mount it as root disk with some specific
> mount options is not really sensible in the design...
A possible solution could be to fall back to simply announce
SYSTEMD_READY=1 after a sensible timeout instead of waiting forever for
a situation that is unlikely to happen. That way, the system would boot
slowly in the degraded case but it would continue to boot. If something
goes wrong now, it would probably fall back to rescue shell, right?
--
Regards,
Kai
Replies to list-only preferred.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
