On Apr 26, rleigh <rleigh@codelibre.net> wrote: > Testing with initramfs-tools (maks/run) with current unstable shows > udev appearing to work correctly with it using /dev/.udev when /run > is not present on the host system. And also with /run present on Did you check with LVM and that all its persistent symlinks are still there? > In a kvm VM, I do see some errors from udev at startup: These are unrelated and harmless (the errors are old, only the message is new). > > Why does /run should not be noexec? > If /run/shm is also on /run (not a separate mount), it needs to be > executable. Why do we need it executable? > > > Marco, have you tested this upgrade path? That is /run in the > > > initramfs and no /run on the rootfs? Is udev checking for that and > > No, but if the database is not copied to the initramfs then LVM will be > > annoyed. > Which database is this? Is this something that the LVM scripts need > updating to handle? It is /dev/.udev/ or /run/udev/. I do not know exactly how LVM interacts with it, just that it must be preserved. > I just sent a separate mail after doing some testing. The current logic > in 168-1 does appear to move /run/udev (initramfs) to /dev/.udev when > /run is not present on the host. Looks good to me. No, there is no such code in the udev package. What you are seeing is /run/udev/ being lost when the initramfs is destroyed and a new /dev/.udev/. -- ciao, Marco
Attachment:
signature.asc
Description: Digital signature