our archive has an update from 2016 pointing to usenix.org/memoriam-roger-faulkner as "additional materials"

q

hrm..illumos.org/man/7/zones <-- that seems like 'DOWN' should have it's own explanation the current formatting implies (to me at least) SHUTTING_DOWN and DOWN are synonymous, but i'm fairly sure that's not true

that isn't my recollection either

but I also think the difference isn't what you'd assume it is

in that (iirc) a zone that is _down_ down, should be "installed"

isn't naming things fun?

I just bounced on C-c because this keyboard is bad, and ksh93 gave me a snippet of its configuration.

Hopefully because it responded to a second SIGINT, but either way, a surprise!

I guess for illumos (PS)ARC has been sort of replaced with IPD's

Hadn't had the time to look more into the L3 mode mentioned in combination with zones, what I've been trying is probably the default L2 mode (didn't even know where multiple modes)

But that could explain it being stuck in INIT and the error being caused by CARP was a red herring (I never got this expression)

hm, getting 504 from code.illumos.org

yeah.. i found an old change that (mandoc conversion) that for some reason I seem to have forgotten to put up for review and tried to do it last night, but it was hanging

testing

Guest76: passed.

Thanks for the verification

It's my first time using IRC

I am having trouble finding solutions to some questions about illumos development on third party forums. Is this the right place to ask questions about illumos development?

sure

And is this the right channel for beginners to ask questions?

dont worry, we will redirect you to the manuals if needed;)

Cool!

I usually try to consult the illumos or OpenSolaris manual pages and docs before reaching out

The main advice for questions is just that sometimes there will be a delay depending on folks availability so just make sure to stick around as folks are often in different time zones.

I'll keep it in mind. Thanks for the advice

Timely advice

Well, one question that I have is about the build. I made a mistake in illumos.sh and the build completed although the packages were not present in /illumos-gate post build. I did manage to find the error in the logs and change the variable. Upon attempting to build again, it seemed that the build was hanging as tailing nightly.log did not produce

any output. I removed the directories produced during the build, and the build began, seemingly per normal. My question is this; is there a more idiomatic way of preparing for a build than doing what I did (simply removing the directories produced by the build, and running .../nightly again)?

So in general if you don't run an incremental build, then nightly will do a clobber which should clean up everything.

So in general I find that I don't ever really do a manual clean up.

and clobber can take quite a while:)

Well, I suppose that it's safe to assume that when I tried to do the rebuild (not incremental), that no output was being produced because it was doing a clobber

Now, seeing that I made a mistake in the Makefile variables, is there no way to avoid doing a full rebuild after updating the variables in illumos.sh? I hadn't used the right Perl variables, and I find it hard to believe that an entire rebuild is necessary, considering what seems like a minor change

The rebuild failed again. The compilation passed, but there is no /packages in /illumos-gate. The mail_msg is showing that the command for target perl failed. Apparently perl should be in /usr/perl5/5.36/bin/i386/perl or /usr/perl5/5.36/bin/amd64/perl? At least according to the this log? Yet, the only place I have found it is in

/usr/perl5/5.36/bin/perl

What distro are you building on?

OpenIndiana

I guess they've changed how they've packed things then and probably need to provide instructions for an updated illumos.sh.

Usually it is in that spot, but I guess they've changed it.

I read through illumos.sh twice over and didn't find any reference to the path to perl. I am trying to modify it to point to the right place. Where should the path be, so that I might change it?

When you clone oi-userland you will find components/openindiama/illumos-gate. This is our build area for illumos-gate. We use the provided illumos.sh from illumos-gate but have some environment variables defined in our Makefile. The last perl related change was from July of this year.

You will also find some minor patches we apply for illumos-gate.

I looked in the vanilla illumos-gate/usr/src/tools/scripts/Makefile and did not come across any obvious references to the path that is being used for perl

I am looking in the oi-userland repo now. I opened components/openindiana/illumos-gate/Makefile

And I haven't found the reference to the path for searching for perl. Please bear in mind that I am a beginner. Where might I locate this path?

Yes, by default the illumos.sh lets folks specify the version so it isn't there in default.

Thank you

So the main place this comes is in Makefile.perl. I'm getting a link, one moment.

So the variables in illumos.sh are basically used for github.com/illumos/illumos-gate/blo…ster/usr/src/cmd/perl/Makefile.perl.

This appears to be the mods that wacki descried above.

I don't use or build on OI, so I haven't executed anything like this personally, but hopefully this helps a little bit.

Thank you for sharing these links

I'll have to study these

It is getting over my head

Oops. I meant to send that as a single message

Yeah, most distros just supply a stock file so you don't have to figure this out yourself.

I'm not sure what the OI process is currently given the changes they've made.

wacki: Do you know if OI has docs on this that we can point someone at to speed up this confusion?

I have a pending pull request for illumos-docs which updates the OI recommendations: illumos/docs #98

(it's been sitting for a while; not sure what secret handshake I'm missing to get it integrated)

OK. Is that information up to date sommerfeld?

We have docs.openindiana.org/dev/building-openindiana

I dunno. It wasn't clear I think to an outside reader that it was there or not.

sommerfeld: in my case it's stronger vyvanse lol

(Sorry, I was mostly out when this came in)

But that is very generic and does not mention the needed details.

OK. I think getting something on the OI site that describes stuff in addition to whatever we do at the docs at our end would help.

rmustacc: double-checking now

rmustacc: yes, that's up-to-date and will auto-sense the right perl version based on what's installed on the build machine.

OK, sounds good. jclulow you want to get that deployed?

rmustacc: I can, or you can!

I'll get it after I finish fixing gerrit

there is also another tweak to the external package stuff in illumos-gate needed due to the /32 package naming crud in OI but the only effect of that is noise in the mail_msg file

What are we deploying?

I'll have to step away for a while. Thanks for everyone's help

jclulow, tsoome: I think booting off sliced pools was an unableness of the booter to read it, rather than the to come up?

"than the OS to..."

(it's also not something I can understand wanting to do, fwiw)

That was definitely contributing factor, but I am quite sure I did attempt to boot from striped setup with loader -- however, can not be 100% sure;)

right, I'm just confused by the bug, but also confused by why OS changes (especially that one) would have changed things

it feels like that would only matter if we had a striped pool _and also_ had lost one or more of the device paths

so the "wait, stripes work now?" part is still a mystery.

richlowe: I can imagine in some cases being constrained in how many storage devices you could attach and not wanting to burn one or two on a separate root/boot pool.

richlowe: Well, and critically, if we're leaning on the 7119 mechanism every boot, the fix is incomplete

So we need to understand why it works

looking at the 7119 fix, it does look somewhat chatty in the logs -- so we should be able to tell from system logs whether 7119 is load-bearing on striped pools.

wouldn't be surprised if it was just a "first boot after install" thing due to some difference in drivers loaded from install media vs driver loaded from freshly-installed system.

thats not quite so:D pastebin.mozilla.org/1eyxFYDb

sommerfeld: We store the /devices path rather than the /dev path so generally even if things come and go we can find the right one from installer to first boot

7119 is not so much chatty, as it says "Hi" and also when it succeeded. (for me, it _is_ in the active boot path, because I never moved to the better fix for image building yet)

basically sommerfeld's "first boot after install" situation, but without an install

I anticipate that it will ultimately always fire in "build and image, dd an image" situations like cloud systems or writing things onto boot media and inserting them into systems like you're doing, richlowe

right

You're doing the installation on a third system ultimately

yeah, I was just explaining that I see it often and the boot logging is just the right amount of noticable when it's load bearing

Ah, then yes!

FWIW, it's certainly possible to extend the scan mechanism so that it works with more complex topologies, and for secondary pools from the cache file, but I haven't needed to do that myself yet

cache file by itself is rather fragile mechanism

I think it's exactly as fragile as the boot stuff

rename your pool, forget to nuke the cache file, boot from it and you can have interesting stuff going on.

When you say "rename your pool", though, how are you doing that?

I believe the only supported way is to export it and then import it with a new name

boot from alternate media. or split the mirror and move disks

Certainly if you act entirely behind its back it's not going to be able to know about it haha

thats for sure, but, one must not blindly trust the data it has.

I agree we could be better at determining when subterfuge has occurred

If you have surprises like that happen, those are definitely bugs we should get filed

whether it's just that it didn't work, or especially if it does something unsafe

Gerrit News: It should be back now! It's also updated to 3.10.3! I've also blocked some new spam crawlers. Let me know if you have any issues with it.

I think a lot of the tricks played behind our back, at the ZFS layer, are probably because things are not supported and people try to do them by hand.

(something I'll own up to, at least a couple of times)

[illumos-gate] 16967 cxgbe: clean up unused TCP_OFFLOAD_ENABLE -- Patrick Mooney <pmooney⊙pc>

jclulow: thanks again for keeping gerrit going!

richlowe: Sure; renaming a pool is supported, though, it just requires an export and an import.

sommerfeld: You're welcome! Doing my best haha

jclulow: yeah, but "if you just..." you have online rename

"if [you] just..." is the root of so much evil

I mean, you don't have online rename in the case that you reboot into other media haha

To be clear, I'm sure we could support a lot more stuff -- and also people should absolutely file bugs when things don't work, or especiallly when they do unsafe things

but be aware that for some things, the fix is to make you stop doing it

or at least notice if you did it wrong

Right that's what I mean by "unsafe things" -- e.g., we should stop and say "it looks like you did something weird" rather than "here I come to corrupt the memory!"

Except there is this little thing.... well, sure, we are failing those issues and could also do better, but then again.. we do have some 3291 open atm....

We're always going to have open issues. If something new is found to be broken, we still need to file new ones

3291 open issues is not a lot

it's just a list of things that don't work, that's always good to know!

I would also suggest that constant passive aggressive digs at the project for being a small community rarely work to motivate people to work harder

In fact they probably have the opposite effect on morale

sommerfeld: The docs stuff should be live at illumos.org/docs/developers/build/#openindiana_1 if you refresh

Thanks for that

jclulow: thanks again!