Alvin Oga wrote: > ... >>I know - that is why i was very disappointed to find that it wasn't >>supported even in the latest Sarge snapshot (i honestly expected it to >>be supported in Woody as well). > > > yup ... people's ( developer's ) preferences and requirements are > different or "just plain it'd be fun to do this wy instead of that way" Any idea where i can sign up to drive this issue? This list obviously isn't the right place. > ... >>I know. I tried to do this, but Debian's mkinitrd is not giving me the >>joy the Red Hat one did (see below). > > initrd is for the fun of things and a pat-pat on the shoulders when it > works ( time vs other stuff to do issue ) I don't understand what you're trying to say. > ... >>Again, why? My preferred setup for a workstation is *everything* in /. > > that's an age old preferences or time or ??? issue ... > - it will become an issue at 3:00am when you;re sleeping and > get called in to fix the disks cause it crashed because a user > created the wrong kinda of files or filenames It's my *workstation*. The only one calling will be me. Only 3 of the 18 machines i support have normal users on them, and all of those either have a separate partition for user files or quotas. Anyway, i'm not here to debate the merits of my partitioning scheme - as you say, that is a personal preference issue. I just want to get Debian installed where every partition is mirrored - that is not a preference issue, it is a reliability issue. > ... >>and has saved me from machines crashing when hard drives go >>bad (especially the ones that don't even know they're going bad ;-). > > > if you dint know the drives went bad... thats a bad thing??? If a drive is silently corrupting data, it's definitely bad. I've had 3 drives do this on me in the past (2 of the 3 were Samsung drives :-). The only way i detected it was the fact that random files were showing up in the tripwire reports, and it was changing every night. > ... >>-- Snip -- >>4. Install latest Sarge snapshot to standard ATA drive. Set up RAID >>devices (md0 = 1 Gb /boot, md1 = 4 Gb swap, md2 = 195 Gb /), rsync ATA >>partition to SATA partitions, chroot to target partitions and run LILO. > ... >>This last method seems to be on the verge of working, but when i boot >>from the /boot partition, it can't mount md2 on /. > > usually means a partition problem ( should be "FD" ) or > fix lilo or grub ... and do NOT use initrd you didnt create unless > you know it works for booting on 1/2 or 1/4 of the working raid disk I managed to get a partially working system by changing MODULES=dep and ROOT=/dev/md2 in /etc/mkinitrd/mkinitrd.conf. However, it only starts the RAID device on /dev/md2, not /dev/md0 or /dev/md1, even though all the partitions are type 0xFD and the RAID sets are working correctly. >> I can boot from the >>SATA /boot and use the ATA /. It seems the md devices aren't started, >>and i can't work out how to include them in the initrd. I did some hacking on mkinitrd to include the right mdadm commands to start md0 and md1, but it still doesn't work, because at the time when the initrd/script runs, not all the device files exist. Is this a feature of Debian's initrd setup, or the 2.6 kernel? (All of my Red Hat boxes are 2.4, so i'm not familiar with the way it is done on 2.6.) The way that mkinitrd is setting up the RAID devices seems really poor to me anyway, since it hard-codes the array names and UUIDS. The autodetection that is present in the kernel would seem to be a far better approach to me. > to look at the initrd .. > mount -o loop initrd.gz /mnt/initrd ( fix for the exact syntax ) > ls -la /mnt/initrd > fix what you want > recompress it and replace the original one You can't do that on the latest installer, because it uses a cramfs (mounts read-only), not a compressed ext2. >> On RH, you >>could just specify preload modules on the mkinitrd command line, but >>that doesn't seem to be the case here. I added raid1 and md to >>/etc/mkinitrd/modules, but that doesn't help. Any suggestions? > > > i say mkinitrd and its variations is all broken in most versions i played > with > - and better yet, its not needed if the kernel is built right > ( raid built into the kernel and not a module ) Do you think building a custom kernel with RAID built in will cause it to autodetect all of my 0xFD partitions? -- Paul <http://paulgear.webhop.net> -- Did you know? Email addresses can be forged easily. This message is signed with GNU Privacy Guard <http://www.gnupg.org> and Enigmail <http://enigmail.mozdev.org> so you can be sure it comes from me.
Attachment:
signature.asc
Description: OpenPGP digital signature