There are a lot of probably cheaper machines that will be much better for a home lab setup, FWIW

mid 2010s Dell and Lenovo small form factor systems are quite cheap, and you can usually find one with a proper physical serial port which is much better than a framebuffer console

doh! how did i miss that tab :(

rmustacc: you hade suggestions as you were leaving?

regarding propolis rebooting the host

Well, if it is, that should generally create a kernel crash dump. So I would verify you have a dump device set up in dumpadm.

one of these days, i'm going to spend a week or two documenting all the various APIs and such surrounding the device tree... (as I dig into what looks like a use-after-free issue with multipath devices)

Is there something specifically you're looking for we could help with?

just that most of it's undocumented

so at least whenever i'm dealing with it, it always feels like i'm just cargo culting other code without feeling fully confident I know i'm doing the right thing

I get that. Was just trying to see if I could help share knowledge or something in the interim.

Even knowing what specifically you're looking for better docs for. Just saying others can help potentially.

one thing that'd be useful is for devices (and specifically mdi devices in this case, but it's been a general thing), there are a number of states and just what exactly the expectations/guarantees are for each.. i mean the names imply some stuff, but it seems like there's often some not as obvious implications

(sorry.. been jumping around from multiple things)

jclulow do you want to speak about this call: src.illumos.org/source/xref/illumos…ain.c?r=64439ec0&mo=4578&fi=181#197 ?:)

[illumos-gate] 16024 bofi(4D) should not use sparc specific headers on intel -- Richard Lowe <richlowe⊙rn>

[illumos-gate] 16025 nxge(4D) shouldn't look for sparc specific headers -- Richard Lowe <richlowe⊙rn>

i know sometimes order matters when building stuff, but for ld's -z assert-deflib, if -L/path -L/path2... come after, should it still be ok?

The -z assert-deflib placement shouldn't matter.

ok

What matters is where the -L/path and the -lfoo is.

If your -l is before the required -L we won't find it on that path, IIRC.

does the 'default search path' that it'll assert on also include anything set via LD_LIBRARY_PATH when invoking ld?

(for some reason, in our internal illumos build, after we (finally) switched to gcc10, debug builds are failing building the platform's (i.e. not bootstrap) perl

because it's finding libc.so

but the error message doesnt' say where

but the parameters passed to perl's configure script all look correct to building using the proto area

tsoome: What would you like me to say about it!

jbk: I read ld(1) that LD_LIBRARY_PATH is treated as similar to -L.

But I don't know more than manual page.

LD_DEBUG=libs, probably would help say where. Sorry the error message isn't as helpful as it could be there.