Bug 883072 - Upgrading fails, maybe because of encrypted harddisk; renders system unbootable
Summary: Upgrading fails, maybe because of encrypted harddisk; renders system unbootable
Keywords:
Status: CLOSED DUPLICATE of bug 885853
Alias: None
Product: Fedora
Classification: Fedora
Component: fedup
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Will Woods
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-03 17:46 UTC by m-redhat
Modified: 2012-12-10 21:00 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-12-10 21:00:50 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description m-redhat 2012-12-03 17:46:24 UTC
Description of problem:

I have been running F17, triggered the upgrade via fedup and when I came back to the computer it was unbootable.

Version-Release number of selected component (if applicable):

fedup.noarch                         0.7.1-1.fc18                installed      

How reproducible:

I have not tried reproducing the bug.
  
Actual results:

On the screen there were some messages saying that mounting my (encrypted) harddisk failed. Sadly I don't have the specific message written down (my theory here is that the system rebooted during upgrade, waited for my harddisk passphrase and hit some timeout -- hence, the system did not came up).

Expected results:

I would have expected the system either to wait forever until I enter the passphrase or when it hits a timeout at least offer a convenient way to continue a this stage.

So, I rebooted the system and it didn't come up -- it simply displayed the fedora logo for about 30 (?) minutes doing nothing (no harddisk activity). I had to disable the graphical boot and then I saw an error message (can look up the specific text on my camera if that is necessary) mentioning D-BUS and systemd, trying to connect to some socket which fails with a connection refused error.

Additional info:

I did some trial-end-error debugging and figured out that removing the following parameter systemd.unit=system-upgrade.target from the kernel boot line makes the system comes up just fine. Currently, without any manual changes, the entry in /boot/grub2/grub.cfg looks like this:

linux   /vmlinuz-3.6.7-5.fc18.x86_64 root=/dev/mapper/vg_lily-lv_root ro rd.md=0 rd.dm=0 rd.luks.uuid=luks-e7d3371d-e50a-4c5a-a1af-380b7009c045 rd.lvm.lv=vg_lily/lv_root  KEYTABLE=us SYSFONT=latarcyrheb-sun16 rd.lvm.lv=vg_lily/lv_swap LANG=en_US.UTF-8 rhgb quiet systemd.unit=system-upgrade.target

I was told on IRC that the last parameter is not supposed to be there. So it seems it is some kind of leftover from the fedup upgrading process. Maybe it is related to the upgrad process finishing unexpectedly duo the encrypted harddisk.

Thank you very much,
melanie

Comment 1 Tim Flink 2012-12-03 17:52:22 UTC
Have you tried removing the systemd.unit=system-upgrade.target from the kernel args when booting? If so, did it work?

Comment 2 m-redhat 2012-12-03 17:56:25 UTC
I thought I made that clear... yes, removing that parameter manually makes the system boot fine!

Comment 3 Will Woods 2012-12-10 21:00:50 UTC

*** This bug has been marked as a duplicate of bug 885853 ***


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