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?
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
