Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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:

fstab

crypttab

update-initramfs

/var/log/boot

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!

share|improve this question
    
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

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.