My computer is set to uefi boot
I am using gnome-boxes which can only do legacy boot
When I try to install Debian in gnome-boxes, it fails to write grub to the virtual disk
In a normal hard disk install of Debian, if you boot the installer in uefi mode, it installs grub in efi mode
and
if you boot the installer in legacy mode, it installs grub in the MBR.
but
what happens in a VM?
Where does the Debian installer get its information about what mode to write grub in?
and
How can I force a Debian VM install to write grub in a way that is compatable with gnome-boxes?
The issue is only with Debian installer. Other Debian derivatives, eg Antix, install with no problem in gnome-boxes.
Sounds like you are in need of a /boot partition for Debian and create and use lsblk and mount your partitions in gnome-boxes before trying to install Debian.
Why a /boot partition?
Will try, I cant think of anything else
I tried leaving some unused space at beginning of disk
I tried making an EFI partition
I did not try making a bios-grub partition, because that is only for gpt disks… boxes definitely makes an msdos partition table, not gpt… it asks if partitions are to be primary or logical.
Boxes cant do that. I have to do it in the installer. The root partition is definitely mounted, and the installer copies all the system files in properly… it then fails to write grub
Do you know if a VM has its own virtial BIOS which might differ from the hardware BIOS?
I suspect the Debian installer is looking at the hardware BIOS rather than the virtual BIOS?
I found this
"I prefer to use Boxes, but it’s missing an absolutely essential feature that makes it almost impossible to use. When you first create a virtual machine with a new ISO image, you can select EFI boot, but if I create a new virtual machine with the same ISO then you can’t and it defaults to legacy BIOS, which means it will never boot and installation always fails. It literally doesn’t even give you the option to enable EFI if you’ve already created a virtual machine with that same ISO file. "
It came from here
Looks like it is a bug in Boxes.
I did have a previous Debian guest in Boxes. Wondered why
I could not repeat the install
It looks like the Debian installer insists on EFI mode.?
That is why I use VirtualBox, it does not care whether you boot your PC with UEFI or BIOS. You just use gparted and do a msdos with the virtualbox disk and it will usually boot.
Yeah, virt-manager and virtualbox have no issue with boot mode or partition table type.
Unfortunately gnome-boxes seems to be rather restricted , if not faulty. That is a shame, it is a nice easy user interface.
I switched frim Debian to Devuan. It has the Refracta installer
which drops you into gparted . I made a msdos partition table, made 2 partitions for / and swap, then let it install.
It completed the install, but when I rebooted it would not boot.
So, same as Debian, no grub written
Then I went to Antix… it is Arch based. It installed in Boxes
quite smoothly, and rebooted properly… so no problem there.
Summary:
In Boxes … I cant install Debian or Devuan
but
I can install Antix and Artix.
Now, Antix is Debian based… so it has to be an installer problem, or because Debian and Devuan are larger… I allowed 50Gb, surely that is enough.
In any case, it is to do with failing to write grub, for whatever reason.
This is not a solution, but it is an understanding of the problem.
I had another try at Devuan.
When it put me into Gparted, I made
msdos partition table, made 2 partitions for / and swap,
as previously,
but I left 1Mb of unused space before the first partition.
Then , when I get to the install grub step , I tell it to
copy the grub config files to /dev/sda1
install grub on the MBR of /sda
It works, I can reboot, and Devuan boots inside Boxes.
So the trick is to leave space at the start of the virtual disk for the MBR
but
why was that not necessary in Antix or Artix?
and why did that space at the beginning not work in Debian?.. perhaps I did it wrong … Debian does not use Gparted, so it is hard to see what you are doing.
Yes.
I think the solution is that I need a boot flag
but
a boot flag on / is enough
What you say will work, but there does not have to be a separate /boot partition… I just need the flag.
Lots of experiments… I now have a successful Debian install in Boxes… with a boot flag on /.
but
I dont understand why Devuan needed that unused space at the beginning of the disk… that should not be needed… gparted should leave the first sector alone, even on a virtual disk. I want to retry with Devuan.
Yes I know that but the proper way to install linux is with a /boot partition on a msdos drive just like a fat32 partition is needed for a gpt drive. All of this is because linux is trying to be like Windows.
It would seem Windows bootloader needs a boot flag,
Grub does not need a boot flag,
but some BIOS’s check for a boot flag and will not proceed if it is absent.
so maybe, the virtual BIOS in gnome-boxes is checking for a boot flag and stopping the grub install, or stopping grub from booting, if there is no boot flag.
Yes it probably is, but also /boot will store the vmlinuz and the initramfs and with the boot flag on /boot and it will then boot the / partition. I have used a VM, with and without a /boot, but that had more to do with, i just was to lazy to create a /boot.
Where does the boot flag go then?
on / or on the bios-grub partition?
Apparently , one good reason for having /boot on a separate
partition is if the system files are encrypted.
The boot process cant handle encrypted files.
I marked your boot flag reply as solution
Thanks, that is the problem… Boxes needs it because it uses legacy boot and some installers do not provide it.
Not sure why putting some free space at front of disk in Devuan was a workaround?
Not sure if that is a gnome-boxes issue or a gparted bug. I find it does some of my VM drives with some unallaocated space, some at the front-end and some on the back-end. I am sure it has something to do with and how partition are created and placed.