Summary: | LUKS volumes not detected properly | ||
---|---|---|---|
Product: | hal | Reporter: | Malte Starostik <m-starostik> |
Component: | hald | Assignee: | David Zeuthen (not reading bugmail) <zeuthen> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Malte Starostik
2009-05-06 02:02:16 UTC
As my main concern is with the external HDD, I found a kludge to make it work: <device> <match key="info.udi" string="/org/freedesktop/Hal/devices/storage_serial_XXXXXXXXXXXXX"> <merge key="volume.fstype" type="string">crypto_LUKS</merge> </match> </device> This workaround seems to confirm my guess about the fakevolumes getting into the way. I'm tempted to add a check for that case to the code, but I found no indication of what exactly fakevolumes do and why they're created for basically all of my volumes: /dev/md0 has an fstab entry (ext3 on /boot) but is not mounted. A fakevolume is created and neither file system type nor mount point are recognized by hal. /dev/md1 is a non-LUKS encrypted swap partition. This is the only device without a fakevolume, yet the corresponding plaintext device /dev/mapper/swap missing (don't know if swap is supposed to be listed). /dev/md2 is a LUKS encrypted LVM volume. I know these aren't handled, yet there is a fakevolume /dev/sdc and /dev/sdd are whole-disk LUKS volumes containing ext3 file systems. Again, fakevolumes exist, no further info about the corresponding device mapper mappings, file systems or mount points is provided by hal |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.