07:04:55 <Emqvee> offtopic, does anyone have payed job for illumos based system administration?
10:26:42 <Woodstock> did we somehow reintroduce https://www.illumos.org/issues/12895 ?
10:26:43 <fenix> → BUG 12895: zfs_onexit_fd_hold fails to release non-zfs fds (Closed) | https://code.illumos.org/c/illumos-gate/+/773
10:26:58 <Woodstock> just got the exact same panic after onu'ing to debug bits
14:18:20 <sommerfeld> 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.  
14:34:22 <wiedi_> Hi, we have a N100M system ( https://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. 
14:34:40 <wiedi_> https://up.frubar.net/4676/IMG_2132.mov <- any ideas on how to debug this?
14:37:29 <wiedi_> hmm maybe that warning is relevant: https://up.frubar.net/4677/IMG_2133.jpg
14:52:18 <rmustacc> 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.
14:52:29 <rmustacc> (I would veryify the loader method of setting kbm_debug first).
14:52:55 <rmustacc> That will basically tell you whether or not you entered _start() which is what dboot calls or not.
14:55:09 <rmustacc> That will basically help us bifurcate the search. Did we get through dboot or not.
15:12:26 <wiedi_> oki thx, we'll try that
15:13:12 <rmustacc> 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.
15:22:39 <wiedi_> did "set kbm_debug=1" in the loader prompt but that looks the same. Will try with a custom debug build
15:48:33 <wiedi_> 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: https://up.frubar.net/4678/IMG_2134.jpg
15:49:52 <rmustacc> that's definitely suspicious.
15:58:54 <danmcd> Oh fun with framebuffer!
15:59:21 <danmcd> Sorry, I have unfinished business with iPXE in Triton where it needs to construct a framebuffer payload properly.
16:00:13 <danmcd> 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).
16:01:53 <wiedi_> interesting, yes that mainboard apparently also doesn't have a serial port
16:04:12 <danmcd> Yeah... on those same classes of NUC, however, I can get SmartOS from USB-key (and subsequently disk-booting) with illumos loader to DTRT.
16:05:06 <danmcd> https://gist.github.com/danmcd/91befa92cb605b0ac40ed503e56aca4e
16:05:38 <danmcd> I can't get that mofo to EFI-netboot ==> iPXE ==> illumos    chain.
16:06:07 <danmcd> 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.
16:06:14 <danmcd> Looking for a console that isn't there.
16:07:52 <danmcd> 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).
16:08:12 <danmcd> We even tried wiring an actual port of the mobo's header, but that failed to show anything.
16:38:16 <drscream> danmcd: thanks for the https://docs.smartos.org/non-interactive-install/ feature - so we got it installed without UI :)
16:38:37 <wiedi_> that also confirms it boots, we're just missing the output 
16:44:11 <danmcd> drscream: those docs are courtesy of bahamat  :)
16:51:55 <rmustacc> Glad that worked.
16:52:04 <rmustacc> That does tell us it's something in framebuffer comms.
17:04:52 <jbk> does prtconf show a framebuffer device?
17:06:13 <jbk> 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
18:08:59 <wiedi_> jbk: https://gist.github.com/wiedi/36a22e188d1546e8aa7ff350c27cfd62 - I don't see any
18:12:02 <jbk> the 'display' one is probably it, but doesn't seem to have a driver attached for it
18:12:48 <wiedi_> ah yep
18:16:37 <jbk> at the same time, if loader isn't finding it, then it can't pass along the info it has onto the kernel
18:17:18 <jbk> IIRC, it uses that during the initial part of the boot until more modules have been loaded
18:28:29 <rmustacc> Yeah, so the loader issue there seems like the starting point given what was pointed out above.
19:08:18 <wiedi_> what's also interesting is that the loader uses the ascii box drawing chars instead of the utf-8 ones