Bug 236447 - No support for encrypted partitions build in kernel or boot
No support for encrypted partitions build in kernel or boot
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
bzcl34nup
:
Depends On:
Blocks: FC7Target
  Show dependency treegraph
 
Reported: 2007-04-14 07:06 EDT by Mark van Rossum
Modified: 2014-03-16 23:06 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 21:29:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
katzj: fedora_requires_release_note+


Attachments (Terms of Use)

  None (edit)
Description Mark van Rossum 2007-04-14 07:06:53 EDT
From Bugzilla Helper:
User-Agent: Opera/9.20 (X11; Linux i686; U; en)

Description of problem:
I have a setup with an encrypted partition for /home.
Encryption was setup using crypt-setup and maps under /dev/mapper/encrypt.

In FC6, the boot process would simply ask the pw after the UDEV initialization.

In FC7test3, there is a complaint that fcsk2 does not find an ext2 partition on 
/dev/mapper/encrypt and goes to the root prompt for manual disk check.

THis could be serious, if people have not kept the old kernel they might not be 
able to access their data anymore  

Version-Release number of selected component (if applicable):
 Fedora (2.6.20-1.3062.fc7)

How reproducible:
Always


Steps to Reproduce:
1. BOot fc7 kernel on a system with encrypted partition


Actual Results:
Booting falls into the manual disk check root prompt.

Expected Results:
It should have mounted the encrypted partition after asking for the encryption 
password, and then performed a disk check,

Additional info:
Reverting back to any fc6 kernel fixes it.
Comment 1 Christophe Saout 2007-04-23 15:11:05 EDT
Does it work if you call cryptsetup by hand on the emergency console (and can
you mount the filesystem after that) -  if not, how does cryptsetup fail?
Comment 2 Dave Jones 2007-04-23 15:32:23 EDT
(Adding cryptsetup-luks maintainer to cc).
Comment 3 Mark van Rossum 2007-04-23 16:52:24 EDT
I can call cryptsetup under the emergy console, and decrypt,
but I need to replace hda6 with sda6.
(cryptsetup luksOpen /dev/sda6 encrypt)

Apparently under fc7, hda becomes sda, somewhere during the boot.
Although my boot disk is still hda3.
Comment 4 Christophe Saout 2007-04-23 16:58:05 EDT
Huh?

Is the fc7 kernel using the new unified ata driver for pata+sata instead of the
old ide driver? I don't think it's possible to move from hd* to sd* in the
middle of the boot process. Or how did you conclude that hda3 is still your boot
disk?
Comment 5 Dave Jones 2007-04-23 17:03:16 EDT
ahhh, this is another casualty of the libata conversion.
I guess some configuration file for your crypto stuff is still referencing hda6.

I'm not sure if the userspace tools can handle filesystem labels, or uuid's yet.
Peter?
Comment 6 Mark van Rossum 2007-04-23 17:14:55 EDT
Well, it does look like it changes from hda to sda,
as in the emergy console, 
mount returns
/dev/hda3 /
but fdisk /dev/hda fails, while /dev/sda is ok.

I forgot how it setup the encryption...
Comment 7 Peter Jones 2007-04-23 17:15:56 EDT
I think this is coming from hal as HAL_PROP_BLOCK_DEVICE when it calls
tools/linux/hal-luks-setup-linux .
Comment 8 David Zeuthen 2007-04-23 18:52:45 EDT
(In reply to comment #7)
> I think this is coming from hal as HAL_PROP_BLOCK_DEVICE when it calls
> tools/linux/hal-luks-setup-linux .

Uh, HAL is only a mechanism; that script runs _only_ if someone calls
org.freedesktop.Hal.Device.Volume.Crypto.Setup() on HAL. And
HAL_PROP_BLOCK_DEVICE isn't read from a configuration or something. Anyway I
doubt anything but gnome-mount etc. calls this method etc. etc.

Reassigning to initscripts; that's probably the right place for this bug.
Comment 9 Bill Nottingham 2007-04-24 17:42:00 EDT
For the non-luks case, is there any sort of metadata on the block device that
can be read/verified?
Comment 10 Bill Nottingham 2007-04-24 18:07:25 EDT
To recap everything, to the best of my knowledge:

- For non-luks devices, there doesn't appear to be a way to determine that a
block device is part of a dm-crypt mapping
- For any machine with multiple devices being used by cryptsetup, there's no way
to associate which new device with which new entry (it's entirely possible that
hda + hdc will change to sdc + sdb)
- You couldn't actually do any automatic conversion until you booted a new
kernel, which rules out any script which runs as part of a package upgrade
- At the point where the crypto is done in rc.sysinit, nothing is read-write, so
you can't do the conversion there.

So, we're pretty much screwed all the way around.

In retrospect, /etc/crtypttab is a pretty bad format - before any changes like
this, it would handle things like multiple USB drives very badly, as those are
likely to change device names often.
Comment 11 Mark van Rossum 2007-04-24 18:33:54 EDT
Would a manual update option be to run mkinitrd
with an edited fstab file and fstab option?
Comment 12 Bill Nottingham 2007-04-24 22:20:23 EDT
No, you need to change the device name in /etc/crypttab to the new device name.

(/dev/hdXX to /dev/sdYY)
Comment 13 Mark van Rossum 2007-05-13 08:58:41 EDT
The work around suggested above works for me:

I edited /etc/crypttab so that it now contains:
 encrypt /dev/hda6 none
 encrypt /dev/sda6 none

This double entry made sure I could still boot with the old kernel.
The first entry can be removed after all is working fine.

In my case I also had to change the explicit reference to the boot partition in 
/etc/fstab, by labeling it. This can be done using e2label.
I changed /etc/fstab from
 /dev/hda2    /boot                  ext3    defaults 1 1
to
 LABEL=boot       /boot                  ext3    defaults 1 1

Hopes this helps others as well.




Comment 14 Mark van Rossum 2007-05-13 08:58:55 EDT
The work around suggested above works for me:

I edited /etc/crypttab so that it now contains:
 encrypt /dev/hda6 none
 encrypt /dev/sda6 none

This double entry made sure I could still boot with the old kernel.
The first entry can be removed after all is working fine.

In my case I also had to change the explicit reference to the boot partition in 
/etc/fstab, by labeling it. This can be done using e2label.
I changed /etc/fstab from
 /dev/hda2    /boot                  ext3    defaults 1 1
to
 LABEL=boot       /boot                  ext3    defaults 1 1

Hopes this helps others as well.




Comment 15 Charles R. Anderson 2007-05-14 12:45:58 EDT
Check out this message:

http://feraga.com/comment/reply/30/174

content reproduced here:

"OK, I've been working on the Automated Installer, and I've got the UUIDs
working for both encrypted and non-encrypted installs. It was a little more
complicated than I initially believed but it works.

For fstab, you can use the UUID for /boot but you need to use /dev/mapper/rootfs
for / (root).

For grub, you need to add root=/dev/mapper/rootfs to the kernel options.

And in crypttab, you need to use /dev/disk/by-uuid/<UUID> instead of UUID=<UUID>.

Also keep in mind that UUIDs will only work for XFS, Ext2/3 and LUKS enabled
Dm-Crypt formated partitions. Also, you should use '/lib/udev/vol_id -u <dev>'
or 'cryptsetup luksUUID <dev>' to lookup the UUIDs. For some reason, /sbin/blkid
doesn't get the right UUID from the LUKS header."

Comment 16 Jeremy Katz 2007-05-18 12:04:27 EDT
Is there anything we can actually do here other than release note this?
Comment 17 Bill Nottingham 2007-05-18 14:12:57 EDT
Not really. It *should* be mentioned briefly in the relnotes already.
Comment 18 Jeremy Katz 2007-05-18 16:46:10 EDT
Dropping off the blocker list then and setting the release notes flag so that we
can get a summary of this there especially including the workaround of including
both devicenames in crypttab to work with both kernel types.
Comment 19 Mark van Rossum 2007-05-18 17:35:48 EDT
Perhaps a detection of encrypted partition is worhtwhile to warn users.

cryptsetup isLuks /dev/XXX
Comment 20 Bug Zapper 2008-04-03 20:05:11 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 21 Bug Zapper 2008-05-06 21:28:59 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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