Bug 461696 - cannot upgrade encrypted system
cannot upgrade encrypted system
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
5.3
All Linux
low Severity low
: rc
: ---
Assigned To: David Lehman
Alexander Todorov
:
Depends On: 437604
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-09 19:02 EDT by David Lehman
Modified: 2009-01-20 16:37 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 16:37:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Lehman 2008-09-09 19:02:44 EDT
+++ This bug was initially created as a clone of Bug #437604 +++

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.

--- Additional comment from katzj@redhat.com on 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.

--- Additional comment from fedora-triage-list@redhat.com on 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

--- Additional comment from redhat-bugzilla@krp.org.uk on 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?


--- Additional comment from jonstanley@gmail.com on 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.

--- Additional comment from redhat-bugzilla@krp.org.uk on 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).

--- Additional comment from matt@mattmccutchen.net on 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?

--- Additional comment from dlehman@redhat.com on 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 1 David Lehman 2008-09-09 19:04:17 EDT
Since cryptsetup-luks has been in RHEL5 since GA we should have the capability to upgrade a 5.2 system that the user has manually set up with LUKS block devices.
Comment 2 RHEL Product and Program Management 2008-09-15 20:11:43 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 4 David Lehman 2008-09-17 20:31:46 EDT
Fixed in anaconda-11.1.2.126-1.
Comment 6 Alexander Todorov 2008-11-10 10:10:44 EST
1) Installed a system with RHEL5.3 Beta using default partitioning + encryption.
2) Booted snap #2
3) Entered pass phrase to unlock encrypted block devices
4) Anaconda presented me with the option to install or upgrade
5) After choosing upgrade it calculated dependencies and started installing packages
6) System is able to boot to runlevel 3 after the upgrade completes.

I'm moving this one to VERIFIED
Comment 8 errata-xmlrpc 2009-01-20 16:37:52 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0164.html

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