Hi,
On 09/30/2009 09:47 PM, Chris Lumens wrote:
Touch /dev/.in_sysinit, as that stops /lib/udev/rules.d/65-md-incremental.rules
from messing with mdraid sets.
This patch adds the touching twice, once to our own init, for when running
as standalone installer, and once in python for when running from a livecd,
to stop the udev trigger "block" we do will cause
/lib/udev/rules.d/65-md-incremental.rules to trigger in the livecd case.
This means that now we're embedding knowledge of how the udev rules
operate into the loader. They're already frustrated with us for using
the udevdb directly, and now we'd be relying on knowing how some of the
rules work and setting state up to make sure they function differently.
Ack, I agree this is very ugly, and we will only get in to more trouble
as more storage subsystems move to udev based auto assembly of the stack,
for example lvm will start doing the same with the new code which was in
rawhide for a short while.
In the case of mdadm, it was decided that the auto assembly stuff only
is for things hot plugged after boot, so its disabled when udev is started
from rc.sysinit. The lockfile I use is shared between the mdadm installed
rules and initscripts.
I wonder if lvm will have something similar for us to be able to tell it
to not do auto assembly though.
As Dave already said, it will probably be a good idea, to instead of relying
on hacks like this, to start filtering which udev rules we will include
in stage1. This however won't help for the livecd case.
So in the long run we will definitely need to come up with a better solution
for this.
Regards,
Hans
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
