Am Wed, 6 Jul 2016 06:21:17 +0200 schrieb Lennart Poettering <lenn...@poettering.net>:
> On Mon, 04.07.16 12:32, Chris Murphy (li...@colorremedies.com) wrote: > > > I have a system where I get an indefinite > > > > "A start job is running for dev-vda2.device (xmin ys / no limit)" > > > > Is there a boot parameter to use to change the no limit to have a > > limit? rd.timeout does nothing. When I use rd.break=pre-mount and > > use blkid, /dev/vda2 is there and can be mounted with the same mount > > options as specified with rootflags= on the command line. So I'm not > > sure why it's hanging indefinitely. I figure with > > systemd.log_level=debug and rd.debug and maybe rd.udev.debug I > > should be able to figure out why this is failing to mount. > > It should be possible to use x-systemd.device-timeout= among the mount > options in rootflags= to alter the timeout for the device. > > But what precisely do you expect to happen in this case? You'd simply > choose between "waits forever" and "fails after some time"... A > missing root device is hardly something you can just ignore and > proceed... I think a degraded btrfs is not actually a missing rootfs. Systemd tries to decide between black and white here - but btrfs also knows gray. And I don't mean that systemd should incorporate something to resolve or announce this issue - that's a UI problem: If the device pool is degraded, it's the UI that should tell the user. I think, some time in the future btrfs may automatically fall back to degraded mounts just like software and hardware raid do. Systemd also doesn't decide not to boot in that case (raid) and wait forever for a device that's not going to appear. The problem currently is just that btrfs doesn't go degraded automatically (for reasons that have been outlined in the btrfs list) - systemd apparently should have a way to work around this. The degraded case for btrfs is already covered by the fact that you need to supply degraded to rootflags on the kernel cmdline - otherwise mounting will fail anyways, no matter if systemd had a workaround or not. So the UI part is already covered more or less. I don't think that incorporating rootflags into "btrfs ready" decision is going to work. And as I understand, using device-timeout will just turn out as a missing rootfs after timeout and the degraded fs won't be marked as ready by it. So btrfs maybe needs a special timeout handling for "btrfs ready", as I wrote in the other post of this thread. -- Regards, Kai Replies to list-only preferred. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
