List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
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
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
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