Any tips for running omnios on linux kvm? Looks like it starts loading the kernel then hard resets.

This is both off the installer iso and the qcow2 image.

Can you turn on the kernel debugger (kmdb) from the loader menu and see if reports more information when it resets?

Yeah lemme see what it says.

I can't remember the exact path but it's something like Boot Options -> KMDB

Yeah, it was 5 (boot options) -> 7 (kmdb mode).

Looks like its throwing "Bad kernel fault at addr=0xfffffe0b8b006370" I'm not totally sure what I'm doing here though.

Looking through the stack trace on screen, it went main+36 -> startup+5a -> real_mode_stop_cpu_stage2_end+7221

And then into a bcopy, which threw a trap.

Can you paste the output of the `::status` and `$C` commands somewhere? (paste.omnios.org is one option)

or use boot -k ;)

We'd definitely expect this to work so would like to fix whatever's going on.

Yeah, lemme transcribe it from the framebuffer real quick. ::status only returns a few lines, the last of which is "stopped on: debugger entry trap".

Okay, um. What boot options do I need to get kmdb over on the serial port?

"text" option is vga. yep.

Boot options, Os Console = ttya should work

Looks like it was caused by a page fault?

I'm gonna read up on kmdb rq, see what other info I can get outta this. It may entirely be an issue with the virtual hardware setup, but if so, I don't know what exactly.

Can you do `$C -v` to get the function arguments?

It produces the same output.

Ah right, that makes sense as `$C` is already verbose (unlike `$c`)

Would you like my virtual machine manifest? See if I have anything configured incorrectly compared to what's expected? I'm having a hard time finding examples of known good configurations.

So it's a page fault in "repz movsq (%rsi),(%rdi)" where rsi is fffffe0b8b006370 and rdi is fffffe0bd2bf4000, and rsi was the responsible address.

I got the instruction from `bcopy_ck_size+0xea::dis`

I see. Is there something I can do about this? Or...? I'm not sure what rsi is supposed to represent here?

You're somewhere in `startup_end()` but I don't know exactly where.

Try `fffffe0b8b006370::whatis`

I don't know much about KVM but it's worth sharing the manifest in case somebody here has an idea, or can replicate and dig into it.

I've booted omnios under KVM on omnios before, and under qemu, but not on Linux.

and the omnios KVM is old now

Alright, give me a second, and I'll get a new paste thrown together.

I have to step away. Back around later.

No worries. I also have to for a bit.

paste.sr.ht/~spicywolf/9de59e7b8f15a6aac8ac778682e5606438699c04 this is the kvm manifest, as well as the combined outputs from before and the ::whatis on that address.

So the disassembly of address fffffffffb864ffa produces "testq %rax,%rax", but that... can't possibly be right. It is immediately preceeded by a call to smbios_open, but wouldn't the stack trace actually show that? Whatever's going on, it looks like it is trying to iterate over devices. That address 0xfffffe0b8b006370::whatis shows that its an allocation from the device vmem arena. I don't know, I definitely don't understand the boot proc

ess well enough for this, and I'm probably going to have to brush up really well with mdb to competently help debug this.

I'm going to kill the vm for now.

spicywolf: scanning through your manifest the i440fx chipset seems to be quite old (wikipedia says it dates back to P3 times), Trying to create a new VM I get the options for i440fx and Q35 chipsets, I wonder if using Q35 might work better

I was trying to compare the XML with a Linux VM I've got on a Fedora host here (I don't think I've tried OmniOS in a VM for a long time)

the other quick difference I've seen is my CD-ROM device shows <target dev="sda" bus="sata"/> compared to yours using hda and ide

I wasn't aware of what CPU options were available. I'll give these changes a try. honestly I think a lot of options are hidden behind that libosinfo.

I think you get a bunch of defaults based on what OS it selects at the start - I'm not sure how that's defined.

I don't know if that's the actual problem, just a couple of obvious differences I could see quickly

ugh. kernel panic in smbsrv due to a null pointer dereference.

I'm supposed to be on vacation!

I'm doing a savecore -f /dev/zvol/dsk/rpool/dump and it isn't giving any errors so I presume it survived the host coming back up multiuser.