Is anyone able to build the latest Nixpkgs natively?
My build is failing during xgcc.

checking for suffix of object files... configure: error: in `/build/build/riscv64-unknown-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile

Oh so you are getting kernel logs even without setting console=....
One of the annoying things about systemd is that it doesn't log anything useful during boot.
Btw the console=... isn't really helping, even if it no longer prints warnings about backdoor.service, because it's still unable to send commands to the VM.

You could I guess try building the driverInteractive version of the test, then inside the interactive prompt run machine.shell_interact() to get a prompt (assuming this doesn't require the backdoor service, which it might).

It's also pretty slow.

I think that's because you're emulating RISC-V using binfmt emulation to run a riscv64-linux build of qEMU to run the test? That sounds to me like you have qEMU running under qEMU.

You could I guess try building the driverInteractive version of the test, then inside the interactive prompt run machine.shell_interact() to get a prompt (assuming this doesn't require the backdoor service, which it might).

I tried that, but I wasn't able to do anything:

• shell_interact(): same issues and doesn't give return a shell
• ssh backdoor: crashes the VM

It's also pretty slow.

I think that's because you're emulating RISC-V using binfmt emulation to run a riscv64-linux build of qEMU to run the test? That sounds to me like you have qEMU running under qEMU.

When I first read this comment, I thought so as well, but then it got me thinking: why not enable binfmt inside the test itself? So I commented out everything I previously made and did just that. Performance-wise, everything seemed ... fine, actually.

The test fails ofc, because the package wasn't installed. But then I noticed something interesting:

{
  # the package works when installed directly
  environment.systemPackages = [
    pkgs.pkgsCross.riscv64.felix86
  ];
}

Whereas:

{
  # enabling the module, I get the previous issue with `backdoor.service`
  programs.felix86.enable = true;
}

Investigating further, I tracked this back to the felix86 boot.binfmt.registrations. More importantly, the logs now actually print something useful:

machine # [    6.846377] systemd[1]: lastlog2-import.service: Failed to spawn executor: Exec format error
machine # [    6.852359] systemd[1]: lastlog2-import.service: Failed to spawn 'start' task: Exec format error
machine # [    6.857462] firewall-start[607]: /nix/store/qhsrmq9784wvy0la4nr62dhgrjwn93sv-firewall-start/bin/firewall-start: line 105: /nix/store/s657hsrj1cknm7c4cbi87f6w7f3mlv11-iptables-1.8.11/bin/iptables: cannot execute binary file: Exec format error

Then everything clicked: my system is x86_64-linux and I'm using binfmt to emulate risc64-linux, but the module also enables emulation in the other direction, after which chaos ensues.

I already suspected this would happen, but I'm glad to actually confirm it. In a way, this kinda means the module's binfmt registration is working and I can just disable it for now in the test.

You could I guess try building the driverInteractive version of the test, then inside the interactive prompt run machine.shell_interact() to get a prompt (assuming this doesn't require the backdoor service, which it might).

I tried that, but I wasn't able to do anything:

• shell_interact(): same issues and doesn't return a shell
• ssh backdoor: crashes the VM

It's also pretty slow.

I think that's because you're emulating RISC-V using binfmt emulation to run a riscv64-linux build of qEMU to run the test? That sounds to me like you have qEMU running under qEMU.

When I first read this comment, I thought so as well, but then it got me thinking: why not enable binfmt inside the test itself? So I commented out everything I previously made and did just that. Performance-wise, everything seemed ... fine, actually.

The test fails ofc, because the package wasn't installed. But then I noticed something interesting:

{
  # the package works when installed directly
  environment.systemPackages = [
    pkgs.pkgsCross.riscv64.felix86
  ];
}

Whereas:

{
  # enabling the module, I get the previous issue with `backdoor.service`
  programs.felix86.enable = true;
}

Investigating further, I tracked this back to the felix86 boot.binfmt.registrations. More importantly, the logs now actually print something useful:

machine # [    6.846377] systemd[1]: lastlog2-import.service: Failed to spawn executor: Exec format error
machine # [    6.852359] systemd[1]: lastlog2-import.service: Failed to spawn 'start' task: Exec format error
machine # [    6.857462] firewall-start[607]: /nix/store/qhsrmq9784wvy0la4nr62dhgrjwn93sv-firewall-start/bin/firewall-start: line 105: /nix/store/s657hsrj1cknm7c4cbi87f6w7f3mlv11-iptables-1.8.11/bin/iptables: cannot execute binary file: Exec format error

Then everything clicked: my system is x86_64-linux and I'm using binfmt to emulate risc64-linux, but the module also enables emulation in the other direction, after which chaos ensues.

I already suspected this would happen, but I'm glad to actually confirm it. In a way, this kinda means the module's binfmt registration is working and I can just disable it for now in the test.