On Tue, Mar 15, 2011 at 18:38, Marco d'Itri <md@xxxxxxxx> wrote: > On Mar 15, Kay Sievers <kay.sievers@xxxxxxxx> wrote: > >> The maintainers of the commonly used early-boot tools agreed to use a >> /dev/.run/<package>/ dir instead, which will be provided by initramfs >> and systemd. After the basic bootup, the /dev/.run/ tmpfs mountpoint >> will be available at /var/run/. The /dev/.run/ directory is at that >> point just an "early-boot alias" for /var/run/, and all early-boot >> tools will have their data in /var/run/, just like any other service. > This looks complex and requiring coordination among multiple packages. > Where is the documentation of everything which needs to be done by the > surrounding boot scripts? I can't know, or document anything. The init scripts I maintain do not know anything about /dev/.udev/. > Will anything break if I still create an empty /dev/.udev/ for the > benefit of everything which checks for it to know if udev is running? I wouldn't do that. But it should work, if you don't create the db/ dir there, that would trigger the built-in converter. And please don't make it a symlink to /dev/.run/, I don't know how that behaves. Anyway, if you really still need that check, you should probably add a command to 'udevadm info ...' using the libudev check, instead of poking directories. >> If you support LVM, please make sure to conflict udev if neccessary >> with older initramfs implementations, so that no new udev gets into an >> old initramfs image, udev puts the data in /dev/.run/ which isn't its >> own mountpoint, and the real root would overmount the udev directory. > I am not sure that I understand this sentence. LVM needs the udev database from initramfs to be preserved. Non-adapted initramfs images with the new udev might not create the /dev/.run/ mountpoint, and any new init system will just overmount the entire /dev/.run/ from initramfs, and the udev database is gone and LVM will not find the udev database .... Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
