Surviving OSX crash on Linux



The aim of this post is to provide some ideas for recovering work from a crashed Mac machine, at least when the hard disk has not been damaged.

Objectives:
  • mount the Time Machine backup
  • mount the original disk as R/W with permissions
  • mount the disk as Copy on Write
  • clone the original disk as VDI and mount it
  • run OSX from Virtual Box


In the following I will note in upper case the mount points and the other parameters needed to the commands. These solutions will be relative to Linux, because, in my case, I was not having another Mac machine at disposal.
# The first option is the access to the Time Machine backup. This is possible through a Python based FUSE filesystem that is available at this link. As from the website documentation we need the path to the mounted Time Machine drive as TIMEMACHINEPATH and the full name of the Mac as HOSTNAME, due to the fact that multiple backups can be present on that Time Machine disk.
python fuse-tm.py NEWMOUNT --hfs-path=TIMEMACHINEPATH --hostname=HOSTNAME
# The second option is to mount the original disk as HFS+ partition in Read/Write mode on Linux. This is automatic in recent Linux versions. There is anyway an issue of permissions. In particular all the system files of the OSX partition are visible, but the user's files are locked. Instead of accessing the files as root we use the bindfs virtual filesystem. Bindfs allows to mount any existing folder of Linux setting the rights of all the files to a given user.
sudo bindfs -u $(id -u) -g $(id -g) EXISTINGMOUNT NEWMOUNT
# In the case you don't like to mount the original disk in Read/Write mode it is still possible to get a read/write access using a Copy on Write approach. The resulting mount point will be read/write but all the changed files will be stored  on a separate location. This is possible thanks to the use of unionfs, in particular the unionfs-fuse package. The following command merges SOURCEMOUNT and STORAGELOCATION accessing the former read only and the latter as copy on write storage:
sudo unionfs-fuse -o cow -o allow_other,use_ino,suid,dev,nonempty \
SOURCEMOUNT=RO:STORAGELOCATION=RW NEWMOUNT
The copy-on-write approach can be applied in general, also in the case of the mounting of the Time Machine backup.

# We probably do not want to keep the original hard drive connected all the time, and instead we would like to clone the disk. This could be done with dd at command line or with other tools creating a raw image. Instead we prefer to make a VirtualBox VDI, that is a virtual disk file for a Virtual Machine. The advantage is that the VDI of a read only disk is smaller than the physical disk, and, it is the necessary step for running if from VirtualBox. Assuming VirtualBox is installed we will use the VBoxManage tool as follows:
sudo dd if=DISKPATH | VBoxManage convertfromraw stdin OUTFILE.vdi DISKSIZEBYTES
The DISKSIZEBYTES can be obtained by querying the disk size in bytes to fdisk, referring to the disk device, like /dev/sda or /dev/sdb.
sudo fdisk -l /dev/sda
# Now that the VDI has been created we need to mount it. If the VDI disk is a fixed size it can be directly mounted because the original content is placed on the disk at a given offset. We can use a loop mount:
sudo mount MYVDI NEWMOUNT -o ro,loop,offset=OFFSET
Where OFFSET is obtained from VBoxManage:
VBoxManage internalcommands dumphdinfo MYVDI
In general the VDI is not of fixed size, so we need to use another approach. In the past there was a FUSE filesystem provided with VirtualBox but currently the support is broken. There is also a general library called libguestfs that is super flexible and powerful. For this discussion I suggest to use a feature provided by the qemu emulator. This is obtained by the kernel module nbd (Network Block Device):
sudo modprobe nbd
sudo qemu-nbd -c DEVPATH MYVDI
sudo mount DEVPATHPART -o ro,nouser NEWMOUNT
The DEVPATH is "/dev/nbd#" where # is the number of the device (0-15). DEVPATHPART is "/dev/nbd#p#" where the first # is the nbd device number, and the second is the number of partition in the disk (typically 1 or 2). All the considerations about HFS+ mounting and copy on write apply also to the mount of the VDI.

All the mounts can be destroyed with umount, while the qemu-nbd can be deleted with the -d flag:
sudo qemu-nbd -d DEVPATH
# The last possibility is to run OSX inside VirtualBox. This is a bit more difficult than installing OSX on a new disk, as can be found online. At the date of writing I am not able to boot to the graphical mode of a Maverick 10.9. What is anyway possible is to boot in single user mode. This can be done without any hacking, just using the  latest version of VirtualBox.

What is needed is to create a VirtualBox machine pointing to the VDI file, to enable the EFI bios, and to provide enough memory to the machine. Then at the boot press ESC to enter the EFI boot manager. Then select the EFI Internal Shell from the Boot Manager. This will allow to specify boot options to the OSX boot manager:
fs4:
\System\Library\CoreServices\boot.efi -v -s
The first command moves from current drive to one of the hard disk partition, and this will depend on the layout of the disk. The second command boots the single user mode thanks to the -s option. From the single user mode the disk can be mounted in write mode and many useful commands can be issued...

I hope this could be of help.

Comments

Popular posts from this blog

Docker for our ROS robotic overlords

cmakego: Simpler access to external libraries in CMake

Algebrical Data Types in C++