initqueue

initqueue

[Harald Hoyer]

To move all "big" jobs out of the udev event handling, I introduce the 
"initqueue". This prevents the job from being killed by udev timeouts.

See
http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut;a=commit;h=eab677a2164bccb3990487dc5ef4549b30cb1055

for the patch.

Basically inside a udev event, you don't do

RUN+="/sbin/ifup $env{INTERFACE}"

you now queue this in the initqueue with:

RUN+="/sbin/initqueue /sbin/ifup $env{INTERFACE}"

Inside init all jobs are worked on in serial order by the do_initqueue() function.

Now we have no more side effects due to the parallel nature of udev and still be 
fast, in case udev supports "udevadm settle --exit-if-exists="
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: initqueue

[Seewer Philippe]

Harald Hoyer wrote:
> To move all "big" jobs out of the udev event handling, I introduce the 
> "initqueue". This prevents the job from being killed by udev timeouts.
> 
> See
> http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut;a=commit;h=eab677a2164bccb3990487dc5ef4549b30cb1055 
> 
> 
> for the patch.
> 
> Basically inside a udev event, you don't do
> 
> RUN+="/sbin/ifup $env{INTERFACE}"
> 
> you now queue this in the initqueue with:
> 
> RUN+="/sbin/initqueue /sbin/ifup $env{INTERFACE}"
> 
> Inside init all jobs are worked on in serial order by the do_initqueue() 
> function.
> 
> Now we have no more side effects due to the parallel nature of udev and 
> still be fast, in case udev supports "udevadm settle --exit-if-exists="

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.

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.

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: initqueue

[Hannes Reinecke]

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-l3A5Bk7waGM@public.gmane.org			      +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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: initqueue

[Harald Hoyer]

On 07/02/2009 02:39 PM, Seewer Philippe wrote:
> Harald Hoyer wrote:
>> To move all "big" jobs out of the udev event handling, I introduce the
>> "initqueue". This prevents the job from being killed by udev timeouts.
>>
>> See
>> http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut;a=commit;h=eab677a2164bccb3990487dc5ef4549b30cb1055
>>
>>
>> for the patch.
>>
>> Basically inside a udev event, you don't do
>>
>> RUN+="/sbin/ifup $env{INTERFACE}"
>>
>> you now queue this in the initqueue with:
>>
>> RUN+="/sbin/initqueue /sbin/ifup $env{INTERFACE}"
>>
>> Inside init all jobs are worked on in serial order by the
>> do_initqueue() function.
>>
>> Now we have no more side effects due to the parallel nature of udev
>> and still be fast, in case udev supports "udevadm settle
>> --exit-if-exists="
>
> 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.
>
> 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
>

Well, you could remove the initqueue for ifup events, but I would like to keep 
it at least for cryptsetup.

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: initqueue

[Seewer Philippe]

Harald Hoyer wrote:
> On 07/02/2009 02:39 PM, Seewer Philippe wrote:
>> Harald Hoyer wrote:
>>> To move all "big" jobs out of the udev event handling, I introduce the
>>> "initqueue". This prevents the job from being killed by udev timeouts.
>>>
>>> See
>>> http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut;a=commit;h=eab677a2164bccb3990487dc5ef4549b30cb1055 
>>>
>>>
>>>
>>> for the patch.
>>>
>>> Basically inside a udev event, you don't do
>>>
>>> RUN+="/sbin/ifup $env{INTERFACE}"
>>>
>>> you now queue this in the initqueue with:
>>>
>>> RUN+="/sbin/initqueue /sbin/ifup $env{INTERFACE}"
>>>
>>> Inside init all jobs are worked on in serial order by the
>>> do_initqueue() function.
>>>
>>> Now we have no more side effects due to the parallel nature of udev
>>> and still be fast, in case udev supports "udevadm settle
>>> --exit-if-exists="
>>
>> 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.
>>
>> 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
>>
> 
> Well, you could remove the initqueue for ifup events, but I would like 
> to keep it at least for cryptsetup.

Why not just put cryptsetup back into mountscripts as I've suggested before?

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: initqueue

[Harald Hoyer]

On 07/02/2009 03:08 PM, Seewer Philippe wrote:
> Harald Hoyer wrote:
>> On 07/02/2009 02:39 PM, Seewer Philippe wrote:
>>> Harald Hoyer wrote:
>>>> To move all "big" jobs out of the udev event handling, I introduce the
>>>> "initqueue". This prevents the job from being killed by udev timeouts.
>>>>
>>>> See
>>>> http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut;a=commit;h=eab677a2164bccb3990487dc5ef4549b30cb1055
>>>>
>>>>
>>>>
>>>> for the patch.
>>>>
>>>> Basically inside a udev event, you don't do
>>>>
>>>> RUN+="/sbin/ifup $env{INTERFACE}"
>>>>
>>>> you now queue this in the initqueue with:
>>>>
>>>> RUN+="/sbin/initqueue /sbin/ifup $env{INTERFACE}"
>>>>
>>>> Inside init all jobs are worked on in serial order by the
>>>> do_initqueue() function.
>>>>
>>>> Now we have no more side effects due to the parallel nature of udev
>>>> and still be fast, in case udev supports "udevadm settle
>>>> --exit-if-exists="
>>>
>>> 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.
>>>
>>> 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
>>>
>>
>> Well, you could remove the initqueue for ifup events, but I would like
>> to keep it at least for cryptsetup.
>
> Why not just put cryptsetup back into mountscripts as I've suggested
> before?
>

Because so much more can be inside the crypto partition, which might need 
further processing.
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: initqueue

[Seewer Philippe]

Harald Hoyer wrote:
> On 07/02/2009 03:08 PM, Seewer Philippe wrote:
>> Harald Hoyer wrote:
>>> On 07/02/2009 02:39 PM, Seewer Philippe wrote:
>>>> Harald Hoyer wrote:
>>>>> To move all "big" jobs out of the udev event handling, I introduce the
>>>>> "initqueue". This prevents the job from being killed by udev timeouts.
>>>>>
>>>>> See
>>>>> http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut;a=commit;h=eab677a2164bccb3990487dc5ef4549b30cb1055 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> for the patch.
>>>>>
>>>>> Basically inside a udev event, you don't do
>>>>>
>>>>> RUN+="/sbin/ifup $env{INTERFACE}"
>>>>>
>>>>> you now queue this in the initqueue with:
>>>>>
>>>>> RUN+="/sbin/initqueue /sbin/ifup $env{INTERFACE}"
>>>>>
>>>>> Inside init all jobs are worked on in serial order by the
>>>>> do_initqueue() function.
>>>>>
>>>>> Now we have no more side effects due to the parallel nature of udev
>>>>> and still be fast, in case udev supports "udevadm settle
>>>>> --exit-if-exists="
>>>>
>>>> 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.
>>>>
>>>> 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
>>>>
>>>
>>> Well, you could remove the initqueue for ifup events, but I would like
>>> to keep it at least for cryptsetup.
>>
>> Why not just put cryptsetup back into mountscripts as I've suggested
>> before?
>>
> 
> Because so much more can be inside the crypto partition, which might 
> need further processing.

That is correct. But if it's in mountscripts, it would fire more
udev-events which are caught again by udevadm settle. I don't see
a problem there.
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: initqueue

[Seewer Philippe]

Hannes Reinecke wrote:
> 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.
> 
[snip]
> 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.

Damned. I didn't think about that. Any hints how I could simulate that with kvm/qemu?

> 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.

Just blindly waiting for the node to appear is dangerous. We might not
know which node to wait for or we might not have one at all (like
nfsroot for example). And in cases where the node never appears due to
lack of drivers,hardware,cmdline,... we'd never bail out without a timeout.

Suggestion: What about a solution like this?

while [ ! -d $NEWROOT/proc ] ; do
 while [ ! -d $NEWROOT/proc ] ; do
   #...current code as in my patch 
 done

 if [ ! -d $NEWROOT/proc ] ; do
    # No root around, give devices some time to do things asynchronous
    # and settle
    sleep 5
    # If the queue is still empty, bail
    udevadm settle --timeout 1 && break
 fi
done

Sleeping is not a real solution, as is just simply fiddling with timeouts.
Same goes for counting, that's why I tried to implement the udev-queue
approach after all. But I can't think of any other solution that does
not poll a devicenode.

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: initqueue

[Harald Hoyer]

On 07/02/2009 03:20 PM, Seewer Philippe wrote:
>>> Why not just put cryptsetup back into mountscripts as I've suggested
>>> before?
>>>
>>
>> Because so much more can be inside the crypto partition, which might
>> need further processing.
>
> That is correct. But if it's in mountscripts, it would fire more
> udev-events which are caught again by udevadm settle. I don't see
> a problem there.

Hmm, we maybe should think of merging pre-mount and mount.
pre-mount makes no sense, if mounting is done inside udev rules.
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: initqueue

[Victor Lowther]

On Thu, 2009-07-02 at 16:10 +0200, Harald Hoyer wrote:
> On 07/02/2009 03:20 PM, Seewer Philippe wrote:
> >>> Why not just put cryptsetup back into mountscripts as I've suggested
> >>> before?
> >>>
> >>
> >> Because so much more can be inside the crypto partition, which might
> >> need further processing.
> >
> > That is correct. But if it's in mountscripts, it would fire more
> > udev-events which are caught again by udevadm settle. I don't see
> > a problem there.
> 
> Hmm, we maybe should think of merging pre-mount and mount.
> pre-mount makes no sense, if mounting is done inside udev rules.

I would like to chime in again with the longstanding race condition
inherent in having resume from hibernate and root fs mounting as udev
rules.

> --
> To unsubscribe from this list: send the line "unsubscribe initramfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: initqueue

[Harald Hoyer]

On 07/03/2009 02:04 AM, Victor Lowther wrote:
> On Thu, 2009-07-02 at 16:10 +0200, Harald Hoyer wrote:
>> On 07/02/2009 03:20 PM, Seewer Philippe wrote:
>>>>> Why not just put cryptsetup back into mountscripts as I've suggested
>>>>> before?
>>>>>
>>>> Because so much more can be inside the crypto partition, which might
>>>> need further processing.
>>> That is correct. But if it's in mountscripts, it would fire more
>>> udev-events which are caught again by udevadm settle. I don't see
>>> a problem there.
>> Hmm, we maybe should think of merging pre-mount and mount.
>> pre-mount makes no sense, if mounting is done inside udev rules.
>
> I would like to chime in again with the longstanding race condition
> inherent in having resume from hibernate and root fs mounting as udev
> rules.

Right. Maybe we really should not mount from udev rules, and only generate a 
/mount script or set a symlink to /dev/root.
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: initqueue

[Daniel Drake]

On Fri, 2009-07-03 at 10:06 +0200, Harald Hoyer wrote:
> Right. Maybe we really should not mount from udev rules, and only generate a 
> /mount script or set a symlink to /dev/root.

This would also suit OLPC... We have a premount script in our own module
which we would like to have run *before* the root fs is available (for
the purposes of maximum security). Right now the root fs gets mounted by
udev while that premount script is running.

Daniel


--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html