You can’t cross the same river twice, but can you boot the same laptop twice (at the same time)? Yes indeed, with the magic of VM’s and weird passthrough setups. I have a Slimbook with openSUSE and FreeBSD installed on it. Most of the time I use openSUSE – there’s suspend and resume and wifi things that need tweaking under FreeBSD. I’ve written about FreeBSD on Slimbook before. But with some magic, I can boot the laptop into openSUSE and them boot it again simultaneously into FreeBSD. Probably I can also mess things up royally, but let’s not get ahead of ourselves.
- Add a user (e.g. my regular user) to the disk group. With
usermod(as root) I added myself to that group, and after logging back in, can check with
idthat it was successful. On my system the disk group has write-access to disks, including the NVMe disk which has both OS’es installed on it.
- Create a virtual disk that refers to the raw drive. I did this as root as well. I made a VMDK somewhere the user can reach, and specified the raw disk device being used. It’s the whole disk.
- Make the file readable by the user, since the VMDK was created by root.
Together, the three steps look like this:
usermod -G disk -a adridg VBoxManage internalcommands createrawvmdk \ -filename /home/adridg/VBox/FreeBSD.vmdk \ -rawdisk /dev/nvme0n1 chown adridg /home/adridg/VBox/FreeBSD.vmdk
After these steps, I have a disk device I can hand to a VM. It’s the whole of my drive, so whatever I do in the VM can totally clobber the installed system, e.g. by overwriting the GPT or messing in the filesystems of another OS. But that’s not the point (except accidentally, because it’s got sharp edges).
Create a VM – I gave it 4 cores, 4GiB of RAM, and the new virtual disk attached to the SATA controller. Why SATA? Because it looks like NVMe is a proprietary extension. Boot the VM: it comes up with the same openSUSE-branded GRUB as when I boot the laptop normally! I have not tried inception-booting openSUSE inside itself, but FreeBSD starts.
I would expect booting the same filesystem twice would lead to massive filesystem corruption or kernel panics as two kernels write to the same block device at once, arguing over metadata updates.
There’s some (minor) caveats to the “FreeBSD starts” situation, though:
- I installed the system from physical media, to physical media.
That means that
/is expected to be on
/dev/nvd1p5– the NVMe drive in the laptop. Under VirtualBox, the device – I did say I attached it as SATA – has a different path. On boot, the loader stops and asks for a path for root. I enter
- The physical machine has WiFI and a RJ45 LAN, but the VM presents a
single Intel LAN, which isn’t configured by default. I run
dhclient em0after boot to get it working.
I don’t want to change the configuration on-disk, since I may want to start the (bare-metal) machine as FreeBSD as well. Dealing with weirdness is easier from within a VM.
As far as functionality goes: I can NFS-mount
/usr/src from elsewhere
in my home network – this goes out through the VM’s
em0, over the
host system’s WiFI to a FreeBSD-based NFS server – and build world.
Works like a charm. I have not yet sat down to figure out things
like X (or Wayland) inside the VM; Wayland on bare metal is similarly
an issue to be dealt with. Dealing with weirdness is easier when you
also have a working graphical display and a web browser,
so the VM approach has value here, too.
Takeaway: VirtualBox raw disk access can be used to do amazingly dangerous things to your drive, but also to do cool tricks.