Re: Root-on-raid install ?
Tim Day wrote: I just tried to use a software raid device as '/', but soon after selecting the partitioner's "Finish partitioning and write changes to disk" a dialog says: "Debian does not currently support using software raid for the root filesystem or /boot partition. A system installed in this way will not boot". Does that simply mean that the debian installer doesn't support setting it up, or is it telling me something more fundamental (ie lots of other debian stuff won't support it either) ? Any plans for this to change ? Would I fare any better throwing LVM or EVMS into the mix too ? (I'm using the 20040704 sarge netinst, BTW). Debian's mkinitrd supports root on RAID1, LVM, or LVM-on-RAID1. The debian installer, however, doesn't know how to install with root & boot on anything but a 'plain' partition. There are several ways around this (search the archives for a message from me describing how to install to root-on-LVM-on-RAID for details on one such method). I've recently decided to move root off the LVM, and am now running root and boot as seperate RAID1 devices, with everything else (usr, var, tmp, home, and swap) on LVM+RAID5. You can 'trick' the debian installer to install directly onto a RAID, or (what I did), just do a plain install (root and boot on plain partitions), then migrate to a RAID1 mirror after the system is installed. You'll probably also want to dig up my patches to add RAID1 support to grub-install and update-grub (posted to debian-boot a week or two ago) if you're running grub (and don't want to manually update menu.lst whenever you add/remove kernels). -- Charles Steinkuehler [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#257168: Promise TX4 SATA controller not detected automatically
Package: discover1-data Version: 1.2004.02.08-7 (June 21, 2004 sarge d_i netinst daily build) The debian installer did not automatically dectect my Promise TX4 SATA controller, although the card is supported by the libata drivers in both the 2.4 and 2.6 kernels for testing. Manually modprobing the sata_promise module prior to partitioning gets the card supported and the attached drives recognized. lspci details follow: naibed:~# lspci :00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) (rev a2) :00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev a2) :00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev a2) :00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev a2) :00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev a2) :00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev a2) :00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a3) :00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2) :00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3) :00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3) :00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3) :00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet Controller (rev a1) :00:05.0 Multimedia audio controller: nVidia Corporation nForce MultiMedia audio [Via VT82C686B] (rev a2) :00:06.0 Multimedia audio controller: nVidia Corporation nForce2 AC97 Audio Controler (MCP) (rev a1) :00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3) :00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2) :00:0c.0 PCI bridge: nVidia Corporation nForce2 PCI Bridge (rev a3) :00:0d.0 FireWire (IEEE 1394): nVidia Corporation nForce2 FireWire (IEEE 1394) Controller (rev a3) :00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev a2) :01:07.0 Unknown mass storage controller: Promise Technology, Inc. PDC20318 (SATA150 TX4) (rev 02) :02:01.0 Ethernet controller: 3Com Corporation 3C920B-EMB Integrated Fast Ethernet Controller [Tornado] (rev 40) :03:00.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4 Ti 4200 AGP 8x] (rev a1) naibed:~# lspci -n :00:00.0 Class 0600: 10de:01e0 (rev a2) :00:00.1 Class 0500: 10de:01eb (rev a2) :00:00.2 Class 0500: 10de:01ee (rev a2) :00:00.3 Class 0500: 10de:01ed (rev a2) :00:00.4 Class 0500: 10de:01ec (rev a2) :00:00.5 Class 0500: 10de:01ef (rev a2) :00:01.0 Class 0601: 10de:0060 (rev a3) :00:01.1 Class 0c05: 10de:0064 (rev a2) :00:02.0 Class 0c03: 10de:0067 (rev a3) :00:02.1 Class 0c03: 10de:0067 (rev a3) :00:02.2 Class 0c03: 10de:0068 (rev a3) :00:04.0 Class 0200: 10de:0066 (rev a1) :00:05.0 Class 0401: 10de:006b (rev a2) :00:06.0 Class 0401: 10de:006a (rev a1) :00:08.0 Class 0604: 10de:006c (rev a3) :00:09.0 Class 0101: 10de:0065 (rev a2) :00:0c.0 Class 0604: 10de:006d (rev a3) :00:0d.0 Class 0c00: 10de:006e (rev a3) :00:1e.0 Class 0604: 10de:01e8 (rev a2) :01:07.0 Class 0180: 105a:3318 (rev 02) :02:01.0 Class 0200: 10b7:9201 (rev 40) :03:00.0 Class 0300: 10de:0281 (rev a1) -- Charles Steinkuehler [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with Sil SATA
Harald Dunkel wrote: Harald Dunkel wrote: I don't even get that far. After manually loading sata_sil (using expert26) the Partition Disks menu still does not show any disks. I had plugged the SATA cable into the wrong socket, so the disk became /dev/sdb instead of /dev/sda. But nevertheless /dev/sdb should be shown in the Partition Disks menu, even if there is no /dev/sda. What modules do you have loaded? When I tried using the 6/21 daily build to install to a machine with a Promise TX4 SATA card (only supported by libata), the disks were not automatically detected. To get d_i to see the partitions, I had to modprobe the SATA driver prior to entering the partition disks menu choice. It might also work if you manually install both the SATA driver and the required SCSI modules (ie: modprobe at least sata_sil *AND* sd_mod for SCSI disk support). Can someone tell me if libata hardware is supposed to be auto-supported by d_i (ie: should I file a bug report if it doesn't detect supported hardware)? -- Charles Steinkuehler [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with Sil SATA
Harald Dunkel wrote: Charles Steinkuehler wrote: [EMAIL PROTECTED] wrote: HeIlo I have Asus A7N8X-E motherboard with sil SATA and only disk IBM 80GB SATA. I haven´t instaled debian yet. Debian instalating program can´t detedt my disk. where can I get module for my SATA or how can I use newer kernel for instalation or what can I do? Thanks. The daily builds have seen my on-board Silicon Image 3112 (I've got an A7N8X-Delux), but you might still run into problems. Depending on your drives, there may be problems with the siimage driver (Seagate drives are apparently the ones to avoid). I think all the problems have been worked out, but you'd need the latest patches from the lkml or linux-ide list. With the most recent posted just a few days ago, you'll probably have to build your own kernel: I don't even get that far. After manually loading sata_sil (using expert26) the Partition Disks menu still does not show any disks. lspci says: :01:07.0 RAID bus controller: Silicon Image, Inc. (formerly CMD Technology Inc) Silicon Image Serial ATARaid Controller [ CMD/Sil 3512 ] (rev 01) :01:07:0 Class 0104: 1095:3512 (rev 01) And /proc/scsi/sata_sil/0 says, that there is no support for /proc yet. Am I missing another module? I've been using the siimage driver for my 3112 based controllers (and had some problems), I'm not sure if they work better with the 3512 or not. If you're using the sata_sil module, you'll also need libata and scsi_mod (which should get loaded automatically if you modprobe sata_sil), but you won't see any partitions (or be able to access the disks at all) until you also load sd_mod. Remember, libata makes new sata drives look like scsi disks, so they'll show up as /dev/sdX, not /dev/hdX. -- Charles Steinkuehler [EMAIL PROTECTED]
Re: problems with Sil SATA
[EMAIL PROTECTED] wrote: HeIlo I have Asus A7N8X-E motherboard with sil SATA and only disk IBM 80GB SATA. I haven´t instaled debian yet. Debian instalating program can´t detedt my disk. where can I get module for my SATA or how can I use newer kernel for instalation or what can I do? Thanks. The daily builds have seen my on-board Silicon Image 3112 (I've got an A7N8X-Delux), but you might still run into problems. Depending on your drives, there may be problems with the siimage driver (Seagate drives are apparently the ones to avoid). I think all the problems have been worked out, but you'd need the latest patches from the lkml or linux-ide list. With the most recent posted just a few days ago, you'll probably have to build your own kernel: http://marc.theaimsgroup.com/?l=linux-ide&m=108793699914304&w=2 You may also find your particular combination of drives/controller revision work OK as-is. With the Debian kernel from recent debian daily builds (5/26 and 6/21) and new Seagate SATA drives (ST3160023AS Firmware Rev: 3.18), my on-board (revision 1) 3112 controller works OK, but using an add-in card with a revision 2 chip causes lots of data corruption. -- Charles Steinkuehler [EMAIL PROTECTED]
Re: Bug#251905: Problems/workarounds for install to root on LVM on RAID
Martin Michlmayr wrote:
* tbm <[EMAIL PROTECTED]> [2004-05-31 13:37]:
1) partman won't let you build an LVM on top of a RAID device
Still there. This needs changed to libparted - maybe you can look at
this.
I haven't looked at this. If it doesn't involve lots of coding, I may
be able to take a stab at it.
3) Grub install fails when /boot is on a RAID1 device
Still there.
Attached are two patches to address this (one for grub-install, and one
for update-grub). Patches are against the version I have installed,
which according to the changelog is 0.94+cvs20040511-1
update-grub:
This one is pretty easy. The convert routine (which fails when passed
an md device) is only called to get a default grub root device to use if
one is not provided in the menu.lst file. It's not really necessary to
have anything provided by this routine (in fact, if device.map doesn't
exist, the default behavior is simply set the default to (hd0,0)).
I just created a convert_default 'wrapper', which calls convert() and
returns the result or (hd0,0) if anything goes wrong (ie: convert exits
with non-zero status).
grub-install:
-
This is a bit more complicated, as we actually have to figure out what
device(s) to install grub on. My solution was to add a test for an md
device prior to any of the other processing in the convert() procedure.
If we're trying to convert /dev/md*, the new procedure getraid_mdadm()
is called to identify a BIOS device we can then pass to the rest of the
convert() code.
The getraid_mdadm procedure is pretty much lifted from the Debian
mkinitrd scripts (at least the part that converts an md device into a
list of physical drives). I modified the routine to return a single
device, and to return the highest priority BIOS device that's also part
of the RAID array. If no RAID members are BIOS devices (according to
the device.map file), the first device listed by mdadm is returned.
NOTES:
--
- I have not implemented support for raidtools extraction of the RAID
device info (ie: mdadm is required), although the code is in the
mkinitrd script. If needed, this is left as an exercise for the reader :)
- I did not modify grub-install to install itself on the MBR of *ALL*
devices in the array (which I usually do manually, in case the 'primary'
HDD is the one that dies). This may or may not be desired behavior, but
it seems somewhat unsafe to simply assume this behavior is wanted. You
can do this manually by:
grub-install '(hd0)'
grub-install '(hd1)'
...
- I have not yet tested these mods on a 'bare-metal' install, but my
system still boots after running 'grub-install' and 'update-grub' with
the included mods. I need to do another re-install, so hopefully I'll
be able to report on the success (or failure) of these patches on a
ground-up install.
--
Charles Steinkuehler
[EMAIL PROTECTED]
--- grub-install.was2004-06-21 14:36:27.0 -0500
+++ grub-install2004-06-21 14:34:05.0 -0500
@@ -80,6 +80,50 @@
EOF
}
+# Usage: getraid_mdadm mddevice
+# Routine to find a physical device from an md device
+# If found, the first grub BIOS device (from device.map) is returned
+# If no BIOS drives match the RAID devices, the first device returned
+# from mdadm -D is returned
+getraid_mdadm() {
+ device=$1
+ mdadm=$(mdadm -D "$device") || {
+ echo "$PROG: mdadm -D $device failed" >&2
+ exit 1
+ }
+ eval "$(
+ echo "$mdadm" | awk '
+ $1 == "Number" && $2 == "Major" { start = 1; next }
+ $1 == "UUID" { print "uuid=" $3; start = 0; next }
+ !start { next }
+ $2 == 0 && $3 == 0 { next }
+ { devices = devices "\n" $NF }
+ END { print "devices='\''" devices "'\''" }
+ '
+ )"
+
+ # Convert RAID devices list into a list of disks
+ tmp_disks=`echo "$devices" | sed -e 's%\([sh]d[a-z]\)[0-9]*$%\1%' \
+-e 's%\(d[0-9]*\)p[0-9]*$%\1%' \
+-e 's%\(fd[0-9]*\)$%\1%' \
+-e 's%/part[0-9]*$%/disc%' \
+-e 's%\(c[0-7]d[0-9]*\).*$%\1%' \
+-e '/^$/d' |
+sed -n '1h;2,$H;${g;s/\n/|/g;p}'`
+
+ # Find first BIOS disk that's a member of the RAID array
+ # Default to first RAID member if no tmp_disks are BIOS device
Bug#255541: software raid1 installation fails
Udo Rader wrote: Package: debian-installer Version: tc1 During installation I was successfully able to set up a kernel 2.6 based software raid1 array with XFS on it, but after the reboot the array is not accessible: -CUT- $ mount /usr XFS: SB read failed mount: /dev/md0: can't read superblock -CUT- Mounting one of the individual physical devices instead works and they even contain the expected /usr file & directory structure, so the base installation process itself was probably successful. My first thought was that it might be /usr related and made a completely fresh install, this time using /storage as the mount point for the array. But that would not work either. /etc/fstab looks ok, but I notice a missing /etc/raidtab (if that is still neccessary for 2.6 kernels). happy hacking The default install doesn't seem to create entries in /etc/mdadm/mdadm.conf to start the RAID arrays configured durring install, and the startup-scripts don't seem to start all RAID arrays by default. The only RAID arrays started automatically after a fresh install seem to be the array holding root (if you have root on RAID), as this is started by the initrd scripts. Creating an appropriate mdadm.conf file for your system should fix the problem. -- Charles Steinkuehler [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RAID1 on / planned?
Andrew Pollock wrote: On Sun, Jun 13, 2004 at 02:49:26PM +0100, Martin Michlmayr wrote: * Charles Steinkuehler <[EMAIL PROTECTED]> [2004-06-11 14:45]: > I'm pretty handy with shell scripting, and could probably come up with a > fix to the grub stuff (espeically with the nice auto-detect stuff in > mkinitrd already working!), if that would be of assistance. It would be good if you could find out why LILO and GRUB fail in the first place instead of being able to cope with the situation. Then we can figure out whether we need to put in a workaround or whether LILO/GRUB should just get fixed. I'll look into it more closely after exams (if it isn't sorted by then) but I think in the case of GRUB (from what I've read wrt the hacks to get it to work) it's because /dev/md/0 doesn't correspond to a BIOS device. This is my read on the problem, as well. I believe what needs to happen is: - grub-install needs to recognize a RAID device when installing, and install itself (ie setup ) onto the device(s) making up the RAID, rather than trying to find /dev/md? as a BIOS device. - update-grub needs to generally ignore the fact that / or /boot is installed on a RAID1 device (or correctly deal with it, if really necessary), and simply update the appropriate files in /boot and /boot/grub (which should already be mounted...no knowledge about how / or /boot or /boot/grub exist on BIOS devices should be required). I'm back from a trip to the PCI-Sig DevCon and will try to work on this in the next couple of days. -- Charles Steinkuehler [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RAID1 on / planned?
Martin Michlmayr wrote: * W. Borgert <[EMAIL PROTECTED]> [2004-06-11 15:00]: - Is RAID1 on / planned to be supported? IMHO, it doesn't make much sense to have RAID1 support, but not on /. OK, you may save the / or /boot from time to time manually on the second disk, but that's not convenient... I intend to work on this after rc1 has been released. There is one problem with mkinitrd which will be easy to fix; apparently, there are problems with the boot loader too. I don't know details, though. I haven't seen problems with mkinitrd and RAID1 on the x86 arch, at least circa the end-of-May daily builds (just with mkinitrd defaulting to LVM1 instead of LVM2 when running root-on-LVM-on-RAID). I've switched my testing system to /boot and / on seperate RAID1 partitions (I installed with root on LVM on RAID), and now the only issues I have are with grub. Both update-grub and grub-install fail when they can't find /dev/md? as a BIOS device. This seems to me to be a problem with the scripts trying to be either too smart for their own good, or not quite smart enough (note the debian-stable grub-update script works fine with RAID1, but you have to install grub by hand). You can 'trick' update-grub by manually adding /dev/md0 to the device.map file in /boot/grub, but that seems like a very dirty hack, probably with several unintended (and likely nasty) consequenses farther down the line. I'm pretty handy with shell scripting, and could probably come up with a fix to the grub stuff (espeically with the nice auto-detect stuff in mkinitrd already working!), if that would be of assistance. -- Charles Steinkuehler [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RAID1 install fails
Andrew Pollock wrote: On Sun, May 30, 2004 at 11:06:16PM +, W. Borgert wrote: On Sun, May 30, 2004 at 06:35:41PM -0300, Martin Michlmayr wrote: > * W. Borgert <[EMAIL PROTECTED]> [2004-05-30 18:40]: > > /usr/sbin/mkinitrd: RAID support requires raidtools2 > > Failed to create initrd image. > > root on RAID is currently not supported, due to the bug you just saw. > With newer d-i images, you should get a warning of root is RAID or > LVM. Does somebody have the bug number or at least the name of the package the bug is filed against? Because I'm keen to do a complete RAID1 install, I would like to test again as soon as the bug is closed. TIA! Well the problem is with mkinitrd from initrd-tools. And it used to work. Is initrd-tools being maintained by the new kernel team also, in Herbert's absence? If this is the same problem I ran into when installing to root on LVM on RAID, mkinitrd's only problem is that it's missing the mdadm program. Simply adding mdadm to the list of packages to install as part of base should fix the problem. See my post on installing to root on LVM on RAID for details: http://lists.debian.org/debian-boot/2004/05/msg03665.html If just installing to a RAID device, you don't have to work around the mkinitrd behavior of defaulting to LVM1 when both LVM1 and LVM2 are present, so simply installing mdadm prior to the kernel should allow mkinitrd to complete successfully, meaning you can install to root on a RAID device. -- Charles Steinkuehler [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems/workarounds for install to root on LVM on RAID
OK, I tried this again from 'bare metal', and verified the overall procedure works, but there are a couple of additional issues and corrections (inline). Using the 20040526 netinst image, there seem to be no problems with the initial ramdisk image created (it starts both the md device and lvm, allowing root to be mounted) as has been reported with earlier versions. The only initrd problem seems to be it's desire to default to LVM1 instead of LVM2 if both are detected... Charles Steinkuehler wrote: I'm trying to install testing onto an x86 box with root on LVM on RAID1, and I ran into several issues with the latest daily image: http://cdimage.debian.org/pub/cdimage-testing/sarge_d-i/i386/20040526/sarge-i386-netinst.iso First, the problems: 1) partman won't let you build an LVM on top of a RAID device 2) Kernel install portion of base install fails due to mkinitrd failure 2a) LVM tools missing 2b) Raidtools (actually mdadm) missing 2c) LVM entries in /dev missing on target 2d) initrd defaults to LVM1 instead of LVM2 3) Grub install fails when /boot is on a RAID1 device 4) md devices (other than the one holding root) are not started at boot Workarounds: 1) partman won't let you build an LVM on top of a RAID device This is the easiest to fix...just switch over to the console and manually run pvcreate, etc. to build the LVM VG(s) & LV(s). Once created, the logical volums are properly recognized by partman, allowing them to be formatted, mount points to be set, etc. NOTE: You have to run at least pvcreate and vgcreate manually, ie: pvcreate /dev/md/1 vgcreate -A n VolGroup /dev/md/1 You can then use partman to create logical volumes. 2) Kernel install portion of base install fails due to mkinitrd failure 2a) LVM tools missing 2b) Raidtools (actually mdadm) missing Prior to installing the base system, switch to a console and edit /usr/lib/debootstrap/scripts/sarge, adding the following modules to the base="..." line near the top of the file: LVM Packages: binutils libdevmapper1.00 lvm-common lvm2 RAID Packages: mdadm 2c) LVM entries in /dev missing Switch to a console and copy the entries from the install system to the target system: cp -aR /dev/ /target/dev/ cp -aR /dev/mapper/* /target/dev/mapper/ 2d) initrd defaults to LVM1 instead of LVM2 This is a nasty one, and oddly confusing. If both LVM2 and LVM1 are present (as determined by the existance of appropriate kernel modules), LVM1 is selected. This seems odd, since LVM2 can talk to LVM1 formatted volumes, but not the other way around. Anyway, to fix this I did the following: - Add initrd (plus dash and cramfsprogs dependencies) to base= line in sarge script (see 2a & 2b, above) prior to installing base system Should be initrd-tools instead of initrd! - chroot to target system - Prior to installing kernel, edit /etc/mkinitrd/mkinitrd.conf and set root=/dev/hda1 (a dummy entry that allows mkinitrd to complete successfully, letting the install continue) - Install kernel 2.4.26-1-386 - Move (or delete) /lib/modules/2.4.16-1-386/kernel/drivers/md/lvm-mod.o so mkinitrd won't find it and default to LVM1 - mount -t proc proc /proc - verify /etc/mkinitrd/mkinitrd.conf now lists root=probe (kernel install apparently causes config mods to be lost) - run mkinitrd to replace currently broken root=/dev/hda1 image: mkinitrd -o /boot/initrd.img-2.4.26-1-386 2.4.26-1-386 - umount /proc 3) Grub install fails when /boot is on a RAID1 device Apparently, grub is trying to get 'smarter' about devices, but in the process is breaking functionality that used to work. With /boot installed on a raid1 device (md0), grub-install and update-grub both fail dismally, reporting that /dev/md0 doesn't exist as a BIOS device (like that's a news flash!). The stupid hack to get this to work is: - Install grub from the debian installer menu (it will fail) - Switch to a console and edit /boot/grub/device.map, replacing the (hd0) /dev/??? entry with (hd0) /dev/md0 - Re-run install grub from the debian installer menu (it will still fail, but get farther this time) - Run update-grub from a console to create /boot/grub/menu.lst - run grub and install grub to both HDD's: root (hd0,0) setup (hd0) setup (hd1) - Continue w/o boot loader from the debian installer menu (you manually installed grub) It's worth noting that grub from stable has no problems with /boot on a raid device (once installed). I can see grub-install perhaps failing with /boot on a md device, but why in the world does update-grub even care where boot is?!? All it needs to do is edit menu.lst... NOTE: Your device numbers might be different. Also, it's typically OK to install grub with root set to (hd0,0) on both hd0 and hd1, since if hd0 fails, hd1 will usually become hd0 with most BIOS's. NOTE:
Re: Problems/workarounds for install to root on LVM on RAID
Martin Michlmayr wrote: * Josha Foust <[EMAIL PROTECTED]> [2004-05-27 12:33]: I didn't think that a new mkinitrd would be in testing for a few more days. Even when it does, there's still a bug with LVM on root; see 249641: initrd-tools: does not activate volume groups (LVM2). A patch was posted May 20 that's reported to fix this problem, and I didn't have any issues with LVM (LVM2) not being started by the initrd scripts (May 26 netinst iso). -- Charles Steinkuehler [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems/workarounds for install to root on LVM on RAID
Charles Steinkuehler wrote: Josha Foust wrote: The raid device also shows it only being 2.0 GB in size when the partition underneath it is 79GB. If you're referring to the display in partman, I saw similar behavior, which I attributed to a 'wrapping' problem. My 150G raid partition was listed as some small number of MB on one line, and the correct size on another. I'll note details when I re-install. OK, in partman, once I've built the RAID devices, I get the following output: RAID1 device #0 - 131.4 MB Software RAID device #1 131.4 MB RAID1 device #1 - 993.7 MB Software RAID device #1 159.9 GB In case it matters, details of the big partition: Cylinders 17-19457 Each cyl = 8,225,280 bytes Total size: 159,907,668,480 bytes or 156,159,832+ blocks Note that 159.9 GB MOD 2^32 ~= 993,878,527 Looks like maybe some sort of translation problem (32 bit byte size value?) with large partitions? -- Charles Steinkuehler [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems/workarounds for install to root on LVM on RAID
Josha Foust wrote: A rather serious problem I encountered when running LVM on RAID is that as of a few days ago, RAID wasn't automatically activated on startup. This caused LVM to find its partitions inside the RAID partition and mount one of those. This is obviously a horrible thing to do as it breaks your RAID mirroring and thus you end up with a corrupt RAID device when you do bring it up. Although if you know what you are doing and what happened you could probably recover from it. The lvm lists say you need to put an exclusion in the device section lvm config for the underlying partitions or drives that make up the raid device. There is suppose to be a patch floating around on the lvm list to automatically skip partitions that have a partition type of raid autodetect as the default behavior. This seems to be working with the May 26th image, although I'll verify once I get a working system again (I'm currently wiping the disks so I can start from scratch and verify everything works from 'bare metal'). Are you sure you got the latest mkinitrd, and coerced it into not running LVM1? I think some of the LVM and mkinitrd stuff changed right around the 24th/25th time frame (based on trolling lvm d-i bugs). The raid device also shows it only being 2.0 GB in size when the partition underneath it is 79GB. If you're referring to the display in partman, I saw similar behavior, which I attributed to a 'wrapping' problem. My 150G raid partition was listed as some small number of MB on one line, and the correct size on another. I'll note details when I re-install. This was all on the 20040524 build. I used the May 25 & May 26 builds...not sure what (if anything) changed from the 24th. -- Charles Steinkuehler [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problems/workarounds for install to root on LVM on RAID
I'm trying to install testing onto an x86 box with root on LVM on RAID1, and I ran into several issues with the latest daily image: http://cdimage.debian.org/pub/cdimage-testing/sarge_d-i/i386/20040526/sarge-i386-netinst.iso First, the problems: 1) partman won't let you build an LVM on top of a RAID device 2) Kernel install portion of base install fails due to mkinitrd failure 2a) LVM tools missing 2b) Raidtools (actually mdadm) missing 2c) LVM entries in /dev missing on target 2d) initrd defaults to LVM1 instead of LVM2 3) Grub install fails when /boot is on a RAID1 device Workarounds: 1) partman won't let you build an LVM on top of a RAID device This is the easiest to fix...just switch over to the console and manually run pvcreate, etc. to build the LVM VG(s) & LV(s). Once created, the logical volums are properly recognized by partman, allowing them to be formatted, mount points to be set, etc. 2) Kernel install portion of base install fails due to mkinitrd failure 2a) LVM tools missing 2b) Raidtools (actually mdadm) missing Prior to installing the base system, switch to a console and edit /usr/lib/debootstrap/scripts/sarge, adding the following modules to the base="..." line near the top of the file: LVM Packages: binutils libdevmapper1.00 lvm-common lvm2 RAID Packages: mdadm 2c) LVM entries in /dev missing Switch to a console and copy the entries from the install system to the target system: cp -aR /dev/ /target/dev/ cp -aR /dev/mapper/* /target/dev/mapper/ 2d) initrd defaults to LVM1 instead of LVM2 This is a nasty one, and oddly confusing. If both LVM2 and LVM1 are present (as determined by the existance of appropriate kernel modules), LVM1 is selected. This seems odd, since LVM2 can talk to LVM1 formatted volumes, but not the other way around. Anyway, to fix this I did the following: - Add initrd (plus dash and cramfsprogs dependencies) to base= line in sarge script (see 2a & 2b, above) prior to installing base system - chroot to target system - Prior to installing kernel, edit /etc/mkinitrd/mkinitrd.conf and set root=/dev/hda1 (a dummy entry that allows mkinitrd to complete successfully, letting the install continue) - Install kernel 2.4.26-1-386 - Move (or delete) /lib/modules/2.4.16-1-386/kernel/drivers/md/lvm-mod.o so mkinitrd won't find it and default to LVM1 - mount -t proc proc /proc - verify /etc/mkinitrd/mkinitrd.conf now lists root=probe (kernel install apparently causes config mods to be lost) - run mkinitrd to replace currently broken root=/dev/hda1 image: mkinitrd -o /boot/initrd.img-2.4.26-1-386 2.4.26-1-386 - umount /proc 3) Grub install fails when /boot is on a RAID1 device Apparently, grub is trying to get 'smarter' about devices, but in the process is breaking functionality that used to work. With /boot installed on a raid1 device (md0), grub-install and update-grub both fail dismally, reporting that /dev/md0 doesn't exist as a BIOS device (like that's a news flash!). The stupid hack to get this to work is: - Install grub from the debian installer menu (it will fail) - Switch to a console and edit /boot/grub/device.map, replacing the (hd0) /dev/??? entry with (hd0) /dev/md0 - Re-run install grub from the debian installer menu (it will still fail, but get farther this time) - Run update-grub from a console to create /boot/grub/menu.lst - run grub and install grub to both HDD's: root (hd0,0) setup (hd0) setup (hd1) - Continue w/o boot loader from the debian installer menu (you manually installed grub) It's worth noting that grub from stable has no problems with /boot on a raid device (once installed). I can see grub-install perhaps failing with /boot on a md device, but why in the world does update-grub even care where boot is?!? All it needs to do is edit menu.lst... NOTE: Your device numbers might be different. Also, it's typically OK to install grub with root set to (hd0,0) on both hd0 and hd1, since if hd0 fails, hd1 will usually become hd0 with most BIOS's. Reboot and cross your fingers I can provide additional information, if needed or desired. -- Charles Steinkuehler [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Root-on-LVM-on-RAID with debian mkinitrd HOWTO
ev and /etc need to be read-write, but the default debian mkinitrd is cramfs (read-only). To get around this, writable partitions are mounted on top of the existing cramfs directories. The /etc directory can be empty (it will be populated with lvmtab and lvmtab.d by vgscan), but the /dev directory needs at least the lvm and null devices (possibly others). I initially mount a tmpfs filesystem on dev2 and copy the existing devices to avoid hard-coding any device knowledge in the script. This way, you can simply add any special devices required for your system to /etc/mkinitrd/files and they'll automatically be avaialble when the script above runs. Once the dev2 filesystem is popluated, it's remounted on top of /dev with mount --bind. Finally, root is mounted using the root= portion of the kernel command line for the device (should be /dev//), and any supplied kernel command line parameters for mount flags or filesystem. If you want to give yourself a chance to look around (and maybe fix anything broken) before just blindly trying to boot, uncomment the 'sh' command in the script above. When booting, the script will drop to a shell after (hopefully) mounting root. As long as you exit the shell with root properly mounted in /mnt, the system should boot normally. -- Additional important notes -- - Obviously, you need to setup your boot loader to support initial ramdisks. If you're lucky, there will be an update-* command for your bootloader that will automatically create/remove boot entries when you add/remove a kernel. My /etc/kernel-img.conf contains: do_symlinks = No do_initrd = Yes do_bootloader = No postinst_hook = /sbin/update-grub postrm_hook = /sbin/update-grub - You'll need an appropriate setting for root in the kernel command line provided by your boot-loader. My /boot/grub/menu.lst file contains the following setting (inside the debian AUTOMAGIC KERNELS LIST markers): # kopt=ro root=/dev/SystemCore/root console=ttyS0,38400n8 - My system has 2 raid devices, md0 (/boot) and md1 (the big RAID with logical volumes). Tweak the root= device in mkinitrd.conf to reflect the RAID device your root filesystem is on. - I had to add the following to prevent LVM from spitting out a bunch of (harmless) warnings at boot when the LVM code looks for logical volumes on *ALL* available block devices. This is likely specific to x86 arch, and of course you should leave this device properly enabled if you actually *HAVE* a BIOS RAID. I'm mentioning it here to hopefully save you a heart-attack, or at least a google search :-) : # Disable IDE BIOS RAID devices to prevent (harmless) LVM errors alias block-major-114 off Please CC: me directly on any comments or requests for more info or clarification, as I'm currently only subsribed to these lists through archive searches (which have been very helpful!). :) -- Charles Steinkuehler [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
