Bruce Dubbs wrote: > Matthew Burgess wrote: >> 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,
It doesn't have to; it just has to be within a few minutes, so that ntpd
doesn't refuse to start.
(Since running "ntpd -gqx", as in the blfs ntp bootscript, takes far too
long to finish even when networking *is* working properly, I have ripped
it out of the boot script.)
>> 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.
Also, it doesn't have to be perfect. It just has to be within a few
minutes, so that at the next boot, ntpd doesn't explode.
>> 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?
No, it's not mitigated. devtmpfs is only for /dev; it doesn't know how
to magically find a usable version of the alsactl state file, or the
binary plus its required libs. :-)
> 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.
It's not about space requirements. It's about trivially filling up the
root partition and creating an easy DoS against the system. Same reason
/tmp (or /var/tmp) should never be on the same partition as the root, or
should at least have user quotas. (Though quotas don't work for
/var/log since everything is written by syslogd, running as root.) :-)
>> 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.
As long as the user doesn't ever change their network cards, anyway.
Once they do, these might fail if the scripts are broken.
(It's not just RUN+= rules that can run afoul of this. IMPORT is just
as vulnerable. The difference is, IMPORT already can't signal failure,
so the program or script has to be written to avoid relying on
non-rootfs files.)
>> Similarly, the rules generated by
>> /lib/udev/rules.d/75-cd-aliases-generator.rules don't contain any
>> RUN+= actions.
Depending on which libs are used by the programs involved, the IMPORTs
might break as well.
(But just as above, the --type=failed run won't retry them in today's
config.)
>> 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.
Because before this point in the bootscripts, /etc is read-only.
> In my development system, there is no /run/tmp-rules--*. There is
> /run/udev/rules.d/, but it's empty.
A file will get written to one of those locations if the rootfs is
read-only when a NIC (or CD drive) shows up that needs a new rule to be
written for it.
/dev/.udev/tmp-rules--* was the location before /run showed up. We
might have gotten the path wrong for a system with /run, but I don't
think so; I think that at least the filename is still tmp-rules--*. I'd
have to find a second NIC and reboot to know for sure, though.
>> 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/."
This won't persist the first boot's NIC->name assignment to the next
boots unless the generated rules file gets copied somewhere persistent.
As long as we follow Debian with the rule_generator rules, we'll need to
copy these files to the (writable) rootfs if they exist after mountfs.
> 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?
Please don't yet. :-)
I think before we drop udev_retry we need to either (a) encode somewhere
that the only way that multiple partitions are supported is via an
initramfs (which mounts *all* of them before giving control to the
rootfs), or (b) hack up an initramfs that does exactly that, ourselves.
Of course, --type=failed will actually break at some point. At that
time, we'll need to either re-trigger everything (which will take a
while), or do the initramfs thing.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
