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

Re: Stretch : mount Jessie encrypted HDD via USB



On Tue 31 Oct 2017 at 21:21:01 (+0100), deloptes wrote:
> commentsabout@riseup.net wrote:
> 
> > Hello,
> > 
> > I'm trying to connect my old Jessie HDD via USB in order to transfer
> > files to my new Stretch system (details below). It does not work out of
> > the box because it is encrypted, how should I proceed?
> > 
> > - I only have a laptop;
> > 
> > - 1 old HDD with Jessie (guided encrypted LVM install);
> > 
> > - 1 new SSD with Stretch (guided encrypted LVM install), this drive is
> > in the laptop;
> > 
> > - 1 S-ATA to USB adapter.
> > 
> > Needless to say that I have the passphrase for both systems. I am
> > actually worried to damage the Jessie system by using wrong commands so
> > I am looking for help.
> > 
> > Thank you in advance :)
> > 
> > CA
> 
> most modern desktops will offer a tool to react when disk (usb) is plugged
> in and if encrypted ask for password to decrypt. IF there is lvm they will
> handle the lvm automatically
> 
> Manually it can be done as follows (presumably the disk was encrypted with
> luks)
> 
> 1. plugin in / connect the usb to the computer
> 2. cryptsetup luksOpen /dev/sd<x>1 cryptedDisk

Would I be right in thinking that

  udisksctl unlock --block-device /dev/sd<x>1

would be a safer command because udisksctl lacks the
more destructive subcommands available in cryptsetup?

> 3. vgchange -ay cryptedDisk
> 4. mount /dev/mapper/cryptedDisk-<logical volume> ...
> 
> reverse
> 
> 1. umount /dev/mapper/cryptedDisk-<logical volume>
> 2. vgchange -an cryptedDisk
> 3. cryptsetup luksClose cryptedDisk

and this would then be

  udisksctl lock --block-device /dev/sd<x>1

> 4. unplug
> 
> * <x> - disk id (a,b,c,d etc)
> * <logical volume> - volume name

And one query while we're on the topic. Obviously
umount is necessary and will be noticed later if
it's not performed. However, what about vgchange -an
and locking? AFAICT failing to lock has no later
consequences for the device itself.

Cheers,
David.


Reply to: