On Mon, Apr 15, 2024 at 03:02:25PM +0200, Sven wrote: >> Yea, the early lookup behavior is weird. But it also dates back >> a long time, so I'm not sure this changed, except for maybe timings? > > This might just be a timing change. I don't know. As mentioned in the > initial email, this change looks relevant: > https://lore.kernel.org/all/20230531125535.676098-19-hch@xxxxxx/ Well, only in terms of timing. But as asked before, any chance you could try to bisect the issue? >> If you go down the device open route it should us the kernel open >> routins and not just the not open ones. > > OK. Would you mind elaborating why? Because the no open ones are competely internal. >> That being said the right >> fix is to not use this code at all, which was only shoe horned together >> and doesn't have a chance to work solidly and just wait for the >> device in userspace because we do have reliably udev events there. > > I cannot wait for user space because my root device is dm-verity-backed > which is why I am using dm-init in the first place. And I am not using an > initramfs. But that's exactly the use case the initramfs is made for. > Isn't the point of dm-init to be able to use e.g. dm-verity for > the root device or did I misunderstand the docs? It's sort of the point, but dm-init is a really broken concept and should never have been merged as the whole early bdev lookup is a hack and only works outside the core init code by accident.
