[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: unlocking encrypted root via ssh



Alex Samad wrote:

> On Thu, Aug 06, 2009 at 10:18:28PM -0400, Justin wrote:
>> Or not? I managed to boot it successfully that way only once.
>> 
>> On Thu, Aug 6, 2009 at 9:46 PM, Justin <eqisow@gmail.com> wrote:
>> 
>> > And the answer, for posterity, is that you do killall cryptroot*before*
>> > running it from busybox.
>> >
>> >
>> > On Thu, Aug 6, 2009 at 9:19 PM, Justin <eqisow@gmail.com> wrote:
>> >
>> >> I'm trying to unlock an encrypted root partition via SSH. I finally
>> >> got to the point where I could log in via dropbear and run cryptroot
>> >> successfully. After that I do a 'killall cryptroot & exit' and the
>> >> boot process resumes. However, it hangs after populating /dev. I
>> >> wasn't able to find ANY
> 


Hi, this is what I never found time to do. Few years ago as cryptsetup came
out I had to create my own initrd. After this debian or someone else fixed
the create-ramfs scripts, so it's working.

I often have had a problem when running mkiniramfs or updatecramfs (or
whatever it's called) particularly after installing a custom kernel.
The problem is (I think) if I install the custom kernel and point to the
version it's using the running version to find out modules etc and puts
them into the new initrd. This is not working mostly, so I'm booting with
kernel option init=/bin/sh to go to the shell and doing the stuff myself.
Check also to have setup the correct root in the kernel cmd_line i.e.
root=/dev/mapper/root. This should match your crypttab fstab etc (at time
of initrd creation).

You have to have /proc and /sys mounted I think I remember

when you are in the "limitted" shell you can check the status of udev and
actually you can trigger the hole boot process:

mount -t proc none /proc
cryptsetup .... root
cd /
test -d new || mkdir new
mount -t ext3 -o,ro /dev/mapper/root /new

exec /usr/sbin/chroot . /bin/sh <<- EOF >dev/console 2>&1
exec /sbin/init ${CMDLINE}
EOF

as far as I remember this is part of a trivial linux initramfs init file

Hints:
+ use a nonencrypted usb stick with copy of your binaries (you don't have to
reboot)

+ do it first onsite ;-)

regards


Reply to: