[systemd-devel] udev blkid check on mmcblk0boot0 and boot1

[Alan Perry]

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 at snowmoose.com) 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 at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>