I recently acquired an HP ProDesk 600 G1 (i7). While the official Sculpt 25.10 image runs perfectly on this hardware, I am encountering issues with my own custom builds.
Specifically, any example I build myself using version 25.05 fails to run; the system freezes at the logo screen. Additionally, I am not receiving any serial output, even though the serial port is correctly assigned to the COM (9 pin) port and works fine when tested in qemu.
What could be causing this discrepancy between the official release and my custom build, and why is the serial output missing on physical hardware?
If you want to see serial log output, when building Sculpt OS, you need to state LOG=core in the environment of your make command, e.g.: make run/sculpt KERNEL=nova BOARD=pc LOG=core
Maybe you should start with a more simple run-script to test your debug setup, like: make run/log KERNEL=nova BOARD=pc
Well, there are plenty of potential reasons, if you compare official Sculpt OS release 25.10, with self-built Sculpt OS using Genode release 25.05. Five month development time in between . But seriously, Genode releases are not necessarily tested with respect to the Sculpt OS scenario. We do test a lot of things (look at the tool/autopilot.list file in genode’s repository for reference) automated on a nightly base, but we cannot afford to do the time-heavy testing of Sculpt OS on all available platforms (multiple PC, Pinephone, MNT Reform) when releasing the Genode framework every 3 month. This is part of the semi-annual Sculpt OS release!
Anyway, it might be that it is not a problem of the code-base, but more an issue regarding your concrete build. What about if you build Sculpt yourself using the sculpt_25.10.1 revision of Genode’s git repository? Do you experience the same problems?
make -C build/x86_64/ BOARD=pc KERNEL=nova LOG=core run/sculpt
make -C build/x86_64/ BOARD=pc KERNEL=nova LOG=core run/sculpt_test
As I mentioned, I do get serial output in QEMU, but not on the target hardware.
I even considered the possibility that a high-priority module might be causing a conflict before the serial output initializes. To investigate this, I tested the demo run-script and several other basic scenarios, ensuring serial output was enabled for all of them.
However, the results are identical across all tests: everything works and provides serial logs in QEMU, but on the actual hardware, there is no video output (it hangs at the Genode splash screen) and no serial output whatsoever.
In the meantime, I have obtained versions 25.10 and 25.11 and am currently building and testing them. Hopefully, those “five months of development” have some magic in them to fix my serial port!
I have also downloaded versions 25.11 and 25.10. I built both of them using the following command:
make -C build/x86_64/ BOARD=pc KERNEL=nova LOG=core run/sculpt
Then, using dd, I wrote the generated .img file to a USB drive. However, during boot, the system gets stuck at the Genode boot splash screen, and there is no serial output.
Meanwhile, when I run Sculpt 25.10 that I downloaded from the official repository using the same setup, it works without any issues. However, it still does not provide serial output, which I actually need.
It is worth mentioning that the image built with the command above works correctly in QEMU and does provide serial output.
Just to be on the same page - you already verified by other means that the COM port is working properly in general?
As bender will pick any serial device it finds, if multiple are available, e.g. AMT is enabled and there is also an onboard or external (PCIe) COM device, it could select one you might not expect.
As a test you could mount the USB drive containing the original Sculpt 25.10 image that boots on your machine and add serial as argument for bender in the grub.cfg:
multiboot2 /boot/bender serial …
That should give you the initial log messages from bender, nova and core on the serial connection.
Yes, I tested the COM port using a Linux-to-Linux serial connection, and it worked without any issues.
On the other hand, I checked the configuration of the image that does not boot, and it is as follows:
loadfont /boot/font.pf2
set timeout=0
set gfxpayload=auto
menuentry 'Genode on NOVA' {
insmod multiboot2
insmod gzio
multiboot2 /boot/bender serial intel_hwp_performance
module2 /boot/hypervisor hypervisor iommu_intel iommu_amd serial logmem
module2 /boot/image.elf.gz image.elf
}
This matches your instructions (and it is actually set automatically). Even though there is only a single serial port and I am confident about that, I still tested the following case as well:
serial iobase=0x2f8
In the BIOS, I also verified that the serial port base address is set to 0x3f8.
Additionally, I modified the working version (Sculpt 25.10) in the same way, but I still do not get any serial output.
Note: For testing, I also booted a Linux system and modified its GRUB configuration as follows. The serial output is displayed correctly, and the connection works on both sides:
Thank you for taking the time to describe your testing efforts (I assumed you already took care in that regard but it’s better to have that in writing).
I am afraid I have no idea why that should not work - perhaps one of my colleagues has any inspiration.
That being said, one thing you could try would be to hard-code the serial port in core directly by changing serial_port() to return 0x3f8 (or whatever port is configured) in repos/base/include/spec/x86/bios_data_area.h (the driver implementation is in repos/base/include/drivers/uart/x86_pc.h). This will give you log message from core and the other components running on top and just check with run/log.
Thanks for the tip! Hard-coding the serial port worked perfectly. After changing the serial_port() return value to 0x3f8 in bios_data_area.h, I finally got the serial output.
Regarding the boot issue with my self-built image, it turned out to be a hardware-related bottleneck rather than a software or module error. I discovered that the two USB drives I was using for testing were extremely slow, which caused the boot process to hang or fail. After switching to a higher-quality USB drive, everything is working flawlessly, both the system boot and the serial logs.
. But seriously, Genode releases are not necessarily tested with respect to the Sculpt OS scenario. We do test a lot of things (look at the 