Hi everyone,

I've just did a fresh Slackware 13.1 install on a 32-bit box for friends of mine. It's an older machine with an AMD Athlon XP 2500. Generally everything works just fine, with one exception, however.

Connecting a LUKS encrypted USB harddisk is notified by KDE. Clicking on the device icon in Dolphin opens the dialog asking for the LUKS passphrase. No error message appears, but the file system is not opened and mounted, anyway.
However, before another attempt I have to "remove" the device in Dolphin.
Output of dmesg:

On the other hand, on the CLI everything works just find. I connect the USB device, look at the output of dmesg to find out the device name assigned to the USB device, and use cryptsetup to decrypt the filesystem on the device:

This works, but there is no icon for the decrypted filesystem in Dolphin.

The USB device can be decrypted in KDE on my other computers, a relatively young desktop running Slackware64-13.1 and an old laptop (Pentium III 650 MHz) running Slackware-13.1.

As my friends are not "computer-literate" I want to make things as easy as possible for them. Therefore it would be essential, that the decrypting works in Dolphin, too.

Does anyone have an idea, what could be wrong?

Thanks a lot in advance!

gargamel

The move to udev-enabled LVM2 broke this, and I don't know how to fix it. There's a patch from one of the RH guys that I added to the last hal rebuild in the -current tree, but the problem still isn't fixed. It seems to be some sort of race somewhere, because it work sometimes, especially with some devices -- for example, my MMC card with a LUKS container works great *every* time, while a usb thumb drive almost never works (it's worked *once* during the time I was trying to debug all this). Basically, HAL development is dead, so troubleshooting from that side isn't going to happen. Feel free to open a bug with the KDE folks, but I doubt that will go anywhere either since 4.6 is targeting udisks from all of the device management.

Thanks for the reply. In my environment, it doesn't seem to be dependant on the USB device, but on the machine. The problem persists on one machine for ALL USB devices, but on two others everything works just fine --- no problem with THE VERY SAME USB devices, there.

As KDE 4.6 should arrive early next year, I think, I can wait for that, hoping it is solved by then.

Thanks again!

gargamel

Reading your post again, I have one question for understanding. How can it be, that this affects KDE / Dolphin, but not the CLI?

My understanding up to now was, that udev and LVM2 and HAL were used by the system indepently of the environment (Fluxbox, KDE, CLI, Xfce, ...), and that the difference between the environments only was, how they "pick up" the signals from the systems and process them with or without explicit user interaction to add more comfort or allow more control.

gargamel

There are temporary devices created during the LUKS/LVM 'bring-up' process, and hal isn't (always) ignoring them as it's supposed to do, and this (is|seems to be) confusing the desktop environments. That's what the one of the hal patches in the last rebuild was supposed to address, but it doesn't seem to be complete.

Thanks!
It's still weird, that it happens ALWAYS on one of three machines (AMD Athlon XP 2500), here, but NEVER on two others not on my quite up-to-date desktop/server (Intel Core 2 Duo) and not on my very old laptop (Intel Pentium III 650 MHz).

Hmmm. The machine, where I have this problem has a Tekram DC 395 SCSI controller and a Yamaha CD-RW SCSI drive fitted. No SCSI on the other machines. And all other components (mainboard, CPU, etc.) were used in another machine with (E)IDE only setup with no problem. Would you think, that the SCSI devices cause a race condition somehow?
I am asking, because apart from the age of the components, this is the only obvious major difference between the affected machine and the other two...

I guess, I'll remove the SCSI devices and give it another try, as soon as I have time. I'll report back!

gargamel

Ok, just removed all SCSI devices from the computer and tried again --- no change, unfortunately.

gargamel

Another (last) attempt: I removed the PCI USB board, that adds four USB 2.0 ports to this old machine, which has only one USB 2.0 port by default. I was hoping, to avoid any possible conflicts between the onboard and the PCI controller.

The machine is now fitted with two (E)IDE harddisks running as a Linux software RAID-1 array on IDE controller 2 and a DVD-RW/DVD-RAM drive on IDE controller 1. Plus, there's an MSI AGP graphics adapter. That's all.

It still doesn't work. So it seems not to be caused by the plugged hardware.

As it happens reproducably on this machine with ALL USB devices I tried, and not on other machines, I still think, it could be hardware related. Might there be a problem with older VIA chipsets?

My mainboard is an MSI 6712 aka KT4A-V.


gargamel

Just notices one thing, not sure if it is related:

With everything equipped again (SCSI devices, USB controller board with four external ports) and one external USB device connected at boot time, LILO hangs for several seconds. Output is:

This is right before an overview screen of the hardware appears, followed by the Slackware start screen (with the large Slackware logo), but after the BIOS and SCSI device scans. After a few seconds, the boot process continues. But: My USB keyboard isn't working on the Slackware boot screen, so I have to wait 2 minutes...

With no external USB harddisk connected, the system boots smoothly.

I am really looking forward to seeing the new kernel and KDE versions, soon, hoping, that the new architecture without HAL dependencies really solves this. Still, I don't understand, how this is dependant of the respective machine...

gargamel

One more step that may or may not help to track this down: I fitted a PCI card with two USB ports to one of the two machines where everything worked just fine, so far. This machine has had a few USB 2.0 and 1.1 ports offered by the mainboard and a PCI card with four additional USB ports. Decrypting LUKS encrypted USB volumes worked on all of them (as far as I have tested, but I didn't try the two USB ports for mouse and keyboard). However, when I connect a USB harddisk with an encrypted partition to any of the two new USB ports, I can reproduce exactly the problem described above.

So it seems, it depends on the USB port, if it works or not...

The two PCI cards are from different vendors. Maybe the hardware or firmware of the USB board causes the problem... ?

gargamel

I don't know enough to debug it, to be honest, but the "sometimes works" aspect of it makes me think there's a race condition somewhere.

This might be it. But as I said: Here it is not "sometimes works", but "somewhere (on some machines and particular USB ports) it works, somewhere else (other machines, other ports) it doesn't."

Meanwhile I tried this: Fitted the same model of four-port USB PCI board to both machines. Works on one machine, not on the other, independent of the USB drive I connect. So it's probably NOT the USB board.

Race condition: Quite likely, I'd say.

gargamel

I've just upgraded my main machine to Slackware64-13.37. My first tests seem to indicate, that the problem might be gone. Before I mark the thread as solved I would like to make a few more tests with different computers, though. But at least one scenario, i. e. a particular combination of device and USB port, where the problem used to occur almost always, seems to work now. I'll make a few more tests and then come back to report the results in the next few weeks.

gargamel