[gentoo-dev] udev and /usr

[Joost Roeleveld <joost@antarean.org>]

Hi Devs,

Not sure if you are aware of the discussions on the gentoo-user list about the 
upcoming change where systemd and udev require /usr to be available prior to 
starting of udev.

I would like to know what the position of the Gentoo developers is with 
regarding this and how best to deal with this.

There have been several use-cases mentioned in the other list describing the 
need for a seperate /usr and /var partition. I also have these on seperate 
partitions.

The use for an initrd/initramfs/... will create an additional layer of 
complexity a lot of us users are not really waiting for, especially as we are 
not seeing any issues with our current systems.
It's also one extra thing that can go wrong and it is not clear how we could 
solve the situation where we messed something up with the initramfs and can't 
get to the tools in single-usermode to try and fix it. That is if we can even 
get access to the machine in question.

I have raised a possible alternative on the other list and would like to know 
how you, the Developers, feel about it.

My idea is, to me at least, simple.
"udev" is split into 2 parts:
1) "udevd", which creates the /dev-tree based on the events it currently gets
2) "actiond" processes all the actions "udevd" puts in a seperate queue.

I think that if "udevd" is started at boot-time and "actiond" only after 
"localmount" has finished, there shouldn't be the situation where a script in 
the udev-configuration fails because of missing files.
Even if it does, then this can be handled in "actiond" itself and placed in a 
retry-queue.

With a smaller udev, the chances of it failing should also be less. (less 
code-lines to check) and as long as the /dev-entries are created, these can be 
used to manually mount the other partitions to get to the point where the 
system can be fixed to get it back to a workable state.

If, in the currently planned form, udev fails, it will be necessary to use a 
rescue-cd/usb to boot the system, try to fix it inside a chroot where it's not 
easy to check what is actually going wrong during the boot-process as the 
different tools can then not be run with the error-messages printed to the 
console.

Kind regards,

Joost Roeleveld