How to create bare-metal boot drive using VirtualBox

[Laugh2]

Hi,
I would like to upgrade my main boot drive from LM to the latest version of LM. So I can continue working with the current boot drive until the new drive is ready, I'd like to create, configure, and populate the new drive with data all within VirtualBox. Then finally when the new boot drive is finished then use it to boot from bare-metal i.e. no longer inside a VM.

Since I had already started the process by creating the new boot bare-metal, I'd now like to create a new VM, boot the new VM with this new boot drive, configure and populate it, all before booting bare-metal again from the new drive.

(Of course, if successful, there's still the issue that moving from a VM to bare-metal requires LM to adjust for different drivers, etc. Since modern OSs can be pretty resilient in this respect, hopefully LM will boot into the new environment OK then request updates. Finally the graphics driver will be changed from nouveau to nVidia.)

I found a few related posts:

• Booting from internal drive: https://www.reddit.com/r/virtualbox/com ... h_windows/
  Booting from USB: https://www.reddit.com/r/virtualbox/com ... usb_drive/
  Booting from USB: https://www.howtogeek.com/187721/how-to ... irtualbox/

The first one most closely describes my case except that I have the latest LM on the new drive. So I set about modifying the CLI command for my purposes to:

Code: Select all

VBoxManage internalcommands createrawvmdk -filename test.vdi -rawdisk /dev/sda

Since "internalcommands createrawvmdk" has been deprecated I modified it further to:

Code: Select all

VBoxManage createmedium disk --filename=test.vdi --variant RawDisk --property-file name=/dev/sda

which seems to be correct in most respects but returns the following error message:

Code: Select all

VBoxManage: error: Cannot open replacement value file '/dev/sda': VERR_ACCESS_DENIED

Which presumably means that I somehow have to include username and password into the command.

Can anyone shed light on how I should proceed from here, please?

System - Host
Linux Mint 20 Ulyana 64-bit
MATE 1.24.0
VirtualBox Version 7.0.14 r161095 (Qt5.12.8 )

System - Guest (intended) i.e. the new system
same hardware
Linux Mint 21.3 Virginia 64-bit
MATE

[Laugh2]

I've come a bit further using the solution suggested here:

Code: Select all

https://unix.stackexchange.com/questions/284704/verr-access-denied-when-trying-to-add-a-raw-disk-to-virtual-box

. In short, I executed the following two commands in a terminal then rebooted:

Code: Select all

sudo usermod -a -G disk $USER

sudo usermod -a -G vboxusers $USER

Now when I try the following command:

Code: Select all

VBoxManage createmedium disk --filename=test.vdi --variant RawDisk --property-file name=/dev/sda

I get the following error message:

Code: Select all

VBoxManage: error: Replacement value file '/dev/sda' is to big: 465.7GiB, max 16MiB

Although not the same thing, there are some comments on these posts (which are a bit older now) which might be relevant:
https://forums.virtualbox.org/viewtopic.php?p=336004
https://forums.virtualbox.org/viewtopic.php?t=12907

Is this an insurmountable error? Does VBox and/or raw access have a fixed limit of 16MiB?

[ntrcessor]

No. However, 16MB may be the available "freespace" on /dev/sda
Even as root you would have to use some sort of force option with any tool to overwrite the drive structure/partitions.
And typically, I would probably convert to an img file if possible then just use ddrescue to do the copy.
Also sda cannot be in use. You would have to boot off of an live image or something and the image file you are copying from cannot reside on sda as you would be overwriting the source so to speak.

This is just a best guess as the info you've given on the where's of the image you are copying from reside in relation to your target, and whether you are booted from said target.

(I mention this, as this is how I ended up having /dev/sdd as my current boot device, as the original drive I had refused to work on any other sata slot except the sda one, and once I xferred to the new drive, it refused to work in the sda slot for booting. I later figured out how to use UUID's and can now move things around, which is good as sometimes power hits cause the motherboard to re-enumerate my slots, and sata1 becomes sata3, and and sata0 becomes sata2. )

[Laugh2]

Disks states that there is 1.1MB of Free Space. Perhaps VBoxManage includes the SSD's (sda's) buffering space in its estimate of 16MB? Also, I am booting from a different SSD (sdc) so there isn't a risk of overwriting the active system.

Would it be easier if the target SSD (sda) is empty and I start off by installing LM21.3 onto an empty SSD instead of trying to mount the newly installed system in the VM with the goal of finishing the configuration and migration to the new boot disk??

[linux-rox]

Raw disk doesn't know anything about size. It's a pass through. I think the problem is your form of command. Here's what the VBox manual suggests:

Code: Select all

VBoxManage createmedium disk --filename=/path/to/rawdisk.vmdk --variant=RawDisk --format=VMDK --property RawDrive=/dev/sda

I modify rawdisk.vmdk to sdb.vmdk and make a conforming change for the last field. Be aware, each raw disk file is tethered to the device ID in use when it was created; there's no mechanism for creating one tethered to a UUID or file system label.

Will say, I think raw disk is a poorly suited to your plan. An OS run from raw disk doesn't have guest additions (nor do you want them, if the end game is to run on bare metal). Also, you're limited to BIOS boot; VBox has an EFI mode, but it doesn't work when booting from raw disk (used to).

Rather than try to ride two horses at the same time, install 21.3 and be done with it. You can keep LM20 as a fall-back, of course.

[Laugh2]

Thank you. I've installed LM21.3 the normal way i.e. directly bare-metal. LM20 is still usable on the other HHD.

I'd still be interesting in a method to install a system via VM (or other means) while the destination computer is continuing its normal operation. Perhaps it would work better via USB?

[linux-rox]

Perhaps it would work better via USB?

Don't think it matters, i.e., raw disk shouldn't care. OTOH, raw disk isn't needed to install to USB drive. You can boot a live session from ISO (as virtual CD), attach target from Devices menu (notably, this function doesn't require guest additions), and install to it that way. The drive will boot on bare metal. Where you would need raw disk is to boot post-installation in VBox, which I do sometimes for running updates in background. Indeed, that's why I learned raw disk. For this to work, though, the drive must be hybrid boot; as mentioned, VBox only will boot it in BIOS mode.

[rickNS]

I'd still be interesting in a method to install a system via VM (or other means) while the destination computer is continuing its normal operation. Perhaps it would work better via USB?

I've done this a different way, without Vbox commands.
1, install Mint into a VM, give it a 25 GB disk
2, install all your extra software, and make any customizations you like.
Include in your extra software Systemback from here https://github.com/MaranBr/Systemback.
Click the code button, and download the .zip, unpack it in it's own folder, and run the commands on the github page to install
3, start systemback and select "Live System Create"
put a check in "include user data files" that keeps your customizations. Name the live system, click "create new" it takes 10-15 minutes.
4, when done you can burn the sblive (or .iso) file to USB stick, and use that to install to bare metal.

One note, upon booting the live USB if it hangs with some "cow" error, just press Ctrl + D

[Laugh2]

Thank you, rickNS,
I will try this next time. This time around I followed the "normal" method of replacing the system disk with a fresh disk and installed the fresh system onto it. The machine was effectively off line for about 36 hours since I couldn't devote myself fully to it.