FS#11650 - [cryptsetup] system crashes when creating crypted device
Attached to Project:
Arch Linux
Opened by Arno (ihad) - Friday, 03 October 2008, 17:59 GMT
Last edited by Thomas Bächler (brain0) - Sunday, 07 June 2009, 12:55 GMT
Opened by Arno (ihad) - Friday, 03 October 2008, 17:59 GMT
Last edited by Thomas Bächler (brain0) - Sunday, 07 June 2009, 12:55 GMT
|
Details
Description:
The setup: 2 IDE-Controllers: IDE-Controller1: SIS5513: SiS 962/963 MuTIOL IDE UDMA133 controller SIS5513: IDE controller (0x1039:0x5513 rev 0x00) at PCI slot 0000:00:02.5 SIS5513: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xff00-0xff07 ide1: BM-DMA at 0xff08-0xff0f Probing IDE interface ide0... hda: SAMSUNG SV8004H, ATA DISK drive Switched to high resolution mode on CPU 0 hdb: ST3120023A, ATA DISK drive hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4 hda: UDMA/100 mode selected hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4 hdb: UDMA/100 mode selected Probing IDE interface ide1... hdc: ATAPI DVD+RW 8X4X12, ATAPI CD/DVD-ROM drive hdd: MAXTOR 4K080H4, ATA DISK drive hdc: host max PIO4 wanted PIO255(auto-tune) selected PIO4 hdc: UDMA/33 mode selected hdd: host max PIO4 wanted PIO255(auto-tune) selected PIO4 hdd: UDMA/100 mode selected IDE-Controller2: HPT370A: DPLL base: 48 MHz, f_CNT: 162, assuming 40 MHz PCI HPT370A: using 50 MHz DPLL clock HPT370A: 100% native mode on irq 12 ide2: BM-DMA at 0xc800-0xc807 ide3: BM-DMA at 0xc808-0xc80f Probing IDE interface ide2... hde: ST3120022A, ATA DISK drive hdf: ST3120024A, ATA DISK drive hde: host max PIO4 wanted PIO255(auto-tune) selected PIO4 hde: UDMA/66 mode selected hdf: host max PIO4 wanted PIO255(auto-tune) selected PIO4 hdf: UDMA/66 mode selected Probing IDE interface ide3... hdg: ST380011A, ATA DISK drive hdg: host max PIO4 wanted PIO255(auto-tune) selected PIO4 hdg: host side 80-wire cable detection failed, limiting max speed to UDMA33 hdg: UDMA/33 mode selected ide2 at 0xd800-0xd807,0xd402 on irq 12 ide3 at 0xd000-0xd007,0xcc02 on irq 12 ide_generic: please use "probe_mask=0x3f" module parameter for probing all legacy ISA IDE ports ide_generic: I/O resource 0x1F0-0x1F7 not free. ide_generic: I/O resource 0x170-0x177 not free. hda: max request size: 128KiB hda: 156368016 sectors (80060 MB) w/2048KiB Cache, CHS=65535/16/63 hda: cache flushes supported hda: hda1 hda2 hdb: max request size: 128KiB hdb: 234441648 sectors (120034 MB) w/2048KiB Cache, CHS=65535/16/63 hdb: cache flushes supported hdb: hdb1 hdd: max request size: 128KiB hdd: 156301488 sectors (80026 MB) w/2000KiB Cache, CHS=65535/16/63 hdd: cache flushes supported hdd: hdd1 hdd2 hde: max request size: 512KiB hde: 234441648 sectors (120034 MB) w/2048KiB Cache, CHS=16383/255/63 hde: cache flushes supported hde: hde1 hdf: max request size: 128KiB hdf: 234441648 sectors (120034 MB) w/8192KiB Cache, CHS=65535/16/63 hdf: cache flushes supported hdf: hdf1 hdg: max request size: 512KiB hdg: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=16383/255/63 hdg: cache flushes supported hdg: hdg1 hdg2 2 Softraids: md0: hda2, hdd2, hdg2 md1: hdb1, hde1, hdg1 put in one volume group $ pvcreate /dev/md0 $ pvcreate /dev/md1 $ vgcreate raid /dev/md0 /dev/md1 $ lvcreate -n dunno -L 300G raid When I try to create a crypted device in this volume group, the machine crashes without an oops or a panic. It simply freezes. $ cryptsetup -c aes-cbc-essiv:sha256 luksFormat /dev/mapper/raid-dunno After verifying the password the machine freezes, no oops, panic or anyhting else, just nothing happens. It's reproducable, also happens when trying this with the live/install-cd. BTW, when installing, all drives are SCSI-Drives: md0 = sda2, sdd2, sdf2, md1 = sdb1, sdd1, sde2, but when I boot the installed system, the drives change: md0 = sdc2, sdd2, sdf2 md1 = sda1, sdb1, sde1. I chose hwdetect when creating the initrd. Of course, booting failed because mdassemble was confused. Don't know if this is safe and normal operation. Took me some time to figure this out. After the freeze and reboot md1 was totally screwed. mdassembe said that it didn't have enough drives to build the raid. Kernel: core/kernel26 2.6.26.5-1 cryptsetup: core/cryptsetup 1.0.6-1 Then I installed a vanilla kernel from kernel.org and tried again. This time it worked without a fuss. So I don't think that it's an upstream problem. Working kernel: $ uname -a Linux cimmeria 2.6.26.5 #1 Thu Oct 2 18:42:31 CEST 2008 i686 AMD Athlon(tm) XP 2600+ AuthenticAMD GNU/Linux I won't be able to debug, since that means reinstalling the system every time. But if you need more info, don't hesitate to ask. Additional info: * package version(s) Kernel: core/kernel26 2.6.26.5-1 cryptsetup: core/cryptsetup 1.0.6-1 * config and/or log files etc. none, unfortunately... Steps to reproduce: see above... |
This task depends upon
you could try the older iso from 2008.03 if this works for you, im working on new archboot isos but it will need some time until the archboot rewrite is finished
Anyway, I solved this by compiling a custom kernel and writing my own initrd. Works like a charm.
But the main problem remains: the described setup crashes the raids for good when trying to create a crypted device and the ARCH supplied kernel. As I said, it works with my home brewed one. I can supply my config, if you need it.
Thx.
Anyway, I solved this by compiling a custom kernel and writing my own initrd. Works like a charm.
But the main problem remains: the described setup crashes the raids for good when trying to create a crypted device and the ARCH supplied kernel. As I said, it works with my home brewed one. I can supply my config, if you need it.
Thx.
I also wrote a custom initrd for my kernel. While doing that I realized that you don't really need mdassemble and the command line options. When RAID-support is compiled into the kernel and all raid partitions have partition type 0xFD (LINUX RAID AUTODETECT), the kernel assembles them for you. No need to bother userspace with assembling the array(s). This way you wouldn't have to bother the user with figuring out which device/partition belongs to which raid array. What if the device order changes, because a new HD is added to the system, or a new kernel version sorts the drives differently, i.e. hda becomes hdb, or the user decides to use SCSI-emulation for his IDE-drives (unlikely, I know)? The system won't boot, because the kernel command line is wrong. Hence my question: why not let the kernel do the work? But I'm no kernel expert, so maybe there is a perfectly valid reason to use mdassemble. This part was only meant as a suggestion how to simplify the boot sequence.
I hope that clarifies things. That said, the fact remains that I could reliably crash my system by trying to create a crypted device as described above. Maybe it works with the current kernel (kernel26 2.6.27-1). I haven't tried, and, sorry to say that, I don't have any intention to do so (I need the data on that RAID :)). I just thought it was worth mentioning here, as it was a reproducible bug, and it didn't occur with vanilla sources.
I don't mind if you close this bug. I've found a setup that "works for me".