Re: Etch to 5.0.2 upgrade failed - Encrypted filesystem will not boot

[lineman@ruiner.halo.nu]

Ok I guess the system is just hosed.  If no one has any more suggestions in the next couple days I will reinstall.


I will never trust Debian upgrades again, at least not when encrypted filesystems are in use.







On Mon, Aug 10, 2009 at 06:49:51PM -0500, lineman@ruiner.halo.nu wrote:
> > 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-REQUEST@lists.debian.org 
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org