EDIT: Problem solved, i updated from Debian 6.0.6 to 7.0.0, everything works now!

I have a complex problem at booting. Basically, I have a debian apache box, as a music server in my home network. The root, swap and data hard drives are dm_crypted. The booting should look like this:

  1. GRUB
  2. Ask root pass phrase
  3. Setup swap fs(gets random pw at boot)
  4. Booting continues
  5. Ask data passphrase
  6. Booting finishes
  7. Server is accessible via http & SSH

Some logs:





uname -a returns the following:

Linux linux-server 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012 x86_64 GNU/Linux

debian version: 6.0.6

Version of cryptsetup: 2:1.1.3-4squeeze2

What I did:

  • I ran update-initramfs -u -k all -v
  • I can mount the device with cryptsetup / mount after boot.

I think the problem is that the external hard drive is not available to the system between step 4 & 5, so cryptsetup fails, mount fails, fschk fails and the boot process switches into emergency mode.

Any help would be appreciated!

EDIT: Problem solved, i updated from Debian 6.0.6 to 7.0.0, everything works now!

  • Nice to have the complete logs! Unfortunately I don't see the cause of the error. Debian stable, testing, unstable? If not stable, what version of the kernel and of cryptsetup? – Gilles Feb 1 '13 at 23:20
  • It is debian 6.0.6 stable. It is really stange cause it mounts swap and /, asks me for the / password and i can mount "sdb1" / "sdb1_crypt" with cryptsetup and mount later. cryptsetup is version 2:1.1.3-4squeeze2 kernel is version 2.6.32-5-amd64 x86_64 – TobiasPC Feb 2 '13 at 13:01
  • Can you uncomment set -x at the top of /lib/cryptsetup/cryptdisks.functions and try again? This should give us a debugging trace, hopefully it'll be easier to understand what's going on. – Gilles Feb 2 '13 at 14:29
  • Here it is: Click – TobiasPC Feb 2 '13 at 14:53
  • Ah, got it from the trace. You somehow deleted the # at the beginning of the first line of /etc/crypttab, so <name> <device> <pass> <options> is being parsed as an entry, which causes the not-very-robust script to bomb out. I think fixing that should make your script bootable, so I'm voting to close this question as “too localized”. If that's not enough to fix it, post the new trace. – Gilles Feb 2 '13 at 15:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.