Odd question, but is there a way to clone directly from code.illumos.org?

oooh. nvm I got it.

forgot my local username and my remote username were different. :P

hrm... building edkii (at least ovmf for starters) on smartos was suspiciously too easy

Is there some reason it shouldn't have worked?

it has it's own bespoke build system (possibly systems), which is often never a good sign for being cross platform beyond possibly some specific linux distros

Looking at its build instructions right now, and "how to develop with containers" being its own article definitely gives me the "very linux-centric" kind of vibe. You use Stuart?

no just build

Nice. Glad to know this works though. Maybe I can bap some uefi applications together via rust on smartos. Pretty sure the uefi target requires edk2.

for what? efi applications get passed the pointer to the system table

and it's going to just need rust-native definitions for all the protocols

(which I think uefi-rs already defines common ones)

but it won't be able to read the header files for that...

Not totally sure. Might not require edk2 and I've just got something mixed up somewhere.

[illumos-gate] 17541 Shutdown hang with smb_opipe_read calls blocked -- Gordon Ross <gwr⊙rc>

[illumos-gate] 17542 SMB: File ID problem with nested data sets -- Matt Barden <mbarden⊙rc>

"genunix: [ID 335743 kern.notice] BAD TRAP: type=e (#pf Page fault) rp=fffffcc26c379a40 addr=20 occurred in module "smbsrv" due to a NULL pointer dereference" - omnios problem. Anyone want any details?

I presume I should register this as an illumos problem, not an omnios one.

yeah

and if you can, save the crash dump (or at least, grab the stack trace)

that's assuming I can remember where to file said bug report.

crashdump has been saved. Happy to grab stack trace but I don't have my notes so I'd need guidance.

after the system restarts, it should save the file to probably /var/crash/$HOSTNAME

just got there :)

(the dumpadm command should show the path if unsure)

root@fs3:/var/crash# savecore -f /dev/zvol/dsk/rpool/dump

savecore: System dump time: Fri Aug 15 11:21:11 2025

savecore: Saving compressed system crash dump in /var/crash//vmdump.0

savecore: Decompress the crash dump with

'savecore -vf /var/crash//vmdump.0'

root@fs3:/var/crash# ls -l

total 18086459

-rw-r--r-- 1 root root 2 Aug 15 12:00 bounds

-rw-r--r-- 1 root root 1110 Aug 15 12:00 METRICS.csv

-rw-r--r-- 1 root root 11350835200 Aug 15 12:00 vmdump.0

I'll rename it.

you'll need to expand it (savecore -f vmdump.0 <dir to save>)

then you can do `mdb 0 -e '::stack'`

(if the files are vmcore.0 and unix.0)

waiting on the savecore expansion.

yeah, it's not the fastest thing...

smb2_durable_timers+0x83(fffffe23ee26ba80)

smb_server_timers+0x20(fffffe23ee26c110, fffffe23ee26ba80)

smb_thread_entry_point+0x8f(fffffe23ee26c110)

thread_start+0xb()

I'm creating a ticket and will put this in it as well. I presume I should attach the original dumpfile as well.

The original dump probably won't fit.

It's 10G compressed.

what part(s) should I include?

unix.0 is only 2M but would it be helpful at all?

Usually I would start with '::status', '$C', '::stacks' in general.

No, you need both to be useful. When someone digs further, they'll probably reach out to get the dump.

rmustacc, that's an mdb command, right?

Yeah.

I'm not a kernel dev (or a dev at all).

Is this what you mean?

root@fs3:/var/crash# mdb 0 -e ::status', '$C', '::stacks

debugging crash dump vmcore.0 (64-bit) from fs3

operating system: 5.11 omnios-r151046-4c557abec1d (i86pc)

build version: gfx-drm - heads/master-0-g77f745e

heads/r151046-0-g4c557abec1d

I didn't know -e took multiple lines.

image uuid: a5449e15-d832-4df4-88ff-05eec1c0eea2

panic message: BAD TRAP: type=e (#pf Page fault) rp=fffffcc26c379a40 addr=20 occurred in module "smbsrv" due to a NULL pointer dereference

dump content: kernel pages only

(curproc requested, but a kernel thread panicked)

I've pasted the output of both mdb commands in the ticket. Anything else I should include?

addr=20 is useful-ish. NULL pointer, but a fields 32 bytes (0x20) in.

i can ping gordon -- probably him or matt would be the most interested I suspect

Both are in the ticket yes. And the `::status` answers the question about which OmniOS revision (incl. illumos-omnios commit IIRC).

Yeah, GWR's your guy. GIVEN that it's an old OmniOS and I KNOW there have been smb/cifs fixes (including some recent ones) it'll perhaps be one of those now-fixed bugs.

I've also included the output of uname -a

huh? 151046? I swear I updated these hosts.

omnios-r151054e NR / 24.34G static 2025-06-24 09:17

That's .. very interesting.

all three of my prod hosts are still running 46 when they should be running 54. This is ... very much uncool.

bug filed

seems like you did everything but the reboot

nomad: were you the person with an x4500?

richlowe, I had a few thumpers but they went to surplus a year ago.

IIRC, there were 7 or so 4540s and one 4500 in the lot.

re: reboot - those hosts have been rebooted since the "pgrade"

I clearly missed a step and then clearly missed the critical "make sure it actually did what you thought it did" step.

so not cool.

the "R" is saying that's the be that'll be active next boot

oh, I misread

ignore me

Don't worry, I'm the one who *didn't notice* what OS version he was running. <sigh>

ok, I'm going back to the last day of my 'vacation'. I'll try to schedule patching time for these hosts. At the latest they'll be updated in mid-late September on the next regular patching day.