Ausgangssituation
Es wurde von einer externen Festplatte eine Image mittels DD erstellt. Nach x Wochen wird eine Datei vom System benötigt bzw. es werden Einstellungen eines Benutzers benötigt die mittels gsettings ausgelesen werden können.
Image mounten
Name der Image Datei: 20200419-13_31.dump
DD-Image inspizieren
Zuerst lohnt sich ein Blick auf das Image. Welche Partitionen liegen vor.
$ fdisk -l 20200419-13_31.dump Disk 20200419-13_31.dump: 465,8 GiB, 500107862016 bytes, 976773168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 520D131A-E600-4C51-9771-BFE34EBDB637 Device Start End Sectors Size Type 20200419-13_31.dump1 2048 1050623 1048576 512M EFI System 20200419-13_31.dump2 1050624 428869631 427819008 204G Linux filesystem 20200419-13_31.dump3 428869632 976771071 547901440 261,3G Microsoft basic data
Es liegen drei Partitionen vor:
- UEFI Boot (FAT32)
- Linux (luks verschlüsselt – steht nicht in der Ausgabe, ist aber bekannt)
- Windows NTFS Partition
DD-Image als Loop Device einbinden
Um auf die einzelnen Partitionen zugreifen zu können muss das Image als Loop device eingebunden werden.
$ losetup -P /dev/loop0 20200419-13_31.dump
Die Verwendung von losetup mit dem Parameter -P hat einen charmanten Vorteil. Es werden automatisch alle erkannten Partitionen durchnummeriert eingebunden.
- UEFI Boot (FAT32) > /dev/loop0p1
- Linux (luks verschlüsselt – steht nicht in der Ausgabe, ist aber bekannt) > /dev/loop0p2
- Windows NTFS Partition >/dev/loop0p3
Luks Partition entschlüsselt
Die Linux Partition ist wie gesagt verschlüsselt. Diese muss vor der Benutzung entschlüsselt werden.
$ cryptsetup luksOpen /dev/loop0p2 img Geben Sie die Passphrase für »/dev/loop0p2« ein:
Mounten der Partitionen
Mir ist bekannt, dass auf der Linux Partition btrfs mit Debian kompatiblen Sub Volumes verwendet wurde. Es existieren somit
- @ für /
- @home für /home
Die Volumes werden entsprechend nach /target zusammengemountet. Dazu kommt noch die erste Partition, auf der sich die UEFI Boot Daten befinden.
$ mount -o subvol=@ /dev/mapper/img /target $ mount -o subvol=@home /dev/mapper/img /target/home $ mount /dev/loop0p1 /target/boot/
Kurze kontrolle ob alles geklappt hat. Prüfung mittels df was gemountet wurde
$ df -h | grep target /dev/mapper/img 204G 134G 68G 67% /target /dev/mapper/img 204G 134G 68G 67% /target/home /dev/loop0p1 511M 58M 454M 12% /target/boot
Optional: Falls im Systemkontext des DD Images z.B. Updates installiert werden sollen die den Bootloader verändern sind noch folgende Verzeichnisse für die Systemungebung zu mounten.
$ for i in dev dev/pts proc run sys; do mount -o bind /$i /target/$i; done
Anschließend per chroot in den Systemkontext des Images wechseln. Hier kann dann auch mit gsettings gearbeitet werden um Einstellungen des Benutzers auszulesen.
$ chroot /target
Sauberer Rückbau
$ exit #(chroot) $ sync $ for i in dev/pts dev proc run sys; do umount /target/$i; done $ umount /target/home $ umount /target/boot $ umount /target $ cryptsetup luksClose img $ losetup -d /dev/loop0
Trobleshooting
device-mapper: remove ioctl on img failed: Das Gerät oder die Ressource ist belegt
Die Ressource wird weiterhin verwendet. Prüfen von wem
$ dmsetup info -C Name Maj Min Stat Open Targ Event UUID img 254 0 L--w 1 1 0 CRYPT-LUKS2-57c6706c5ad940f0bcebaea3d6cc3f5f-img
Open gibt die Anzahl der offenen Zugriffe an.
$ sudo dmsetup ls img (254:0)
Jetzt wissen wir von „wem“. lsof sollte uns einen Hinweis geben von wem. Der Prozess kann dann beendet oder gekillt werden.
$ sudo lsof |grep 254,0
target is busy
Auch hier erst prüfen wie zuvor beschrieben von wem der Zugriff blockiert wird. Als harter unmount geht immer „lazy“. Quasi einfach Stecker ziehen. Kann not Datenverlust verbunden sein.
$ umount -lf /target
Quellen
- https://unix.stackexchange.com/questions/504230/mount-encrypted-partition-of-an-image-file
- https://major.io/2010/12/14/mounting-a-raw-partition-file-made-with-dd-or-dd_rescue-in-linux/