Hi all,
Seewer Philippe wrote:
> Harald Hoyer wrote:
[ .. ]
>
> Please don't do that. That way we actually loose the benefit of doing as
> much in parallel as possible. Instead please consider the patch below.
> I've been fiddling with this for a few weeks now. It basically replaces
> the current "wait-for-root" loop with a loop that queries the udev-queue
> and only exits if either root is available or all udev events have been
> processed.
>
D'accord.
> It works, except if a udev event takes longer than the default 180s as is
> the case with an unpatches cryptsetup and/or if we do user-interaction
> from within udev which we shouldn't do anyway.
>
> Thank you,
> Philippe
>
> diff --git a/modules.d/99base/init b/modules.d/99base/init
> index 27c4dad..e14dc20 100755
> --- a/modules.d/99base/init
> +++ b/modules.d/99base/init
> @@ -46,6 +46,11 @@ mkdir /dev/shm
> mkdir /dev/pts
> mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts >/dev/null 2>&1
>
> +# Set version specific udevadm options
> +UDEVVERSION=$(udevadm --version)
> +UDEVADMOPTS=""
> +[ $UDEVVERSION -ge 143 ] && UDEVADMOPTS="--exit-if-exists=$NEWROOT/proc"
> +
> # run scriptlets to parse the command line
> getarg 'rdbreak=cmdline' && emergency_shell
> source_all cmdline
> @@ -76,7 +81,7 @@ source_all pre-trigger
>
> # then the rest
> udevadm trigger $udevtriggeropts >/dev/null 2>&1
> -udevadm settle --timeout=30 >/dev/null 2>&1
> +udevadm settle --timeout=30 $UDEVADMOPTS >/dev/null 2>&1
>
> # pre-mount happens before we try to mount the root filesystem,
> # and happens once.
> @@ -86,18 +91,23 @@ getarg 'rdbreak=mount' && emergency_shell
>
> # mount scripts actually try to mount the root filesystem, and may
> # be sourced any number of times. As soon as one suceeds, no more are
> sourced.
> -i=0
> -while :; do
> - [ -d "$NEWROOT/proc" ] && break;
> -
> +while [ ! -d "$NEWROOT/proc" ] ; do
> for f in /mount/*.sh; do
> [ -x "$f" ] && . "$f";
> [ "$ROOTFS_MOUNTED" ] && break;
> done
>
> - sleep 0.5
> - i=$(($i+1))
> - { flock -s 9 ; [ $i -gt 20 ] && emergency_shell; } 9>/.console_lock
> + # If the queue was empty and mount scripts failed as well, bail out
> + [ -n "$EMPTYQUEUE" ] && break;
> +
> + # Give udev events some time before we try anything. If the queue
> + # is empty, give mount-scripts another chance to get the root
> + udevadm settle --timeout 5 $UDEVADMOPTS && EMPTYQUEUE="1"
> +done
> +
> +# udev queue is empty, no root? Let the user figure this out
> +while [ ! -d "$NEWROOT/proc" ] ; do
> + { flock -s 9 ; emergency_shell; } 9>/.console_lock
> done
>
> # pre pivot scripts are sourced just before we switch over to the new root.
>
Ah, if it were so easy.
This approach work perfectly for any device which does synchronous scanning.
For a device doing asynchronous scan you're out of luck here as the device
might start spitting out udev events at any time, even after the udev
queue is empty.
EG usb or qla2xxx have a habit of doing so. So either you implement
checks for each device (-type) which detects if the device is still
scanning or you indeed just wait until the device appears.
There actually is no problem with the latter, as all the design
goal here is to have _every_ device initialization in the background
/ asynchronously by udev.
So in foreground we indeed just have to wait for the device node
to appear. Even the udev queue check is pointless here; either
we have a device node, in which case we can continue regardless
of how many events are still in the udev queue;
or we don't have one, in which case it quite irrelevant if
udev has still events to process or not.
Think of multipath taking it's time to setup the multipath
environment; it's being notified by udev via a socket, so
udev is done with the event. But the device node is still
not present or not useable as multipath is still setting
up the topology.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
