Bryan Kadzban wrote:

>> What symlinks?  I use /dev/sd?? and those are not symlinks.  I do have
>> /dev/cdrom in fstab, but that's noauto and wouldn't need a checkfs
>> anyway.  I don't use a usb disk; perhaps that uses symlinks.
>
> /dev/disk/by-{id,label,path,uuid}/*
>
> Also I'm pretty sure that UUID=foo or LABEL=foo in fstab still use these
> paths indirectly (by-uuid and by-label, respectively).
>
> If you use /dev/sd??, then I wish you the best of luck the next time the
> kernel's disk discovery order changes. Because it's not guaranteed to
> remain the same forever, and so when it changes, your system won't be
> bootable. :-)

I don't think so.  I don't use UUID or LABEL in fstab, but /dev/sd?? 
would only change if I did somthing with fdisk like deleting a partition 
and splitting two in it's place.  I suppose deleting an extended 
partition could do it also.

> I will also note that using /dev/disk/by-id/ links allowed me to survive
> the IDE -> libata transition (/dev/hd* to /dev/sd*) with zero userspace
> changes.

I don't recall running into that problem.  ISTR that hdx mapped to sdx 
without issue.

>>>> I don't think that you should disable it by default. But you can give
>>>> users a choice. Introduce new variable in rc.site that can allow someone
>>>> to enable/disable udevadm settle command, but enable it by default in
>>>> init script. Of course, make it possible to override the var. I guess
>>>> that would be fair for everyone.
>>> This sounds fine I think.
>>
>> Yes, that seems like a good compromise.  Perhaps two variables; one for
>> the udev script and one for the udev_retry script.  We could even
>> disable the udev_retry script completely if /usr is a part of the root
>> partition.
>
> Still need it for /var, for alsactl.  :-/

Only if /var is separate and LABEL or UUID is used to mount it.

>> The only thing udev_retry does by default is trigger the rtc
>> subsystem but just that takes 4-5 seconds to settle on my system.
>
> Hmm, I thought that was empty by default... Nope, it seems it does have
> rtc in there. Huh.
>
> Oh right, hwclock needs /var/lib/hwclock/adjtime doesn't it.

Yup.

> I wonder if that one can not settle by default. The only thing that will
> require the system time to be set from the RTC by hwclock is NTP, which
> might be far enough down the road (after networking comes up) that it's
> OK to just let it go.
>
> Another option would be to try to figure out why it's waiting so long,
> but I'm not sure how to do that.

Yes, we'd need to look at code and perhaps add some custom debug code to 
figure that out.  Maybe I'll do that.

   -- Bruce



-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to