On 2/2/21 2:13 PM, Jeremy Linton wrote:
Hi,
On 2/2/21 1:46 PM, Alan Perry wrote:
On 2/2/21 1:55 AM, Lennart Poettering wrote:
On Mo, 01.02.21 16:36, Alan Perry (alanp@xxxxxxxxxxxxx) wrote:
Hi, Per the udev rules, the blkid builtin is run on mmcblk*boot*
devices to look for partition and filesystem. Those devices contain
hardware-specific boot information and are unlikely to have
anything on them that blkid would identify. Why isn't there a rule
to exclude them from blkid? Is there some case that I am missing?
Probably noone who cares about MMC enough prepped a patch for this
so far. Also it probably doesn't matter too much... I mean, if blkid
doesn't find anything it doesn't find anything, so not much bad
happened? If this matters to you, and it's really clear that there
is unlikely anything blkid-recognizable on it, then by all means,
please send a PR!
I have been looking into a problem that we occasionally see with
hangs at boot time during the probe of
mmcblk0boot0. Doing some searching, I have seen reports of similar
hangs over the years, so I see a
potential benefit of not doing the probe.
Is the blkid/libblkid code robust enough that it could sanely handle
whatever hardware-specific collection of
bits representing the boot configuration that happens to be there?
Well I guess someone could put something like an efi system partition
on a mmc boot. In which case you would want to probe it.
Yes, but that would seem to be the exception to how it is used. Looking
through u-boot code, it has been used for bootloader executable images
and/or boot info data and parameters.It seems to me that the prudent
thing to do would be to not probe it by default.
OTOH, this really sounds like a determination of why the system is
hanging when its touching those partitions is in order.
(hang as in, does the kernel have a bug, or is it trying to update a
fat/etc dirty bit on a read only partition, etc?)
What I have observed is that a udevd worker thread initiates built-in
blkid and displays nothing else after that. I am still investigating
that part and don't know if it is in the kernel or libblkid or
elsewhere. From systemd's perspective, boot does not complete, because
it is waiting on boot0. However I can run blkid from the shell and it
completes.
But, even if it wasn't hanging, in the typical case it is a waste of
boot time to do blkid probes of these devices.
alan
I had been planning on sending a PR. As I said, the idea seemed so
obvious to me that I wanted to confirm that
it hadn't been considered and rejected at some point in the past
before I did.
As far as the change itself, would it be something as simple as adding:
KERNEL!="mmcblk[0-9]boot[0-9]"
before the last clause of this rule:
# probe filesystem metadata of disks
KERNEL!="sr*", IMPORT{builtin}="blkid"
alan
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
