00:00:39 our archive has an update from 2016 pointing to https://www.usenix.org/memoriam-roger-faulkner as "additional materials" 01:23:03 q 05:31:58 hrm..https://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 05:39:57 that isn't my recollection either 05:40:30 but I also think the difference isn't what you'd assume it is 05:40:39 in that (iirc) a zone that is _down_ down, should be "installed" 05:41:03 isn't naming things fun? 06:44:52 I just bounced on C-c because this keyboard is bad, and ksh93 gave me a snippet of its configuration. 06:45:15 Hopefully because it responded to a second SIGINT, but either way, a surprise! 06:45:59 https://gist.github.com/richlowe/6de2e4017121e2866f4909ff9d089cf8 08:33:11 I guess for illumos (PS)ARC has been sort of replaced with IPD's 08:33:55 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) 08:34:27 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) 14:52:51 hm, getting 504 from code.illumos.org 15:47:10 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 16:58:13 testing 17:07:12 Guest76: passed. 17:07:35 Thanks for the verification 17:07:47 It's my first time using IRC 17:09:17 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? 17:10:08 sure 17:12:02 And is this the right channel for beginners to ask questions? 17:12:44 dont worry, we will redirect you to the manuals if needed;) 17:13:28 Cool! 17:15:04 I usually try to consult the illumos or OpenSolaris manual pages and docs before reaching out 17:25:16 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. 17:29:01 I'll keep it in mind. Thanks for the advice 17:32:11 Timely advice 17:37:28 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 17:37:29 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)? 17:41:43 So in general if you don't run an incremental build, then nightly will do a clobber which should clean up everything. 17:42:00 So in general I find that I don't ever really do a manual clean up. 17:43:55 and clobber can take quite a while:) 17:57:38 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 18:00:07 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 18:52:48 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 18:52:49 /usr/perl5/5.36/bin/perl 18:58:53 What distro are you building on? 18:59:52 OpenIndiana 19:00:50 I guess they've changed how they've packed things then and probably need to provide instructions for an updated illumos.sh. 19:01:27 Usually it is in that spot, but I guess they've changed it. 19:07:24 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? 19:09:13 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. 19:10:51 You will also find some minor patches we apply for illumos-gate. 19:16:06 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 19:17:17 I am looking in the oi-userland repo now. I opened components/openindiana/illumos-gate/Makefile 19:18:41 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? 19:20:19 Yes, by default the illumos.sh lets folks specify the version so it isn't there in default. 19:25:33 Thank you 19:27:10 So the main place this comes is in Makefile.perl. I'm getting a link, one moment. 19:27:43 So the variables in illumos.sh are basically used for https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/perl/Makefile.perl. 19:32:20 https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/openindiana/illumos-gate/Makefile#L92-L107 19:32:32 This appears to be the mods that wacki descried above. 19:32:58 I don't use or build on OI, so I haven't executed anything like this personally, but hopefully this helps a little bit. 19:42:19 Thank you for sharing these links 19:43:01 I'll have to study these 19:44:15 It is getting over my head 19:44:52 Oops. I meant to send that as a single message 19:50:02 Yeah, most distros just supply a stock file so you don't have to figure this out yourself. 19:50:13 I'm not sure what the OI process is currently given the changes they've made. 19:54:14 wacki: Do you know if OI has docs on this that we can point someone at to speed up this confusion? 19:55:37 I have a pending pull request for illumos-docs which updates the OI recommendations: https://github.com/illumos/docs/pull/98 19:56:07 (it's been sitting for a while; not sure what secret handshake I'm missing to get it integrated) 19:56:22 OK. Is that information up to date sommerfeld? 19:56:30 We have https://docs.openindiana.org/dev/building-openindiana/ 19:56:34 I dunno. It wasn't clear I think to an outside reader that it was there or not. 19:56:34 sommerfeld: in my case it's stronger vyvanse lol 19:57:05 (Sorry, I was mostly out when this came in) 19:57:13 But that is very generic and does not mention the needed details. 19:57:34 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. 19:57:39 rmustacc: double-checking now 19:58:53 rmustacc: yes, that's up-to-date and will auto-sense the right perl version based on what's installed on the build machine. 19:59:58 OK, sounds good. jclulow you want to get that deployed? 20:00:13 rmustacc: I can, or you can! 20:00:28 I'll get it after I finish fixing gerrit 20:00:44 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 20:02:07 What are we deploying? 20:03:33 I'll have to step away for a while. Thanks for everyone's help 20:44:35 jclulow, tsoome: I think booting off sliced pools was an unableness of the booter to read it, rather than the to come up? 20:44:42 "than the OS to..." 20:44:59 (it's also not something I can understand wanting to do, fwiw) 20:47:18 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;) 20:48:29 right, I'm just confused by the bug, but also confused by why OS changes (especially that one) would have changed things 20:49:06 it feels like that would only matter if we had a striped pool _and also_ had lost one or more of the device paths 20:49:18 so the "wait, stripes work now?" part is still a mystery. 20:52:01 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. 21:07:34 richlowe: Well, and critically, if we're leaning on the 7119 mechanism every boot, the fix is incomplete 21:07:38 So we need to understand why it works 21:11:41 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. 21:15:17 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. 21:18:41 thats not quite so:D https://pastebin.mozilla.org/1eyxFYDb 21:23:27 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 21:25:02 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) 21:25:29 basically sommerfeld's "first boot after install" situation, but without an install 21:25:50 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 21:25:54 right 21:26:05 You're doing the installation on a third system ultimately 21:26:21 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 21:26:43 Ah, then yes! 21:27:38 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 21:29:02 cache file by itself is rather fragile mechanism 21:30:06 I think it's exactly as fragile as the boot stuff 21:30:26 rename your pool, forget to nuke the cache file, boot from it and you can have interesting stuff going on. 21:30:57 When you say "rename your pool", though, how are you doing that? 21:31:21 I believe the only supported way is to export it and then import it with a new name 21:31:22 boot from alternate media. or split the mirror and move disks 21:31:56 Certainly if you act entirely behind its back it's not going to be able to know about it haha 21:32:37 thats for sure, but, one must not blindly trust the data it has. 21:32:57 I agree we could be better at determining when subterfuge has occurred 21:33:26 If you have surprises like that happen, those are definitely bugs we should get filed 21:33:46 whether it's just that it didn't work, or especially if it does something unsafe 21:35:48 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. 21:39:45 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. 21:40:04 (something I'll own up to, at least a couple of times) 21:49:45 [illumos-gate] 16967 cxgbe: clean up unused TCP_OFFLOAD_ENABLE -- Patrick Mooney 21:53:50 jclulow: thanks again for keeping gerrit going! 21:54:41 richlowe: Sure; renaming a pool is supported, though, it just requires an export and an import. 21:54:53 sommerfeld: You're welcome! Doing my best haha 22:06:46 jclulow: yeah, but "if you just..." you have online rename 22:06:59 "if [you] just..." is the root of so much evil 22:07:29 I mean, you don't have online rename in the case that you reboot into other media haha 22:08:50 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 22:09:33 but be aware that for some things, the fix is to make you stop doing it 22:09:46 or at least notice if you did it wrong 22:10:15 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!" 22:10:52 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.... 22:12:06 We're always going to have open issues. If something new is found to be broken, we still need to file new ones 22:12:31 3291 open issues is not a lot 22:12:49 it's just a list of things that don't work, that's always good to know! 22:14:26 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 22:14:36 In fact they probably have the opposite effect on morale 22:20:58 sommerfeld: The docs stuff should be live at https://illumos.org/docs/developers/build/#openindiana_1 if you refresh 22:21:01 Thanks for that 22:22:36 jclulow: thanks again!