Now that I've found ViewSVN for debian-installer, I've managed to work out exactly where it's dying.
In base-installer's postinst, the following stanza
is create_devices(). The mdadm support was added in
revision 16940 on June 18th, so I expect this in itself
was not the problem, by mdadm was. Mind you, I did an
install in mid August which didn't show this problem,
but I had added mdadm to the base packages list in
debootstrap so maybe I just bypassed this one.
Anyway, here's create_devices():
create_devices () {
# RAID
if [ -e /proc/mdstat ] && grep -q ^md /proc/mdstat ; then
apt-install mdadm
fi
# LVM: create VG and LV devices
if pvdisplay | grep -iq "physical volume ---" && grep -q " device-mapper$"
/proc/misc; then
apt-install lvm2
mount -t proc proc /target/proc
mkdir -p /target/dev/mapper
if [ ! -e /target/dev/mapper/control ] ; then
major=$(grep "[0-9] misc$" /proc/devices | sed 's/[ ]\+misc//')
minor=$(grep "[0-9] device-mapper$" /proc/misc | sed 's/[
]\+device-mapper//')
mknod /target/dev/mapper/control c $major $minor
fi
chroot /target vgscan --mknodes || true
umount /target/proc
fi
}
The issues arises when apt-install mdadm installs mdadm,
"mdadm --monitor" is run without debconf asking questions,
as it does if it's installed with apt-get install. In
particular, mdadm/start_daemon is skipped, and defaults to
"true".
Once mdadm is started, neither /proc nor /target/proc can
be unmounted. (I don't know why it affects /target/proc
_and_ /proc... That seems weird to me.)
And then unmount /target/proc fails after lvm2's installed,
and the whole things comes down around my ears.
Now that I've found the process being undertaken for this
menu option, I can either manually simulate it myself, or
try and stop mdadm starting mdadm --monitor...
It looks to me like a change in mdadm caused this, in
particular 1.6.0-1's changelog lists:
* Changed default to autostart RAID array.
(closes: Bug#250792)
(Dated Tue, Jul 20 2004)
which I suspect may have involved changing _both_
defaults to "true". This version migrated into
testing on the 5th of August, so it was almost
certainly already in place when I did my previous
install.
So in short, I'm stumped as to why the first one worked,
and not sure what to do about this... I'm guessing that
putting
mdadm/start_daemon=false
on the kernel command line will work, and will try it
when I reinstall the first machine (which was done w/out
lvm2 due to it segfaulting on the initrd. >_<)
Alternatively, my reading of base-install's postinst
suggests that putting "|| true" after umount /target/proc
would also work w/out any obvious side effects... except:
I should also point out that being unable to umount /target/proc
means that you can't go back up the menu to "partition your disks"
(eg. if you want to blank them out and try again ^_^) since that
menu entry starts by trying to umount /target and its subsidiaries.
Putting "|| true" after "umount /target/proc" in checkdevices()
would not fix that issue.
My ideal preference would be for mdadm --monitor to not run
during the install, irrespective of whether the user wants it
when the system's running. But short of adding 'killall mdadm'
after apt-install mdadm in base-install's postinst, I dunno
how else to do that.
I think I'll try that last solution first, in fact. It gives me
the result I want at the end of the day in the cleanest way
possible.
--
Paul "TBBle" Hampson, [EMAIL PROTECTED]
7th year CompSci/Asian Studies student, ANU
Shorter .sig for a more eco-friendly paperless office.
signature.asc
Description: Digital signature
