Ubuntu

Karmic update "Waiting for encrypted source device..." error

Bug #446591 reported by David Brownlee
This bug report is a duplicate of:  Bug #428435: luks encrypted partition not detected. Edit Remove
30
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Ubuntu
Confirmed
Undecided
Unassigned
Nominated for Karmic by Gunni

Bug Description

My initial post to answers.launchpad.net (question 84659) with a few extra details follows.

Upgraded 64bit Desktop from Jaunty to Karmic Beta using "update-manager -d". The upgrade completed successfully but, on reboot, it is unable to find the encrypted harddrive. This is on a laptop which was initially installed using the Jaunty alternate iso image so that the entire harddisk could be encrypted. At present, it prints a message about not finding the disk and drops me out to a Busybox "(initramfs)" prompt.

Update:
Confirmed on another, older laptop that the same problem exists for upgrades on 32bit systems.

Update:
Hmm, this may be bug #430496. I will dig further tonight and link to the bug if it turns out to be the same.

Update:
OK, this doesn't look like the same bug. I changed "splash" to "nosplash" on the kernel arguments in grub and all I see on boot is:

  Boot from (hd0,4) ext2 9df54a9f-bee2-48cd-ae71-863098345c65
  Starting up ...

The cursor sits there blinking under the 'B' and then it appears that some timeout it reached and it writes to the screen without first clearing it leaving me with:

  Boot froCheck cryptopts=source= bootarg cat /proc/cmdline5c65
  Startingor missing modules. devices: cat /proc/modules ls /dev
  -r ALERT! /dev/disk/by-uuid/927c495b-179f-439a-9580-6cb6057b92ea does not exist.
   Dropping to a shell!

  BusyBox v1.13.3 (Ubuntu 1:1.13.3-1ubuntu7)
  Enter 'help' for a list of built-in command

  (initramfs) _

At this point, I have two unbootable systems (although they boot the Karmic Beta LiveCD just fine). The 64bit system is a Lenovo laptop and the 32bit system is an HP Pavillian laptop. If I recall correctly, the steps I followed when initially installing both of these systems with Jaunty on an encrypted disk using the alternate CD image where the same as those posted at http://news.softpedia.com/news/Encrypted-Ubuntu-8-04-85271.shtml

FYI, If possible, I would like to recover data from one of the two systems.

David Brownlee (david-m-brownlee)
summary: - Karmic update results in systems that won't boot
+ Laptops with encrypted harddisks won't boot after Karmic Update
Revision history for this message
David Brownlee (david-m-brownlee) wrote : Re: Laptops with encrypted harddisks won't boot after Karmic Update

OK, it looks like I also needed to remove "quiet" from the boot arguments to see what was really going on. On both systems, before it hangs waiting for the timeout, the last messages are:

Begin: Running /scripts/init-premount ...
Done.
Begin: Mounting root file system... ...
Begin: Running /scripts/local-top ...
Begin: Waiting for encrypted source device... ...

David Brownlee (david-m-brownlee)
summary: - Laptops with encrypted harddisks won't boot after Karmic Update
+ Karmic update "Waiting for encrypted source device..." error
Revision history for this message
David Brownlee (david-m-brownlee) wrote :

FYI, I have access to the contents of my encrypted root filesystem now as outline in question 84659 on answers.launchpad.net so I can backup (I know, should have done that first) and reinstall from scratch if necessary.

Revision history for this message
Gunni (fgunni) wrote :

Updated today, and have the same problem. With the old jaunty kernel (2.6.28) i can boot in recovery mode, so i can work a bit, but with 2.6.31 i got the same symptoms here.

Revision history for this message
Gunni (fgunni) wrote :

Found a workaround:

http://ubuntuforums.org/showpost.php?p=7159100&postcount=4

With this changes everything working again. initrd is 3 times the size, but i dont mind the size if its working :)

Revision history for this message
Gunni (fgunni) wrote :

Maybe this could also help, but i dont know.
"I don't want to suggest any command like "sudo update-initramfs -k all -c" without knowing exactly what I'm doing, since I don't know if a mistake could make your encrypted partition totally unaccessible."
(Source: http://ubuntuforums.org/showpost.php?p=7151878&postcount=5 )

Revision history for this message
David Brownlee (david-m-brownlee) wrote :

This problem may have pre-dated Karmic. Here is what looks to be the identical problem:
https://answers.launchpad.net/ubuntu/+question/68158

Note, also that the workaround in the forum link did not work for me. One difference with my system as compared to the one in the forum link is that on my system, the encrypted partition contains a Physical Volume which is the only PV in a Volume Group that is then divided into two Logical Volumes, one for swap and for /. This is one of the default installation options on the alternate LiveCD as shown here:
http://news.softpedia.com/images/extra/LINUX/large/encryptedubuntu804-large_013.png

Revision history for this message
Gunni (fgunni) wrote :

Yes for me it is one volume, too, but the solution works.
I just needed to change in a similar way, and at the end of the rows there was an additional lvm_... or something, and that stays unchanged.
so it should be something like:

>> There you will see something like
target=sda5_crypt,source=/dev/disk/by-uuid/blahdiblah,key=none

Change this to:
target=sda1_crypt,source=/dev/sda1,key=none, lvm=root
target=sda1_crypt,source=/dev/sda1,key=none, lvm=swap (dont know the exact syntax of the lvm thingy)

But that did work for me.

Revision history for this message
Slight Slightly (slight--deactivatedaccount) wrote :

Same problem here, fix also worked for me. Hoping I won't have to do this for every kernel update though ;)

Revision history for this message
Gunni (fgunni) wrote :

But you can run it as script. I changed it to my needs, and now when i start the script, it begins, vi opens the file, i change the values manually (could be done by a script for sure, but doing by hand is shorter than thinking of a right script), save the file, and the script continues. Reboot and done.
Sure, when kernel number will change you have to change the script, but for minor changes it works.
Maybe when @home i put the script up here, but its only for you, if like me can boot in an older kernel.
For booting from live cd and mounting it has to be changed.

Revision history for this message
Antti Kaijanmäki (kaijanmaki) wrote :

This is clearly a duplicate of bug #428435

I had the same error when I started to look into this problem:
    /dev/disk/by-uuid/xxxxxx-xxxx-xxxx-xxxx-xxxxxxx does not exist.

Revision history for this message
Pyrrhus (carsten-holzmueller) wrote :

Hi,
I have the "Waiting for encrypted source device..." message too (32 bit; 9.10 Ubuntu) but not all the time.
- 80% of all boots are normal
- 15% ends with "Waiting for encrypted source device..."
- 5% ends with loud beep sounds
(subjective numbers)

Maybe a deadlock?

My Ubuntu is updated from 9.4. 9.4 works without sucht problems.

Are you realy sure that this is a duplicate?

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubuntu:
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.