> hmmm not sure, you could try > turning of quiet mode remove the quiet from the kernel option on boot > and maybe try turning on debug (add debug to the kernal options)
There is no quiet mode in my kernel line. Adding the debug option didn't seem to add any additional relevant information; > anothering to try is place a shell script in > /etc/initramfs/scripts/local-top/ call something like 00mine and open a > console with something like bash or try some command here like I tried adding the 00mine script (mode 755, just one line which says bash), then updated the initramfs, but it didn't stop and spawn a shell at any point in the boot process. > cryptsetup -T1 luksOpen /dev/sda2 sda2_crypt After it dropped me to the (initramfs) prompt I entered that command (I had to change it to sda5) and I was able to unlock the drive. I was unable to mount it however. (initramfs) mount /dev/mapper/sda5_crypt /a mount: mounting /dev/mapper/sda5_crypt on /a failed: Invalid argument > or add to your kernel options something like break=local-top Adding the break=local-top option did not do anything different. > It may be related to the "driver sd needs updating" thing, but > it seems to be contradicted by your observation that /dev/sda appears > to be present and functional from within the busybox shell. I think the SCSI driver is working ok - I am able to unlock the volume with crypptsetup luksOpen, and head /dev/sda5 gives me some garbage, indicating that I can read the drive. > One thing you *can* do easily is, boot with the "break" > option, and from within the resulting shell, run > /scripts/init-premount/udev, which will create all the devices. > You can then do an "ls" in /dev, and see if the relevant > hard drive partition (/dev/sda5, in your case) is are present -- > this tests the udev step pretty directly. (initramfs) /scripts/init-premount/udev udevd[2891]: init_udevd_socket: bind failed: Address already in use error initializing the udevd socket udevd[2891]: main: error initializing the udevd socket > Please bear with me, I'm asking this out of curiousity. Why did you > encrypt the full root FS? The root filesystem is encrypted to make it more difficult for a local attacker to replace system binaries with backdoored versions. I am not sure what else to try at this point, all suggestions are appreciated! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
