Description of Problem: First, fine that putting the /boot and /root partition onto a software RAID partition works, even with ext3 filesystem :) Here is the partitioning of two SCSI disks as declared in ks.cfg: # Partitioning # PLEASE remind: The partitioning has to be done manually! # The automatic partitioning doesn't work really well ;( # # Disk /dev/sd[ab]: 64 heads, 32 sectors, 17547 cylinders # Units = cylinders of 2048 * 512 bytes # # Device Boot Start End Blocks Id System # /dev/sd[ab]1 * 1 65 66544 fd Linux raid autodetect # /dev/sd[ab]2 66 4162 4195328 fd Linux raid autodetect # /dev/sd[ab]3 4163 8259 4195328 fd Linux raid autodetect # /dev/sd[ab]4 8260 17547 9510912 85 Linux extended # /dev/sd[ab]5 8260 8772 525296 82 Linux swap # /dev/sd[ab]6 8773 17547 8985584 fd Linux raid autodetect # part raid.11 --usepart sda1 part raid.12 --usepart sdb1 part raid.21 --usepart sda2 part raid.22 --usepart sdb2 part raid.31 --usepart sda3 part raid.32 --usepart sdb3 part swap --usepart sda5 part swap --usepart sdb5 part raid.61 --usepart sda6 part raid.62 --usepart sdb6 raid / --device md0 --fstype ext2 --level 1 raid.21 raid.22 raid /boot --device md1 --fstype ext2 --level 1 raid.11 raid.12 raid /opt --device md2 --fstype ext2 --level 1 raid.31 raid.32 raid /var --device md3 --fstype ext2 --level 1 raid.61 raid.62 wished result: # df /dev/md0 4128320 412072 3506488 11% / /dev/md1 64324 9699 51304 16% /boot /dev/md2 4128320 20 3918540 1% /opt /dev/md3 8844364 6704 8388388 1% /var here are the results after kickstarting the same configuration three times (other filesystems were removed): 1st) # df Filesystem 1k-blocks Used Available Use% Mounted on /dev/md1 4128320 412072 3506488 11% / /dev/md0 64324 9699 51304 16% /boot /dev/md3 4128320 20 3918540 1% /opt /dev/md2 8844364 6704 8388388 1% /var 2nd) # df Filesystem 1k-blocks Used Available Use% Mounted on /dev/md3 4128320 412072 3506488 11% / /dev/sda1 64324 9699 51304 16% /boot * ? this is not very fine! /dev/md0 4128320 20 3918540 1% /opt /dev/md2 8844364 6704 8388388 1% /var /dev/md1 64324 9699 51304 16% /boot 3rd) # df /dev/md3 4128320 412072 3506488 11% / /dev/md1 64324 9698 51305 16% /boot /dev/md0 4128320 20 3918540 1% /opt /dev/md2 8844364 6704 8388388 1% /var obvisously, the --device option has no influence during the kickstart process, what is the reason that there is no deterministic result in the md order? is there another possibility to get the md order in such a way how declared or could you fix that, please? thanx and take care Andreas
What filesystem corresponds to which RAID device is largely an asthetic issue that the new partitioning infrastructure doesn't let you map. Marking as an RFE for the next release
yes, you're right, but see at the 2nd example: that's definitely a bug!
That's strange... haven't seen it here but will try to run some kickstarts in the background while I work on other things to try to reproduce
And do you happen to still have the second system around -- if so, what does the /etc/fstab and /etc/raidtab look like?
as I ran the 3rd over the 2nd I'm sorry that I can't deliver that information anymore ;(
the bug appeared again yesterday, so I can deliver the necessary information: the part of the kickstart.config file is # Partitioning # PLEASE remind: The partitioning has to be done manually! # The automatic partitioning doesn't work really well ;( # # Disk /dev/sd[ab]: 64 heads, 32 sectors, 17547 cylinders # Units = cylinders of 2048 * 512 bytes # # Device Boot Start End Blocks Id System # /dev/sd[ab]1 * 1 65 66544 fd Linux raid autodetect # /dev/sd[ab]2 66 4162 4195328 fd Linux raid autodetect # /dev/sd[ab]3 4163 8259 4195328 fd Linux raid autodetect # /dev/sd[ab]4 8260 17547 9510912 85 Linux extended # /dev/sd[ab]5 8260 8772 525296 82 Linux swap # /dev/sd[ab]6 8773 17547 8985584 fd Linux raid autodetect # part raid.11 --size 64 --usepart sda1 part raid.12 --size 64 --usepart sdb1 part raid.21 --size 4096 --usepart sda2 part raid.22 --size 4096 --usepart sdb2 part raid.31 --size 4096 --usepart sda3 part raid.32 --size 4096 --usepart sdb3 part swap --size 512 --usepart sda5 part swap --size 512 --usepart sdb5 part raid.61 --size 8774 --usepart sda6 part raid.62 --size 8774 --usepart sdb6 raid / --device md0 --fstype ext2 --level 1 raid.21 raid.22 raid /boot --device md1 --fstype ext2 --level 1 raid.11 raid.12 raid /opt --device md2 --fstype ext2 --level 1 raid.31 raid.32 raid /var --device md3 --fstype ext2 --level 1 raid.61 raid.62 df output: Filesystem 1k-blocks Used Available Use% Mounted on /dev/md0 4128320 419432 3499128 11% / /dev/md1 64324 3245 57758 6% /boot /dev/md3 4128320 20 3918540 1% /opt none 320868 0 320868 0% /dev/shm /dev/md2 8661880 6988 8214888 1% /var /dev/sda1 64324 3245 57758 6% /boot mount says /dev/md0 on / type ext2 (rw) none on /proc type proc (rw) /dev/md1 on /boot type ext2 (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) /dev/md3 on /opt type ext2 (rw) none on /dev/shm type tmpfs (rw) /dev/md2 on /var type ext2 (rw) /dev/sda1 on /boot type ext2 (rw) fstab: LABEL=/ / ext2 defaults 1 1 LABEL=/boot /boot ext2 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 LABEL=/opt /opt ext2 defaults 1 2 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 LABEL=/var /var ext2 defaults 1 2 /dev/sdb5 swap swap defaults 0 0 /dev/sda5 swap swap defaults 0 0 raidtab: raiddev /dev/md0 raid-level 1 nr-raid-disks 2 chunk-size 64k persistent-superblock 1 nr-spare-disks 0 device /dev/sda2 raid-disk 0 device /dev/sdb2 raid-disk 1 raiddev /dev/md1 raid-level 1 nr-raid-disks 2 chunk-size 64k persistent-superblock 1 nr-spare-disks 0 device /dev/sda1 raid-disk 0 device /dev/sdb1 raid-disk 1 raiddev /dev/md3 raid-level 1 nr-raid-disks 2 chunk-size 64k persistent-superblock 1 nr-spare-disks 0 device /dev/sda3 raid-disk 0 device /dev/sdb3 raid-disk 1 raiddev /dev/md2 raid-level 1 nr-raid-disks 2 chunk-size 64k persistent-superblock 1 nr-spare-disks 0 device /dev/sda6 raid-disk 0 device /dev/sdb6 raid-disk 1 could you reassign this bug to the dist 7.2 (Enigma) please? Happend with this version with all erata installed... take care Andreas
Are you booting to single user mode first or something like that or just booting directly into the system?
after kickstart step finishes, I start the machine direct into runlevel 3 as I mentioned it, these symptom is rare, but happens (maybe about 5-10%), mostly the result is acceptable (no extra /boot-mount of a real scsi device)
As for the first issue of not being able to assign filesystems to raid devices I would disagree that this is merely asthetic, since this is behavior that is documented (--device option to the raid command), even in 7.2, and is behavior that many would probably expect since it worked in previous releases. This could become problematic in a large deployment if you run the risk of the machines being built with a nondeterministic partition/raid device structure, and you have scripts for example that may rely on a pre-set structure.
Fixed for kickstart for the next release
Also, if there are partitions that you want to preserve and partitions that you want to replace, leaving the installer choose raid device names however it wishes will cause data loss. It happened to me before, and I can't install skipjack on any of my machines now because, no matter what I do, it won't map the raid devices in such a way that it won't destroy the contents of existing RAID devices. The problem appears to be that it will just order raid device names in decreasing order of size. What if I create a new RAID device for my root partition that is larger than the existing /boot partition?
Are you seeing this problem even when you set the raid device manually?
I don't see how to set the raid devices manually any longer. Was this put back in or is it just hidden somewhere I can't see?
It dropped out in 7.2 and is back in Skipjack with the same syntax as prior to 7.2 (eg, raid / --device md0 raid.03 raid.02)
kickstart only? I'd like to be able to do it with the non-kickstart installer (text and graphical). I now realize this bug report was about kickstart only. I wondered why it hadn't been marked as a duplicate of 53665, but the fact that it was still open gave me some hope of having my problem fixed in 7.3.
Fixed for kickstart only for the next release, maybe more for the one after that (and MODIFIED isn't open as much as waiting for verification)
Deferring complete solution to a future release.
Fixed in internal CVS.
Time tracking values updated