udev in initrd

[Harald Hoyer]

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