[OE-core] udev + 60-persistent-storage.rules + IDE

Bruce Ashfield bruce.ashfield at gmail.com
Thu Sep 17 12:24:02 UTC 2015


On Thu, Sep 17, 2015 at 2:44 AM, Patrick Ohly <patrick.ohly at intel.com> wrote:
> On Wed, 2015-09-16 at 14:11 +0200, Patrick Ohly wrote:
>> I just noticed that udev (no longer) creates /dev/disk/by-uuid links for
>> my boot partition under qemu when booting a whole-disk image
>> (hdddirect). The device is then /dev/hda, with /dev/hda2 being the root
>> partition.
>>
>> systemd's 60-persistent-storage.rules indeed skips the relevant rules
>> because "hd" is not listed:
>>
>> KERNEL!="loop*|mmcblk*[0-9]|msblk*[0-9]|mspblk*[0-9]|nvme*|sd*|sr*|vd*|xvd*|bcache*|cciss*|dasd*|ubd*", GOTO="persistent_storage_end"
>>
>> Adding "hd*" to that line fixes the problem. I'll send patches to
>> systemd and for OE-core.
>
> Lennart argued that /dev/hd* is caused by using the deprecated
> CONFIG_IDE in the kernel and therefore rejected adding "hd*" to upstream
> udev.
>
> CONFIG_IDE seems to come from common-pc-drivers.cfg [1] but that's just
> a guess - I'm not entirely sure how to identify the actual kernel config
> fragments that were used during a build. Anyway, it has been there since
> 2011 and modernizing that is a different topic, so I'll just send the
> patch for systemd/udev.


That is in fact where it comes from for those machines .. and in fact, I started
removing it from various trees about a year ago. Up until recently, it
was around
for compatibility reasons .. but now the generic scsi subsystem
provides everything
that CONFIG_IDE used to .. and they can in fact be dropped.

I may do it to the 4.1 kernel, or wait until after the upcoming
release to avoid any
chance of breaking something that still depends on it.

Bruce

>
> [1]
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/tree/bsp/common-pc/common-pc-drivers.cfg
>
> --
> Best Regards, Patrick Ohly
>
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
>
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"



More information about the Openembedded-core mailing list