Trying to install Qubes 4.2 on KGPE D16 cause sudden reboot

Hello Qubes users,

First time on the forum but few years Qubes user too and happy with it

I have spend the last days and much hours to try install Qubes 4.2 on a KGPE D16 server rack, but I can’t achieve this because I think the installer seams to crash and cause the system sudently reboot

Now I start to reach out of of ideas
I have re-download, re-verify signatures, re-check hash after move the iso with DD on two usb key (one of 8gb and one of 16gb)
This is the orginal BIOS with corrects parameters for Qubes
I have already install Qubes, maybe 4.1 on this machine and it worked like a charm
Debian has just been installed for test hardware without any problem
In doubt every pcie card (including pike2008 hardware raid) has been removed appart a RX590 graphic card
The installer reboot the machine mostly at the stage where there is the gui and the installation begin, but sometimes it randomly do that before
When GRUB is starting there are two errors (efi_gop.mod and efi_gop.mod), I can’t remember if I already have these errors in the past but I have read we can ignore them
The problem is the same with install with the newest kernel
Tested with a monitor connect trought HDMI and with an HDMI-to-VGA connector

Any ideas ?
How can I view some logs ?
I have thinked about the bios mode or uefi mode ?
Maybe the monitor is faulty ?

I will continue some attemps with only single CPU, or with a Libreboot chip

If some people want to help me I can give more details about hardware or config, give thanks in advance

2 Likes

The KGPE-16 is not supported any longer, the CPUs are not compatible with recent CPU security patches.

https://github.com/QubesOS/qubes-issues/issues/9150
The comments in that thread has more details.

3 Likes

Thank you for your fast reply, despite the disappointing conclusion.

I haven’t found that while doing my research

This effectively happened on KGPE-D16 with Opteron 6282 SE

I have do a lot of work and spend much money for this board and this rack… When I have started she was compatible and famous

Some quotes that have my agree from your Github issue link:

“This is a really unfortunate situation as the KGPE-D16 is the most powerful, binary blob free (when used with Libreboot, old Coreboot, or Dasharo) system that supports Qubes.”

“this system is all we got if you want Qubes on blob free firmware.”

“This is pretty old system, it may be that recent workaround for speculative-execution bugs made it significantly slower.”

“there is not much hope for this old-ish system…”

“blame AMD for making buggy CPU, and replace with something newer”

I will search if with family 15th CPU it can work or not
If not have you another mother board to recommand ?
the issue is only affecting Xen, so if someone want to use this board with an other os there is no security problem ?

2 Likes

This is the first time stetessi has posted — let’s welcome them to our community!

Welcome @stetessi
Much thanks for post!

If know, what are current “corrects parameters” for D16? Is spec-ctrl=no-ibpb-entry seen in No Qubes/VMs starting - libxenlight failed to create new-domain in 4.2.1 · Issue #9150 · QubesOS/qubes-issues · GitHub workaround? If test “family 15th CPU” please please post findings.

Hi again @renehoj always appreciate you share knowledge. When KGPE-16 become unsupported by Qubes are we back to "AMD appears to lack sufficient testing...and may harbor latent bugs" - Trail of Bits SecureDrop Workstation Review

Echo:

Very sad :sob: Know no answer :cry:

Any other BMC hardware removable or absent Qubes compatible boards still available? Anyone?

@Insurgo @mike_banon etc etc

1 Like

By “corrects parameters” I mean enable IOMMU, disable Onboard VGA, things like that

I can’t test family 15th CPU because I haven’t anyone and don’t want to spend more money for that, this board end up to be a Debian server

1 Like

Understand.

Best, stay safe, and good luck!

1 Like

Thank you !

you think it’s safe to use this board for virtualisation with KVM ?

1 Like

Sadly I know not. I have two of those d16 boards and presently only run them air-gaped or not at all. Truly hoping @Insurgo @mike_banon @miczyg or others will weigh in here. I think you got it very right when you quoted tonux

From my understanding the Qubes team is not likely responsible for this. Seems to be a XEN issue IIUC. Maybe the experts will visit this thread and clarify. @marmarek “blame AMD for making buggy CPU, and replace with something newer” seems like an insufficient “pass the buck” answer to me. Strangely the INTEL x230 from the same era has gotten a lot more mitigations from Qubes and even remains Qubes certified hardware. I think @Justin was prescient in "AMD appears to lack sufficient testing...and may harbor latent bugs" - Trail of Bits SecureDrop Workstation Review Wonder what @tasket would make of the situation today.

Really trying here @stetessi to bring some attention to this. Best!

1 Like

The short version to this is that qubesos (Xen) speculation must be turned off (don’t remember which one parameter, reported by tonux under qubesos issue for d16) or otherwise extending qubes timeout in qvm-prefs accordingly (but still meaning things became really slower at some point).

Nothing much more I can say here that was not already been said.

Rings a bell.

I do not use nor maintain the d16 under Heads for a really long while, having been alone testing it and maintaining it for a really long while and feeling lonely doing so.

Note that turning off speculation mitigation will make things work, while exposing qubes and dom0 to those speculative vulns.

If that’s a deal breaker for you (it is for me, added to lack of responsive testers for the past years etc etc etc), I slowly reduced my caring for that platform to the point I don’t care at all anymore. That is, caring more then technical users who should have been able to put that board back to tested, talking to FSF, making the fork work while being stable and merging patches from now 3 different coreboot forks branches we currently have for that platform with nobody agreeing on what should be used either and nobody really pasting result publicly to foster proper, and expected, collaboration.

There is a club, though, where everyone here being interested in this platform should be in, and that is this fam15h /d16 club matrix room.

Sorry folks. Maybe @miczyg or @mike_banon will have more hopefull answers to give. On my side I stopped hoping/fighting for that platform. Even the FSF, depending on that blobless platform, didn’t really fought for it or not enough when it was required, even if RYF certified. Vikings didn’t pay for the porting effort when it was the time. Current forks we have have different problems. There is this fork that is interesting, but I would say: your turn people.

Follow this rabbit and start collaborating where it matters 15h.org

Sorry for the tone, I cannot count the number of hours I invested promoting this platform before it got dropped by coreboot 4.12. I’m a bit sour on the d16 subject.

2 Likes

Sorry to bother.

Appreciate important note!

Sad you have given up on the KGPE-D16 but completely understood.

No need to be sorry. I really really applaud all you have done over many years for this board. IMO you have gone above and beyond and I (and countless silent others are eternally grateful). Sorry if pinging you in this thread pushed salt in old wounds :frowning_face:

Luv your effforts, work, and countless contributions to open source security!

THANK YOU!

2 Likes

i could not get the 4.2.3 installer to crash on my kgpe-d16 running the 15h.org bios if you want to try installing qubes again in the future you can find me in the 15h.org matrix room i would be happy to try and help getting your board running with qubes

3 Likes

Okay ! thanks for your interest, I can only try in few weeks because now I haven’t the possiblity
What about the usabilty of the system after install ?
it’s the first time I ear about this BIOS

1 Like

I created a wiki entry about it QubesOS - 15h.org

tldr; should work with slight performance and security decrease (when compared to before the exploit was known)
@Tonux have reported issues like non smooth browser scrolling when the system is under heavy load

performance hit depends on your system specifications so if your running 6300 cpus you might not have the same issue as tonux

2 Likes