Matthew Burgess wrote:
> On 12/09/2011 20:40, Bruce Dubbs wrote:
>> Matt,
>> I saw your conversation with Kay Sievers at
>> http://comments.gmane.org/gmane.linux.hotplug.devel/17011
>>
>> How do we want to address this? I'm not sure that the advice to ignore
>> the clock setting and always use ntp is the best approach. It ignores
>> the situation when you do not have a network connections.
>
> Well, we had this discussion back in August:
> http://www.linuxfromscratch.org/pipermail/lfs-dev/2011-August/064960.html.
>
> From that discussion we appear to have 3 issues with boot
> ordering/early boot device discovery that the udev_retry script is
> attempting to help out with:
>
> 1) Setting the kernel time from the rtc
>
> I'm in vehement agreement with Kay here; the rtc *cannot* be trusted to
> provide an accurate time, and therefore setting the kernel time to it
> with any kind of smarts is an exercise in futility. I still stand by my
> original recommendation here and advise our readers to use the
> CONFIG_RTC_HCTOSYS kernel config option (along with an explanation of
> situations where it isn't appropriate such as when the rtc isn't in
> UTC).
The problem with using something like ntpdate (ntpd -q) in a boot script
is that if the network is down for some reason, the bootscript hangs
forever. I think that we need to be able to tell the system that the
clock is set in local time and not GMT, even if all networking is
disconnected.
About the only way I can see that the script can detect if the network
is up and can get a ntp time value is to use ping with a timeout to the
ntp server and skip setting the clock if it gets a timeout. However,
this is a BLFS issue.
> Likewise, I don't see the point of setting the rtc to the kernel
> time on shutdown unless you have an accurate time source.
If the user sets the clock on the system manually with `date`, shouldn't
the system write that to the HW clock on shutdown? Yes, I know that
hwclock can be used, but not all users know that.
> 2) alsactl if /usr or /var are on a separate partition and the alsa udev
> rules trigger before /usr and /var have been mounted.
>
> I don't know Whether this is mitigated by the CONFIG_DEVTMPFS_MOUNT=y
> option that Andy mentioned in the thread linked to above?
I'm not sure if we should be worried about alsa in LFS. A note in the
appropriate section of BLFS that describes the problem of a separate
/var and /usr. Personally, I don't think /var should ever be a separate
partition. You could make a case for /var/log, but otherwise, the space
required is quite minimal.
> 3) The write_{net,cd}_rules stuff.
>
> This, I really don't understand. For the net stuff, we give the users
> instructions to generate /etc/udev/rules.d/70-persistent-net.rules
> before they boot into the LFS system for the first time. Those
> generated rules will succeed as they don't have a RUN+= action.
>
> Similarly, the rules generated by
> /lib/udev/rules.d/75-cd-aliases-generator.rules don't contain any RUN+=
> actions.
>
> There's some commands in the udev_retry script that copy the contents of
> /run/tmp-rules--* that are generated by the above 2 scripts, but I don't
> see why that needs to be in a script by itself, and it certainly doesn't
> look to be dependent on any invocation of udev_retry.
In my development system, there is no /run/tmp-rules--*. There is
/run/udev/rules.d/, but it's empty.
> So, I think all that is need for point 3 is to move that "copy temporary
> generated rules to /etc" code into the main udev script.
I don't think that is even necessary. Looking at the latest udev man page:
"The udev rules are read from the files located in the default rules
directory /lib/udev/rules.d/, the custom rules directory
/etc/udev/rules.d/ and the temporary rules directory /run/udev/rules.d/."
I am working on rewriting the bootscripts (again). This time, the LSB
functions are used. I've got them working and the bootlog looks right,
but I need to test the error paths.
What do you think if I just dropped udev_retry?
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
