Fujitsu/Kontron D3644 => issues installing OMV 6.5

tullsta · 12. Oktober 2023

Hello,

I'm trying to build a 2nd OMV-based server with the following HW configuration:

- Kontron (Fuijitsu) D3644-B with latest BIOS (1.28 - AMI-based)

- Intel i7-9700K

- 1x 16 GB RAM (compatible with motherboard)

- 256 GB Samsung SSD (also listed on the compatibility list)

Kontron HW diagnosis reports all fine

memtest86+ V10.6 reports after 4h all fine

Nevertheless, at the moment I'm seeing (a lot of different) issues.

I can boot Grub and start OMV 6.5 installation (tried USB-stick and DVD), but the system reports rather soon (before the language selection) e.g.

- segfault Kernel panic CPU 2 PID 1 Comm init not tainted

- clocksource: Switched to clocksource tsc

- BUG: soft lockup - CPU#2 stuck for 22s! [klogd:222]

I tried replacing power supply, RAM modules as well asSDD w/o success.

Also tried a different motherboard (D3643 - same BIOS) with similar issues.

Does anyone have an idea how to further debug the system and/or does anyone know whether there are any BIOS-related settings that are required.

Thanks and kind regards - tullsta

crashtest · 13. Oktober 2023

If possible, it would be best to set BIOS to "Legacy BIOS" boot versus UEFI. This topic is covered in the following

Try this install method -> Alt 64bit Install
As noted in the doc, you'll want to download the AMD64 version of Debian's netinst CD

mischka · 13. Oktober 2023

Have you tried installing Debian with a nonfree firmware image (https://cdimage.debian.org/ima…-11.8.0-amd64-netinst.iso) of Debian 11.8.0? OMV is then installed via script (https://docs.openmediavault.or…stallation/on_debian.html)

tullsta · 13. Oktober 2023

Hello - thanks for your fast replies!

Unfortunately, the motherboard is UEFI only...

Regarding the suggested image: it shows the same/similar issues: getting to GRUB but then I get similar issues as described above.

trying further...

Kind regards - tullsta

mischka · 14. Oktober 2023

The board is for Intel CPU of the 8th/9th generation and should have no problems with OMV/Debian 11. You have probably already reset or deleted BIOS settings (via jumper or temporarily remove battery). I would test if the computer boots with a Linux Live system (Live USB stick). You don't have to install anything. I would test this with various Linux Live systems (Ubuntu, Manjaro, Debian) on a USB stick. If there are also problems, I think the board has a hardware problem (e.g. SATA controller) or the CPU is defective. You could also try installing OMV on a USB drive. I have here a Fujitsu Esprimo Q558 running a D3603 board with Proxmox. This works perfectly. Of course, it's different from your board.

tullsta · 14. Oktober 2023

Hello,

thanks again - I've tried a Linux LIve system, but also there no real improvement.

However, I played with the BIOS settings in the CPU section and after disabling (default enabled)

- Intel Virtualization Technology

- Intel VT-d (Intel Virtualization Technology for Directed I/O)

- Intel Software Guard Extensions (SGX)

I could install OMV 6.5 without any issues whatsoever.

To be honest, I do not have a clue why these changes mean in the context of OMV (and I have not tried yet which of the three are the essential ones), but maybe someone can explain what makes the difference here.

Thanks and kind regards - tullsta

chente · 14. Oktober 2023

Zitat von tullsta

- Intel Software Guard Extensions (SGX)

Possibly this made the difference. The other two should have no influence.

crashtest · 14. Oktober 2023

Zitat von tullsta

- Intel Software Guard Extensions (SGX)

Zitat von chente

Possibly this made the difference. The other two should have no influence.

I agree. While I've built a limited number of MB's, I have yet to see any BIOS Virtualization setting cause a problem with OMV. Issues come in (in some cases) with UEFI where OS's are not "trusted" (like Linux) or software guards that block any bootable install.

tullsta , you might want to trying reenableing virtualization. There are some OMV plugins that can use it.

tullsta · 14. Oktober 2023

Hello - thanks for the explanations.

after re-enabling

- Intel Virtualization Technology

- Intel VT-d (Intel Virtualization Technology for Directed I/O)

the system booted properly (from installed SSD - did not boot from live stick).

after additionally re-enabling

- Intel Software Guard Extensions (SGX)

the system booted again properly (again from installed SSD).

=> can it be that this is an issue only when booting from USB and/or during install?

will try in the next days with life stick.

crashtest · 14. Oktober 2023

Zitat von tullsta

after additionally re-enabling
- Intel Software Guard Extensions (SGX)
the system booted again properly (again from installed SSD).

This "might" make sense. With OMV installed, SGX may be guarding the installed system as of when it's turned on. (But, from what I read on-line, SGX appears to be geared toward Windows 10)

chente · 15. Oktober 2023

It is difficult to decide the exact problem in this case, each manufacturer makes their own bios as they see fit. I can only say that there are protection systems in certain bios, especially modern ones, that prevent operating systems from being installed if they do not meet certain security conditions. This is a common custom frequently as time goes by. SGX is probably one of them. All that remains is to delve deeper into each specific case by thoroughly studying the manual for the motherboard in question.

crashtest · 15. Oktober 2023

Zitat von chente

It is difficult to decide the exact problem in this case, each manufacturer makes their own bios as they see fit. I can only say that there are protection systems in certain bios, especially modern ones, that prevent operating systems from being installed if they do not meet certain security conditions. This is a common custom frequently as time goes by. SGX is probably one of them.

For the reason highlighted abive, UEFI is a mess. Each OEM does what they want, the way they want to do, and since they have plenty of room for their code, the differences between implementations are substantial. Further, most OEM's either don't bother to document their UEFI implementations or they don't make their doc's available to the public. I'm NOT a fan.

Jetzt mitmachen!