Bruce Dubbs wrote: > 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.
Yeah. The issue is that /run can't ever work for this, since the whole point of these scripts is to persist the current configuration across reboots. :-) Using /run *could* work if IFNAMSIZ was larger than 16 (but that's an ABI change, and impossible) and if NIC aliases were supported -- then the same setup as disks could work. udev could create by-mac/xxx, by-path/yyy, etc., aliases for each NIC, and people could just use those. Then it wouldn't require persistence either, and the whole set of scripts could disappear. But that's impossible. :-( >> 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. Not a ton, although I wouldn't include the configuration in the kernel anymore. (That was just to make the hint require fewer other tools.) I have moved to a mkinitramfs package (that I wrote, which is why I use it; I don't actually trust the others ;-) ), but part of that package is also there to support dm-crypt, LVM, and some RAID setups. So it's a lot more complex. (I haven't tried to add the code to that one to mount other FSes from the final system, either. Actually, that will require a checkfs equivalent as well, since I don't want to mount a potentially broken FS. And it was looking like it might actually work. Nuts. :-P ) > In any case, it's a lot of work because upstream wants to drop what > appears to be a small capability. Yup. > We may just have to accept the limitation of not having separate /usr > and /var partitions for LFS. Or at least point to the instructions for a couple initramfs implementations that are known to work, when telling this to users.
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
