Jeremy Katz wrote:
Right, but we run udevstart in the initrd, too. So if the code to
create them is all in udevstart (and we have rc.sysinit call udevstart
instead of the start_udev wrapper), then everything should still get
created at the same times and not have any newer problems. Or if it
can, I'm missing something entirely (not impossible)
The other possibility would be, not to --bind the ramfs /dev to the sysimage /.
Then our old /dev is there and start_udev can be run again after root is mounted rw.
We could strip down our dev.rpm and autoloading of modules would also work.
We only have to prevent udev from removing device nodes it has not created.
* The pam_console_setowner stuff really needs to just be a patch to
pam_console_apply and then use that. Otherwise, we have a second copy
of that code to maintain and fix bugs in. Nalin didn't seem against
this when I mentioned it to him at dinner
would be cool!
Okay -- do you want to look at this or would you rather I do so?
I will tomorrow, if no one does it today...
* Any reason why udevstart can't be done after rhgb starts to avoid text
seen before the graphical boot?
You may see some udev messages, if root is mounted (ro) at the time modules are loaded,
which trigger hotplug events.
Right, but for udev to be set as the hotplug handler, then it got set
from the initrd and you're using a ramfs dev. In which case /dev is not
going to be read-only. Do you have an example case? And the downside
here is that it makes the rhgb details pop open instead of remaining
hidden?
It just seems a shame to be adding more messages that are going to be
potentially confusing before rhgb starts up. It also makes it look like
something is broken since you get the console font loading ([OK]), then
welcome to fedora, then starting udev ([ok]). The space between these
just looks and feels awkward.
needs testing
