Bryan Kadzban wrote:
> Bruce Dubbs wrote:
>> 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.
Grepping the source, we have
RUNDIR=$(udevadm info --run)
It looks like this is /run/udev. It is in the current udev_retry that
way too.
local tmp_rules_file="$RUNDIR/tmp-rules--${RULES_FILE##*/}"
and in another file
RULES_FILE='/etc/udev/rules.d/70-persistent-net.rules'
So it looks like for us it should be /run/udev/tmp-rules--*, but we
could copy that to /run/udev/rules.d/ for a temporary location or to
/etc/udev/rules.d/ for a permanent location.
I'd like to use /run/udev/rules.d/ because the less we write to /etc,
the better. There is discussion of moving mtab and the like to other
places. Someday, I'd like to be able to leave / as read only.
>>> 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.
Sadly, I have to agree.
>> 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. :-)
OK.
> 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.
I took a quick glance at your 2005 hint on building an initramfs. I
wonder how much has changed. In any case, it's a lot of work because
upstream wants to drop what appears to be a small capability.
We may just have to accept the limitation of not having separate /usr
and /var partitions for LFS.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
