Bug 627364 - After the update to udev I am no longer able to mount my encrypted home directory created using liveUSB tools
Summary: After the update to udev I am no longer able to mount my encrypted home direc...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 13
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-25 20:13 UTC by dalbers
Modified: 2010-10-30 23:40 UTC (History)
6 users (show)

Fixed In Version: dracut-005-5.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-10-27 22:55:30 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description dalbers 2010-08-25 20:13:29 UTC
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.126 Safari/533.4

I run a liveUSB Fedora 13 install that has an encrypted home directory that uses a luks encrypted img.   In this environment there is a livesys init script that mounts the home directory as shown below:

-------------------------
mountPersistentHome() {
  # support label/uuid
  if [ "${homedev##LABEL=}" != "${homedev}" -o "${homedev##UUID=}" != "${homedev}" ]; then
    homedev=`/sbin/blkid -o device -t "$homedev"`
  fi

  # if we're given a file rather than a blockdev, loopback it
  if [ "${homedev##mtd}" != "${homedev}" ]; then
    # mtd devs don't have a block device but get magic-mounted with -t jffs2
    mountopts="-t jffs2"
  elif [ ! -b "$homedev" ]; then
    loopdev=`losetup -f`
    if [ "${homedev##/mnt/live}" != "${homedev}" ]; then
      action "Remounting live store r/w" mount -o remount,rw /mnt/live
    fi
    losetup $loopdev $homedev
    homedev=$loopdev
  fi

  # if it's encrypted, we need to unlock it
  if [ "$(/sbin/blkid -s TYPE -o value $homedev 2>/dev/null)" = "crypto_LUKS" ]; then
    echo
    echo "Setting up encrypted /home device"
    plymouth ask-for-password --command="cryptsetup luksOpen $homedev EncHome"
    homedev=/dev/mapper/EncHome
  fi

  # and finally do the mount
  mount $mountopts $homedev /home
  # if we have /home under what's passed for persistent home, then
  # we should make that the real /home.  useful for mtd device on olpc
  if [ -d /home/home ]; then mount --bind /home/home /home ; fi
  [ -x /sbin/restorecon ] && /sbin/restorecon /home
  if [ -d /home/darren ]; then USERADDARGS="-M" ; fi
}

findPersistentHome() {
  for arg in `cat /proc/cmdline` ; do
    if [ "${arg##persistenthome=}" != "${arg}" ]; then
      homedev=${arg##persistenthome=}
      return
    fi
  done
}

if strstr "`cat /proc/cmdline`" persistenthome= ; then
  findPersistentHome
elif [ -e /mnt/live/${livedir}/home.img ]; then
  homedev=/mnt/live/${livedir}/home.img
fi

# if we have a persistent /home, then we want to go ahead and mount it
if ! strstr "`cat /proc/cmdline`" nopersistenthome && [ -n "$homedev" ] ; then
  action "Mounting persistent /home" mountPersistentHome
fi
-------------------

I see no errors in /var/log/messages but I will do more testing tomorrow to see if I can get more details.

Reproducible: Always

Steps to Reproduce:
1.Load a usb liveUSB with Encrypted Home Directory
2.Update to the latest version of udev.   
3. Profit!  err don't mount home directory
Actual Results:  
Home .img is not loaded


None

Comment 1 Darwin Slattery 2010-08-26 09:14:27 UTC
I'm also having trouble with encrypted partitions since updating to version 153-3 of udev and libudev on Fedora 13.

Reproducible: Always

Steps to Reproduce:
1. Attach a USB drive with unencrypted and luks-encrypted partitions
2. Click on each partition in the KDE file manager to mount it, entering required password for encrypted partitions

Expected Results:
The unencrypted partitions are mounted, /dev/mapper/ devices are created for each decrypted partition, and those partitions then become available for mounting in the file manager.

Actual Results:
The unencrypted partitions are mounted, /dev/mapper/ devices are created for each decrypted partition, but only some of those become available for mounting.

Additional notes:
All of the decrypted partition devices in /dev/mapper/ can be mounted through the command-line.

It is not always the same partitions nor the same number of partitions that do not become available.

This problem disappeared after downgrading to version 151-9 of udev and libudev. 

I don't have much more info at the moment but will keep testing.

---
Fedora 13, 2.6.33.6-147.2.4.fc13.i686.PAE

Comment 2 Josh Bressers 2010-08-26 15:06:02 UTC
The issue here seem to be that /dev/live doesn't exist, which means /mnt/live never gets mounted.

I'm not exactly sure why just yet.

Comment 3 Harald Hoyer 2010-08-30 09:33:23 UTC
(In reply to comment #2)
> The issue here seem to be that /dev/live doesn't exist, which means /mnt/live
> never gets mounted.
> 
> I'm not exactly sure why just yet.

Because start_udev does not delete the udev database, udev knows about the /dev/live symlink. Because /proc/self/mountinfo does not contain information about the mounted live medium, /lib/udev/cdrom_id tries to open the cdrom with O_EXCL, which then returns EBUSY. So, no medium info can be gathered and no by-label symlinks are present.

The fix would be an updated dracut, which adds a symlink rule for /dev/live and mounts the live image in /dev/.initramfs (all fixes in the F14 dracut version, try it).

Comment 4 dalbers 2010-08-30 17:04:19 UTC
Harold,

Excuse my ignorance with how things like this work in Fedora but is there a way to request the fix being pushed to dracut?   Just another bug assigned to the Dracut package?

Thank you!

Comment 5 Harald Hoyer 2010-08-31 08:52:32 UTC
(In reply to comment #4)
> Harold,
> 
> Excuse my ignorance with how things like this work in Fedora but is there a way
> to request the fix being pushed to dracut?   Just another bug assigned to the
> Dracut package?
> 
> Thank you!

I'll push an update, being the dracut author/maintainer myself :)

Comment 6 dalbers 2010-08-31 13:30:58 UTC
Excellent, thank you!   Should I just mark this as closed when the update comes out?

Comment 7 Scott Dowdle 2010-08-31 20:45:42 UTC
Would this bug also cause an .iso image built with livecd-creator to fail?

I make a remix of Fedora 13 i686 and x86_64 and a recent build with updates applied builds just fine but when I try to boot from the iso image I get the following error:

- - - -

No root device found

Boot has failed, sleeping forever.

- - - -

I get the same error from both the i686 and the x86_64 builds.

Comment 8 Fedora Update System 2010-09-23 15:32:10 UTC
dracut-005-4.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/dracut-005-4.fc13

Comment 9 Fedora Update System 2010-09-23 15:33:31 UTC
dracut-005-4.fc12 has been submitted as an update for Fedora 12.
https://admin.fedoraproject.org/updates/dracut-005-4.fc12

Comment 10 Fedora Update System 2010-09-24 20:39:14 UTC
dracut-005-4.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update dracut'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/dracut-005-4.fc12

Comment 11 dalbers 2010-09-25 19:11:08 UTC
The update did not seem to work for me.  Are there any tests I can perform that will help?

Comment 12 Fedora Update System 2010-10-27 22:54:07 UTC
dracut-005-5.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 13 Fedora Update System 2010-10-30 23:38:43 UTC
dracut-005-5.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.