Well I got the GCC message to not have two -lpcaps and now its complaining about undefined symbols gist.github.com/Smithx10/7da0e300509930560eacc2fd7b4b99dc

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

So when they are in the aggregate its possible when i Pcacp on iface0 ill get iface1s ToR frame

linking is frustrating :)

I diiiidddd itttt woowoooooo hahaha

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.

Quick Sanity heck here..... using libpcap and setting a bpf to "ether proto lldp" shouldn't kill my box cpu / network perf right?

Smithx10: seems unlikely

connecting with libpcap and iterating over every frame would probably increase load yea? Or am I paranoid ?

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.

sigh. zpool destroy does unmount /var despite of /var/run mount :(

win 23

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.

[illumos-gate] 15916 bhyve upstream sync 2023 September -- Andy Fiddaman <illumos⊙fn>

THank you @andyf --> I'll hold off on upstream merges for tomorrow's SmartOS release branch. I can help with the followup.

tsoome: Did you "zpool destroy -f" ?

no

It probably didn't do the force unmount then

its /opt/zfs-tests/tests/functional/rootpool/rootpool_002_neg

I think -f also ends up skipping things like the sync() -- see #16128

it is supposed to try to destroy rpool, and fail + recover, however, it still does manage to unmount /var

and we have tempfs mount in /var/run ....

Oh, you're saying it _shouldn't_ unmount

ok

That's sad haha

yes, it should have refused to.

Yeah I understand now

I wonder why it was able to do that

and, I havent checked what did happen with /var/run - was it orphaned and still present in mnttab or what...

it certainly was not listed with df

Maybe it wasn't actually mounted?

it was.

we get it mounted early (filesystem/minimal) and we basically can not unmount it because init has open pipe there

unless with force

you have /var set up as a separate filesystem on this test machine?

yes, rpool/ROOT/openindiana-2024:01:09/var, otherwise it would be no problem:)

well, otherwise it would not have revealed the problem.

I think that's probably not a common configuration

from what I have seen

I assume the installer did not do it for you:?

I'm not really sure tbh, let me check other host

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

oh, it seems I was wrong, it is /opt/zfs-tests/tests/functional/rootpool/rootpool_003_neg making this mess.

so it was a destroy -f ..

(zfs destroy -f at least)

question: can I bootstrap illumos from scratch using something like hex0, or a self-bootstrapped tcc?

it is zfs rename -f

antranigv of course.... but since no one probably has done it, we do not really know:D

tsoome looooool

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

so I really need some guides for that

I know that tcc can't compile FreeBSD

we do depend on list of compiler features

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

same here :(

If you were trying to go that way, I would use whatever your tcb is to bootstrap a gcc.

And related.

rmustacc sorry, not familiar with the term, tcb?

trusted compute base

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.

the set of software (and hardware) which must be correct for the system's security guarantees to hold.

ohh okay, my brain was in a different context

yes, I am able to reach gcc 4.8

illumos (-core at least) generally used specially patched gcc, like gcc-4.4.4-il and certain later versions

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

(if you're being particularly picky about this you'll be looking at things like keyboard firmware...)

You can, or you can use gcc 4.8 to build gcc7/gcc10

But I think there are probably other assumptions here like what system are you starting on that you're running tcc on.

that is what i don't know where to start...

(yet?)

yeah, scrape chips layer by layer to make sure all the transistors match the blueprint ;)

I don't know how to advise you there as it really depends on what your goals are.

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?

No, not really. It's not an explicit project goal.

As we rely on using illumos tools to build and execute it (e.g. our ld, etc.).

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

Sure, but what are you starting on?

Presumably something has to run hex0 to create its block.

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.

Or is that you're starting assuming something you trust has built hex0?

For your own sanity you have to assume something or it's a very deep well.

can I build a hardware system that generates hex0 on the hardware and I can scp(?) it? maybe

it's a very deep well indeed

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

o.O

and then the OS sources were given in pre-OpenSolaris times (sol9, maybe 8?) for similar checks

that gave a bit of "peace of mind" that allowed paper-ware stamp of security

so the servers were allowed into some ministries etc.

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.

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 :)

sommerfeld that doesn't work on some systems like macOS btw, because Mach-O puts has a UUID

we've had that issue when we were porting our compiler to macOS

but I guess that's not our goal anyway. so yes. need to make sure that checksums are always the same

"different paths" huh... is it even possible to coerce say gcc and clang to build binary identical products?

antranigv: yes, you sometimes need to define "same" in special ways (for instance, wsdiff ignores ELF timestamps)

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.

this chat is a lot more active (And technical) than I thought. maybe I should spend more time at #illumos.

;)

me too, got too pre-ossupied with other life stuff so only pop here once in a few weeks :(

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

you can argue at least for the cause of "shadow builds" or similar concept

different toolkits and systems expose or ignore different flaws

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

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

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.

antranigv: you are lucky that you are not forced to use linux and docker, then. no?

just because different distros seem to have different priorities, security-wise etc.

otis I've been told that I'm harsh towards some people and technologies, so I will answer with "no comment"

:D

- You crashed Dad's car! What did he say?

- Can I omit the bad words? He was diplomatically quiet and ominous.