udev rescan for newly configured disk drives

[J. Mixer]

I use the kiwi boot initrd, slightly alterred, as the basis for loading brand new servers with a kiwi disk image.  When "new" these servers do not have any disk drives configured in their RAID controller card.  My init script can configure all the drives to the correct configuration and I perform a "udevKill" and "udevStart" to see the newly configured hard drives in the /dev/sdX list.

Here's my problem.  When USB flash sticks exist in the system (we use one in the back of the server to save configuration data from our big application, and more importantly when I'm loading the system from a USB flash stick) the USB flash will show up as /dev/sda and when the disk drives show up, they are /dev/sdb through /dev/sdf.  When rebooted, the disk drives show up "first" in the list and the USB at the end.

Without rebooting, is there a way to reset the device orders to put the disk drives first?

J.

[Marcus Schäfer]

Hi,

> I use the kiwi boot initrd, slightly alterred, as the basis for loading
> brand new servers with a kiwi disk image. When "new" these servers do
> not have any disk drives configured in their RAID controller card. My
> init script can configure all the drives to the correct configuration
> and I perform a "udevKill" and "udevStart" to see the newly configured
> hard drives in the /dev/sdX list.

I think it would be better to call

udevPending

which in fact calls 'udevadm settle' and thus waits for the new
devices to appear, killing udev and re-trigger the creation of all
devices is imho not the right way to deal with new udev handled
devices

> Here's my problem. When USB flash sticks exist in the system (we use
> one in the back of the server to save configuration data from our big
> application, and more importantly when I'm loading the system from a
> USB flash stick) the USB flash will show up as /dev/sda and when the
> disk drives show up, they are /dev/sdb through /dev/sdf. When
> rebooted, the disk drives show up "first" in the list and the USB at
> the end.
>
> Without rebooting, is there a way to reset the device orders to put the
> disk drives first?

I'm sorry the unix device names as associated with the drivers are
not persistent. That's one of the major reasons for udev which also
creates a persistent representation in /dev/disk/by-[id|uuid|..]

From a kiwi perspective I cannot influence when and how kernel
device names are created. This is all done in the driver layer
and the load and initialization times decide how they appear.
kiwi itself identifies the boot device by an id written on the
device and into the initrd. That way I could safely find my boot
device and use the unix device name it belongs to.

If possible you should not rely on unix device names

Regards,
Marcus
--
Public Key available
gpg --keyserver gpg-keyserver.de --recv-keys 0xCCE3C6A2
-------------------------------------------------------
Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH
Tel: 0911-740 53 0 Maxfeldstrasse 5
FAX: 0911-740 53 479 D-90409 Nürnberg
GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer
HRB: 21284 (AG Nürnberg) Germany
http://www.suse.de
-------------------------------------------------------

[j.m...@infoprint.com]

Marcus,

Thanks for the response.  I will "bite the bullet" and use id or uuid device names.

You suggest using "udevPending" to wait until the newly configured RAID drives show up.  Can udevPending be called anytime?

Regards,

J.

J. Mixer
Advisory Engineer
Phone: 720-663-3532
Email: j.m...@infoprint.com
infoprint.com

Ricoh Production Print Solutions, LLC

Marcus Schäfer <m...@suse.de> Sent by: kiwi-...@googlegroups.com 09/30/2012 12:33 PM Please respond to kiwi-...@googlegroups.com

To kiwi-...@googlegroups.com cc Subject Re: [kiwi] udev rescan for newly configured disk drives

[Marcus Schäfer]

Hi,

> Thanks for the response. I will "bite the bullet" and use id or uuid
> device names.

ok :)

> You suggest using "udevPending" to wait until the newly configured RAID
> drives show up. Can udevPending be called anytime?

yep it doesn't hurt, it just waits for udev/kernel events to settle