01:26:36 <Smithx10> Well I got the GCC message to not have two -lpcaps and now its complaining about undefined symbols https://gist.github.com/Smithx10/7da0e300509930560eacc2fd7b4b99dc
01:41:41 <jbk> you should be able to see them, but i think the problem is that you can't tell which physical link the frame arrived on in an aggr
01:42:59 <Smithx10> So when they are in the aggregate its possible when i Pcacp on iface0 ill get iface1s ToR frame
02:14:13 <Smithx10> linking is frustrating :)
04:41:01 <Smithx10> I diiiidddd itttt woowoooooo hahaha
05:02:13 <Smithx10> jbk:  it looks like all of the interfaces are consistently getting the same info from ToR ,  gonna verify it  with what we know from the switch dump.      
05:15:58 <Smithx10> Quick Sanity heck here..... using libpcap  and setting a bpf  to "ether proto lldp" shouldn't kill my box cpu / network perf right?
05:22:24 <sommerfeld> Smithx10: seems unlikely  
05:29:06 <Smithx10> connecting with libpcap and  iterating over every frame would probably increase load yea?    Or am I paranoid ?
06:16:35 <sommerfeld> a little, yes.  really depends on how much margin you have on the system.   bpf shouldn't wake up userland unless the packet filter matches.
11:00:17 <tsoome> sigh. zpool destroy does unmount /var despite of /var/run mount :(
13:30:54 <tomww> win 23
13:58:23 <andyf> danmcd - thanks, I'll take a look. Those cv_signal() calls on proc_pageout->p_cv should be broadcasts now there are multiple scanner threads, and the macro should be used more widely as it is in SmartOS. I'll do a followup.
14:34:12 <gitomat> [illumos-gate] 15916 bhyve upstream sync 2023 September -- Andy Fiddaman <illumos⊙fn>
14:57:21 <danmcd> THank you @andyf --> I'll hold off on upstream merges for tomorrow's SmartOS release branch.  I can help with the followup.
19:09:30 <jclulow> tsoome: Did you "zpool destroy -f" ?
19:09:37 <tsoome> no
19:09:58 <jclulow> It probably didn't do the force unmount then
19:10:15 <tsoome> its  /opt/zfs-tests/tests/functional/rootpool/rootpool_002_neg
19:10:24 <jclulow> I think -f also ends up skipping things like the sync() -- see #16128
19:11:42 <tsoome> it is supposed to try to destroy rpool, and fail + recover, however, it still does manage to unmount /var 
19:12:04 <tsoome> and we have tempfs mount in /var/run ....
19:16:32 <jclulow> Oh, you're saying it _shouldn't_ unmount
19:16:35 <jclulow> ok
19:16:39 <jclulow> That's sad haha
19:16:50 <tsoome> yes, it should have refused to.
19:16:56 <jclulow> Yeah I understand now
19:17:43 <jclulow> I wonder why it was able to do that
19:19:35 <tsoome> and, I havent checked what did happen with /var/run - was it orphaned and still present in mnttab or what...
19:19:56 <tsoome> it certainly was not listed with df
19:20:10 <jclulow> Maybe it wasn't actually mounted?
19:23:04 <tsoome> it was.
19:23:53 <tsoome> we get it mounted early (filesystem/minimal) and we basically can not unmount it because init has open pipe there
19:24:23 <tsoome> unless with force
19:55:52 <sommerfeld> you have /var set up as a separate filesystem on this test machine?
20:32:40 <tsoome> yes, rpool/ROOT/openindiana-2024:01:09/var, otherwise it would be no problem:)
20:33:35 <tsoome> well, otherwise it would not have revealed the problem.
20:33:55 <jclulow> I think that's probably not a common configuration
20:33:59 <jclulow> from what I have seen
20:34:13 <jclulow> I assume the installer did not do it for you:?
20:34:57 <tsoome> I'm not really sure tbh, let me check other host
20:40:56 <tsoome> hm, my other OI also has separate var, I guess oi installer does offer the option, I do not think I cared to do manual change there:D
21:33:52 <tsoome> oh, it seems I was wrong, it is /opt/zfs-tests/tests/functional/rootpool/rootpool_003_neg making this mess.
21:35:04 <sommerfeld> so it was a destroy -f ..
21:35:09 <sommerfeld> (zfs destroy -f at least)
21:41:44 <antranigv> question: can I bootstrap illumos from scratch using something like hex0, or a self-bootstrapped tcc?
21:42:53 <tsoome> it is zfs rename -f 
21:45:42 <tsoome> antranigv of course....  but since no one probably has done it, we do not really know:D
21:45:55 <antranigv> tsoome looooool
21:46:22 <antranigv> okay, we're gathering a team here with govt funding to have a bootstrappable linux. I've pushed in to also try FreeBSD and illumos and they agreed
21:46:42 <antranigv> so I really need some guides for that
21:46:50 <antranigv> I know that tcc can't compile FreeBSD
21:47:17 <tsoome> we do depend on list of compiler features
21:47:24 <antranigv> but maybe I can use tcc to compile gcc or llvm, and then compile a modern version of gcc/llvm and then compile illumos and FreeBSD
21:47:27 <antranigv> same here :(
21:47:51 <rmustacc> If you were trying to go that way, I would use whatever your tcb is to bootstrap a gcc.
21:47:58 <rmustacc> And related.
21:48:52 <antranigv> rmustacc sorry, not familiar with the term, tcb?
21:49:02 <rmustacc> trusted compute base
21:49:38 <rmustacc> Basically start with the thing you trust or want to use (say tcc in this case) and build things incremetnally to get to a gcc.
21:49:51 <sommerfeld> the set of software (and hardware) which must be correct for the system's security guarantees to hold.
21:49:51 <antranigv> ohh okay, my brain was in a different context
21:49:58 <antranigv> yes, I am able to reach gcc 4.8
21:50:48 <jimklimov> illumos (-core at least) generally used specially patched gcc, like gcc-4.4.4-il and certain later versions
21:50:50 <antranigv> I know I can use gcc to compile and get old FreeBSD. I wonder if I can build some older versions of illumos as well
21:50:57 <sommerfeld> (if you're being particularly picky about this you'll be looking at things like keyboard firmware...)
21:51:16 <rmustacc> You can, or you can use gcc 4.8 to build gcc7/gcc10
21:51:39 <rmustacc> But I think there are probably other assumptions here like what system are you starting on that you're running tcc on.
21:52:21 <antranigv> that is what i don't know where to start...
21:52:25 <antranigv> (yet?)
21:52:27 <jimklimov> yeah, scrape chips layer by layer to make sure all the transistors match the blueprint ;)
21:53:11 <rmustacc> I don't know how to advise you there as it really depends on what your goals are.
21:54:28 <jimklimov> taking a step back: AFAIK we've long celebrated building "illumos on illumos" (might be even more distro specific); do we currently support (cross?-)building illumos on some other system?
21:54:45 <rmustacc> No, not really. It's not an explicit project goal.
21:55:05 <rmustacc> As we rely on using illumos tools to build and execute it (e.g. our ld, etc.).
21:56:07 <antranigv> rmustacc well the end goal is to have a system that can be "trusted". trusted in the sense that we've built everything from scratch. we're gonna start with hex0, then m2, then tcc, etc etc
21:56:20 <rmustacc> Sure, but what are you starting on?
21:56:53 <rmustacc> Presumably something has to run hex0 to create its block.
21:57:41 <antranigv> rmustacc yes. the current team has used Ubuntu and... Gentoo. they "felt" safe since they compiled gentoo from scratch, but I think its the same scenario there.
21:57:43 <rmustacc> Or is that you're starting assuming something you trust has built hex0?
21:58:24 <rmustacc> For your own sanity you have to assume something or it's a very deep well.
21:59:11 <antranigv> can I build a hardware system that generates hex0 on the hardware and I can scp(?) it? maybe
21:59:16 <antranigv> it's a very deep well indeed
22:00:27 <jimklimov> well, at some point certain models of Sun pizza-boxes were trusted in Russia since all the chip blueprints were provided, logically analyzed, and actual HW scraped to make sure it fits
22:01:00 <antranigv> o.O
22:01:02 <jimklimov> and then the OS sources were given in pre-OpenSolaris times (sol9, maybe 8?) for similar checks
22:01:25 <jimklimov> that gave a bit of "peace of mind" that allowed paper-ware stamp of security
22:02:08 <jimklimov> so the servers were allowed into some ministries etc.
22:02:25 <sommerfeld> another mechanism that people use to build trust is reproduceable builds - do you get the exact same set of executables out of builds on N different systems that were put together via different paths.
22:03:08 <jimklimov> surprisingly, R280's with a LOM card that included a PCMCIA cellular modem made the cut - too nice to pass by for very remote areas :)
22:03:18 <antranigv> sommerfeld that doesn't work on some systems like macOS btw, because Mach-O puts has a UUID
22:03:28 <antranigv> we've had that issue when we were porting our compiler to macOS
22:03:46 <antranigv> but I guess that's not our goal anyway. so yes. need to make sure that checksums are always the same
22:04:40 <jimklimov> "different paths" huh... is it even possible to coerce say gcc and clang to build binary identical products?
22:04:53 <sommerfeld> antranigv: yes, you sometimes need to define "same" in special ways (for instance, wsdiff ignores ELF timestamps)
22:05:34 <sommerfeld> jimklimov: need to take one step further back -- a gcc built with clang should hopefully generate the same code as a gcc built with gcc.
22:05:42 <antranigv> this chat is a lot more active (And technical) than I thought. maybe I should spend more time at #illumos. 
22:05:58 <jimklimov> ;)
22:06:22 <jimklimov> me too, got too pre-ossupied with other life stuff so only pop here once in a few weeks :(
22:09:02 <antranigv> my main "issue" is that my company is completely FreeBSD based and we have no "need" to move to illumos, altho our income is completely based on ZFS and DTrace
22:09:51 <jimklimov> you can argue at least for the cause of "shadow builds" or similar concept
22:10:18 <jimklimov> different toolkits and systems expose or ignore different flaws
22:11:28 <jimklimov> generally newer is better, but with NUT I occasionally have relevant hits from some older systems in the build matrix like CentOS6 or Solaris 8 that newer ones neglrected to mention
22:14:53 <jimklimov> at the very least, building same code with different generations of GCC and CLANG is helpful to ensure portability and weed out assumptions from PRs; doing that (and running tests) on different CPUs (bitness, endinanness) is too
22:16:36 <jimklimov> but even so, default build settings for something that claims to be similar versions of, say, gcc in Linux, OI or OpenBSD differs a lot by output and bugs found.
22:17:06 <otis> antranigv: you are lucky that you are not forced to use linux and docker, then. no?
22:17:17 <jimklimov> just because different distros seem to have different priorities, security-wise etc.
22:17:34 <antranigv> otis I've been told that I'm harsh towards some people and technologies, so I will answer with "no comment"
22:17:44 <jimklimov> :D
22:18:30 <jimklimov> - You crashed Dad's car! What did he say?
22:18:31 <jimklimov> - Can I omit the bad words? He was diplomatically quiet and ominous.