Bug#317285: marked as done (initrd-tools: mkinitrd infinite recursion f RAID component device file missing)
Your message dated Thu, 7 Jul 2005 16:15:06 +0200
with message-id <20050707141506.GD1394@sputnik.stro.at>
and subject line Bug#317285: initrd-tools: mkinitrd infinite recursion f RAID component device file missing
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 7 Jul 2005 13:08:06 +0000
>From ken@vanguard.xorian.net Thu Jul 07 06:08:06 2005
Return-path: <ken@vanguard.xorian.net>
Received: from vanguard.xorian.net [63.114.52.26]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1DqW6o-0004dg-00; Thu, 07 Jul 2005 06:08:06 -0700
Received: by vanguard.xorian.net (Postfix, from userid 1000)
id 2E59C1659; Thu, 7 Jul 2005 09:07:35 -0400 (EDT)
From: Ken Schalk <ken@vanguard.xorian.net>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: initrd-tools: mkinitrd infinite recursion f RAID component device file missing
X-Debbugs-CC: Ken Schalk <ken@xorian.net>
Message-Id: <[🔎] 20050707130735.2E59C1659@vanguard.xorian.net>
Date: Thu, 7 Jul 2005 09:07:35 -0400 (EDT)
Delivered-To: submit@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-11.0 required=4.0 tests=BAYES_00,HAS_PACKAGE,
X_DEBBUGS_CC autolearn=ham version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
Package: initrd-tools
Version: 0.1.81.1
Severity: normal
In trying to perform a new sarge install onto a multi-disk RAID array,
I ran into a problem which caused the install to hang when installing
the kernel package. Investigation revealed that the
/usr/sbin/mkinitrd script was falling into infinite recursion and
eventually failing.
The core cause of this was that my RAID array involved a partition on
the 9th IDE device position (hdi). The block devices for hdi were not
present in the /dev of the installation target. This apparently
caused "mdadm -D" (which is invoked in the function getraid_mdadm) to
output lines for some partitions without a device file. Something
like this (not the real output):
Number Major Minor RaidDevice State
0 3 1 0 active sync /dev/hda1
1 22 1 1 active sync
The awk script in the getraid_mdadm function assumes that the final
field of these lines will always be a device file. In my case (where
the device file was missing), it added the word "sync" to the devices
variable. This caused the getroot function to be invoked with "sync"
as its argument. Because getroot was given a single argument which
was not a block device, this code got executed:
# Assume label or UUID.
eval "$(
awk 'NR > 2 { printf "getroot -s %d %d\n", $1, $2 }' \
/proc/partitions
)"
This generated multiple calls to getroot, one of which had major
number 9, so it called getraid_mdadm again. Thus, it recursed
infinitely. During this, the shell process ran out of file
descriptors, but continued for some time after that. It eventually
failed, but took more than an hour to do so.
I avoided this problem for my installation purposes by moving my disk
from hdi to hda. This made the device node for the partition present
in the filesystem (which included hda-hdh but not hdi), which made the
output of "mdadm -D" include a device file, which avoided the "getroot
sync" call, and allowed mkinitrd to complete.
--Ken Schalk <ken at xorian dot net>
P.S. There's a separate problem here in that the installation
filesystem was missing /dev/hdi* when I was clearly using it, but I'm
not sure which package to file that bug against. Could someone point
me in the right direction?
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-k7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages initrd-tools depends on:
ii coreutils [fileutils] 5.2.1-2 The GNU core utilities
ii cpio 2.5-1.2 GNU cpio -- a program to manage ar
ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F
ii dash 0.5.2-5 The Debian Almquist Shell
ii util-linux 2.12p-4 Miscellaneous system utilities
-- no debconf information
---------------------------------------
Received: (at 317285-done) by bugs.debian.org; 7 Jul 2005 14:15:05 +0000
>From max@stro.at Thu Jul 07 07:15:05 2005
Return-path: <max@stro.at>
Received: from baikonur.stro.at [213.239.196.228]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1DqX9c-0005hv-00; Thu, 07 Jul 2005 07:15:05 -0700
Received: from sputnik (stallburg.stro.at [128.131.216.190])
by baikonur.stro.at (Postfix) with ESMTP id 7BC8F5C011
for <317285-done@bugs.debian.org>; Thu, 7 Jul 2005 16:14:55 +0200 (CEST)
Received: from max by sputnik with local (Exim 4.50)
id 1DqX9e-0005mD-9q
for 317285-done@bugs.debian.org; Thu, 07 Jul 2005 16:15:06 +0200
Date: Thu, 7 Jul 2005 16:15:06 +0200
From: maximilian attems <debian@sternwelten.at>
To: 317285-done@bugs.debian.org
Subject: Re: Bug#317285: initrd-tools: mkinitrd infinite recursion f RAID component device file missing
Message-ID: <20050707141506.GD1394@sputnik.stro.at>
References: <[🔎] 20050707130735.2E59C1659@vanguard.xorian.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[🔎] 20050707130735.2E59C1659@vanguard.xorian.net>
User-Agent: Mutt/1.5.9i
X-Virus-Scanned: by Amavis (ClamAV) at stro.at
Delivered-To: 317285-done@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
On Thu, 07 Jul 2005, Ken Schalk wrote:
> In trying to perform a new sarge install onto a multi-disk RAID array,
> I ran into a problem which caused the install to hang when installing
> the kernel package. Investigation revealed that the
> /usr/sbin/mkinitrd script was falling into infinite recursion and
> eventually failing.
>
> The core cause of this was that my RAID array involved a partition on
> the 9th IDE device position (hdi). The block devices for hdi were not
> present in the /dev of the installation target. This apparently
> caused "mdadm -D" (which is invoked in the function getraid_mdadm) to
> output lines for some partitions without a device file. Something
> like this (not the real output):
>
> Number Major Minor RaidDevice State
> 0 3 1 0 active sync /dev/hda1
> 1 22 1 1 active sync
>
> The awk script in the getraid_mdadm function assumes that the final
> field of these lines will always be a device file. In my case (where
> the device file was missing), it added the word "sync" to the devices
> variable. This caused the getroot function to be invoked with "sync"
> as its argument. Because getroot was given a single argument which
> was not a block device, this code got executed:
>
> # Assume label or UUID.
> eval "$(
> awk 'NR > 2 { printf "getroot -s %d %d\n", $1, $2 }' \
> /proc/partitions
> )"
>
> This generated multiple calls to getroot, one of which had major
> number 9, so it called getraid_mdadm again. Thus, it recursed
> infinitely. During this, the shell process ran out of file
> descriptors, but continued for some time after that. It eventually
> failed, but took more than an hour to do so.
>
> I avoided this problem for my installation purposes by moving my disk
> from hdi to hda. This made the device node for the partition present
> in the filesystem (which included hda-hdh but not hdi), which made the
> output of "mdadm -D" include a device file, which avoided the "getroot
> sync" call, and allowed mkinitrd to complete.
indeed that's a possible workaround.
well i assume that you are using a static /dev tree.
in that case makedev handles which devices show up in /dev.
as one can't populate every debian system with all possible devices,
the maintainer maid a trade-off to cut after 8 discs,
which should not be noticable for the vast majority.
> --Ken Schalk <ken at xorian dot net>
>
> P.S. There's a separate problem here in that the installation
> filesystem was missing /dev/hdi* when I was clearly using it, but I'm
> not sure which package to file that bug against. Could someone point
> me in the right direction?
sure,
read the man of MAKEDEV(8) it tells you how to create those needed nodes.
i'm closing this bug as initrd can't possibly work
for non existing device nodes.
--
maks
Reply to: