07:12:02 <sjorge> I like to imagine it like the beacons of Gondor being lit
11:28:16 <stevenm_> is DilOS the only illumos/open-solaris based distro that is both a) still actively worked on, and b) uses debian packaging / apt ?
11:28:30 * stevenm_ wonders if debian itself can use the same kernel as illumos
11:29:22 <neuroserve> stevenm_ : were there other illumos distros using apt/debian packaging despite dilos?
11:30:15 <stevenm_> well nexenta os was
11:30:32 <stevenm_> aka illumian
11:33:29 <psydroid> it's an interesting question, but shouldn't IPS work fine too?
11:33:56 <Woodstock> illumian was never a thing, and nexenta stopped using debian packaging with their 5.0 release five years ago. and the whole debian stuff never worked that well for it anyway.
11:36:43 <stevenm_> Woodstock, according to this... https://illumos.org/docs/about/distro/
11:36:49 <stevenm_> NexenStor is still using APT
11:41:54 <Woodstock> don't believe everything you read on the internet
11:44:35 <stevenm_> shame if it's not true
11:45:19 <stevenm_> tbh I think my dream scenario would be an official debian port ... like they do for the kfreebsd and hurd kernels
12:27:28 <stevenm_> igork, ^ :P
12:28:25 <igork> stevenm_: dilos is active and many into at #dilos channel :)
12:28:44 <stevenm_> Woodstock, strange I watched a whole presentation on youtube about illumian being a thing last night :P https://www.youtube.com/watch?v=P4SS3R_4oy8
12:29:01 <stevenm_> the audience looked a little empty - and it was 9 years ago :P
12:43:50 <toasterson> stevenm_: it was a debian fork for illumos like kfreebsd but like kfreebsd it did not find traction and died about 3 years after
12:47:20 <stevenm_> toasterson, so what'd be the proper term (if 'k' is 'kernel of') if debian did have a port?  in the illumos/opensolaris sense?
12:47:26 <stevenm_> kIllumos ?
12:48:12 <stevenm_> or is the kernel still seen as the OpenSolaris kernel?
12:52:06 <jperkin> "OpenSolaris" hasn't been a thing for well over a decade, Solaris is very much not open, and if you find anything still referencing that name (other than historical) then it should be removed
12:55:57 <toasterson> stevenm_: no clue. we never gave the kernel a dedicated name. the source is illumos-gate but that also includes userland things not just the kernel.
13:02:17 <stevenm_> toasterson, well you could say that the linux kernel 'project' hosts a few userland tools too
13:03:04 <stevenm_> but no one calls the linux kernel (between your normal desktop/server gnu/linux distro's - nothing exotic like android) "forks" just because they might add/remove the odd patch or select/deselect things at compile time
13:03:28 <stevenm_> so maybe 'illumos-gate' kernel is about the right name?   doesn't uname still show SunOS for some reason!? :D
13:14:00 <toasterson> it does, but that has historical reasons. C programs still need it to detect things sometimes.
13:21:38 <stevenm_> hmm, if I ask google to show me any pages mentioning "NexentaStor CE" OR "NexentaStor community edition" for the last 2 years...
13:21:48 <stevenm_> I get 8 pages lol
15:38:30 <jclulow> I would just call it "the illumos kernel".
18:06:10 <andyf> That's what `uname -o` shows, after all
18:18:36 <alanc> certainly better than the threatening looking "killumos"
18:28:59 * pmooney chuckles
19:13:55 <bahamat> rmustacc: I've got a system getting an error creating overlays. Wondering if you've got any insight before I get lost in this stuff.
19:14:00 <bahamat> Error is: dladm: warning: failed to set property vxlan/listen_ip
19:14:23 <bahamat> The IP specified *is* plumbed (at least according to ipadm)
20:04:38 <sjorge> killumos sounds like what a terminator would run on
20:12:12 <richlowe_> weren't they commodore 64 or something like that?
20:12:16 <richlowe_> when you saw the code on screen
20:13:33 <andyf> It was 6502 at least, IIRC
20:38:56 <toasterson> it was a couple ones depending on era. Terminator 4 ran linux. I don't know the older ones.
20:50:44 <rmustacc> bahamat: It didn't tell you why it failed did it?
20:52:53 <bahamat> rmustacc: It says "dladm: overlay creation failed: <unknown error>"
20:54:55 <rmustacc> Ah, that's too bad. I didn't remember how much additional info we had there.
20:55:05 <rmustacc> There'll probably be a kernel ioctl that's issuing it.
20:58:55 <bahamat> Yeah, the dladm_overlay_setprop function does ioctl(dladm_dld_fd(handle), OVERLAY_IOC_SETPROP, &prop)
20:59:21 <rmustacc> Yeah, I was hoping it would have given you a bit more there, but it's been 5+ years since i've looked at any of this.
21:03:37 <rmustacc> Maybe grab a quick truss of it?
21:05:49 <danmcd> truss is good, and I think I have a good kernel place to throw downstack.d at.
21:05:52 <bahamat> It happens during vmadm start, so it's hard to grab.
21:06:07 <rmustacc> OK, one min.
21:06:18 <rmustacc> I can give you a dtrace thing for it and then I have to get back to something for danmcd.
21:07:03 <bahamat> Sweet, that'll help a lot. I was looking at writing one myself
21:07:38 <rmustacc> dtrace -n 'fbt::vxlan_o_setprop:entry{ printf("%s\n", stringof(args[1])); }' -n 'fbt::vxlan_o_setprop:return{ trace(arg1); }'
21:07:41 <rmustacc> Something like that.
21:07:46 <rmustacc> Haven't built it.
21:08:14 <bahamat> ok, let me see what I can get out of that.
21:09:38 <danmcd> (That's the function I want to downstack...)
21:10:07 <rmustacc> It doesn't call anything else.
21:10:11 <rmustacc> It all returns directly.
21:11:15 <danmcd> Oh...
21:12:45 <danmcd> .. nothing that'll get reached at all on a failure.  Gotcha.
21:13:07 <rmustacc> I mean, you'll call bcopy, but that's not useful.
21:13:11 <rmustacc> Or mutex calls.
21:13:20 <rmustacc> But there are no return values generated from downstack stuff.
21:13:55 <bahamat> That's what that ioctl is doing?
21:14:02 <rmustacc> Yes.
21:14:07 <rmustacc> Eventually.
21:22:02 <bahamat> Hmm, crap. dtrace: invalid probe specifier
21:22:29 <bahamat> The CN I'm testing on has no vms with overlays currently. I tried on another one that does already have overlays and that worked.
21:24:00 <rmustacc> Invalid probe specifier or doesn't match any probes?
21:24:30 <bahamat> I copied it
21:25:59 <bahamat> Hmm. modinfo says overlay is loaded
21:28:21 <rmustacc> It comes from the vxlan module. If had said it didn't match any probes then you'd just toss in a -Z.
21:28:28 <rmustacc> *If it had
21:28:34 <bahamat> Yeah, vxlan isn't loaded
21:34:09 <bahamat> Ok, even with -Z it was giving me an error about, but I modloaded it, and dtrace is happy now.
21:36:11 <rmustacc> It probably would have complained about using args[1].
21:36:22 <rmustacc> what is the address anyways?
21:54:29 <bahamat> of the module?
21:54:42 <bahamat> or the listen_ip?
21:59:59 <rmustacc> The IP.
22:00:31 <bahamat> -p svp/underlay_ip=10.3.248.238 -p vxlan/listen_ip=10.3.248.238
22:02:06 <bahamat> Things that I don't think matter: They have aggrs, lldp falls to maintenance
22:02:31 <bahamat> We had both of that happening at Joyent and it never caused this issue.
22:02:57 <rmustacc> So most of the checks are all about whether or not something is a multicast address.
22:03:07 <bahamat> There are also CNs running the same PI that aren't having this error, but the ones that do, it's consistent.
22:03:10 <rmustacc> So I think the quesiton I'd ask is whether we're somehow not properly doing an endian encoding.
22:03:21 <rmustacc> As 238.* is an IPv4 mcast address.
22:03:37 <rmustacc> But that's why I'd confirm that we're getting EINVAL, that that was the property, and then we'll change it to print the data.
22:03:44 <bahamat> Ah...that may be.
22:04:11 <bahamat> I'll see if there are any other servers exhibiting this issue or just the one.
22:04:31 <rmustacc> Well, we should go diagnose the bug.
22:06:37 <bahamat> I'll try mocking up this IP on a CN and see what I get out of that dtrace
22:06:57 <rmustacc> Can't force the provision to that CN?
22:07:24 <rmustacc> If that is right (and I sincerely hope not), then anything that ends in .224-.239 would fail.
22:08:03 <bahamat> It's a customer, so I'm preparing a set of things for them to get back to me with, but it'll probably be tomorrow at the earliest that I'd get a response.
22:08:15 <rmustacc> You should be able to mock that up.
22:08:26 <rmustacc> As long as you never start the overlay the set-prop will work.
22:08:37 <rmustacc> Because we don't try to use that until we get further there.
22:08:48 <rmustacc> So even on a system without that IP you can try it and see.
22:08:55 <rmustacc> It'll fail in a different way later.
22:09:02 <bahamat> I'll check with Joyent to see if they have any underlay addresses with that host ID. If they do, and they have no issues there, that would seem to absolve the endianness
22:09:28 <rmustacc> OK. Well if you have more info, let me know.
22:09:50 <bahamat> OK, so I could just do the dladm create-overlay even without plumbing it up and it should hit the same error, if it's an issue with the IP itself?
22:10:38 <bahamat> FWIW: vxlan_o_setprop:return                22
22:11:21 <bahamat> Hmm, just EINVAL.
22:11:23 <rmustacc> So you'd want to modify the DTrace to then print the opening bits there.
22:11:32 <rmustacc> EINVAL is the only error that whole chunk there.
22:12:06 <rmustacc> So basically print the property name. If it maches what you expect, then you want DTrace to print the buffer as an in6_addr.
22:14:42 <bahamat> So I'm going to have to do that in the call to strcmp(), right?
22:15:05 <bahamat> O, no, actually I don't need to
22:15:29 <rmustacc> No, you use the entry probe and predicate.
22:15:33 <bahamat> Yeah
22:15:42 <rmustacc> And if it matches, then you case arg2 to the right type and print.
22:19:04 <bahamat> How do I make it print as a type?
22:27:55 <rmustacc> Something like print((struct in6_addr *)arg2);
22:28:05 <rmustacc> But you'd only want to do that if the predicate about the property name matches.
22:31:53 <rzezeski> maybe: `print(*(struct in6_addr *)arg2)` (so you don't just print it as pointer)
22:32:27 <rmustacc> ah yeah, thanks.
22:32:41 <bahamat> Ah, ok, here we go:
22:32:43 <bahamat>         uint8_t [16] _S6_u8 = [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0xff, 0xff, 0xa, 0x3, 0xf8, 0xee ]
22:42:36 <bahamat> So that macro does this: #define IN6_IS_ADDR_MULTICAST(a)        ((a)->s6_addr[0] == 0xff)
22:42:47 <bahamat> Now I want to get at that s6_addr
22:45:49 <bahamat> wait, we're probably falling all the way through to IN6_IS_ADDR_V4MAPPED so what I really want to look at is IN_MULTICAST
22:51:19 <bahamat> OK, so if I manually `0xeef8030a & 0xf0000000`, that does indeed equal 0xe0000000.
22:54:50 <bahamat> rmustacc: Thanks for your help here, you literally saved me days of trying to decipher all of this on my own.
23:20:27 <danmcd> Callers to IN_MULTICAST must normalize-to-host-order whatever it feeds.  Other callers of IN_MULTICAST use ntohl() first, so should the overlay code in question.
23:20:50 <danmcd> (Don't ask me WHY it's that way, likely a 4BSD choice inherited from 2BSD.)
23:21:39 * danmcd is trying to remember which BSD first got multicast.  I think it was 4.3 proper, or 4.3 Net/1 or Net/2.