Re: partman chokes on partitionable md arrays
[Sorry for taking so long to respond, your reply had landed in my spam
bucket. CC'ed to the mdadm maintainer, who might be interested.]
Looks like you're trying to do something that is just not supported. In
general the installer does not support direct partitioning of a software
raid device.
Oh, it's possible ... like this: (This is from memory, the installer
options may be named differently)
1. "detect harddisks"
2. "partition disks"
3. immediately exit "partition disks" again
(otherwise the RAID will build very slowly)
4. switch to console and create your array using mdadm
5. "partition disks" again
It will complain about not being able to find /dev/md/_d0. Do not cancel but
6. symlink /dev/md/_d0 to /dev/md_d0
(if you symlink before you get the error it won't work, possibly
the error will infinite-loop,
and partman's state will be corrupted)
7. hit "retry"
you should now have the partman overview with /dev/md_d0 and
/dev/md/_d0. As you can
see, partman works absolutely fine if you can work around its
brain-dead "device
classification by parsing the dev node name". Whoever thought
that's a good idea, please
speak up. What's wrong with detection over sysfs?
8. partition /dev/md_d0
9. carry on with installation
10. right before the end chroot to the installed system.
11. if you use sata install a working kernel image
2.6.15-2.6.17 and possibly earlier ones have horribly broken sata
error-reporting support.
If a disk fails, md will not be able to detect the failiure - any
access to the affected array
will just hang the process. I've been bitten by this using an
ICH7-R in AHCI mode and
sata-uli, other drivers may or may not be fine. There's a
libata-tj-stable patch for 2.6.17.4
that has worked well for me.
12. follow the steps outlined here to get the box to boot:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377801
What's wrong with using LVM on RAID?
Nothing except that
- I don't need to resize the partitions
- I don't need an added layer for reasons of complexity
- I don't need an added layer for reasons of performance
- I can't stick one member of a mirror in a random other Linux box and
get at the data
If you can give us very good reasons (your "various reasons" won't really
convince anybody, you'll have to be much more specific) why such a
partitioning scheme should be supported _and_ you can can point to
documentation that says your naming scheme is generally accepted, I guess
you could file a wishlist bug report against partman-md.
Now that's an excellent attitude. I'd rather file a whishlist bug
against the BTS for a "maintainer" pseudo-package, really :)
However, I very much doubt it would get supported anytime soon unless you
provide patches yourself. Probably not only for partman, but also for
bootloader installers, initrd generators and various other utilities...
The only reason it doesn't work out of the box is because the
installer is, from a user perspective, extremely unflexible. Being
able to add modules easily is great and all ...
partman makes assumptions about devices based solely on the name of
the device node, thus unnecessarily restrictiong it to "known" types
of block devices. That's got nothing to do with supported or not -
that's a bug. I shouldn't wonder if that breaks lots of other
use-cases. As I said, traversing /sys/block would be a better way.
C.
Reply to: