Red Hat Bugzilla – Bug 469231
Can't install from repository on encrypted partition
Last modified: 2008-10-31 16:53:03 EDT
Description of problem:
Anaconda doesn't offer to unlock encrypted devices during the first stage. Therefore preupgrade doesn't work for systems with /var/cache/yum on an encrypted partition.
Version-Release number of selected component (if applicable):
How reproducible: Always
Steps to Reproduce:
1. System with /var/cache/yum on an encrypted partition
2. run preupgrade to create update repository on /var/cache/yum
3. Reboot system to installer
It is too late in the development cycle to try adding such things to the first stage. If possible, rearrange things so it is not on an encrypted device -- if this is not possible, you cannot use preupgrade.
I'm not sure we will ever do this, but certainly not for F10.
So what happens when you reboot to try the actual upgrade? Error messages, tracebacks, anacdump.txt, screenshot....?
I know this isn't going to be fixed for F10 but I wanted to put the problem on record for future developments. Currently the only way to use "preupgrade" on an encrypted system is the following way:
- run preupgrade
- copy /var/cache/yum/preupgrade to a web server
- modify "hd:UUID=....:/var/lib/cache/preupgrade" to a http://... URL in /etc/grub.conf
I tried to use an external USB hard drive instead of the web server, but unfortunately anaconda does not mount those in stage 1 :-/
Anyway if I remember correctly anaconda went through the first stage completely (keyboard, language and [in my case] network setup + download of stage 2 image from the net) but then complained that it couldn't find /var/lib/cache/preupgrade.
Hm, I did a default install of F9 plus encrypting the default partitioning layout, upgraded, made sure I got the latest preupgrade, and then attempted to preupgrade to rawhide.
This worked fine - anaconda is reading the packages from the encrypted device as can be evidenced by the fact that it's still upgrading and I removed the network cable. Two things to take into consideration here:
(1) You'll need to make sure you have the absolute latest preupgrade. I had to pull one from updates-testing since otherwise it crashes.
(2) Something's going wrong with ks= in anaconda so you will need to remove that bit from the "Upgrade to Rawhide" entry in grub if you ever want anaconda to get farther than the "Waiting for hardware..." message early on.
When I tried I had the latest preupgrade installed. I don't think preupgrade is the problem here, because when I moved the created repo to my web server and modified the grub entry the update went through without a hitch.
Sorry, but how can anaconda read /var/cache/yum/preupgrade without asking for the password to unlock my PV partition? And the UUID used in the hd: entry is from filesystem on the logical volume that is stored on the encrypted PV.
I don't remember seeing a ks= option in grub.conf.
I just tried again with
At the end I get this message:
DEBUG /sbin/grubby --title="Upgrade to Rawhide" --remove-kernel="/boot/upgrade/vmlinuz" --add-kernel="/boot/upgrade/vmlinuz" --initrd="/boot/upgrade/initrd.img" --args="preupgrade repo=hd:UUID=711dc45e-9530-4d46-918d-e7b9293d6896:/var/cache/yum/preupgrade stage2=ftp://alviss.et.tudelft.nl/pub/fedora/linux/development/i386/os/images/install.img"
title Upgrade to Rawhide
kernel /upgrade/vmlinuz preupgrade repo=hd:UUID=711dc45e-9530-4d46-918d-e7b9293d6896:/var/cache/yum/preupgrade stage2=ftp://alviss.et.tudelft.nl/pub/fedora/linux/development/i386/os/images/install.img
# df -kh /var/cache/yum/preupgrade
Filesystem Size Used Avail Use% Mounted on
9.4G 4.7G 4.2G 53% /
# /lib/udev/vol_id /dev/mapper/VolGroup00-LogVol00
So the UUID in repo= points to the filesystem /var/cache/yum/preupgrade is on.
Early on during the install when we're probing for devices, we do ask for a passphrase to decrypt devices. That's exactly what happened in my test.
I'm unsure what happened in your preupgrade run, though. You should definitely have a ks= parameter that sets things like language and keyboard, and your stage2= parameter should be something like stage2=hd:UUID=... just like everything else.
My /boot is too small for stage2. That's why the hd:UUID is replaced with a http: URL.
Whatever had been the problem in my earlier attempt it seems that anaconda has been fixed now. Now it goes through into stage 2, asks for the password and then accesses the repository.
I guess I'll see when preupgrading to F11 :-)