Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
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.orig2008-12-17
> 21:48:06.0 +
> +++ /usr/share/initramfs-tools/hook-functions 2008-12-17 21:53:02.0
> +
> @@ -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
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
On Tue, Feb 17, 2009 at 05:35:16PM +, 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
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
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 Description: This is a digitally signed message part
Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
tags 501359 + moreinfo thanks * Ian Campbell [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 Description: Digital signature
Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
Michael Prokop writes: > * Ferenc Wagner [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. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r5k9oppt@tac.ki.iif.hu
Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
* Ferenc Wagner [Mon Jun 14, 2010 at 12:47:42PM +0200]: > Michael Prokop writes: > > * Ferenc Wagner [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 Description: Digital signature
Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
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 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100406022332.gc7...@stro.at
Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
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. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1270568595.4740.659.ca...@zakaz.uk.xensource.com
Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
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 jbd40212 1 ext3 mbcache 7876 1 ext3 dm_mirror 15872 0 dm_log 9220 1 dm_mirror dm_snapshot15108 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-2utilities 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
> 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 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
On Mon, Jun 14, 2010 at 12:47:42PM +0200, Ferenc Wagner wrote: > 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. You need to replace /dev/ptmx in this case. Bastian -- Spock: We suffered 23 casualties in that attack, Captain. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100614202627.ga10...@wavehammer.waldi.eu.org
Processed: Re: Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
Processing commands for cont...@bugs.debian.org: > tags 501359 + moreinfo Bug #501359 [initramfs-tools] initramfs-tools: MODULES=dep does not like Xen virtual block devices Ignoring request to alter tags of bug #501359 to the same tags previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 501359: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501359 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.127598998623016.transcr...@bugs.debian.org
Processed: Re: Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
Processing commands for cont...@bugs.debian.org: > tags 501359 - moreinfo Bug #501359 [initramfs-tools] initramfs-tools: MODULES=dep does not like Xen virtual block devices Removed tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 501359: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501359 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.127609501031286.transcr...@bugs.debian.org
Processed: Re: Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
Processing commands for cont...@bugs.debian.org: > tags 501359 moreinfo Bug #501359 [initramfs-tools] initramfs-tools: MODULES=dep does not like Xen virtual block devices Ignoring request to alter tags of bug #501359 to the same tags previously set > stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.127052065822278.transcr...@bugs.debian.org
