Changes to EFI settings lost

[MSA]

Hello,

I am using version 5.1.8 r111374 (Qt5.6.1) on LinuxMint 17.2

I have set up a virtual machine guest and am trying to change the BIOS settings for that guest system, specifically the boot order settings and UEFI boot options.
When I am done with my changes and start booting the VM guest with the new settings, everything works fine. However, when I shut down and reboot the VM guest, all my changes are lost and I have to reconfigure everything.

How can I get my changes saved permanently for this guest system?

Thank you in advance!

[socratis]

You can't have "BIOS settings" and "UEFI boot options" in the same sentence, unless you say "BIOS settings have nothing to do with UEFI boot options".

Did you mean the "Boot options" in the VM settings, System, Motherboard? If they are changing after a reboot, are you sure you're not reverting to a previous snapshot?

If these settings are indeed what you're talking about, right-click on the VM, Show in (...), attach the .vbox file to your answer.

[MSA]

No, I am not talking about the "Settings" tabs.

I start the VM, then hit F2 right away.
This gets me into what I would call "the BIOS" on a "real" bare metal system.
I will keep calling it "BIOS" for now, because I have no idea what else to call it...

In this BIOS, I have the items "Boot Manager" and "Boot Maintenance Manager".
Under "Boot Maintenance Manager" > "Boot Options" > "Add Boot Option", I add an option for the grubx64.efi boot loader of my VM guest Linux system.
Then, under "Boot Maintenance Manager" > "Boot Options" > "Change Boot Order", I move the newly created item all the way up to the top.
I save with F10, then go back to the main Menu and verify that my changes are there, then boot my newly created EFI entry.
So far so good, things are going exactly like I want them to...

However, when I shut down the VM guest system, and then start it again and hit F2 again, going back into the "BIOS", all my changes from the previous session are gone.

[socratis]

You are talking about EFI settings, not BIOS settings. I went ahead and changed the titles of all previous posts so that we're not confusing future searchers.

EFI can be described as experimental at its best. In fact it is described exactly as such (in the manual and the tooltip if you hover over it). The settings from the EFI options are not saved. The answer, again, is in the manual, Ch. 3.12.2. But please read the whole Ch. 3.12 Alternative firmware (EFI), its only one page. Not too much going on

My best bet is that the "settings" in that EFI menu are just a skeleton of what could become one day a fully functional working option. Although I doubt it, because it's way harder to save settings from changes when you're in the guest to the host. My feeling is that the settings will be changed from the VBoxManage interface (as now) and the EFI settings interface will be a read-only one. Or a volatile one at its best.

[MSA]

Thanks for the pointer; so I guess I can not permanently change those boot options to use a different boot loader (grub) by default instead of using the windows one (my VM is set up as a dual boot Windows/LinuxMint environment).

However, I was able to achieve the same result by replacing the files /EFI/Boot/bootx64.efi and /Boot/bootx64.efi in the EFI partition with the grubx64.efi files .

[socratis]

However, I was able to achieve the same result by replacing the files /EFI/Boot/bootx64.efi and /Boot/bootx64.efi in the EFI partition with the grubx64.efi files .

Great!
You replaced them how by the way? Please share for future reference. And why? To be able to select at run time the OS to boot? Since you're at it, why a dual boot VM and not two VMs?

[MSA]

You replaced them how by the way?

I simply booted into linux, mounted the EFI partition (it's really just a fat32 partition, so any linux live cd or other linux system will mount it), then replaced the file with a mv command:

Code: Select all

mv EFI/ubuntu/grubx64.efi  EFI/Boot/bootx64.efi

And why? To be able to select at run time the OS to boot?

Correct. I had Windows and Ubuntu installed, and the VM would always boot the bootx64.efi, which would boot right into Windows , without me being able to boot into Ubuntu instead.
So I replaced the Windows Boot loader with the grub loader to be able to select which one to boot.

why a dual boot VM and not two VMs?

Well, that's a longer story, and it will probably go a bit off topic. It really is not just a standard VM, otherwise you would be right - just have two and be done worrying.
I have a working laptop with LinuxMint running fine on a regular HDD. I just added an additional disk (SSD) to that laptop, which will in the future host both Windows and LinuxMint OS as dual boot.
However, just setting up and configuring both systems in "bare metal mode" so to speak, would have meant that my laptop would be unusable during all this time and I would not be able to do any real work on it.
So instead, I had set up this VM with raw disk access to the new SSD. Then I installed both OSes in the VM, which was pointing to the physical SSD, while I was still able to use the exising OS to do work as usual.
Plus, I was able to run the new LinuxMint OS in the VM inside the old OS and do a side-by-side comparison of behaviour and configurations if anything weird would have popped up.

Now that everything is done, I just boot the laptop into the new OS on the SSD.

The same way, in the new LinuxMint OS, I could now also set up a raw disk access VM for the new Windows or for the old LinuxMint on the first HDD (this one will remain in the machine).
The ultimate goal is to have the new LinuxMint and Windows OS on the SSD run in parallel at the same time, one as physically booted host OS, the other as VM guest via raw disk/partition access; being able to chose either one as host or guest at any time. And also, to have both of them behave the exact same way no matter if they are running as host or guest inside the VM.

So when I am working in LinuxMint, I can just quickly kick off my regular Windows OS inside the VM, rather than having to save everything, shut down Linux, boot Windows, do what I need in Windows and then reboot back into Linux. And even though it's a guest inside the VM it is still my "real" Windows environment, not a second Windows VM that lives in some vmdi...

[socratis]

Thank you very much for the detailed explanation! A noble cause and very much on topic.

Two things that I'd like to draw your attention to:

• Be really, really careful not to start your host OS as a VM at the same time, i.e. boot Linux and run the Linux VM. Expect disasters. Major and catastrophic, measurable in the Richter scale. I'm not sure if you're going to be using the same VBOX files from a common partition, but if you don't, leave the host VM outside of the host OS VirtualBox configuration, just to avoid any accidents.
• Not sure how the OSes are going to react to the constant hardware changes, which BTW is something I've never seen anyone mentioning. Your VM is faced with definitely less memory and a different graphics card, at a minimum. That is if everything else (audio, HD controllers, network, USB, etc) match, otherwise, more differences are introduced. Especially with the Windows activation, I'm not sure how that thing is going to react.

Nicely done so far and keep us updated. I love those R&D projects...

[MSA]

leave the host VM outside of the host OS VirtualBox configuration

I understand the potential disaster you are talking about if the same OS is running in both modes at the same time by accident, but I am not sure I understand this specific part.
Do you mean if I have a windows VM config file and a Linux VM config file, put the Linux VM config file somewhere where it can not be accessed when the Linux OS is running as host (and the same for Windows)?
I guess that's a good idea.

Not sure how the OSes are going to react to the constant hardware changes, which BTW is something I've never seen anyone mentioning

There are posts about this and quite a few people have done it. You will most likely find related posts when you search for VirtualBox and "raw disk access".

I had expected Windows to be more problematic with the changing hardware thing, especially since I had older Windows versions completely unbootable after upgrading a CPU or swapping mainboards. But Windows 8.1 surprisingly has no (obvious) problems at all. Although, that windows installation is a plain vanilla installation so far, e.g. I have not yet installed the nVidia-specific graphics driver. But there might not be a reason for doing that, because I am not using the machine for gaming or other hard-core graphics work.
I also saw someone mentioning potential issues in Linux with the MAC address changing between physical and virtual mode, but have not experienced any problem related to this so far...

On the linux side, you need to be careful to specify the mount points in /etc/fstab correctly and in a scenario where both host and guest are Linux, make sure that they do not use the same swap partition (or any other partition for that matter).
That's probably easier to do when you have two completely separate disks rather than just partitions on the same disk.
Also, if you are using the "/dev/sdx" addressing syntax for filesystems in Linux's /etc/fstab rather than using UUID or LABEL; in the system that is running off of sdb2 in raw disk mode, you need to add a virtual disk (vmdi file) and configure the VM to have the virtual disk be disk1 (sda) so that the raw disk access disk will end up being sdb, like it would be when it is running in host mode.

[MSA]

Now I actually did run into a small problem:
Both my Linux and Windows systems are installed on sdb and are booted from the EFI partition on sdb1.
Now I am booting the Linux OS as host and running the Windows OS inside it as guest using raw disk access.
My partition layout is:
sdb1: EFI
sdb2: MS reserved
sdb3: Microsoft rescue tools
sdb4: Windows OS
sdb5-7 : Linux OS (swap / root / home)
So I give the Windows guest raw disk access to partitions 1-4 of sdb.

This works so far; but technically, both host and guest OS are using sdb1. Is this a problem (I know it is in theory, but I am really wondering about the practical side)? I know that the Linux host has sdb1 mounted, although it might never do any actual write operations. I know that the Windows guest needs sdb1, because if I change raw disk access from sdb1-sdb4 to sdb2-sdb4 only (taking away sdb1), it will no longer boot. But I don't know if Windows would ever write to it, or if it is just using it as read-only mount during boot. Like I said, I have been running Windows as guest like this a few times already, and the system still boots OK, so maybe having both host and guest accessing the EFI partition at the same time like this is not a much of a problem as accessing any of the other data or OS partitions would be...

Is there a way that I can restrict the raw disk access to sdb1 to read-only mode for the guest? I can not do this in the

Code: Select all

VBoxManage internalcommands createrawvmdk

command that creates the raw disk access vmdk file.
But I do need to chmod /dev/sdb[x] to 666 in order for raw disk access to work at all (by default it is 600). So I am wondering whether I can restrict the guest to read-only access to sdb1 by setting /dev/sdb1 to 644 instead of 666.
I tried doing this and the guest booted, but I am not sure if it is in fact restricted to read-only or not...

Any ideas?

[MSA]

Regarding the concurrent access to the EFI partition: since I was not able to reliably disable write access for the guest, I had actually tried the other way around and blocked the host from write-access by mounting it read-only.
This worked so far (almost 2 months). The only thing is that the partition needs to be remounted in RW mode before updating any grub packages, otherwise update will fail.

After the update, remount in RO mode again...