At 13:08 2005-05-23, martin f krafft wrote:
also sprach Moshe Yudkowsky <[EMAIL PROTECTED]> [2005.05.23.1956 +0200]:
> >Are you running udev on /dev?
>
> No, I haven't made the transition yet. I'm still running devfs.
Oh dear.
Yes, well, I can't find a coherent explanation of how to make the transition...
> >What was the last version of mdadm you had installed that worked?
>
> That'd be whatever the previous release was under unstable.
You can check the versions by saving /var/lib/dpkg/status to
somewhere, fetching the last one from /var/backup and putting it
into place, running dpkg -l to get the version info, and then
restoring the original /var/lib/dpkg/status file.
Ok. The old packages were:
ii initrd-tools 0.1.79 tools to create initrd image for prepackaged
ii mdadm 1.9.0-2.1 Manage MD devices aka Linux Software Raid
The new packages are:
ii initrd-tools 0.1.80 tools to create initrd image for prepackaged
ii mdadm 1.9.0-2.3 Manage MD devices aka Linux Software Raid
> >You mention initrd-tools -- is your root fs on RAID? If so,
> >which device is it? Did you also upgrade initrd-tools and mdadm
> >at the same time?
>
> My root fs is on RAID, /dev/md/1. I noticed last night when I did
> the update that I'd picked up initrd-tools, mdadm, and a new
> kernel all at once -- again, up from the previous versions of
> unstable.
Mh, then it could be literally anything, though I think it's most
likely related to the initrd problems.
Yes, it could be any of those, but since changing the mdadm.conf file
elminated the problem, and I had that /dev/md3 to /dev/md/3 issue, I
guessed the problem is probably in mdadm.
However, it seems to apply to three of your partitions, /dev/md1 is
the root partition, /dev/md3 is a different one. Am I correct in
assuming that /dev/md1 was correctly configured and mounted, or did
you get a kernel panic saying that the root device could not be
mounted? How far did you get in the boot process? Did it start INIT?
/dev/md1 mounted, read only. As far as I can tell, so did /dev/md2 (swap).
Then when it was time for /dev/md3 to mount, reiserfsck failed to find the
superblock and the boot stopped and waited for me to intervence. Linux
would continue to boot if I control-D to ignore the problem, but of course
without my /home directories.
I *think* that counts as "not able to boot." Please forgive me for starting
a panic if I'm not right.
I am trying to reproduce the problem right now, so if I fail,
I would have to ask you to go back to the broken version.
I should be able to do that.
> >Does initrd fail to start the device? Or does it fail to start
> >afterwards?
>
> I really can't tell. The device didn't start, and the reason I did
> what I did to fix the problem is because I suspected that the md
> device didn't start.
Which devices failed?
Just /dev/md3 didn't start. /dev/md1 and /dev/md2 did; combine that with
the reiserfsck boot block report, and I was about ready to panic.
> The reason I suspected it is because if mdadm.conf has /dev/md3 as the
> device in its ARRAY statement, and I use the notation "mdadm --assemble
> /dev/md/3", then mdadm wouldn't start. It couldn't translate between the
> two. Since /script in initrd.img had this notation, I thought that if I
> moved everything to /dev/md/n style notation, I'd be able to boot -- and I
> could.
This *could* be related to Steve's patch. I'll check it out.
Let me know if you need any further information.
--
Moshe Yudkowsky
Disaggregate
2952 W Fargo
Chicago, IL 60645 USA
www.Disaggregate.com
[EMAIL PROTECTED]
+1 773 764 8727
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
