offtopic, does anyone have payed job for illumos based system administration?

did we somehow reintroduce illumos.org/issues/12895 ?

→ BUG 12895: zfs_onexit_fd_hold fails to release non-zfs fds (Closed) | code.illumos.org/c/illumos-gate/+/773

just got the exact same panic after onu'ing to debug bits

Woodstock: I haven't seen it. Probably best to open a fresh bug with your stack trace and details about the system and what you were doing before the panic.

Hi, we have a N100M system ( download.asrock.com/Manual/N100M.pdf ) here that fails to boot (or display things). After the loader "Booting..." line it just prints "_" and is stuck. No SunOS line or anything, even with kmdb enabled.

up.frubar.net/4676/IMG_2132.mov <- any ideas on how to debug this?

hmm maybe that warning is relevant: up.frubar.net/4677/IMG_2133.jpg

So the banner happens spiritually later than we'd like. I think the thing I'd want to do is get a custom build that enabled kbm_debug or set that in the boot properties.

(I would veryify the loader method of setting kbm_debug first).

That will basically tell you whether or not you entered _start() which is what dboot calls or not.

That will basically help us bifurcate the search. Did we get through dboot or not.

oki thx, we'll try that

I would test it on another system first just to make sure you have the right syntax or if you're building your own stuff just change the variable to default to 1.

did "set kbm_debug=1" in the loader prompt but that looks the same. Will try with a custom debug build

while the build is going we tested the freebsd loader. With that the framebuffer address is detected as 4000000000 and size 1d4c00 instead of both 0 in ours: up.frubar.net/4678/IMG_2134.jpg

that's definitely suspicious.

Oh fun with framebuffer!

Sorry, I have unfinished business with iPXE in Triton where it needs to construct a framebuffer payload properly.

Some classes of NUC will not iPXE boot because they don't have tty[ab] and the framebuffer payload fails, even if seemingly properly-constructed (but thank you for the datapoint from the FreeBSD loader).

interesting, yes that mainboard apparently also doesn't have a serial port

Yeah... on those same classes of NUC, however, I can get SmartOS from USB-key (and subsequently disk-booting) with illumos loader to DTRT.

I can't get that mofo to EFI-netboot ==> iPXE ==> illumos chain.

I get a kernel panic. I only know this because if I set the Triton CN (in this case the NUC) to boot with kmdb, instead of rebooting, it hangs.

Looking for a console that isn't there.

And it seems, we have OTHER NUCs at MNX's main office that HAVE serial ports but still don't boot with iPXE, but do with Loader, and show a single serial port (ttya IIRC).

We even tried wiring an actual port of the mobo's header, but that failed to show anything.

danmcd: thanks for the docs.smartos.org/non-interactive-install feature - so we got it installed without UI :)

that also confirms it boots, we're just missing the output

drscream: those docs are courtesy of bahamat :)

Glad that worked.

That does tell us it's something in framebuffer comms.

does prtconf show a framebuffer device?

that was a problem with hyper-v gen2 vms -- it existed, but there was nothing (no PCI bus, and nothing in ACPI) to cause the OS to create a device node for it

jbk: gist.github.com/wiedi/36a22e188d1546e8aa7ff350c27cfd62 - I don't see any

the 'display' one is probably it, but doesn't seem to have a driver attached for it

ah yep

at the same time, if loader isn't finding it, then it can't pass along the info it has onto the kernel

IIRC, it uses that during the initial part of the boot until more modules have been loaded

Yeah, so the loader issue there seems like the starting point given what was pointed out above.

what's also interesting is that the loader uses the ascii box drawing chars instead of the utf-8 ones