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.
> >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.
> >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.
> lr-xr-xr-x 1 root root 4 May 23 00:51 /dev/md0 -> md/0
> lr-xr-xr-x 1 root root 4 May 23 00:51 /dev/md1 -> md/1
>
> Then comes the real devices:
>
> /dev/md:
> total 0
> brw-rw---- 1 root disk 9, 0 Dec 31 1969 0
> brw-rw---- 1 root disk 9, 1 Dec 31 1969 1
> brw-rw---- 1 root disk 9, 10 Dec 31 1969 10
looks good.
> I haven't the foggiest notion of what the mdp[0-9]+ devices are.
"partitionable RAID devices"
> I'm not certain what you mean. initrd.img has the following entry in its
> /script file (last two lines):
>
> ROOT=/dev/md1
> mdadm -A /dev/md/1 -R -u 5842a331:676c7ce4:06417154:50dffb65
oh? that's weird.
> /dev/ide/host0/bus0/target0/lun0/part1
> /dev/scsi/host0/bus0/target0/lun0/part1
>
> and while it has a devfs directory, it's empty,
it's just a mount point. it might not be empty during the initial
boot sequence.
> I'd hate to go back to the error version, but if you really need me to, I
> can reproduce this failure with bootlogd turned on.
well, right now all I know is that it does not work.
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?
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.
> >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?
> 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.
> Physically, it's /dev/hda3 and /dev/sda3 (yes, a SATA and an IDE drive,
> call me crazy). It's my /home directories.
Nothing wrong with that. :)
--
.''`. martin f. krafft <[EMAIL PROTECTED]>
: :' : proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
"it has been said about the EPO that if you fart in front of their
building, you are granted a patent on 'gas tank depressurizing by
opening a venting pipe.'"
-- gyrosgeier on #debian-devel
signature.asc
Description: Digital signature
