[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#380049: debian-installer/etch bug report



On Friday 28 July 2006 19:06, Ryan Rawson wrote:
> no, the md doesn't exist at all.  Only physical disks, using paths in
> /dev/discs.  What I did is to use alt-f2 before I hit that portion of
> the rescue and tried to start the md array, which then failed with the
> "device or resource busy" error.

Seems to me that your RAID setup is either to some extend broken or at 
least does not conform to what current code in Debian expects.

> Looks like rescue isn't really designed to rescue a root part on a md

Then please explain the function of the code below that I've taken from 
the postinst of the rescue-mode udeb.

<snip>
# RAID support
try_load_module md
try_load_module raid0
try_load_module raid1
try_load_module raid5
log-output -t rescue mdrun || true

# LVM support
try_load_module dm-mod
try_load_module lvm-mod
log-output -t rescue pvscan || true
log-output -t rescue vgscan || true
</snip>

(We are currently switching from using mdrun to using mdadm as mdrun is 
being deprecated.)

> device - it doesn't seem to be trying to start the md device.  I had
> to modprobe raid1 and mdrun by hand, but I still ended up with the
> busy error.

The installer's rescue mode _does_ support RAID and also LVM over RAID. I 
have used it in my own installation tests.

You mentioned in your initial mail that your system also has a second 
controller (hdf/hdg) that is not relevant. However, it may be relevant if 
the order in which the drivers for the controllers changes. Check console 
messages or dmesg to see in what order modules are being loaded.
See the first item in the errata for the Etch Beta 2 release of the 
installer for further info [1].

[1] http://www.debian.org/devel/debian-installer/errata

Attachment: pgpqZ6Pkk1b_F.pgp
Description: PGP signature


Reply to: