Debian Bug report logs - #501359
initramfs-tools: MODULES=dep does not like Xen virtual block devices

version graph

Package: initramfs-tools; Maintainer for initramfs-tools is Debian kernel team <debian-kernel@lists.debian.org>; Source for initramfs-tools is src:initramfs-tools.

Reported by: Ferenc Wagner <wferi@niif.hu>

Date: Mon, 6 Oct 2008 21:00:05 UTC

Severity: normal

Found in version initramfs-tools/0.92j

Done: Ferenc Wagner <wferi@niif.hu>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#501359; Package initramfs-tools. (Mon, 06 Oct 2008 21:00:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ferenc Wagner <wferi@niif.hu>:
New Bug report received and forwarded. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. (Mon, 06 Oct 2008 21:00:07 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Ferenc Wagner <wferi@niif.hu>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: initramfs-tools: MODULES=dep does not like Xen virtual block devices
Date: Mon, 06 Oct 2008 22:59:33 +0200
Package: initramfs-tools
Version: 0.92j
Severity: normal

Hi,

when trying to build a small initramfs via MODULES=dep:

$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.26-1-xen-686
mkinitramfs: missing xvda root /dev/xvda1 /sys entry
mkinitramfs: workaround is MODULES=most
mkinitramfs: Error please report the bug
update-initramfs: failed for /boot/initrd.img-2.6.26-1-xen-686

So here you are.  This virtual machine has a single virtual partition
(/dev/xvda1) imported, no /dev/xvda.

Thanks,
Feri.

-- Package-specific info:
-- /proc/cmdline
root=/dev/xvda1 ro

-- /proc/filesystems
	ext3

-- lsmod
Module                  Size  Used by
evdev                   8768  0 
pcspkr                  3200  0 
ext3                  106024  1 
jbd                    40212  1 ext3
mbcache                 7876  1 ext3
dm_mirror              15872  0 
dm_log                  9220  1 dm_mirror
dm_snapshot            15108  0 
dm_mod                 46952  3 dm_mirror,dm_log,dm_snapshot

-- /etc/kernel-img.conf
# Kernel Image management overrides
# See kernel-img.conf(5) for details
do_symlinks = No

-- /etc/initramfs-tools/initramfs.conf
MODULES=most
BUSYBOX=y
KEYMAP=n
BOOT=local
DEVICE=eth0
NFSROOT=auto


-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-xen-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages initramfs-tools depends on:
ii  cpio                          2.9-13     GNU cpio -- a program to manage ar
ii  findutils                     4.4.0-2    utilities for finding files--find,
ii  klibc-utils                   1.5.12-2   small utilities built with klibc f
ii  module-init-tools             3.4-1      tools for managing Linux kernel mo
ii  udev                          0.125-6    /dev/ and hotplug management daemo

Versions of packages initramfs-tools recommends:
ii  busybox                       1:1.10.2-2 Tiny utilities for small and embed

initramfs-tools suggests no packages.

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#501359; Package initramfs-tools. (Mon, 15 Dec 2008 10:21:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to maximilian attems <max@stro.at>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. (Mon, 15 Dec 2008 10:21:06 GMT) Full text and rfc822 format available.

Message #10 received at 501359@bugs.debian.org (full text, mbox):

From: maximilian attems <max@stro.at>
To: Ferenc Wagner <wferi@niif.hu>
Cc: 501359@bugs.debian.org
Subject: Re: initramfs-tools: MODULES=dep does not like Xen virtual block devices
Date: Mon, 15 Dec 2008 11:17:40 +0100
> update-initramfs: Generating /boot/initrd.img-2.6.26-1-xen-686
> mkinitramfs: missing xvda root /dev/xvda1 /sys entry
> 
> So here you are.  This virtual machine has a single virtual partition
> (/dev/xvda1) imported, no /dev/xvda.

hmm could you please post the output of
ls /sys/block

so that i can add the relevant rule for xen block devices.
thanks

-- 
maks




Tags added: moreinfo Request was from maximilian attems <maks@debian.org> to control@bugs.debian.org. (Mon, 15 Dec 2008 10:21:07 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#501359; Package initramfs-tools. (Mon, 22 Dec 2008 09:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Campbell <ijc@hellion.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. (Mon, 22 Dec 2008 09:12:06 GMT) Full text and rfc822 format available.

Message #17 received at 501359@bugs.debian.org (full text, mbox):

From: Ian Campbell <ijc@hellion.org.uk>
To: maximilian attems <max@stro.at>, 501359@bugs.debian.org
Subject: Re: Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
Date: Mon, 22 Dec 2008 09:07:42 +0000
[Message part 1 (text/plain, inline)]
On Mon, 2008-12-15 at 11:17 +0100, maximilian attems wrote: 
> > update-initramfs: Generating /boot/initrd.img-2.6.26-1-xen-686
> > mkinitramfs: missing xvda root /dev/xvda1 /sys entry
> > 
> > So here you are.  This virtual machine has a single virtual partition
> > (/dev/xvda1) imported, no /dev/xvda.
> 
> hmm could you please post the output of
> ls /sys/block
> 
> so that i can add the relevant rule for xen block devices.
> thanks

Ferenc seems to be using the xvda1=img1,xvda2=img2 scheme of Xen disks
(this is what xentools gets you) rather than the whole disk with
partition scheme.

In the xvda1/xvda2 scheme /sys/block contains:
        # ls /sys/block/
        ram0  ram1  ram10  ram11  ram12  ram13 ram14  ram15  ram2  ram3
        ram4 ram5  ram6  ram7  ram8 ram9  xvda1  xvda2

In the whole disk scheme it contains xvda as you would expect:
        # ls /sys/block/
        loop0  loop1  loop2  loop3  loop4  loop5  loop6  loop7 ram0
        ram1  ram10  ram11  ram12  ram13 ram14  ram15  ram2  ram3  ram4
        ram5  ram6  ram7  ram8 ram9  xvda

I've attached a patch which takes care of this difference. However the
modules still aren't loaded.

Note that the -xen type images seem to have the block driver builtin
(and therefore work fine) while the -686-bigmem ones have it modular
(xen-blkfront.ko) and break with MODULES=dep.

I've attached ls -lRt of my /sys running -686-bigmem
and /sys/devices/vbd-51712/modalias contains "xen:vbd" which is present
as an alias on the xen-blkfront.ko module. Any other info required
please ask.

Ian.
-- 
Ian Campbell

One meets his destiny often on the road he takes to avoid it.
[initramfs-xvd-partition-only.patch (text/x-patch, attachment)]
[ls-lRt-sys.txt (text/plain, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#501359; Package initramfs-tools. (Tue, 17 Feb 2009 17:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to maximilian attems <max@stro.at>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. (Tue, 17 Feb 2009 17:21:04 GMT) Full text and rfc822 format available.

Message #22 received at 501359@bugs.debian.org (full text, mbox):

From: maximilian attems <max@stro.at>
To: Ian Campbell <ijc@hellion.org.uk>
Cc: 501359@bugs.debian.org
Subject: Re: Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
Date: Tue, 17 Feb 2009 17:58:32 +0100
On Mon, 22 Dec 2008, Ian Campbell wrote:

> Ferenc seems to be using the xvda1=img1,xvda2=img2 scheme of Xen disks
> (this is what xentools gets you) rather than the whole disk with
> partition scheme.
> 
> In the xvda1/xvda2 scheme /sys/block contains:
>         # ls /sys/block/
>         ram0  ram1  ram10  ram11  ram12  ram13 ram14  ram15  ram2  ram3
>         ram4 ram5  ram6  ram7  ram8 ram9  xvda1  xvda2
> 
> In the whole disk scheme it contains xvda as you would expect:
>         # ls /sys/block/
>         loop0  loop1  loop2  loop3  loop4  loop5  loop6  loop7 ram0
>         ram1  ram10  ram11  ram12  ram13 ram14  ram15  ram2  ram3  ram4
>         ram5  ram6  ram7  ram8 ram9  xvda

thanks for the analysis and the explanation.
 
> I've attached a patch which takes care of this difference. However the
> modules still aren't loaded.

hmm what?
which modules are not loaded?
 
> Note that the -xen type images seem to have the block driver builtin
> (and therefore work fine) while the -686-bigmem ones have it modular
> (xen-blkfront.ko) and break with MODULES=dep.

argh,
the syswalking doesn't add that one?
could you post output with MODULES=dep for the modular case of
sh -x mkinitramfs -o /tmp/foo
 
> I've attached ls -lRt of my /sys running -686-bigmem
> and /sys/devices/vbd-51712/modalias contains "xen:vbd" which is present
> as an alias on the xen-blkfront.ko module. Any other info required
> please ask.
 

thanks for the patch bellow i'll apply it asap,
as it is an improvement anyway

> --- /usr/share/initramfs-tools/hook-functions.orig	2008-12-17 21:48:06.000000000 +0000
> +++ /usr/share/initramfs-tools/hook-functions	2008-12-17 21:53:02.000000000 +0000
> @@ -269,6 +269,14 @@
>  		root=${root#/dev/}
>  		block=$(awk "/^${root}/{print substr(\$5, 1, 3); exit}" \
>  			/proc/mdstat)
> +	# Xen virtual device /dev/xvdX
> +	elif [ "${root#/dev/xvd}" != "${root}" ]; then
> +		block=${root#/dev/}
> +		# Xen has a mode where only the individual partitions are registered with the kernel
> +		# as well as the usual full disk with partition table scheme.
> +		if [ ! -e /sys/block/${block} ] ; then
> +			block=${block%[0-9]*}
> +		fi
>  	# classical root device
>  	else
>  		block=${root#/dev/}

-- 
maks




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#501359; Package initramfs-tools. (Tue, 17 Feb 2009 17:39:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Campbell <ijc@hellion.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. (Tue, 17 Feb 2009 17:39:09 GMT) Full text and rfc822 format available.

Message #27 received at 501359@bugs.debian.org (full text, mbox):

From: Ian Campbell <ijc@hellion.org.uk>
To: maximilian attems <max@stro.at>
Cc: 501359@bugs.debian.org
Subject: Re: Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
Date: Tue, 17 Feb 2009 17:35:16 +0000
[Message part 1 (text/plain, inline)]
On Tue, 2009-02-17 at 17:58 +0100, maximilian attems wrote:
> On Mon, 22 Dec 2008, Ian Campbell wrote:
> 
> > Ferenc seems to be using the xvda1=img1,xvda2=img2 scheme of Xen disks
> > (this is what xentools gets you) rather than the whole disk with
> > partition scheme.
> > 
> > In the xvda1/xvda2 scheme /sys/block contains:
> >         # ls /sys/block/
> >         ram0  ram1  ram10  ram11  ram12  ram13 ram14  ram15  ram2  ram3
> >         ram4 ram5  ram6  ram7  ram8 ram9  xvda1  xvda2
> > 
> > In the whole disk scheme it contains xvda as you would expect:
> >         # ls /sys/block/
> >         loop0  loop1  loop2  loop3  loop4  loop5  loop6  loop7 ram0
> >         ram1  ram10  ram11  ram12  ram13 ram14  ram15  ram2  ram3  ram4
> >         ram5  ram6  ram7  ram8 ram9  xvda
> 
> thanks for the analysis and the explanation.
>  
> > I've attached a patch which takes care of this difference. However the
> > modules still aren't loaded.
> 
> hmm what?
> which modules are not loaded?

It's so long ago ;-) I _think_ I meant that the xen-blkfoo.ko wasn't
included in the initrd (and hence not loaded on boot) even with the
patch.

> > Note that the -xen type images seem to have the block driver builtin
> > (and therefore work fine) while the -686-bigmem ones have it modular
> > (xen-blkfront.ko) and break with MODULES=dep.
> 
> argh,
> the syswalking doesn't add that one?
> could you post output with MODULES=dep for the modular case of
> sh -x mkinitramfs -o /tmp/foo

OK, have attached modules.most and modules.dep. In the modules.dep case
xen-blkfront.ko is not included in the initrd.

Ian.

-- 
Ian Campbell

 be vewwy vewwy qwuiet .. I'm huntin wuntime ewwos
[modules.most (text/plain, attachment)]
[modules.dep (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#501359; Package initramfs-tools. (Wed, 18 Feb 2009 00:06:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to maximilian attems <max@stro.at>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. (Wed, 18 Feb 2009 00:06:02 GMT) Full text and rfc822 format available.

Message #32 received at 501359@bugs.debian.org (full text, mbox):

From: maximilian attems <max@stro.at>
To: Ian Campbell <ijc@hellion.org.uk>, 501359@bugs.debian.org
Subject: Re: Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
Date: Wed, 18 Feb 2009 01:01:40 +0100
On Tue, Feb 17, 2009 at 05:35:16PM +0000, Ian Campbell wrote:
> 
> OK, have attached modules.most and modules.dep. In the modules.dep case
> xen-blkfront.ko is not included in the initrd.

ok.


+ block=xvda1
+ block=xvda
+ '[' -z xvda ']'
+ '[' '!' -e /sys/block/xvda ']'
++ readlink -f /sys/block/xvda/device
+ root_dev_path=/sys/devices/vbd-51712
+ sys_walk_mod_add /sys/devices/vbd-51712
+ local driver_path module
+ device_path=/sys/devices/vbd-51712
+ '[' /sys/devices/vbd-51712 '!=' /sys ']'
+ sys_walk_modalias /sys/devices/vbd-51712
+ local device_path modalias
++ dirname /sys/devices/vbd-51712
+ device_path=/sys/devices
++ dirname /sys/devices
+ device_path=/sys
+ '[' -e /sys/modalias ']'
+ '[' -n '' ']'
++ readlink -f /sys/devices/vbd-51712/driver
+ driver_path=/sys/bus/xen/drivers/vbd
+ '[' -e /sys/bus/xen/drivers/vbd ']'
+++ readlink -f /sys/bus/xen/drivers/vbd
++ basename /sys/bus/xen/drivers/vbd
+ module=vbd
+ '[' -n vbd ']'
+ force_load vbd
+ manual_add_modules vbd
+ local mam_x firmwares firmware
++ modprobe --set-version=2.6.26-1-686-bigmem --ignore-install --show-depends vbd
++ awk '/^insmod/ { print $2 }'
+ echo vbd
++ dirname /sys/devices/vbd-51712
+ device_path=/sys/devices
+ '[' /sys/devices '!=' /sys ']'
+ sys_walk_modalias /sys/devices
+ local device_path modalias
++ dirname /sys/devices
+ device_path=/sys
++ dirname /sys
+ device_path=/

well also according to the /sys tree you posted [1] this seems
to be an error of xen-blkfront declaring itself as vbd module
in sys?

-- 
maks

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=17;filename=ls-lRt-sys.txt;att=2;bug=501359




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#501359; Package initramfs-tools. (Wed, 18 Feb 2009 07:51:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Campbell <ijc@hellion.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. (Wed, 18 Feb 2009 07:51:05 GMT) Full text and rfc822 format available.

Message #37 received at 501359@bugs.debian.org (full text, mbox):

From: Ian Campbell <ijc@hellion.org.uk>
To: maximilian attems <max@stro.at>
Cc: 501359@bugs.debian.org
Subject: Re: Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
Date: Wed, 18 Feb 2009 07:47:28 +0000
[Message part 1 (text/plain, inline)]
On Wed, 2009-02-18 at 01:01 +0100, maximilian attems wrote:
> well also according to the /sys tree you posted [1] this seems
> to be an error of xen-blkfront declaring itself as vbd module
> in sys?

Could be, I don't really know how this sysfs stuff is supposed to work.

The module has several aliases:
        alias:          xenblk
        alias:          xen:vbd
        alias:          block-major-202-*
but not just plain vbd. (Similarly xen-netfront has xen:vif etc but not
plain vif). I guess it is the name of the entry
under /sys/bus/xen/drivers which matters?

Weirdly under /sys/module/xen_fbfront/drivers/ there is xen:vbd
-> .../bus/drivers/vbd, I'm not sure where that name comes from, it's
not even the first alias.

(FYI I'm about to leave for a weeks travel, I'll hopefully be on email
but not sure how often).

Ian.
-- 
Ian Campbell

Time to be aggressive.  Go after a tattooed Virgo.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#501359; Package initramfs-tools. (Tue, 06 Apr 2010 02:27:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to maximilian attems <max@stro.at>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. (Tue, 06 Apr 2010 02:27:02 GMT) Full text and rfc822 format available.

Message #42 received at 501359@bugs.debian.org (full text, mbox):

From: maximilian attems <max@stro.at>
To: Ian Campbell <ijc@hellion.org.uk>
Cc: 501359@bugs.debian.org
Subject: Re: Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
Date: Tue, 6 Apr 2010 04:23:32 +0200
tags 501359 moreinfo
stop

On Wed, 18 Feb 2009, Ian Campbell wrote:

> On Wed, 2009-02-18 at 01:01 +0100, maximilian attems wrote:
> > well also according to the /sys tree you posted [1] this seems
> > to be an error of xen-blkfront declaring itself as vbd module
> > in sys?
> 
> Could be, I don't really know how this sysfs stuff is supposed to work.
> 
> The module has several aliases:
>         alias:          xenblk
>         alias:          xen:vbd
>         alias:          block-major-202-*
> but not just plain vbd. (Similarly xen-netfront has xen:vif etc but not
> plain vif). I guess it is the name of the entry
> under /sys/bus/xen/drivers which matters?
> 
> Weirdly under /sys/module/xen_fbfront/drivers/ there is xen:vbd
> -> .../bus/drivers/vbd, I'm not sure where that name comes from, it's
> not even the first alias.
> 
> (FYI I'm about to leave for a weeks travel, I'll hopefully be on email
> but not sure how often).

sorry for late reponse, 0.94 changed a bit the way sysfs is walked.
could you please check against it if MODULES=dep is fixed?

thanks

-- 
maks




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#501359; Package initramfs-tools. (Tue, 06 Apr 2010 16:12:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Campbell <ijc@hellion.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. (Tue, 06 Apr 2010 16:12:06 GMT) Full text and rfc822 format available.

Message #47 received at 501359@bugs.debian.org (full text, mbox):

From: Ian Campbell <ijc@hellion.org.uk>
To: maximilian attems <max@stro.at>, Ferenc Wagner <wferi@niif.hu>
Cc: 501359@bugs.debian.org
Subject: Re: Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
Date: Tue, 06 Apr 2010 16:43:15 +0100
On Tue, 2010-04-06 at 04:23 +0200, maximilian attems wrote:
> 
> sorry for late reponse, 0.94 changed a bit the way sysfs is walked.
> could you please check against it if MODULES=dep is fixed? 

It works for me but I do not recall if I was originally able to
reproduce the issue with the "whole device" disk configuration I
typically use and I don't have an easy way to construct a "partitions
only" configuration at the moment. IIRC Ferenc (the original reporter)
was using the partition based scheme so perhaps he can confirm if it
works for him now.

Ian.
-- 
Ian Campbell

Thrashing is just virtual crashing.





Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#501359; Package initramfs-tools. (Tue, 08 Jun 2010 09:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Prokop <mika@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. (Tue, 08 Jun 2010 09:42:03 GMT) Full text and rfc822 format available.

Message #52 received at 501359@bugs.debian.org (full text, mbox):

From: Michael Prokop <mika@debian.org>
To: Ian Campbell <ijc@hellion.org.uk>, 501359@bugs.debian.org
Cc: maximilian attems <max@stro.at>, Ferenc Wagner <wferi@niif.hu>, control@bugs.debian.org
Subject: Re: Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
Date: Tue, 8 Jun 2010 11:39:16 +0200
[Message part 1 (text/plain, inline)]
tags 501359 + moreinfo
thanks

* Ian Campbell <ijc@hellion.org.uk> [Die Apr 06, 2010 at 04:43:15 +0100]:
> On Tue, 2010-04-06 at 04:23 +0200, maximilian attems wrote:

> > sorry for late reponse, 0.94 changed a bit the way sysfs is walked.
> > could you please check against it if MODULES=dep is fixed? 

> It works for me but I do not recall if I was originally able to
> reproduce the issue with the "whole device" disk configuration I
> typically use and I don't have an easy way to construct a "partitions
> only" configuration at the moment. IIRC Ferenc (the original reporter)
> was using the partition based scheme so perhaps he can confirm if it
> works for him now.

Ferenc, any news on that? Would be great if you could
give initramfs-tools >=0.95.1 a try.

regards,
-mika-
[signature.asc (application/pgp-signature, inline)]

Removed tag(s) moreinfo. Request was from Ferenc Wagner <wferi@niif.hu> to control@bugs.debian.org. (Wed, 09 Jun 2010 14:51:06 GMT) Full text and rfc822 format available.

Reply sent to Ferenc Wagner <wferi@niif.hu>:
You have taken responsibility. (Wed, 09 Jun 2010 14:51:08 GMT) Full text and rfc822 format available.

Notification sent to Ferenc Wagner <wferi@niif.hu>:
Bug acknowledged by developer. (Wed, 09 Jun 2010 14:51:08 GMT) Full text and rfc822 format available.

Message #59 received at 501359-done@bugs.debian.org (full text, mbox):

From: Ferenc Wagner <wferi@niif.hu>
To: Michael Prokop <mika@debian.org>
Cc: Ian Campbell <ijc@hellion.org.uk>, 501359-done@bugs.debian.org, maximilian attems <max@stro.at>, control@bugs.debian.org
Subject: Re: Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
Date: Wed, 09 Jun 2010 16:14:22 +0200
tags 501359 - moreinfo
thanks

Michael Prokop <mika@debian.org> writes:

> * Ian Campbell <ijc@hellion.org.uk> [Die Apr 06, 2010 at 04:43:15 +0100]:
>
>> On Tue, 2010-04-06 at 04:23 +0200, maximilian attems wrote:
>>
>>> sorry for late reponse, 0.94 changed a bit the way sysfs is walked.
>>> could you please check against it if MODULES=dep is fixed? 
>>
>> It works for me but I do not recall if I was originally able to
>> reproduce the issue with the "whole device" disk configuration I
>> typically use and I don't have an easy way to construct a "partitions
>> only" configuration at the moment. IIRC Ferenc (the original reporter)
>> was using the partition based scheme so perhaps he can confirm if it
>> works for him now.
>
> Ferenc, any news on that? Would be great if you could
> give initramfs-tools >=0.95.1 a try.

Sorry for the delay.  I stopped using "partitions only" configs myself,
but now took the time to install a test system.  The fresh Lenny install
reproduced the error fine, then I upgraded initramfs-tools (and nothing
else) to version 0.96.1 from Sid, and the error went away.  The
resulting iniramfs even works. :)  It gives an error message:

[    0.212391] Freeing unused kernel memory: 256k freed
Loading, please wait...
mount: mounting none on /dev failed: No such device
Begin: Loading essential drivers ... done.

which probably comes from init trying to mount devtmpfs as

if ! mount -t devtmpfs -o mode=0755 none /dev; then

which the Lenny kernel does not support, so this is OK.  It was a nice
move to make this conditional, otherwise I had had problems testing.

A side note: a couple of lines later devpts is still mounted in "legacy"
mode.  This makes full devpts isolation impossible, which is a problem
if the running system wants to use Linux containers.  I didn't track,
maybe this devpts mount does not survive the initramfs phase, but if it
does, this issue is something to think about (until the devpts default
changes, which won't be soon, and surely not for 2.6.32).
-- 
Thanks,
Feri.




Message #60 received at 501359-done@bugs.debian.org (full text, mbox):

From: Michael Prokop <mika@debian.org>
To: Ferenc Wagner <wferi@niif.hu>
Cc: Ian Campbell <ijc@hellion.org.uk>, 501359-done@bugs.debian.org, maximilian attems <max@stro.at>
Subject: Re: Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
Date: Mon, 14 Jun 2010 12:20:36 +0200
[Message part 1 (text/plain, inline)]
* Ferenc Wagner <wferi@niif.hu> [Wed Jun 09, 2010 at 04:14:22PM +0200]:
> Michael Prokop <mika@debian.org> writes:

> > * Ian Campbell <ijc@hellion.org.uk> [Die Apr 06, 2010 at 04:43:15 +0100]:

> >> On Tue, 2010-04-06 at 04:23 +0200, maximilian attems wrote:

> >>> sorry for late reponse, 0.94 changed a bit the way sysfs is walked.
> >>> could you please check against it if MODULES=dep is fixed? 

> >> It works for me but I do not recall if I was originally able to
> >> reproduce the issue with the "whole device" disk configuration I
> >> typically use and I don't have an easy way to construct a "partitions
> >> only" configuration at the moment. IIRC Ferenc (the original reporter)
> >> was using the partition based scheme so perhaps he can confirm if it
> >> works for him now.

> > Ferenc, any news on that? Would be great if you could
> > give initramfs-tools >=0.95.1 a try.

> Sorry for the delay.  I stopped using "partitions only" configs myself,
> but now took the time to install a test system.  The fresh Lenny install
> reproduced the error fine, then I upgraded initramfs-tools (and nothing
> else) to version 0.96.1 from Sid, and the error went away.  The
> resulting iniramfs even works. :)

Excellent, thanks a lot for testing!

> It gives an error message:

> [    0.212391] Freeing unused kernel memory: 256k freed
> Loading, please wait...
> mount: mounting none on /dev failed: No such device
> Begin: Loading essential drivers ... done.

> which probably comes from init trying to mount devtmpfs as

> if ! mount -t devtmpfs -o mode=0755 none /dev; then

> which the Lenny kernel does not support, so this is OK.  It was a nice
> move to make this conditional, otherwise I had had problems testing.

Ok.

> A side note: a couple of lines later devpts is still mounted in "legacy"
> mode.  This makes full devpts isolation impossible, which is a problem
> if the running system wants to use Linux containers.  I didn't track,
> maybe this devpts mount does not survive the initramfs phase, but if it
> does, this issue is something to think about (until the devpts default
> changes, which won't be soon, and surely not for 2.6.32).

Sorry, I'm not sure I can follow you. Can you please elaborate a
bit?

regards,
-mika-
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#501359; Package initramfs-tools. (Mon, 14 Jun 2010 11:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ferenc Wagner <wferi@niif.hu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. (Mon, 14 Jun 2010 11:12:03 GMT) Full text and rfc822 format available.

Message #65 received at 501359@bugs.debian.org (full text, mbox):

From: Ferenc Wagner <wferi@niif.hu>
To: Michael Prokop <mika@debian.org>
Cc: Ian Campbell <ijc@hellion.org.uk>, 501359@bugs.debian.org, maximilian attems <max@stro.at>
Subject: Re: Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
Date: Mon, 14 Jun 2010 12:47:42 +0200
Michael Prokop <mika@debian.org> writes:

> * Ferenc Wagner <wferi@niif.hu> [Wed Jun 09, 2010 at 04:14:22PM +0200]:
>
>> A side note: a couple of lines later devpts is still mounted in "legacy"
>> mode.  This makes full devpts isolation impossible, which is a problem
>> if the running system wants to use Linux containers.  I didn't track,
>> maybe this devpts mount does not survive the initramfs phase, but if it
>> does, this issue is something to think about (until the devpts default
>> changes, which won't be soon, and surely not for 2.6.32).
>
> Sorry, I'm not sure I can follow you. Can you please elaborate a bit?

You may want to refer to Documentation/devpts.txt in the Linux kernel
tree for more details.  Above I mixed up the terminology somewhat.  The
Squeeze kernel has CONFIG_DEVPTS_MULTIPLE_INSTANCES=y, so it isn't
running in legacy mode, but the devpts mounts (both in the initramfs and
in the startup scripts) don't use the 'newinstance' option, so the
system ends up using the "initial kernel mount of devpts".  Now even if
the container setup scripts take care to mount their own devpts
instances using the 'newinstance' option, this does not forbit the
contained system to also mount the "initial kernel mount of devpts" and
possibly interfere with the host system through it.  The solution is to
mount devpts in the host system with the 'newinstance' option, too, and
thus insulate it from the containers possibly running on the host.

I'm still disturbed by the fact that several containers could mount the
"initial kernel mount of devpts" and cooperate through it, but that's
their choice to use the inherently insecure common instance.

Hope I managed to make it clearer now.  I'm no expert of this, but this
concern seems somewhat founded, cf.
http://article.gmane.org/gmane.linux.kernel.containers.lxc.devel/298
-- 
Thanks,
Feri.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#501359; Package initramfs-tools. (Mon, 14 Jun 2010 14:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Prokop <mika@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. (Mon, 14 Jun 2010 14:45:03 GMT) Full text and rfc822 format available.

Message #70 received at 501359@bugs.debian.org (full text, mbox):

From: Michael Prokop <mika@debian.org>
To: Ferenc Wagner <wferi@niif.hu>
Cc: Ian Campbell <ijc@hellion.org.uk>, 501359@bugs.debian.org, maximilian attems <max@stro.at>
Subject: Re: Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
Date: Mon, 14 Jun 2010 16:43:54 +0200
[Message part 1 (text/plain, inline)]
* Ferenc Wagner <wferi@niif.hu> [Mon Jun 14, 2010 at 12:47:42PM +0200]:
> Michael Prokop <mika@debian.org> writes:
> > * Ferenc Wagner <wferi@niif.hu> [Wed Jun 09, 2010 at 04:14:22PM +0200]:

> >> A side note: a couple of lines later devpts is still mounted in "legacy"
> >> mode.  This makes full devpts isolation impossible, which is a problem
> >> if the running system wants to use Linux containers.  I didn't track,
> >> maybe this devpts mount does not survive the initramfs phase, but if it
> >> does, this issue is something to think about (until the devpts default
> >> changes, which won't be soon, and surely not for 2.6.32).

> > Sorry, I'm not sure I can follow you. Can you please elaborate a bit?

> You may want to refer to Documentation/devpts.txt in the Linux kernel
> tree for more details.  Above I mixed up the terminology somewhat.  The
> Squeeze kernel has CONFIG_DEVPTS_MULTIPLE_INSTANCES=y, so it isn't
> running in legacy mode, but the devpts mounts (both in the initramfs and
> in the startup scripts) don't use the 'newinstance' option, so the
> system ends up using the "initial kernel mount of devpts".  Now even if
> the container setup scripts take care to mount their own devpts
> instances using the 'newinstance' option, this does not forbit the
> contained system to also mount the "initial kernel mount of devpts" and
> possibly interfere with the host system through it.  The solution is to
> mount devpts in the host system with the 'newinstance' option, too, and
> thus insulate it from the containers possibly running on the host.

> I'm still disturbed by the fact that several containers could mount the
> "initial kernel mount of devpts" and cooperate through it, but that's
> their choice to use the inherently insecure common instance.

> Hope I managed to make it clearer now.  I'm no expert of this, but this
> concern seems somewhat founded, cf.
> http://article.gmane.org/gmane.linux.kernel.containers.lxc.devel/298

Ok thanks.

Would be a "mount -o remount,newinstance /dev/pts" right after
mounting /dev/pts be an option for us? The command fails without
causing any problems if the required kernel option isn't set, so it
should be safe.

Though AFAICS udev unmounts /dev/pts via /etc/init.d/udev anyway
(stating "we need to unmount /dev/pts/ and remount it later over the
tmpfs"). Should we ask the udev maintainer about it this issue as
well?

regards,
-mika-
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#501359; Package initramfs-tools. (Mon, 14 Jun 2010 17:39:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ferenc Wagner <wferi@niif.hu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. (Mon, 14 Jun 2010 17:39:07 GMT) Full text and rfc822 format available.

Message #75 received at 501359@bugs.debian.org (full text, mbox):

From: Ferenc Wagner <wferi@niif.hu>
To: Michael Prokop <mika@debian.org>
Cc: Ian Campbell <ijc@hellion.org.uk>, 501359@bugs.debian.org, maximilian attems <max@stro.at>, md@Linux.IT (Marco d'Itri)
Subject: mount devpts with the newinstance option
Date: Mon, 14 Jun 2010 19:36:06 +0200
Michael Prokop <mika@debian.org> writes:

> * Ferenc Wagner <wferi@niif.hu> [Mon Jun 14, 2010 at 12:47:42PM +0200]:
>> Michael Prokop <mika@debian.org> writes:
>>> * Ferenc Wagner <wferi@niif.hu> [Wed Jun 09, 2010 at 04:14:22PM +0200]:
>>>
>>>> A side note: a couple of lines later devpts is still mounted in "legacy"
>>>> mode.  This makes full devpts isolation impossible, which is a problem
>>>> if the running system wants to use Linux containers.  I didn't track,
>>>> maybe this devpts mount does not survive the initramfs phase, but if it
>>>> does, this issue is something to think about (until the devpts default
>>>> changes, which won't be soon, and surely not for 2.6.32).
>>>
>>> Sorry, I'm not sure I can follow you. Can you please elaborate a bit?
>>
>> You may want to refer to Documentation/devpts.txt in the Linux kernel
>> tree for more details.  Above I mixed up the terminology somewhat.  The
>> Squeeze kernel has CONFIG_DEVPTS_MULTIPLE_INSTANCES=y, so it isn't
>> running in legacy mode, but the devpts mounts (both in the initramfs and
>> in the startup scripts) don't use the 'newinstance' option, so the
>> system ends up using the "initial kernel mount of devpts".  Now even if
>> the container setup scripts take care to mount their own devpts
>> instances using the 'newinstance' option, this does not forbit the
>> contained system to also mount the "initial kernel mount of devpts" and
>> possibly interfere with the host system through it.  The solution is to
>> mount devpts in the host system with the 'newinstance' option, too, and
>> thus insulate it from the containers possibly running on the host.
>>
>> I'm still disturbed by the fact that several containers could mount the
>> "initial kernel mount of devpts" and cooperate through it, but that's
>> their choice to use the inherently insecure common instance.
>>
>> Hope I managed to make it clearer now.  I'm no expert of this, but this
>> concern seems somewhat founded, cf.
>> http://article.gmane.org/gmane.linux.kernel.containers.lxc.devel/298
>
> Ok thanks.
>
> Would be a "mount -o remount,newinstance /dev/pts" right after
> mounting /dev/pts be an option for us? The command fails without
> causing any problems if the required kernel option isn't set, so it
> should be safe.

Probably yes.

> Though AFAICS udev unmounts /dev/pts via /etc/init.d/udev anyway
> (stating "we need to unmount /dev/pts/ and remount it later over the
> tmpfs"). Should we ask the udev maintainer about it this issue as
> well?

Absolutely, I put Marco on Cc.  Although I seem to recall sending him a
note about this, I can't find any trace of it...  We should really find
a better place for this discussion, the current Cc list is somewhat
stale.  I changed the subject now.

So, Marco, what do you think about this issue?
-- 
Thanks,
Feri.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#501359; Package initramfs-tools. (Mon, 14 Jun 2010 17:51:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to md@Linux.IT (Marco d'Itri):
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. (Mon, 14 Jun 2010 17:51:05 GMT) Full text and rfc822 format available.

Message #80 received at 501359@bugs.debian.org (full text, mbox):

From: md@Linux.IT (Marco d'Itri)
To: Ferenc Wagner <wferi@niif.hu>
Cc: Michael Prokop <mika@debian.org>, Ian Campbell <ijc@hellion.org.uk>, 501359@bugs.debian.org, maximilian attems <max@stro.at>
Subject: Re: mount devpts with the newinstance option
Date: Mon, 14 Jun 2010 19:46:52 +0200
[Message part 1 (text/plain, inline)]
On Jun 14, Ferenc Wagner <wferi@niif.hu> wrote:

> Michael Prokop <mika@debian.org> writes:

> > Though AFAICS udev unmounts /dev/pts via /etc/init.d/udev anyway
> > (stating "we need to unmount /dev/pts/ and remount it later over the
> > tmpfs"). Should we ask the udev maintainer about it this issue as
> > well?
It's not really hard to check the init script. /dev/pts/ and /dev/shm/
are mounted by /etc/init.d/mountkernfs.sh .
Send patches to the initscripts maintainer.

-- 
ciao,
Marco
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#501359; Package initramfs-tools. (Mon, 14 Jun 2010 18:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ferenc Wagner <wferi@niif.hu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. (Mon, 14 Jun 2010 18:18:02 GMT) Full text and rfc822 format available.

Message #85 received at 501359@bugs.debian.org (full text, mbox):

From: Ferenc Wagner <wferi@niif.hu>
To: Petter Reinholdtsen <pere@debian.org>,
Cc: Michael Prokop <mika@debian.org>, Ian Campbell <ijc@hellion.org.uk>, 501359@bugs.debian.org, maximilian attems <max@stro.at>, md@Linux.IT (Marco d'Itri)
Subject: Re: mount devpts with the newinstance option
Date: Mon, 14 Jun 2010 20:15:06 +0200
md@Linux.IT (Marco d'Itri) writes:

> On Jun 14, Ferenc Wagner <wferi@niif.hu> wrote:
>
>> Michael Prokop <mika@debian.org> writes:
>
>>> * Ferenc Wagner <wferi@niif.hu> [Mon Jun 14, 2010 at 12:47:42PM +0200]:
>>>
>>>> Michael Prokop <mika@debian.org> writes:
>>>>
>>>>> * Ferenc Wagner <wferi@niif.hu> [Wed Jun 09, 2010 at 04:14:22PM +0200]:
>>>>>
>>>>>> A side note: a couple of lines later devpts is still mounted in "legacy"
>>>>>> mode.  This makes full devpts isolation impossible, which is a problem
>>>>>> if the running system wants to use Linux containers.  I didn't track,
>>>>>> maybe this devpts mount does not survive the initramfs phase, but if it
>>>>>> does, this issue is something to think about (until the devpts default
>>>>>> changes, which won't be soon, and surely not for 2.6.32).
>>>>>
>>>>> Sorry, I'm not sure I can follow you. Can you please elaborate a bit?
>>>>
>>>> You may want to refer to Documentation/devpts.txt in the Linux kernel
>>>> tree for more details.  Above I mixed up the terminology somewhat.  The
>>>> Squeeze kernel has CONFIG_DEVPTS_MULTIPLE_INSTANCES=y, so it isn't
>>>> running in legacy mode, but the devpts mounts (both in the initramfs and
>>>> in the startup scripts) don't use the 'newinstance' option, so the
>>>> system ends up using the "initial kernel mount of devpts".  Now even if
>>>> the container setup scripts take care to mount their own devpts
>>>> instances using the 'newinstance' option, this does not forbit the
>>>> contained system to also mount the "initial kernel mount of devpts" and
>>>> possibly interfere with the host system through it.  The solution is to
>>>> mount devpts in the host system with the 'newinstance' option, too, and
>>>> thus insulate it from the containers possibly running on the host.
>>>>
>>>> I'm still disturbed by the fact that several containers could mount the
>>>> "initial kernel mount of devpts" and cooperate through it, but that's
>>>> their choice to use the inherently insecure common instance.
>>>>
>>>> Hope I managed to make it clearer now.  I'm no expert of this, but this
>>>> concern seems somewhat founded, cf.
>>>> http://article.gmane.org/gmane.linux.kernel.containers.lxc.devel/298
>>>
>>> Ok thanks.
>>>
>>> Would be a "mount -o remount,newinstance /dev/pts" right after
>>> mounting /dev/pts be an option for us? The command fails without
>>> causing any problems if the required kernel option isn't set, so it
>>> should be safe.
>>
>> Probably yes.
>>
>>> Though AFAICS udev unmounts /dev/pts via /etc/init.d/udev anyway
>>> (stating "we need to unmount /dev/pts/ and remount it later over the
>>> tmpfs"). Should we ask the udev maintainer about it this issue as
>>> well?
>
> It's not really hard to check the init script. /dev/pts/ and /dev/shm/
> are mounted by /etc/init.d/mountkernfs.sh .

You mean /etc/init.d/mountdevsubfs.sh .

> Send patches to the initscripts maintainer.

That's why didn't find this stuff: because I mentioned it instead to the
initscripts maintainer in Bug#584742.  That bug was meanwhile closed,
let's ask Petter about it again!

Besides that, I still think fixing this in the initramfs would be a good
idea, just in case something goes wrong or changes later.
-- 
Thanks,
Feri.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#501359; Package initramfs-tools. (Mon, 14 Jun 2010 18:24:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Petter Reinholdtsen <pere@hungry.com>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. (Mon, 14 Jun 2010 18:24:03 GMT) Full text and rfc822 format available.

Message #90 received at 501359@bugs.debian.org (full text, mbox):

From: Petter Reinholdtsen <pere@hungry.com>
To: Ferenc Wagner <wferi@niif.hu>
Cc: Michael Prokop <mika@debian.org>, Ian Campbell <ijc@hellion.org.uk>, 501359@bugs.debian.org, maximilian attems <max@stro.at>, Marco d'Itri <md@Linux.IT>
Subject: Re: mount devpts with the newinstance option
Date: Mon, 14 Jun 2010 20:22:19 +0200
[Ferenc Wagner]
> That's why didn't find this stuff: because I mentioned it instead to
> the initscripts maintainer in Bug#584742.  That bug was meanwhile
> closed, let's ask Petter about it again!

Bug #584742 was about adding mkdir calls, and tat part is fixed.  If
you want something new done, create a new bug report. :)

As for the mount options for /dev/pts/, I have no idea what it should
be, and have not had time to investigate it.  We are seriously short
on man-power maintaining the sysvinit package, so help, feedback and
patches are needed to get fixes for the 300 open bugs added to the
package. :)

Happy hacking,
-- 
Petter Reinholdtsen




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Tue, 13 Jul 2010 07:36:29 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 13:34:25 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.