8.3 Cannot boot from CD Rom
-
@Andrew Thanks was this VM created using Xen Orchresta? I have been trying to do this from a newly installed machine with no XO on it. Creating a Debian VM from XO seems to work fine and is possible on systems that I have upgraded to 8.3
-
@escape222 Yes, using XO.
You can do a quick deploy of XOA as a bootstrap to build your own XO VM.
-
@olivierlambert I tried with with the template for Ubuntu and also with Debian 12.9. Still I am getting the same error in 8.3
I am trying to get this automated using Ansible so deploying via the Quick deploy is not an option and this is a tested script which used to work fine in 8.2
When i started failing in 8.3 is when i tried deploying manually.
I will try to see if I can reproduce this in a different HW configuration but maybe over the weekend.
-
@olivierlambert
After some digging around this seems to be an known issue with QEMU. As this is related to Apple, Not sure if this is the same issue that I am facing. But the symptoms are exactly the same(https://github.com/utmapp/UTM/issues/2333#issuecomment-786307182)
The solution atleast for Macbooks seem to be
*There is a race condition in QEMU's (emulated) USB device reset and OVMF enumerating the boot options. M1 macs are too fast and can enumerate the boot options before QEMU sets up the device. This race condition is why it occurs for some people and not others and also why it stops appearing if you enable debug logging.
Without thinking too hard how to prevent the race, the hack around is to have a 1 second wait between the device enumeration and boot option enumeration.*
-
@escape222 It looks like I found something which is preventing me from booting. When the HVM firmware mode is set to UEFI then this does not boot. But changing to BIOS mode the boot is successful and I can continue
Any suggestions on how this can be fixed?
-
Ping @stormi
I have no idea why UEFI boot doesn't work for you.
-
@olivierlambert After a bit of trial and error I think I found out why this was not working for me. There were two issues which I think was causing the issue.
(i) I had a local SR which was used for ISO storage. I deployed a Debian VM via XO (which had a bios firmware) and noticed that I was getting the same error when the OS was being installed. This ISO SR was created on a SSD which was with Advanced Format (4K). Even though XCP-ng allows the SR to be created it seems it is not able to read from the SR if it is with 4K format. The release note for 8.3 says it supports 4K via largeblock driver, but it seems it it is not for iso, So I moved the SR from a 4K disk to a legacy one and XO was able to create the VM and start install
(ii) The default Debian 12 template has Secureboot enabled by default along with UEFI. Since I had no reason for to enable Secureboot I had not enrolled the platform keys on the host. Once the VM is created from the template I disabled secureboot with the command
xe vm-param-set platform:secureboot=falseOnce this was done I was able to boot from the CD ROM.
If possible I have a couple of suggestions
When the SR is created using type ext it does not allow the SR to be created if the underlying disk is 4K format without specifying largeblock. But it allows the SR creation when the type is iso. Maybe it is possible to check the type of underlying storage before ISO SR creation?
Else it could be documented in this page Storage in XCP-ng with a clear warning not to create SRs in 4K storage. It looks like XCP-ng has not issues in installing itself in a 4K storage, but then the Guesttools will not work anymore as it gets installed in the 4K disk and the VM is not able to read it and gives and IO error
The template for Linux systems may be modified to not require Secureboot.
-
All of that makes sense then, thanks a lot for your feedback! Pinging @stormi so we can triage your input
-
@escape222 Every single UEFI VM I migrated from VMware using Xen Orchestra had Secure Boot enabled - except for the BIOS-configured VMs. I too had to disable Secure Boot to get them to boot. None of my VMs ever had Secure Boot enabled while they were on VMware, so I'm unsure where this came from unless it's a default somehow.
-
Reping @stormi
