Hey everyone, Robby Andrews here from MNX. I wanted to announce we are doing an office hours for TritonData Center over on Discord

This Thursday 11am PT/2pm ET. Here is the link to join our discord discord.gg/v4NwA3Hqay

Come and participate and hear what we're doing with Triton DataCenter and give suggestions and feedback

as usual, I've mailed ptribble already, but for anyone else who likes tidying up the man pages, some things you may consider: pastebin.com/jvjhrqf0

one of those might even be jbk's fault

though more likely it was whoever at Sun merged his ls(1) changes into the man page gate long long ago

I apologize for being totally spaced out about this. Do we still need Sun Studio bits for building illumos anymore?

Nope

Not us

A code review of some Triton stuff mentioned Studio and I was like, "huh?" It's vestigal I'm sure, but I wanted to check if, even post-libm, we didn't need something from there.

OmniOS hasn't shipped it for a long time. Once it was no longer required there was (as I understand it) no legal protection for shipping it.

or whatever word the lawyers used

We have it still in smartos-live, due to some ancient OS-xxx bug (yes 3-digits) about mysql needing it. I should ask an OG Joyeur about it.

I'd very much like to kill it for good:D

Here's what we actually ship from it: gist.github.com/danmcd/7a4feb7af79653e7caab5014ce321238

Those files are *optional* on OmniOS (in the pkg:/system/library/c++/sunpro package).

The runtime libraries are still shipped for people who need to run old binaries that they either can't or won't recompile

And that's likely why we have it living in smartos-live still.

(and what we do have in smartos-live is merely the libraries and one header file).

so just C++ runtime and demangler support, really.

Yeah, that was all we were using it for. Feel free to reach out if you need more what were these people thinking questions answered danmcd.

No doubt it's due to the "C++ doesn't do compiler-independent ABIs" problem.

Yeah, pretty much.

that was basically fixed in later C++ standards by Studio just adopting the g++ ABI's and libraries instead of rolling their own

but enough damage had been done by the older generations that binaries had been compiled for

[illumos-gate] 15389 zfs-tests zfs_allow_003_pos fails due to unexpected property inheritence -- Bill Sommerfeld <sommerfeld⊙ame>

I forget the details offhand, but when we removed that package from OmniOS there were multiple complaints. People run a surprising amount of closed source legacy stuff.

Yeah, our own reading(s) got us to the same place everyone above did. Thanks!

@bahamat and I will figure out what to do from there.

danmcd: there is C++ runtime stuff for people who managed to use it (libC, libCrun) that you might want, and there are math-library tie-ins that might still work. I doubt either practically matters unless people are running 3rd party binaries.

or rather, I bet what the people using those things _really_ want is the s10 zone brand.

Yeah.

is there a reason I'm spacing on why sys/systm.h is so sloppy about `extern`?

I sure don't know Rich (sorry).

Presumably the standard legacy reasons any code with oldest copyright year 1984 hasn't been brought up to modern C best practices - nobody's gotten around to it yet?

well my next question was how strlcat got in there (as well as sunddi.h)

perhaps I should just stop wondering things that don't directly matter right now

next you'll be asking why they decided to leave the 'e' out of the filename just to save one character

danmcd: sun studio libs can be use for oracle jdk8 amd64 version as i know

richlowe: Well, part of the extern thing is people are inconsistent and people grumble when I try to be consistent (as it impacts #pragma redefine_extname).

And so a lot of folks just say it's extern by default so I can leave it off.

So I probably wouldn't think too hard on the why extern stuff for the most part (ignoring the C++ duplications there which are surprising).

alanc: yeah it wasn't me.. my ls change didn't include any diffs to ls(1) -- someone at sun added those

sommerfeld: so the full story, I was checking where strlcat(9f) actually was, and as the manual page says, sunddi.h. It turns out though it's also in sys/systm.h, along with a weird selection of string stuff. The extern question is because strlcat isn't, and strlcpy is, and it sure seems like they'd have come in together. It seemed at least possible there were reasons I'd missed

secondary to "why the heck did all this stuff get in here?"

you should have that in your hg history - I can see strlcat coming in as part of x86 newboot in 2007, and strlcpy later (in our case, post-closing)

git blame answers the call: ae115bc77f6fcde83175c75b4206dc2e50747966 for strlcat, b819cea2f73f98c5662230cc9affc8cc84f77fcf for strlcpy (as part of 5917 User-mode SMB server)

my git blame is still showing a progress indicator.

ah, bill beat me

unfortunately, x86 dboot doesn't answer much except "because they did it".

the xen folks threw an awful lot of crud into that putback

yeah

Maybe related to 6477867 x86 KDI should belong in the kernel

jlevon: what did y'all do? :)

the C++ weirdness also came from there

which is even more surprising.

it's now #15393 (fenix?)

BUG 15393: sys/systm.h has an incongruous mix of string functions iff _KERNEL (New)

↳ illumos.org/issues/15393

richlowe: lord knows

He's pretty quiet though

andyf in which repo do you host the arm cross compile stuff for packages?

They are built out of the same omnios-build repo as the x86 packages

and they are in a repository at pkg.omnios.org/bloody/braich

Are you building NSS at al at the moment?

No, but richlowe is in arm64-gate

it doesn't look pretty!

No, NSS anywhere looks pretty I see

hmm, that typo changed the sentence completely

right, it seems like it's a bear to cross compile. I gave up and took what hayashi did, I think maybe hayashi gave up and took what Solaris did long ago

Well, the make based system seems only partially supported, since nss is using gyp

if I were caring about things like that, I'd honestly look into adding the other build dependencies I ignored because low-reward, rather than fixing that build, right now.

that might just be dbus/hal/glib

but the big push, the big good thing advantage, is what people are doing to build that stuff into a tiny actual distribution, so the build can be pointed at a proper full adjunct.

and then only the more important, variable, pieces need special handling for a bit longer.

Who is doing that?

I'm hesitant to give up the ability to start from absolute 0, but it is definitely more trouble than it is worth in any longer term vision.

True

I haven't seen much coordination on ARM so I am wondering who is doing the tiny distribution

I'm no narc :)

An invite would suffice :)

remind me, I'm getting tests running over the aw thing at the moment.

ok

one day, I will conquer bhyve v. zpool autoexpand

apparently not today

richlowe: What happened? Just no expansion?

It too shall fall

uncorrectable I/O, ate/locked the pool, same old same old

jclulow: boot, zpool set autoexpand=on rpool, or zpool online -e rpool c1t0d0

jclulow: image is from your image-builder, image disk is 5G actual volume is 15

tried the old tricks of zpool list -v, etc, to get the cache up-to-date, reboot after we refound the disk to get the labels up-to-date, etc, no dice

richlowe: current bits?

that is somewhat surprising to be honest

I mean, it's with my aw-removal bits this time, but I would assume I didn't break it.

What disk backend? ahci, vioblk or nvme?

vioblk

illumos.org/issues/14022 should presumably have taken care of that

→ BUG 14022: zpool online -e breaks access to pool (Closed) | code.illumos.org/c/illumos-gate/+/2004

jclulow: I thought so too

That should be working, even with the VM up and running

which is mostly how I use it

I thought so too, that's why I did it

I can try on stock bits, but not right now because I don't have any

there was also illumos.org/issues/14978 for which I did a fair bit of testing with a scenario hopefully similar to the one you're describing

→ BUG 14978: ZFS autoexpand property should work for root pools (Closed) | code.illumos.org/c/illumos-gate/+/2355

I wonder wtf!

It's always possible I'm cursed.

haha

it's not bhyve, but that reminds me i need to RTI the fix for zpool online -e w/ vmware

I think you may be.. paste.ec/paste/FJAbUFpj#3kGtOFFG1KxevSyQ-V2kwjyOyZusWtAzG38S9OgFoeu

jclulow: if you have stock bits to give it a quick try, it'd probably help narrow it down?

that one though shouldn't cause any panics

ok, so my volsize isn't growing, I have an image in a 15G zvol that believes it's 6G

the zvol at every point is 15G

I wonder if it's having fatal I/O errors because it is over quota?

if that matters?

it's just efi_use_whole_disk() doesn't like what ESX does to the disk label when it grows a disk offline

richlowe: I would expect we would use the disk label at the front and not find the backup one at the back where we expect, but otherwise drive on

But who knows

right, and zpool knows the device underneath it is expandable

etc.

but doing the expansion chokes it

all I'm doing is image-buildering a disk dd'ing it onto the zvol, booting, trying to expand the pool to fill the backing store.

nothing out of this world

yeah

It might be worth trying the nvme backend, if you haven't already

I haven't, but I can

and stock bits

I just want to get at least some of this testing I've been trying to start all day actually done.

I have your two ld things running through a bulk build - should have results in the morning but I'm heading offline now. Good luck!

g'night

richlowe: hmm, I successfully expanded a VM's root pool recently (backed by zvol). Used online -e