05:35:08 danmcd not that it helps us at all, seem windows does implement IP(V6)_RECVERR, probbaly for WLS 05:35:15 *WSL 05:39:43 Also did some more digging on the code fragment, seems freebsd opts to lie about it by default ? http://bxr.su/FreeBSD/sys/compat/linux/linux_mib.c#85 05:40:14 So would something similar behind a tunable be OK ? That seems about the right amount I can chew and maybe not choke on 11:13:35 danmcd did more spelunking https://github.com/omniosorg/illumos-omnios/blob/1ad7f63b23e873c3e9901174843ddb02f5cc6dfa/usr/src/uts/common/brand/lx/syscall/lx_socket.c#L3262C1-L3277C14 11:13:43 I guess we already lie the IP_RECVERR case? 11:13:58 We're just missing it for the IPV6_RECVERR one I believe? 11:14:50 So just adding an entry here https://github.com/omniosorg/illumos-omnios/blob/1ad7f63b23e873c3e9901174843ddb02f5cc6dfa/usr/src/uts/common/brand/lx/syscall/lx_socket.c#L3353 for the IPV6 would should work I think, I wonder if I can just build the brand lib and test it easily 11:19:40 https://github.com/omniosorg/illumos-omnios/issues/1219#issuecomment-1725307393 I updated the ticket 12:42:37 what's the last tested virtio driver for the windows platform? 14:42:55 danmcd I build illumos-omnios with the change, IIRC there is a trick to just lofs a library and boot an lx zone to have it use the new one right? 14:42:57 But I can't find it 14:43:03 I vaguely r emember it being on the old smartos wiki 14:53:08 mount -O -F lofs /var/tmp/lx_brand.so.1.$$ /usr/lib/amd64/lx_brand.so.1 14:53:13 I think it's this one 14:53:51 It looks like your change is in the kernel module, so unfortunately that won't do it. 14:54:45 I'm not sure on smartos, but on omnios it's probably easiest to create a new BE, mount it and copy the updated driver in, then activate and reboot. 14:55:30 Well it's omnios :p 14:55:36 But my build host is not my test host 14:55:48 What's the kernel module path? 14:56:00 I can beadm create, beadm mount, cp, ... 14:57:49 I guess /usr/kernel/drv/adm74/lx_systrace ? 14:58:00 actually no 14:58:18 Probably /usr/kernel/brand/amd64/lx_brand 15:00:28 That looks right 15:00:36 okidoki 15:00:54 beadm activate -t is awesome for this :D 15:01:34 I'll report back in the ticket I guess 15:02:20 Yes, alternate BEs are you best bet in OmniOS for changes like this. (It inspired piadm(8) for standalone SmartOS.) 15:05:47 Thanks for digging into this sjorge 15:06:17 Well it was either that, or fix mattermost go mess 15:06:29 And well... one is a ugly place we don't venture into :D 15:06:47 It's just a lot of work I think, with a lot of places to touch. 15:07:30 This seems like a better route, as that same error has been stopping me from running certain things in lx for a yearish or more 15:08:09 root@lxubuntu:~# ping blackdot.be 15:08:09 PING blackdot.be(blackdot.be (2a01:7e01::f03c:93ff:fe79:9d74)) 56 data bytes 15:08:09 64 bytes from blackdot.be (2a01:7e01::f03c:93ff:fe79:9d74): icmp_seq=1 ttl=248 time=11.1 ms 15:08:09 64 bytes from blackdot.be (2a01:7e01::f03c:93ff:fe79:9d74): icmp_seq=2 ttl=248 time=9.65 ms 15:08:09 64 bytes from blackdot.be (2a01:7e01::f03c:93ff:fe79:9d74): icmp_seq=3 ttl=248 time=9.16 ms 15:08:10 Hello 15:08:17 This is new ^.^ 15:08:51 And I also found a work around for the other ipv6 issue I have open (the missing change from SmartOS) 15:09:12 I can just not grab those addresses and take local-link + static by create a /etc/inet/ndpd.conf :D 15:12:28 I'll do a PR and tag dan 15:19:24 sjorge: nice work! 15:22:01 https://github.com/omniosorg/illumos-omnios/pull/1381 done :) 15:22:04 papertigers thanks 15:22:41 Not that I'll go back for plex because NFS still acts weird and well I have a GPU passthru now :D but it's nice for some other stuff 15:27:27 I checked last night actually...I still have 2 lx instances 15:29:08 Well I'll prob move my mattermost I use for D&D from native -> lx given the build is broken and newer stuff doesn't build either 15:29:27 And I'd rather deal with our kernel code than go 15:34:21 sjorge: I tend to run a bunch of things via bhyve now. Alpine + cloud-init to do all the setup -- things are pretty automated now and I am happy with the setup. 15:34:56 Although I may end up getting a PCIe card that does 2x or 4x nvme. It seems my spinning rust makes things noticibly slow 15:39:49 yeah bhyve is generally very good, but the tiny amount of memory this needs doesn't justify a full vm with all the overhead 15:40:15 all my stuff is on mirrored NVMe, at least the vms 15:40:22 I still have a couple of lx zones too, for things like a unifi controller it works very well so far. 15:40:50 andyf: yeah I have the unifi controller and something called channelsdvr 15:40:54 yeah, my main workload was plex which works ish, but has some weirdness from time to time 15:41:23 with ipv6 fixed i just setup mattermost and imported my data 😃 15:41:24 This can't last for ever (as I say pretty much every year), but so far so good. 15:41:39 once it's merged i'll properly redo it and move it over 15:42:49 I have an editorial comment on your PR. Fix that and you'll get my +1 AND a pullover into SmartOS (just in time for this week's Triton-and-SmartOS release cycle). 15:42:59 how are the numbers for name_to_major allocated in smartos? Can one just pick the next one? 15:44:51 pretty much.. 15:48:27 @sjorge --> jinni OS-8487 15:48:28 https://smartos.org/bugview/OS-8487 15:51:45 danmcd OK, let me update the comment block 15:54:11 done 15:55:00 jbk: cool, thx - seems to work :) 16:01:49 Approved, but I can't be an official approver on illumos-omnios (which makes sense). Once @andyf re-ups his +1 I'm sure you're good to go over there. 16:02:09 And this WILL be landing in SmartOS 20230921. 16:08:00 Yay! 16:08:22 I'm mostly on OmniOS these days but I still got a few people into SmartOS that are still using it :p so it's nice it gets fixed everywhere 18:00:25 @sjorge --> https://github.com/TritonDataCenter/illumos-joyent/commit/5760e8de362c7daa48e10bd22a66bcfe1f3bc0f0 18:15:06 awesome! 18:15:11 that was quick 18:17:47 Easy to review... check. 18:17:54 Well-documented testing... check. 18:18:10 Good analysis, which I should've lead with... check. 18:18:25 Thanks again, sjorge. 18:20:13 just shows you how much i dislike dealing with go 😅 18:22:44 heh 18:22:51 go is fine for some things 18:23:00 but for others it's an absolute nightmare 18:49:08 yup, it's like for every thing they got right, they had to make something equally terrible 18:50:06 interoperating with non-go code is horrible 18:50:53 and designing the language around the idea of issuing syscalls directly on linux was arguably a big misstep 18:51:22 since linux is pretty much the only os that has a stable syscall interface 18:51:48 windows, freebsd (with some caveats), illumos..none of them do 18:52:19 but my experience is it tends to push things towards rampant NIHism 18:52:29 often with inferior results 18:52:34 The syscall api on Linux seems to be the only absolute stable thing because of Linus 18:53:21 fast compilation: great! patching go modules: atrocious! cross-compilation: great! per-opsys patches: atrocious! 18:54:07 Linux is a big collection of fastpaths 19:00:12 I had a university class on assembly in 99' - We learned x86 assembly on Linux, made all the kernel calls directly 19:00:13 heh 19:22:25 jperkin: do you happen to know if pkgsrc has an up to date mattermost package on illumos? 20:04:12 sjorge: it does not, if it'd be useful I can update and add it 20:04:20 current one is from 2020 20:05:06 the one in omnios is also rather old and has a bunch of security fixes missing 20:05:21 that why I asked, looks like it would be about the same 20:05:36 I get the feeling that not many people use it anymore so there's no interest in maintainers, but I could be wrong? 20:06:19 seems some of the deps for the newer ones are not illumos friendly 20:06:50 probably not worth spending time trying to update it 20:07:07 well, i mostly gave up on it 😅 20:07:17 there seems to be more interest in e.g. matrix so there are a few people keeping synapse up to date, etc. 20:10:14 We had used XMPP at Joyent, and a lot of people wanted something different. There was a split between Matrix and Slack, and Mattermost was chosen as the compromise. 20:11:01 But after a while, the cost of MM was about the same as the cost of Slack, but without having to expend any time on it, so we just switched to Slack. 20:15:57 and all of those beat teams :) 20:16:22 i still think that new vocabularly is needed to properly convey how horrible of a product it is :) 20:18:40 I find it funny that MS actually got a anti-monopoly probe over teams 20:19:46 well a lot of places that are just looking at $$ will switch to it over other solutions 20:19:58 because it's bundled w/ their other offerings 20:20:32 (I still half think they created it as a way to fend off competition) 20:20:56 basically get any potential competitiors to use it and kill their productivity :) 20:43:08 $work ditches slack, and we're on teams now 😑 20:43:39 so i installed MM for a few collegues to still have a spot to talk about anime and stuff 20:43:40 my condolences 20:43:48 thanks, it's horrible 20:43:51 it is 20:43:57 we use it here and it's awful 20:44:16 like one channel it frequently forgets how to scroll properly 20:44:31 yeah, we switched 2 weeks ago 20:44:50 and stuff just shows up 2 days later sometimes 20:45:08 randomly it switches to right->left for text entry (i suppose if you wanted to type hebrew or another language that does that) 20:45:09 integrations are a pain too 20:45:16 ... 20:46:03 oh yeah and posting a code snippet is just ... yeah pain 20:46:19 yes.. the way it does that is also terrible 20:47:11 i wish it just had a pure time based chat