Description of problem: I think Fedup-dracut has several problems with LUKS encryption. I don't have specific informations that prove the problem between Fedup-dracut and LUKS, but other times I used Fedup without LUKS, everything went fine. Before opening this bugreport, I tried Fedup+LUKS on both my laptop computer and a Virtual Machine, and I had problems on both of them. Different kind of problems, but the final result is that I did not manage to upgrade to Fedora 18. To better explain, I attach down here the entire procedure I followed ***Laptop computer procedure*** 1) I tried to upgrade my computer from Fedora 17 to Fedora 18 with Fedup. I used the command # fedup-cli --network 18 --debuglog fedup.log --instrepo http://dl.fedoraproject.org/pub/fedora/linux/relases/test/18-Beta/Fedora/x86/os Fedup downloaded all packages, but at certain point I had the error messages: [ 136.282] (DD) fedup.download:verify() verifying 2854/2854 plexus-containers-1.5.5-6.fc18.noarch.rpm [ 136.283] (II) fedup.yum:download_packages() beginning package download... [ 811.959] (DD) fedup.yum:treeinfo() fetching .treeinfo from repo 'instrepo' [ 812.443] (II) fedup:<module>() Downloading failed. Exception: Traceback (most recent call last): File "/usr/bin/fedup-cli", line 285, in <module> main(args) File "/usr/bin/fedup-cli", line 237, in main kernel, initrd = f.download_boot_images() # TODO: arch File "/usr/lib/python2.7/site-packages/fedup/download.py", line 259, in download_boot_images raise YumBaseError(_("couldn't get %s from repo") % key) YumBaseError: couldn't get treeinfo from repo [ 812.444] (II) fedup:<module>() /usr/bin/fedup-cli exiting at Thu Dec 27 16:27:17 2012 Asking on IRC a person suggested me to check the URL. Then I solved entering the same command but changing the URL into http://dl.fedoraproject.org/pub/fedora/linux/releases/test/18-Beta/Fedora/i386/os/ 2) I rebooted, then I selected "System upgrade" Grub entry, I entered the LUKS password, then (I assume, because Fedup-dracut is silent) the computer did the upgrade. 3) When the computer rebooted again, I saw that "System upgrade" and the old Fedora 17 kernel entries were still there on the menu. I selected the Fedora 18 kernel, but I obtain the error messages as you can see in LaptopF18BootEntryscreen.JPG I can only reboot by doing CTRL+ALT+RSIST+SUB 4) I used a livecd to retrieve from the disk the logs dmesg, update.log, dracut.log ******************************* ***Virtual Machine procedure*** 1) I installed a fresh Fedora 17 KDE virtual machine with LUKS encryption, without any additional module (like VM addition) 2) I installed Fedup and runned # fedup-cli --network 18 --debuglog fedup.log --instrepo http://dl.fedoraproject.org/pub/fedora/linux/releases/test/18-Beta/Fedora/x86_64/os/ 3)Rebooted into "system update" Grub menu entry, and had system stuck with some errors as shown in VM-systemupgrade.png The system obiouvsly is still bootable from Fedora 17 kernels *******************************
Created attachment 669916 [details] Laptop F18 Boot entry screenshot
Created attachment 669917 [details] VirtualMachine system upgrade failure screenshot
Created attachment 669918 [details] Laptop's /var/log/dmesg
Created attachment 669919 [details] Laptop's /var/log/dracut.log
Created attachment 669920 [details] Laptop's /var/log/upgrade.log
can you try with --instrepo http://dl.fedoraproject.org/pub/alt/qa/20130103_f18-smoke13/fedup/ (x86_64 only)? see https://bugzilla.redhat.com/show_bug.cgi?id=891786 . tflink reports that worked for him. thanks.
I got to this bug report from 891786. Upgrade (fedup) using the link provided by Adam in comment 6 is able to complete successfully on a F17 install containing encrypted filesystems. $ uname -r 3.6.10-4.fc18.x86_64 $ rpm -qa kernel\* kernel-3.6.10-2.fc17.x86_64 kernel-3.3.4-5.fc17.x86_64 kernel-3.6.10-4.fc18.x86_64
(In reply to comment #6) > can you try with --instrepo > http://dl.fedoraproject.org/pub/alt/qa/20130103_f18-smoke13/fedup/ (x86_64 > only)? see https://bugzilla.redhat.com/show_bug.cgi?id=891786 . tflink > reports that worked for him. thanks. It does not work for me. Here the procedure I followed: I took the originary F17 virtual machine, I upgraded fedup, then I cloned the entire vm to have a reliable base from which to restart again in case of failures. I took the cloned virtualmachine and I upgraded with # fedup-cli --network 18 --debuglog fedup.log --instrepo http://dl.fedoraproject.org/pub/alt/qa/20130103_f18-smoke13/fedup/ Then I restarted selecting "System upgrade" Grub entry. I entered LUKS password, then waited for ~20 minutes. Meanwhile, the VirtualBox hdd icon did not show any hdd activity. After this period of time, I pressed a key, and the following screen apperaded to me (see attachments).
Created attachment 674965 [details] VirtualMachine No.2 - System upgrade (graph mode)
Created attachment 674966 [details] VirtualMachine No.2 - System upgrade (text mode)
Does your system have multiple encrypted partitions, or just one? blkid | grep crypto_LUKS should tell you how many LUKS partitions exist.
Hello, My system has only 1 LUKS partition : /dev/sda4: UUID="824e4d30-94e9-40d1-980d-83b89f123d18" TYPE="crypto_LUKS" The solution given above with instrepo is not working any more, see : https://bugzilla.redhat.com/show_bug.cgi?id=891910 So what should we do with a LUKS partition ? Apparently the official repo prevents any upgrade with a LUKS partition and other dispos are prevented from being used to make the upgrade. Any idea ? The issue, for me, is that there is no box that requests the password for the LUKS partition, whether in text or graphic mode. Thanks for your help
(In reply to comment #11) > Does your system have multiple encrypted partitions, or just one? > > blkid | grep crypto_LUKS > > should tell you how many LUKS partitions exist. If I selected the right virtual machine, it should be only one partition: /dev/sda2
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.