FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 04-04-2011, 11:28 AM
Arno Schuring
 
Default Bug#620814: initramfs-tools: fails to include essential module for other leg of md0

Package: initramfs-tools
Version: 0.98.8
Severity: normal

(resending manually because exim hadn't been configured yet)

This is a new Wheezy install on an old server machine. The machine has four
PATA disks, tied to two controllers. The four disks are combined into a SW-raid
volume using mdadm:

ladmin@fury:/tmp$ sudo mdadm --detail /dev/md0|grep /dev/
/dev/md0:
0 8 36 0 active sync /dev/sdc4
1 8 52 1 active sync /dev/sdd4
2 8 4 2 active sync /dev/sda4
4 8 20 3 active sync /dev/sdb4

[ 1.145853] scsi0 : pata_sil680
[ 1.146143] scsi1 : pata_sil680
[ 1.147018] ata1: PATA max UDMA/133 cmd 0xc400 ctl 0xc000 bmdma 0xb000 irq 23
[ 1.147085] ata2: PATA max UDMA/133 cmd 0xb800 ctl 0xb400 bmdma 0xb008 irq 23
[ 1.148407] scsi2 : pata_serverworks
[ 1.148835] scsi3 : pata_serverworks
[ 1.156965] ata3: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
[ 1.157034] ata4: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15


During installation, I configured initramfs-tools to determine the required
modules automatically, which resulted in a non-booting system (notice that
the sil680 module is missing):

ladmin@fury:/tmp$ lsinitramfs /boot/initrd.img-2.6.32-5-686 |grep ata
lib/udev/ata_id
lib/modules/2.6.38-2-686/kernel/drivers/ata
lib/modules/2.6.38-2-686/kernel/drivers/ata/ata_generic.ko
lib/modules/2.6.38-2-686/kernel/drivers/ata/pata_serverworks.ko
lib/modules/2.6.38-2-686/kernel/drivers/ata/libata.ko


As a workaround, I've now added both pata_ modules to /e/i-t/modules,
but that is about as far as my knowledge of initramfs-tools will go.
I'll be glad to try other suggestions, or provide more info.


--
(regarding the below: I apologize, I can get carried away sometimes...
I'll leave solving this up to you

From my reading of sh -x output, it appears that there is just one level too
much indirection going on. We have a
+ readlink -f /dev/mapper/fury-root
/dev/dm-0
Which finds the correct dm device. Following the trace,
+ ls -1 /sys/block/dm-0/slaves
+ block=md0
md0 is identified as the correct md device underlying the lvm VG. But this is
also where it breaks down; the sed expression following it reduces /proc/mdstat
to just a single block device:
+ block=sdc
[...]
+ readlink -f /sys/block/sdc/device

This code maps to dep_add_modules() in hook-functions, particularly the sed
expression on line 288 (preceded by comment "lvm on md"). The code surely
doesn't look like it's designed to handle more than one block device per
invocation, but that is probably what's needed here. It's trivial to modify
the sed expression to that end (replacing the last -e argument):
sed [...] -e 's/[[0-9]+]//g' -e '/^'${block}' :/s/^[^[]*[ //p'
But that still leaves the issue that the rest of the code expects $block to
only represent a single block device. At the very least, the "#Error out" and
"# sys walk ATA" code blocks (line 350+) would need a loop.



-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 4.2M Apr 3 21:37 /boot/initrd.img-2.6.32-5-686
-rw-r--r-- 1 root root 4.3M Apr 3 21:37 /boot/initrd.img-2.6.38-2-686
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-2.6.38-2-686 root=/dev/mapper/fury-root ro

-- resume
RESUME=/dev/mapper/sda3_crypt
-- /proc/filesystems
btrfs
ext4
ext3

-- lsmod
Module Size Used by
ext3 98001 1
jbd 40818 1 ext3
dm_mirror 17249 1
dm_region_hash 13072 1 dm_mirror
dm_log 13269 3 dm_mirror,dm_region_hash
loop 17805 0
sha256_generic 16709 8
aes_i586 16608 16
aes_generic 37066 1 aes_i586
cbc 12659 8
dm_crypt 17809 4
snd_pcm 52774 0
snd_timer 22171 1 snd_pcm
ohci_hcd 21928 0
ehci_hcd 34889 0
snd 38153 2 snd_pcm,snd_timer
usbcore 99058 3 ohci_hcd,ehci_hcd
soundcore 12878 1 snd
snd_page_alloc 12841 1 snd_pcm
tpm_tis 12949 0
tpm 17454 1 tpm_tis
tg3 103807 0
pcspkr 12515 0
tpm_bios 12799 1 tpm
aic7xxx 97720 0
i2c_piix4 12480 0
libphy 18279 1 tg3
evdev 13084 2
processor 26983 0
nls_base 12649 1 usbcore
i2c_core 18989 1 i2c_piix4
thermal_sys 17667 1 processor
scsi_transport_spi 19032 1 aic7xxx
button 12866 0
ext4 251726 3
mbcache 12810 2 ext3,ext4
jbd2 55701 1 ext4
crc16 12327 1 ext4
dm_mod 56394 37 dm_mirror,dm_log,dm_crypt
raid456 51595 1
async_raid6_recov 12459 1 raid456
async_pq 12503 2 raid456,async_raid6_recov
raid6_pq 86733 2 async_raid6_recov,async_pq
async_xor 12390 3 raid456,async_raid6_recov,async_pq
xor 21454 1 async_xor
async_memcpy 12363 2 raid456,async_raid6_recov
async_tx 12510 5 raid456,async_raid6_recov,async_pq,async_xor,async _memcpy
raid10 25891 1
md_mod 80674 4 raid456,raid10
btrfs 419245 1
zlib_deflate 21186 1 btrfs
crc32c 12576 1
libcrc32c 12394 1 btrfs
sd_mod 34941 20
crc_t10dif 12332 1 sd_mod
ata_generic 12439 0
pata_serverworks 12869 8
pata_sil680 12646 8
libata 131904 3 ata_generic,pata_serverworks,pata_sil680
scsi_mod 134369 4 aic7xxx,scsi_transport_spi,sd_mod,libata

-- /etc/initramfs-tools/modules
pata_sil680
pata_serverworks

-- /etc/kernel-img.conf
# Kernel image management overrides
# See kernel-img.conf(5) for details
do_symlinks = yes
do_bootloader = no
do_initrd = yes
link_in_boot = no

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

-- /etc/initramfs-tools/update-initramfs.conf
update_initramfs=yes
backup_initramfs=no

-- /etc/crypttab
sda3_crypt /dev/sda3 /dev/urandom
cipher=aes-cbc-essiv:sha256,size=256,swap
sdb3_crypt /dev/sdb3 /dev/urandom
cipher=aes-cbc-essiv:sha256,size=256,swap
sdc3_crypt /dev/sdc3 /dev/urandom
cipher=aes-cbc-essiv:sha256,size=256,swap
sdd3_crypt /dev/sdd3 /dev/urandom
cipher=aes-cbc-essiv:sha256,size=256,swap

-- /proc/mdstat
Personalities : [raid10] [raid6] [raid5] [raid4]
md1 : active raid10 sdc5[0] sdb5[3] sda5[2] sdd5[1]
307062784 blocks super 1.2 512K chunks 2 offset-copies [4/4] [UUUU]
md0 : active raid5 sdc4[0] sdb4[4] sda4[2] sdd4[1]
18869760 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
unused devices: <none>

-- mkinitramfs hooks
/etc/initramfs-tools/hooks/:

/usr/share/initramfs-tools/hooks:
btrfs
busybox
cryptgnupg
cryptkeyctl
cryptopenct
cryptopensc
cryptpassdev
cryptroot
dmsetup
keymap
klibc
lvm2
mdadm
thermal
udev


-- System Information:
Debian Release: wheezy/sid
APT prefers stable
APT policy: (900, 'stable'), (600, 'testing'), (300, 'unstable'), (200, 'experimental') Architecture: i386 (i686)

Kernel: Linux 2.6.38-2-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash

Versions of packages initramfs-tools depends on:
ii cpio 2.11-7 GNU cpio -- a program to manage ar
ii findutils 4.4.2-1+b1 utilities for finding files--find,
ii klibc-utils 1.5.21-1 small utilities built with klibc f
ii module-init-tools 3.12-1 tools for managing Linux kernel mo
ii udev 166-1 /dev/ and hotplug management daemo

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

Versions of packages initramfs-tools suggests:
ii bash-completion 1:1.3-1 programmable completion for the ba

-- no debconf information



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110404132815.4229b8c8@neminis.loos.site">http://lists.debian.org/20110404132815.4229b8c8@neminis.loos.site
 
Old 04-04-2011, 12:08 PM
Ben Hutchings
 
Default Bug#620814: initramfs-tools: fails to include essential module for other leg of md0

On Mon, Apr 04, 2011 at 01:28:15PM +0200, Arno Schuring wrote:
> Package: initramfs-tools
> Version: 0.98.8
> Severity: normal
>
> (resending manually because exim hadn't been configured yet)
>
> This is a new Wheezy install on an old server machine. The machine has four
> PATA disks, tied to two controllers. The four disks are combined into a SW-raid
> volume using mdadm:
>
> ladmin@fury:/tmp$ sudo mdadm --detail /dev/md0|grep /dev/
> /dev/md0:
> 0 8 36 0 active sync /dev/sdc4
> 1 8 52 1 active sync /dev/sdd4
> 2 8 4 2 active sync /dev/sda4
> 4 8 20 3 active sync /dev/sdb4
>
> [ 1.145853] scsi0 : pata_sil680
> [ 1.146143] scsi1 : pata_sil680
> [ 1.147018] ata1: PATA max UDMA/133 cmd 0xc400 ctl 0xc000 bmdma 0xb000 irq 23
> [ 1.147085] ata2: PATA max UDMA/133 cmd 0xb800 ctl 0xb400 bmdma 0xb008 irq 23
> [ 1.148407] scsi2 : pata_serverworks
> [ 1.148835] scsi3 : pata_serverworks
> [ 1.156965] ata3: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
> [ 1.157034] ata4: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
>
>
> During installation, I configured initramfs-tools to determine the required
> modules automatically, which resulted in a non-booting system (notice that
> the sil680 module is missing):
[...]

The initramfs-tools 'MODULES=dep' mode is primarily meant for small
systems with limited RAM and disk space for the initramfs. The
dependency detection code does not currently handle all module
dependencies, as you see. I recommend using 'MODULES=most'.

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110404120804.GJ2268@decadent.org.uk">http://lists.debian.org/20110404120804.GJ2268@decadent.org.uk
 
Old 04-04-2011, 12:21 PM
Arno Schuring
 
Default Bug#620814: initramfs-tools: fails to include essential module for other leg of md0

Hi Ben,

> > During installation, I configured initramfs-tools to determine the required
> > modules automatically, which resulted in a non-booting system (notice that
> > the sil680 module is missing):
> [...]
>
> The initramfs-tools 'MODULES=dep' mode is primarily meant for small
> systems with limited RAM and disk space for the initramfs. The
> dependency detection code does not currently handle all module
> dependencies, as you see. I recommend using 'MODULES=most'.
>

But MODULES=most is exactly what is set:

> -- /etc/initramfs-tools/initramfs.conf
> MODULES=most

Regards,
Arno




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: SNT108-W200A41EC816F1E33F7649EB8A30@phx.gbl">http://lists.debian.org/SNT108-W200A41EC816F1E33F7649EB8A30@phx.gbl
 
Old 04-04-2011, 06:57 PM
maximilian attems
 
Default Bug#620814: initramfs-tools: fails to include essential module for other leg of md0

On Mon, Apr 04, 2011 at 12:21:16PM +0000, Arno Schuring wrote:
>
> Hi Ben,
>
> > > During installation, I configured initramfs-tools to determine the required
> > > modules automatically, which resulted in a non-booting system (notice that
> > > the sil680 module is missing):
> > [...]
> >
> > The initramfs-tools 'MODULES=dep' mode is primarily meant for small
> > systems with limited RAM and disk space for the initramfs. The
> > dependency detection code does not currently handle all module
> > dependencies, as you see. I recommend using 'MODULES=most'.
> >
>
> But MODULES=most is exactly what is set:
>
> > -- /etc/initramfs-tools/initramfs.conf
> > MODULES=most

no, check your box with:
egrep MODULES -r /etc/initramfs-tools/

--
maks



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110404185732.GA13777@vostochny.stro.at">http://lists.debian.org/20110404185732.GA13777@vostochny.stro.at
 
Old 04-04-2011, 10:15 PM
Arno Schuring
 
Default Bug#620814: initramfs-tools: fails to include essential module for other leg of md0

> no, check your box with:
> egrep MODULES -r /etc/initramfs-tools/

Great.

/etc/initramfs-tools/initramfs.conf:# MODULES: [ most | netboot | dep | list ]
/etc/initramfs-tools/initramfs.conf:MODULES=most
/etc/initramfs-tools/conf.d/driver-policy:MODULES=dep

So, which one is the preferred location? Will anything break if I just clear out the conf.d directory?
ladmin@fury:~$ dpkg -S /etc/initramfs-tools/conf.d/*
dpkg: /etc/initramfs-tools/conf.d/driver-policy not found.
dpkg: /etc/initramfs-tools/conf.d/resume not found.
 
Old 04-05-2011, 06:44 AM
maximilian attems
 
Default Bug#620814: initramfs-tools: fails to include essential module for other leg of md0

On Mon, Apr 04, 2011 at 10:15:21PM +0000, Arno Schuring wrote:
>
>
> > no, check your box with:
> > egrep MODULES -r /etc/initramfs-tools/
>
> Great.
>
> /etc/initramfs-tools/initramfs.conf:# MODULES: [ most | netboot | dep | list ]
> /etc/initramfs-tools/initramfs.conf:MODULES=most

> /etc/initramfs-tools/conf.d/driver-policy:MODULES=dep

you choose so on your Debian installation. on the why only you can respond (:
The expert install has a seemingly bad phrase so that many users seem to prefer
MODULES=dep, when that question is shown.

As you noticed the file is unowned and can be removed and the initramfs regenerated.

Nevertheless your fail in MODULES=dep is interesting and didn't have time yet
to properly read this corresponding bug.

sunny greetings.

--
maks




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110405064455.GB13777@vostochny.stro.at">http://lists.debian.org/20110405064455.GB13777@vostochny.stro.at
 
Old 04-05-2011, 06:50 AM
maximilian attems
 
Default Bug#620814: initramfs-tools: fails to include essential module for other leg of md0

On Mon, Apr 04, 2011 at 10:15:21PM +0000, Arno Schuring wrote:
>
> So, which one is the preferred location? Will anything break if I just clear out the conf.d directory?
> ladmin@fury:~$ dpkg -S /etc/initramfs-tools/conf.d/*
> dpkg: /etc/initramfs-tools/conf.d/driver-policy not found.
> dpkg: /etc/initramfs-tools/conf.d/resume not found.

for assisantance please ask on a debian-user mailinglist not on a bug report!
If you remove the resume file of course you can no longer suspend to disk.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110405065056.GD13777@vostochny.stro.at">http://lists.debian.org/20110405065056.GD13777@vostochny.stro.at
 
Old 04-05-2011, 11:00 PM
Arno Schuring
 
Default Bug#620814: initramfs-tools: fails to include essential module for other leg of md0

Thusly spoke maximilian attems (maks@debian.org on 2011-04-05 06:44
+0000):
> On Mon, Apr 04, 2011 at 10:15:21PM +0000, Arno Schuring wrote:
> >
> >
> > > no, check your box with:
> > > egrep MODULES -r /etc/initramfs-tools/
> >
> > Great.
> >
> > /etc/initramfs-tools/initramfs.conf:# MODULES: [ most | netboot |
> > dep | list ] /etc/initramfs-tools/initramfs.conf:MODULES=most
>
> > /etc/initramfs-tools/conf.d/driver-policy:MODULES=dep
>
> you choose so on your Debian installation. on the why only you can
> respond (:
Habit. But my surprise was that MODULES was defined twice. Having never
dealt with conf.d before, I didn't think to look there.

> The expert install has a seemingly bad phrase so that many
> users seem to prefer MODULES=dep, when that question is shown.
I did use expert install, but I would have chosen dep anyway; it's
never bitten me in the past, and I used to use very small (32MB)
IDE-flash drives for /boot.

> As you noticed the file is unowned and can be removed and the
> initramfs regenerated.
>
> Nevertheless your fail in MODULES=dep is interesting and didn't have
> time yet to properly read this corresponding bug.
Since I had already spent so much time reading into the source, I spent
another hour yesterday to rewrite hook-functions to my liking. Patch
attached. It basically replaces the entire sysfs-from-dev divination
with a walker that uses sysfs' slave links to reach the underlying
device, collecting modules along the way.

Please treat this as an FYI, not a push. The exercise is academic
anyway, since this is not in any way a resource-constrained device. I'm
not comfortable signing off on this code, because
a) I simply can't test and have no experience with block devices other
than lvm, md and plain partitions.
b) the code assumes a lot about sysfs that I have not been able to
support with documentation:
- there appears to be no guarantee about the existence of a block
device at all (maybe it's driver-dependent?)
- no guarantee about whether following slaves/ in /block/ will always
reach an endpoint under /devices/
- "Never depend on the "device"-link" is mentioned explicitly in the
document, but there appears to be no other way to reach driver/ from
/block/ (?). It also explicitly says "Accessing
/sys/class/net/eth0/device is a bug in the application"
c) initramfs is not exactly the place where you can afford to be naive
without consequence


That said, this code WorksForMe(tm), I've tried very hard not to
break any old code paths. It can't replace the existing code anyway
because it relies on udev, which is non-essential. I think
sys_walk_device might be useful though.

Oh, and there's several indentation violations to avoid huge
whitespace-only changes. Like I said, it's not a submission.
 
Old 11-23-2011, 12:27 PM
Michael Prokop
 
Default Bug#620814: initramfs-tools: fails to include essential module for other leg of md0

* Arno Schuring [Mit Apr 06, 2011 at 01:00:23 +0200]:
> Thusly spoke maximilian attems (maks@debian.org on 2011-04-05 06:44 +0000):

[...]

> > As you noticed the file is unowned and can be removed and the
> > initramfs regenerated.

> > Nevertheless your fail in MODULES=dep is interesting and didn't have
> > time yet to properly read this corresponding bug.

> Since I had already spent so much time reading into the source, I spent
> another hour yesterday to rewrite hook-functions to my liking. Patch
> attached. It basically replaces the entire sysfs-from-dev divination
> with a walker that uses sysfs' slave links to reach the underlying
> device, collecting modules along the way.

> Please treat this as an FYI, not a push. The exercise is academic
> anyway, since this is not in any way a resource-constrained device. I'm
> not comfortable signing off on this code, because
> a) I simply can't test and have no experience with block devices other
> than lvm, md and plain partitions.
> b) the code assumes a lot about sysfs that I have not been able to
> support with documentation:
> - there appears to be no guarantee about the existence of a block
> device at all (maybe it's driver-dependent?)
> - no guarantee about whether following slaves/ in /block/ will always
> reach an endpoint under /devices/
> - "Never depend on the "device"-link" is mentioned explicitly in the
> document, but there appears to be no other way to reach driver/ from
> /block/ (?). It also explicitly says "Accessing
> /sys/class/net/eth0/device is a bug in the application"
> c) initramfs is not exactly the place where you can afford to be naive
> without consequence

> That said, this code WorksForMe(tm), I've tried very hard not to
> break any old code paths. It can't replace the existing code anyway
> because it relies on udev, which is non-essential. I think
> sys_walk_device might be useful though.

> Oh, and there's several indentation violations to avoid huge
> whitespace-only changes. Like I said, it's not a submission.

So, maximilian (and other kernel devs reading this) - how do we plan
to proceed with this issue?

a) Align/integrate this patch?
b) Further investigate?
c) Mark won't fix?
d) ...?

Please comment.

regards,
-mika-
 

Thread Tools




All times are GMT. The time now is 08:13 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org