Bug 437604 - cannot upgrade encrypted system
cannot upgrade encrypted system
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F10Blocker/F10FinalBlocker 461696
  Show dependency treegraph
 
Reported: 2008-03-15 00:34 EDT by Jon Stanley
Modified: 2013-01-09 23:36 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-24 19:10:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
initrd from failed system (3.48 MB, application/octet-stream)
2008-09-12 20:30 EDT, Jon Stanley
no flags Details

  None (edit)
Description Jon Stanley 2008-03-15 00:34:56 EDT
Anaconda does not present the option to "upgrade" an encrypted system.  This is
reasonable, since anaconda can't read the disk in order to tell that there is an
existing Fedora installation on it.  There needs to be some way of providing the
LUKS key to anaconda so that it can read the filesystems and do the upgrade.
Comment 1 Jeremy Katz 2008-03-15 11:40:00 EDT
Upgrade support may not land for F9 given that this is the first release with
encrypted root support.

But Dave was looking at it and we'll decide based on how the patch ends up looking.
Comment 2 Bug Zapper 2008-05-14 02:04:55 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 3 Kevin R. Page 2008-06-09 13:28:07 EDT
(In reply to comment #1)
> Upgrade support may not land for F9 given that this is the first release with
> encrypted root support.

I guess this didn't happen? Running the install/upgrade DVD, it unlocks my
encrypted partition ok, but doesn't offer the option of upgrading rather than
install.

I have an encrypted PV with an F8 install on LVs within, created as per bug
#124789 comment #95.

It looks like this is the same layout as F9 creates for an encrypted install?

I can upgrade by migrating the LVs to an unencrypted PV, running upgrade, then
moving them back to the encrypted PV.

Once I've done this, will mkinitrd (on F9 LiveCD or the installation if need be)
correctly build to boot from the encrypted PV? Or do I need any explicit
addition config that anaconda might generate to flag stuff up to mkinitrd?
Comment 4 Jon Stanley 2008-06-10 08:46:53 EDT
Nope, this was intended as more of a long-term TODO item rather than something
that had to be fixed prior to release. So no upgrade support in anaconda. Adding
to F10Blocker just so we don't lose sight of it.
Comment 5 Kevin R. Page 2008-06-12 10:41:19 EDT
(In reply to comment #3)
> Once I've done this, will mkinitrd (on F9 LiveCD or the installation if need be)
> correctly build to boot from the encrypted PV?

In case anyone else ends up in this situation, yes, by and large this works.
I've listed the steps I took in bug #124789 comment #122.

The only thing that might be of more general interest is that mkinitrd seens to
tie the encrypted PV to a specific disk device (e.g. /dev/sda) rather than
something invariant. So in step 5) when I removed the temporary external USB
drive  the PV "moved" from sdb2 to sda2 as the drive ordering changed, and the
initrd I'd previously built failed to work (chrooting from the rescue disk and
running mkinitrd fixed this).
Comment 6 Matt McCutchen 2008-06-12 11:30:12 EDT
The F9 live installer does prompt to open all available LUKS partitions between
the root password step and the disk partitioning step.  Would it work to simply
move the LUKS-opening step to the very beginning so the upgrade check sees
encrypted partitions?
Comment 7 David Lehman 2008-08-14 15:52:43 EDT
Fix will be in anaconda-11.4.1.29-1. This is in rawhide, and is intended to lead to support for upgrade of encrypted F9 systems to F10 using anaconda.
Comment 8 Jon Stanley 2008-09-12 19:49:37 EDT
Upgrade still fails on 11.4.1.34.  Not entirely sure why - it goes through the whole thing as though it's successful, but the resultant system won't boot (never prompts for the passphrase, therefore can't find the vg and switchroot out of the initrd).

I'll try and grab the initrd out of it and see if I can see something obviously wrong there.
Comment 9 Jon Stanley 2008-09-12 20:05:05 EDT
Due to bug 462148, I can't get the initrd off this system :(
Comment 10 Jon Stanley 2008-09-12 20:27:34 EDT
Ahh, I give up too easily sometimes :)  The rescue mode from F9 was able to mount this installation fine, and I ripped apart the initrd and to my untrained eye, it looks fine. init indeed calls plymouth ask-for-password with a seemingly good looking cryptsetup.

I'll attach the initrd in case you can see something that I can't.
Comment 11 Jon Stanley 2008-09-12 20:30:20 EDT
Created attachment 316639 [details]
initrd from failed system
Comment 12 David Lehman 2008-09-13 12:42:18 EDT
There's no plymouth in the initrd!

My money says plymouth is indeed installed on your system and if you re-run mkinitrd it will create a (closer to) working initrd.

There's something about the order in which things actually land on the filesystem, and mkinitrd seems content to build broken initrds if plymouth isn't around when it's being run. Or at least this was my experience around the f10-alpha timeframe.
Comment 13 Jesse Keating 2008-10-03 19:02:35 EDT
Can we get an updated test on this, given that Beta just went out?
Comment 14 Jesse Keating 2008-10-24 19:10:11 EDT
I just tested upgrading, everything seemed to go fine, including the graphical plymouth to unlock.  I'm going to close this bug, it can be re-opened if we find something else.

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