Bug 236447

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?

(Adding cryptsetup-luks maintainer to cc).

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.

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?

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?

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...

I think this is coming from hal as HAL_PROP_BLOCK_DEVICE when it calls
tools/linux/hal-luks-setup-linux .

(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.

For the non-luks case, is there any sort of metadata on the block device that
can be read/verified?

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.

Would a manual update option be to run mkinitrd
with an edited fstab file and fstab option?

No, you need to change the device name in /etc/crypttab to the new device name.

(/dev/hdXX to /dev/sdYY)

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.

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.

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."

Is there anything we can actually do here other than release note this?

Not really. It *should* be mentioned briefly in the relnotes already.

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.

Perhaps a detection of encrypted partition is worhtwhile to warn users.

cryptsetup isLuks /dev/XXX

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.

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