Ubuntu – Disk Drive / not ready yet or not available

The problem resolved mysteriously. I learned that pressing Esc when the "Skip / Manual Recovery" message comes up, you get to see the last error in the system. Mine was problem with some rule hrdjconsole.rule under rules.d. I tried to apt-get remove package libdjconsole associated with it, but got an error. But on next reboot somehow everything "just worked" all the way up to the KDE gui. I reinstalled the grub just in case, found the right name for that libdjconsole0 in synaptic, purged it and had no problems ever since. Why did I not have this issue when booting from normal hard drive previously and just getting it now - and whether this actually was the issue - I don't know.

Before trying to remove the problem package while in recovery console, I also went through mounting all items from fstab manually one by one. Maybe it has instilled confidence into mountall and it decided to do it by itself the next time :)

I hope that this post is not entirely useless.

PS: the increase in performance is really awesome. SSD breathed life into my old machine. Boot time went from 2 minutes (from grub prompt to KDE desktop - 1.8G Core2Duo, 4GB RAM) to 40 sec. Anything that requires reading a lot of small files - e.g. Synaptic building it's database - is now almost instant. Pretty awesome!

I had the same problem when using an encrypted swap partition. Neither the general Swap FAQ, Puny Geek's solution to the "cryptswap1 is not ready yet or not present" message nor Braiam's answer to this question solved the problem for me - sometimes the swap was available, sometimes it wasn't. After many reboots and some poking around, I think I have found the underlying reason:

The path to the swap partition like /dev/sda3 is sometimes different, e.g. /dev/sdb3. Since the file /etc/crypttab by default seems to identify the swap partition through this path, sometimes it would find it (if that partition happens to get the same path at boot) or not (if the partition gets a different path assigned at boot).

Seems like I wasn't the only one with that problem becasue as described here, a better solution would be to bind the swap partition through it's drive ID instead of its /dev/sd* path. This can be found by running

ls -l /dev/disk/by-id/

which lists the disk IDs for all partitions including the swap, which in my case was

ata-TOSHIBA_MQ01UBD100_73JATD5GT-part3 -> ../../sdb3

Double check in a program like Disk Utility that the -> ../../sdb* part of this line is indeed the partition you intend to use for swapping, as this (as I said before) can sometimes change names. As always, keep this in mind:

Caution: fiddling with cryptsetup and disk devices is dangerous for data and OS. I personally made a full backup on a separate disk and then umplugged it to be sure it wouldn’t be involved in any mishap.

Then edit your /etc/crypttab file by using the ID link instead of the "raw" path, in my case this line is

cryptswap1 /dev/disk/by-id/ata-TOSHIBA_MQ01UBD100_73JATD5GT-part3 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

I think this method should be the default for new installations, as one apparently can never be sure of the /dev/sd* paths... which I find somewhat worrying as I have the feeling that there are way more scripts and software out there which still rely on these paths (instead of IDs, labels or UUIDs) to stay the same across reboots.

TODO:

I haven't checked if resuming out of hibernation still works with this setup, as this seems to rely on a UUID (which my swap partition didn't have), as stated on this page: https://altinukshini.wordpress.com/2012/10/15/devmappercryptswap1-is-not-ready-yet-or-not-present/

Update:

Hibernation seems to work fine so far. Hope this solves these problems for others as well!