On Tue 31 Oct 2017 at 21:21:01 (+0100), deloptes wrote: > commentsab...@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.
