Re: Problem: UUIDs not being used everywhere for disks in stretch
On Tue, Jan 15, 2019 at 04:29:36PM +0000, Steve McIntyre wrote:
>I've let this slip off my radar since, and it's not gone away.
>
>I'm seeing this problem really obviously with live installations now,
>as I've just been testing them with Secure Boot.
>
>Hoping to play with this more in the next few days...
OK, I *think* I have worked out the fundamental problem here. I
uploaded an initial fix for #852323 a few weeks back, but it was only
a quick hack (call "udevadm trigger" instead of "udevadm settle")
until I found the time to dig in to the code properly. Now, with a few
hours undisturbed on a long flight, I think I've sussed the root cause
with judicious use of "udevadm monitor", ls and blkid. \o/
It's all down to ordering of events. In /lib/partman/commit.d in d-i,
we have the following ordering at the moment for some of the scripts:
30parted
32update-dev <<----- triggers the udev update
45format_swap
50format_*fs <<----- responsible for running mkfs
It's quite simple. 32update-dev is asking for udev updates, and that
will cause the various /dev/disk/by-*/ symlinks to be updated or
refreshed. But that's the wrong point. In particular for
/dev/disk/bu-uuid, the UUID values themselves come from the filesystem
headers. We *then* make the filesystems for each block device, and
anything that changes at this point will never be represented in the
by-uuid symlinks.
We need to run update-dev *after* the filesystem creation scripts and
this fixes things. I've just copiet it to 99update-dev locally while
testing and that made all the difference. It could probably also just
be moved instead of copied - at this point I'm not sure if anything in
the other scripts also depend on the udev updates for their
functionality. Fundamentally, it's a fairly harmless thing to run
repeatedly so I'm tempted to just run it twice. Thoughts?
So, the question is - how did this *ever* work on older versions of
d-i (Jessie and earlier)? I honestly can't see how it could, so I'm
going to hand-wave and say "timing". If the udev update code took
longer to run, *maybe* the first bit of filesystem creation steps
would have already run by the time the by-uuid symlinks were
made. After all, it's only looking at the filesystem headers so it
wouldn't matter if a long, slow mkfs for a big device was still
going. I know that the systemd folks have put a lot of effort into
making udev more streamlined over the last few years and *maybe* this
has just exposed an underlying bug we've had for ages.
[ Hitting send on this mail now on the plane while I have all this
fresh in my head, even if it's not going to hit network for a few
hours yet! ]
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"Arguing that you don't care about the right to privacy because you have
nothing to hide is no different than saying you don't care about free
speech because you have nothing to say."
-- Edward Snowden
Reply to: