Re: [PATCH] Use udev rules to create dmraid /dev/mapper/ devices

2015-11-13 Thread Hannes Reinecke 
On 11/13/2015 12:00 PM, Harald Hoyer wrote:
> On 07.07.2015 13:54, Hannes Reinecke wrote:
>> On 07/07/2015 01:41 PM, Harald Hoyer wrote:
>>> On 29.06.2015 19:36, Thomas Renninger wrote:
 From: Hannes Reinecke 

 https://bugzilla.opensuse.org/show_bug.cgi?id=905746

 Version 2: Remove 64-md-raid.rules

 Signed-off-by: Thomas Renninger 
 ---
  modules.d/90dmraid/dmraid.sh   | 2 --
  modules.d/90dmraid/module-setup.sh | 2 ++
  2 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/modules.d/90dmraid/dmraid.sh b/modules.d/90dmraid/dmraid.sh
 index 3dcff38..cc4390f 100755
 --- a/modules.d/90dmraid/dmraid.sh
 +++ b/modules.d/90dmraid/dmraid.sh
 @@ -26,8 +26,6 @@ if [ -n "$DM_RAIDS" ] || getargbool 0 rd.auto; then
  if [ "${s##$r}" != "$s" ]; then
  info "Activating $s"
  dmraid -ay -i -p --rm_partitions "$s" 2>&1 | vinfo
 -[ -e "/dev/mapper/$s" ] && kpartx -a "/dev/mapper/$s" 
 2>&1 | vinfo
 -udevsettle
  fi
  done
  done
 diff --git a/modules.d/90dmraid/module-setup.sh 
 b/modules.d/90dmraid/module-setup.sh
 index e8de5f5..797a58e 100755
 --- a/modules.d/90dmraid/module-setup.sh
 +++ b/modules.d/90dmraid/module-setup.sh
 @@ -74,6 +74,8 @@ install() {
  
  inst "$moddir/dmraid.sh" /sbin/dmraid_scan
  
 +inst_rules 66-kpartx.rules 67-kpartx-compat.rules
 +
  inst_libdir_file "libdmraid-events*.so*"
  
  inst_rules "$moddir/61-dmraid-imsm.rules"

>>>
>>> Fedora does not have 66-kpartx.rules nor 67-kpartx-compat.rules ...
>>>
>>> Heinz, do we need the kpartx part still?
>>>
>>> I reverted to kpartx, because "dmraid" adds a "p" as a seperator by default 
>>> for
>>> the partitions and this breaks existing installations.
>>>
>>
>> I would recommend splitting the kpartx call into a separate udev
>> rule; otherwise you'll run into timing issues with udev.
>>
>> Cheers,
>>
>> Hannes
>>
> 
> Care to share your 66-kpartx.rules 67-kpartx-compat.rules or make them
> upstream? Shouldn't we agree on one naming scheme?
> 
Sure, I'd love to.

Although the 67-kpartx-compat.rules is pretty much SUSE specific, as
we've messed up the device-mapper device naming
(older SUSE versions would be creating device-mapper names with
underscores, but the links would be using normal dashes).
So it's not relevant to the general audience, but yeah I'd like
to have them both included.

Will be sending patches to multipath-tools covering that.

Cheers,

Hannes
-- 
Dr. Hannes ReineckezSeries & Storage
h...@suse.com  +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Update FC23 - doesn't boot - ssh preboot not working anymore

2015-11-13 Thread Gerhard Wiesinger 

On 10.11.2015 13:23, Gerhard Wiesinger wrote:

On 09.11.2015 15:58, Harald Hoyer wrote:

Am 03.11.2015 um 22:39 schrieb Gerhard Wiesinger:

Hello,

After upgrading one machine it does't boot anymore. Booting the old 
FC22 kernel

works well.

Reached target Basic System.
Found device /dev/mapper/luks-9fbecd95-508a-45ca-997a-42a613c4e5bf
Found device /dev/mapper/fedora_hostname-root

Also integration of ssh preboot authentication is not available 
anymore.


blkid:
/dev/vda2: UUID="f3e2c8a9-51b1-4110-aef5-039cf714425a" TYPE="ext4"
PARTLABEL="Linux filesystem" 
PARTUUID="6bc53fb0-771b-4b52-b584-c87735715a47"
/dev/vda3: UUID="9fbecd95-508a-45ca-997a-42a613c4e5bf" 
TYPE="crypto_LUKS"
PARTLABEL="Linux filesystem" 
PARTUUID="090ffe9b-6791-46df-b9a4-f30adbb95e50"

/dev/mapper/luks-9fbecd95-508a-45ca-997a-42a613c4e5bf:
UUID="A3RzKd-F7ym-pN6a-F01g-Q0Gw-DrVr-jhTgbo" TYPE="LVM2_member"
/dev/mapper/fedora_hostname-swap: 
UUID="cef5950c-43bc-485c-ae2b-832fcbe752c7"

TYPE="swap"
/dev/mapper/fedora_hostname-root: 
UUID="8f5436a3-28cb-4c7e-91df-e3f9249d17d2"

TYPE="ext4"
/dev/vda1: PARTLABEL="BIOS Boot Partition"
PARTUUID="35685b7e-917c-4cc5-9133-69f00f5a1e2f"

Any ideas?

Thank you.

Ciao,
Gerhard



https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_troubleshooting 



please file a bugzilla on the fedora/redhat bugzilla and add 
rdsosreport.txt





Hello Harald,

Applied kernel parameters from link but I dont't get a shell. Very 
strange, it looks like if you wait for minutes it works well and I get 
a password prompt. But afterwards it is still slow on booting, but get 
the log file after some long waiting and tricks. It looks like it 
hangs in some endless loop when working on string operations.


Send you a private email with further private information about the 
issue (screenshots).


Will open a bug report later on.



Thanx for Harald figuring out/helping that with FC23 changed something: 
interfaces are not anymore eth0 but new interface naming schemes is now 
active e.g. ens18
Therefore dracut couldn't boot waiting for eth0 specified on kernel 
command line which didn't exist anymore because it is named now ens18.


As I use networking in initramfs with dracut and get networking up there 
you can't change the network interface easily (it is possible when you 
unload the network driver modile but for some reason this did not work 
reliable).


For reference: Nevertheless I found a solution to get persisent netnames 
in dracut and later on in the "regular" kernel.

# /etc/grub2.cfg kernel parameters
# before:
ip=1.2.3.4::1.2.3.1:255.255.255.0:myhostname:eth0:off nameserver=8.8.8.8 
nameserver=8.8.4.4

# after:
ifname=lan0:26:a0:fc:12:34:56 
ip=1.2.3.4::1.2.3.1:255.255.255.0:myhostname:lan0:off nameserver=8.8.8.8 
nameserver=8.8.4.4

# and adapt network config and firewall to new interfaces

Harald, thnx for your help.

Ciao,
Gerhard

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

Re: [PATCH] Use udev rules to create dmraid /dev/mapper/ devices

2015-11-13 Thread Harald Hoyer 
On 07.07.2015 13:54, Hannes Reinecke wrote:
> On 07/07/2015 01:41 PM, Harald Hoyer wrote:
>> On 29.06.2015 19:36, Thomas Renninger wrote:
>>> From: Hannes Reinecke 
>>>
>>> https://bugzilla.opensuse.org/show_bug.cgi?id=905746
>>>
>>> Version 2: Remove 64-md-raid.rules
>>>
>>> Signed-off-by: Thomas Renninger 
>>> ---
>>>  modules.d/90dmraid/dmraid.sh   | 2 --
>>>  modules.d/90dmraid/module-setup.sh | 2 ++
>>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/modules.d/90dmraid/dmraid.sh b/modules.d/90dmraid/dmraid.sh
>>> index 3dcff38..cc4390f 100755
>>> --- a/modules.d/90dmraid/dmraid.sh
>>> +++ b/modules.d/90dmraid/dmraid.sh
>>> @@ -26,8 +26,6 @@ if [ -n "$DM_RAIDS" ] || getargbool 0 rd.auto; then
>>>  if [ "${s##$r}" != "$s" ]; then
>>>  info "Activating $s"
>>>  dmraid -ay -i -p --rm_partitions "$s" 2>&1 | vinfo
>>> -[ -e "/dev/mapper/$s" ] && kpartx -a "/dev/mapper/$s" 
>>> 2>&1 | vinfo
>>> -udevsettle
>>>  fi
>>>  done
>>>  done
>>> diff --git a/modules.d/90dmraid/module-setup.sh 
>>> b/modules.d/90dmraid/module-setup.sh
>>> index e8de5f5..797a58e 100755
>>> --- a/modules.d/90dmraid/module-setup.sh
>>> +++ b/modules.d/90dmraid/module-setup.sh
>>> @@ -74,6 +74,8 @@ install() {
>>>  
>>>  inst "$moddir/dmraid.sh" /sbin/dmraid_scan
>>>  
>>> +inst_rules 66-kpartx.rules 67-kpartx-compat.rules
>>> +
>>>  inst_libdir_file "libdmraid-events*.so*"
>>>  
>>>  inst_rules "$moddir/61-dmraid-imsm.rules"
>>>
>>
>> Fedora does not have 66-kpartx.rules nor 67-kpartx-compat.rules ...
>>
>> Heinz, do we need the kpartx part still?
>>
>> I reverted to kpartx, because "dmraid" adds a "p" as a seperator by default 
>> for
>> the partitions and this breaks existing installations.
>>
> 
> I would recommend splitting the kpartx call into a separate udev
> rule; otherwise you'll run into timing issues with udev.
> 
> Cheers,
> 
> Hannes
> 

Care to share your 66-kpartx.rules 67-kpartx-compat.rules or make them
upstream? Shouldn't we agree on one naming scheme?
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dracut is too "clever" at identifying modules to exclude.

2015-11-13 Thread Harald Hoyer 
On 13.11.2015 13:37, Harald Hoyer wrote:
> On 12.10.2015 22:30, Neil Brown wrote:
>> Harald Hoyer  writes:
>>
>>> On 12.10.2015 05:02, Neil Brown wrote:

 If I have booted a kernel with md/raid built in (no modules) and
 I use dracut to build the initramfs for a different kernel which
 has the md code compiled as separate modules, then it does not include
 the required md modules in the initramfs.

 As a particular instance this happen when the root filesystem is on
 RAID0.  The 'raid0.ko' module is not included and boot fails.

 https://bugzilla.opensuse.org/show_bug.cgi?id=935993

 This only happens when 'host-only' is selected (which is the default for
 openSUSE).

 the modules.d/90mdraid/module-setup.sh code calls

 instmods =drivers/md

 instmods calls
module_is_host_only "raid0"
 and this incorrectly fails.

 If raid0.ko didn't have any alias this would succeed, but it does.

 $ modinfo -F alias raid0
 md-level-0
 md-raid0
 md-personality-2
>>>
>>> Huh? Is the module not loaded?
>>
>> No, because the running kernel has "md/raid built in (no modules)".
>>
>> Thanks,
>> NeilBrown
>>
>>>

 However these aliases don't appear in any modalias file in /sys/devices,
 in /proc/crypto, or in /proc/modules.

 Maybe you could parse /proc/mdstat..

 if [ -f /proc/mdstat ]; then
   while read _d _c _a _m _x; do
if [ "$_c" = ':' -a "$_a" = 'active' ]; then
   host_modalias["md-$_m"]=1
fi
   done < /proc/mdstat
 fi

 but it all seems rather fragile.  There are probably other modules that
 might miss out accidentally. dm?

 Do we really need the host_modalias stuff?

 Thanks,
 NeilBrown

> 
> Interesting... so we have to blow up the initramfs with the entire drivers/md
> in the case, where you switch from "compiled in" to "not compiled in"..
> 
> I guess that happens not that often, so better be safe than sorry.

remove host_modalias


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

Re: [PATCH] dracut.sh: Support --mount with just mountpoint as parameter

2015-11-13 Thread Harald Hoyer 
On 11.09.2015 13:35, Fabian wrote:
> Right now the --mount parameter of dracut expects a rather long fstab-like 
> line. This makes it possible to invoke dracut with e.g. --mount /boot.
> 
> ---
>  dracut.8.asc |  4 
>  dracut.sh| 16 +++-
>  2 files changed, 19 insertions(+), 1 deletion(-)

Thanks! Pushed.

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

Re: [PATCH] Add new file to export the common functions

2015-11-13 Thread Harald Hoyer 
On 29.10.2015 07:04, Minfei Huang wrote:
> Hi, Harald.
> 
> Ping. Do you have any feedback about this patch?
> 
> Thanks
> Minfei

cleaned up dracut-functions.sh and moved dracut specific functions to
dracut-inist.sh
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel/initrd loading delays

2015-11-13 Thread Harald Hoyer 
On 14.10.2015 11:04, Dave Young wrote:
> On 10/12/15 at 12:29pm, Felix Miata wrote:
>> On more and more installations since most distros have replaced mkinitrd with
>> dracut, on selecting a bootloader menu choice the "root
>> (hd0,...filesystemtype..[Linux-bzImage, setup, ... initrd /boot/initrd"
>> message stays on screen 40 seconds or more before the time-stamped boot
>> messages begin scrolling the screen. IIRC, these delays first began appearing
>> last January or February, and appear on multiple machines. All kernel and
>> initrd images are on smallish EXT3 or EXT4 (mostly the latter) filesystems
>> using 1024 blocksize on BIOS logical partitions on rotating rust (IIRC, all
>> with native 512b sector size, manufactured in 2011 or earlier). All
>> installations are configured with static IP. All have Plymouth either not
>> installed, or are booted with noplymouth included on kernel cmdline.
>>
>> e.g, on my fastest system, host msi85, a 3.0 GHz dual core Haswell, total
>> time from boot stanza select on BIOS host msi85 to Rawhide 4.3.0-0.rc3.git4.1
>> (dracut initramfs.img 11,326,223) multi-user.target shell prompt ready is
>> about 80 seconds following that 40 second delay, with last time stamp showing
>> 36.844484.
>>
>> Same msi85 system booting LMDE 2 3.16.0-4 (non-dracut? initrd.img 27,362,964;
>> initramfs-tools 0.120) delays start of boot messages nearly 80 seconds,
>> reaching DM greeter ready nearly 140 seconds after stanza selection.
>>
>> Same system booting openSUSE Leap 42.1 4.1.8 (dracut initrd 8,082,360)
>> exhibits no perceptible delay, reaching multi-user.target shell prompt in
>> under 47 seconds from boot stanza selection.
>>
>> Same system booting openSUSE 13.2 3.16.7 (dracut initrd 5,351,996) delays
>> start of boot messages about 40 seconds, reaching multi-user.target bash
>> prompt about 90 seconds after stanza selection.
>>
>> Same system booting Mageia 5 4.1.8 (dracut initrd.img 9,391,664) exhibits no
>> delay, reaching multi-user.target bash prompt in about 45 seconds.
>>
>> Same system booting Wheezy 3.2.0 (non-dracut initrd.img 10,537,321) exhibits
>> no delay, reaching DM greeter in less than about 45 seconds.
>>
>> Same system booting openSUSE 13.1 3.12.44 (non-dracut initrd 7,679,390)
>> exhibits no delay, reaching multi-user.target bash prompt in less than 45
>> seconds.
>>
>> Same system booting Fedora 23 4.2.2 (dracut initramfs.img 11,255,214) reaches
>> multi-user.target shell prompt in about 75 seconds after unknown
>> kernel/initrd delay (puts display into sleep mode until boot messages 
>> appear).
>>
>> Same system booting openSUSE Tumbleweed 4.2.1 (dracut initrd 8,970,760)
>> exhibits no delay, reaching multi-user.target bash prompt in less than 45
>> seconds.
>>
>> Same system booting (second, on sda28, vs. other on sda23) openSUSE
>> Tumbleweed 4.2.1 (dracut initrd 8,965,124) exhibits ~40 second delay,
>> reaching multi-user.target bash prompt in about 100 seconds.
>>
>> Same system booting Kubuntu 14.10 3.16.0 (non-dracut initrd 20,550,608)
>> exhibits no initial (linux/initrd) delay, reaching KDM greeter in about 90
>> seconds.
>>
>> Same system booting Fedora 22 4.1.8 (dracut initrd 10,788,392) exhibits no
>> delay, reaching multi-user.target bash prompt in less than 50 seconds.
> 
> Wow, you are using so many distributions.
> 
> From your previous tests, I feel it should not be a dracut problem.
> But you need first find where is the delay from, bootloader, kernel, or 
> somewhere else.
> I think you can select one distribution delaying happend, try older kernel
> if the older kernel does not have the delay then it should be kernel problem.
> 
> As for boot loader, they may have some debug options but I do not know that
> much.
> 
> Thanks
> Dave

Also rawhide kernels have debugging enabled, which slows down significantly.

Adding "rd.debug" might help.

https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_troubleshooting

Also "debug" for systemd/udevd debug messages.

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

Re: [Patch] Check rd.zfcp= format in dracut hook:cmdline process stage

2015-11-13 Thread Harald Hoyer 
On 16.10.2015 04:04, Zhiguo Deng wrote:
> When using rd.zfcp= parameter in generic.prm file, wrong format
> parameters will prevent the zfcp driver to add the correct SCSI
> disk. dracut should die when a wrong rd.zfcp= parameter supplied.
> 
> Signed-off-by: Zhiguo Deng 
> ---
>  modules.d/95zfcp/parse-zfcp.sh | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/modules.d/95zfcp/parse-zfcp.sh b/modules.d/95zfcp/parse-zfcp.sh
> index 9b22d93..91d790b 100755
> --- a/modules.d/95zfcp/parse-zfcp.sh
> +++ b/modules.d/95zfcp/parse-zfcp.sh
> @@ -5,6 +5,8 @@
>  getargbool 1 rd.zfcp.conf -d -n rd_NO_ZFCPCONF || rm /etc/zfcp.conf
>  
>  for zfcp_arg in $(getargs rd.zfcp -d 'rd_ZFCP='); do
> +echo $zfcp_arg | grep 
> '0\.[0-9a-fA-F]\.[0-9a-fA-F]\{4\},0x[0-9a-fA-F]\{16\},0x[0-9a-fA-F]\{16\}' 
> >/dev/null
> +test $? -ne 0 && die "For argument 'rd.zfcp=$zfcp_arg'\nSorry, invalid 
> format."
>  (
>  IFS=","
>  set $zfcp_arg
> 

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

Re: dracut is too "clever" at identifying modules to exclude.

2015-11-13 Thread Harald Hoyer 
On 12.10.2015 22:30, Neil Brown wrote:
> Harald Hoyer  writes:
> 
>> On 12.10.2015 05:02, Neil Brown wrote:
>>>
>>> If I have booted a kernel with md/raid built in (no modules) and
>>> I use dracut to build the initramfs for a different kernel which
>>> has the md code compiled as separate modules, then it does not include
>>> the required md modules in the initramfs.
>>>
>>> As a particular instance this happen when the root filesystem is on
>>> RAID0.  The 'raid0.ko' module is not included and boot fails.
>>>
>>> https://bugzilla.opensuse.org/show_bug.cgi?id=935993
>>>
>>> This only happens when 'host-only' is selected (which is the default for
>>> openSUSE).
>>>
>>> the modules.d/90mdraid/module-setup.sh code calls
>>>
>>> instmods =drivers/md
>>>
>>> instmods calls
>>>module_is_host_only "raid0"
>>> and this incorrectly fails.
>>>
>>> If raid0.ko didn't have any alias this would succeed, but it does.
>>>
>>> $ modinfo -F alias raid0
>>> md-level-0
>>> md-raid0
>>> md-personality-2
>>
>> Huh? Is the module not loaded?
> 
> No, because the running kernel has "md/raid built in (no modules)".
> 
> Thanks,
> NeilBrown
> 
>>
>>>
>>> However these aliases don't appear in any modalias file in /sys/devices,
>>> in /proc/crypto, or in /proc/modules.
>>>
>>> Maybe you could parse /proc/mdstat..
>>>
>>> if [ -f /proc/mdstat ]; then
>>>   while read _d _c _a _m _x; do
>>>if [ "$_c" = ':' -a "$_a" = 'active' ]; then
>>>   host_modalias["md-$_m"]=1
>>>fi
>>>   done < /proc/mdstat
>>> fi
>>>
>>> but it all seems rather fragile.  There are probably other modules that
>>> might miss out accidentally. dm?
>>>
>>> Do we really need the host_modalias stuff?
>>>
>>> Thanks,
>>> NeilBrown
>>>

Interesting... so we have to blow up the initramfs with the entire drivers/md
in the case, where you switch from "compiled in" to "not compiled in"..

I guess that happens not that often, so better be safe than sorry.
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dracut.sh: allow setting i18n_install_all in command options

2015-11-13 Thread Harald Hoyer 
On 11.09.2015 10:03, Dangyi Liu wrote:
> From: Dave Young 
> 
> During kdump, we need a way to disable i18n_install_all forcedly in
> order to reduce memory usage, especially on PowerPC machines with 64k
> pages, which would efficiently save upto 60MB memory.
> ---
>  dracut.8.asc | 3 +++
>  dracut.sh| 5 +
>  2 files changed, 8 insertions(+)
> 

Thanks! Pushed.

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

Re: [patch 0/6] Revert action_on_fail patches

2015-11-13 Thread Harald Hoyer 
On 29.09.2015 10:11, Dave Young wrote:
> On 08/31/15 at 10:43am, Dave Young wrote:
>> Hi,
>>
>> action_on_fail was introduced originally for kdump error handling.
>> Before the patches, dracut will drop into emergency shell for many
>> failure cases, but kdump does not care about some of failures as
>> long as vmcore can be saved successfully. Thus action_on_fail was
>> introduced to fall to kdump service in case early failure in dracut.
>>
>> But later with new systemd services, there are cases that kdump
>> script can never be called in case early dracut failure because of
>> systemd service dependency issues.
>>
>> Thus there was below post which create a new kdump error handler
>> systemd service:
>> https://lists.stg.fedoraproject.org/archives/list/ke...@lists.fedoraproject.org/thread/3EN63K2NDC6C545M5Z434VCHWDR3BCHD/
>>
>> Now this action_on_fail interface was useless, nobody use it and
>> it is broken with systemd sometimes. So I send this series to revert
>> them one by one.
>>
> 
> Harald, ping
> 
> Since the code is useless, IMHO it is odd to keep them and it will
> cause trouble in the future for further fixes and improvements.
> 
> What do you think?
> 
> Thanks
> Dave


Thanks, pushed!

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