01:46:26 <jclulow> toasterson: If using the gisted XML helped, it was probably not the vioscsi thing -- rather, that the XML constrains it to be a legacy virtio device not the modern speco ne
01:46:28 <jclulow> *one
03:41:28 <rmustacc> jbk: Reading spc4 again with older eyes, I agree that it could be read that way. I did interpret it the way it was a while back, but I think it basically gets to the question of what that buffer represents. Looking at SPC-4 r37 (the public review version), from §5.4 and other places, it's pretty clear that multiple commands can happen.
03:42:09 <rmustacc> I'd feel better if I could grab some SAS device internal docs here, but it does seem likely that it is an operation-specific length and that I made an erroneous conclusion in 2016.
04:32:35 <jbk> the one thing that made me go 'huh' was how SAT-5 says READ BUFFER for mode 3 (descriptor) is emulated -- basically the values are hardcoded to 2^9 alignment and buffer size of 512 bytes for buffer 0... yet it also tells you how to translate WRITE BUFFER to DOWNLOAD MICROCODE... and it seemed unlikely that the entire SATA microcode could fit in 512 bytes :)
04:33:19 <jbk> just reading SPC-4 on it's own i did find it less than straighforward on that bit
04:38:39 <jbk> (I kept going back and forth between SAT-5 READ/WRITE BUFFER and SPC-4 READ/WRITE BUFFER)
04:44:49 <rmustacc> I'll track downa copy of SAT-5 then. I didn't look at that. Thanks for the pointer. I think that does suggest that it's just an intermediate buffer where as I originally took it as the entire buffer.
04:45:05 <rmustacc> Just given how the older modes worked
04:45:41 <rmustacc> Does it help for me to adjust that at all or you'll manage that.
04:47:06 <jbk> i can manage.. still tracking down some other bits on this yak shaving adventure :)
04:48:47 <jbk> i just want to be sure i didn't miss anything
10:24:18 <toasterson> jclulow: In that case I'll make a XML for OI and maybe symlink the omnios bloody to it, It seems they want some sort of year release so we could timestamp it to 2021 or so
10:25:19 <toasterson> or better 2023. Then in future changes we can add vioscsi and I'll check that we start delivering that in Iso's in OI aswell so we can start with a good set of features
10:54:04 * psydroid wonders if and when native ARM and RISC-V Illumos VMs will be made available for development purposes
10:57:49 <andyf> You can run an arm illumos under qemu now, it's being actively worked on.
10:58:41 <toasterson> psydroid: It already is but needs some more advertising so people find it :)
10:59:39 <andyf> toasterson - do you know if qemu in OI has been fixed yet? If not I should maybe do a PR there
11:00:28 <toasterson> I haven't gotten around to it yet. SO a PR would be welcome
11:01:34 <psydroid> Toasterson, you can advertise it to me for a start :)
11:01:36 <toasterson> https://dlc.openindiana.aurora-opencloud.org/aarch64/
11:02:41 <toasterson> The rest works via a cross compile toolchain hosted at https://github.com/richlowe/arm64-gate
11:02:46 <psydroid> I'm more familiar with ARM and RISC-V than with x86
11:02:53 <psydroid> thanks
11:03:01 <andyf> and https://downloads.omnios.org/media/braich/ for a mini-omnios based on that arm64-gate work.
11:03:16 <andyf> The disk image there is updated every week or so with more userland packages
11:03:55 <toasterson> psydroid: In that case grep for `XXXARM` in this repo and start helping with whatever you know https://github.com/richlowe/illumos-gate
11:04:47 <toasterson> psydroid: Better use the omnios image then thats a bit further with packages
11:05:46 <psydroid> I will take a look at it, thanks
11:06:24 <psydroid> I need to become familiar with Illumos kernel architecture at last
11:06:44 <toasterson> psydroid: https://illumos.org/books/wdd/bookinfo.html#bookinfo
11:15:23 <psydroid> Toasterson, that's great, I'll go back to my cave and start reading
11:20:43 <toasterson> jclulow: https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/554 I am going to push that one forward a bit. Lets see that we at least have some entry we can fall back to. I get that they want to be able to support older releases even if we don't. 
15:18:19 <bahamat> toasterson, jclulow: Should SmartOS also be added to that?
15:20:09 <toasterson> bahamat: can. drop me a gist with the names how you would like them. pci defs are the same and the ids I need to update anyway
15:21:31 <bahamat> Ok. I'll get that over to you later today. I've got about 2h worth of stuff I have to take care of first though.
15:22:47 <bahamat> Wow: Accumulated power on time, hours:minutes 30877:38 [1852658 minutes]
15:23:07 <bahamat> That drive's been around the block a few times.
15:24:36 <bahamat> So this bit here: https://gist.github.com/Smithx10/029858ade4296e85bb6532eb52d528df#file-gistfile1-txt-L534-L568
15:24:46 <bahamat> If we can compare with several disks we might be able to figure it out.
15:25:02 <bahamat> In particular, I'm looking at these:
15:25:03 <bahamat> attached initiator port: ssp=0 stp=0 smp=0
15:25:03 <bahamat> attached target port: ssp=0 stp=0 smp=1
15:25:08 <bahamat> attached phy identifier = 6
15:25:17 <bahamat> phy identifier = 1
15:25:27 <Smithx10> ill iterate over all the drives and grab that info
15:25:31 <bahamat> attached SAS address = 0x0
15:25:31 <bahamat> attached phy identifier = 0
15:26:26 <toasterson> bahamat: Cool, will wait for that
15:26:30 <bahamat> If any of those are changing on every drive, then I think that might be it.
15:35:58 <Smithx10> @bahamat  https://gist.github.com/Smithx10/0b8dc8bec6f95ebb0d63dd98fa9c9990
15:37:58 <bahamat> Holy shit, sorry folks. I thought that was all going into private message :-(
15:39:19 <nahamu> and now all the secrets are out... or something. :-P
15:44:01 <bahamat> Not secret or anything, but I was pasting stuff, which I generally try to avoid 
16:36:21 <pmooney> tsoome: is there somewhere you can post the wsdiff report from 15290? (you mentioned it's too large for redmine)
16:36:32 <pmooney> I'd like to look at that before approving
16:36:44 <tsoome> sure, a min...
16:36:55 <pmooney> rgr
16:37:11 <tsoome> have to remember how to use webrev:D
16:42:52 <pmooney> I'm looking for the wsdiff output, not webrev
16:43:13 <tsoome> ou, stupid me:D
16:44:01 <tsoome> I blame this stuff my kid got us (running nose and barking cough)
16:44:44 <danmcd> Ouch.
16:45:09 <danmcd> Nice things about having 20-year-olds is that they are no longer bringing things like that home.  :)
16:45:20 * danmcd feels really old now.
16:45:26 <tsoome> eh, well, you can hope:)
16:45:47 <tsoome> I wont tell how old one born at '71 is... :P
16:45:59 <danmcd> Two years younger than me.
16:46:29 <tsoome> pmooney http://148-52-235-80.sta.estpak.ee/report.txt
16:50:25 <pmooney> tsoome: got it, thanks
16:50:35 <sommerfeld> The stuff they bring home may be good for you in the long run: "In a large, real-world population, exposure to young children was strongly associated with less severe COVID-19 illness, after balancing known COVID-19 risk factors. This epidemiologic signal suggests endemic coronavirus cross-immunity may play a role in protection against severe COVID-19 outcomes."  https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9388132/
16:51:35 <bahamat> toasterson: I think this will do it? https://gist.github.com/bahamat/a5e08922a597982177a64588a4add6fa
16:51:49 <bahamat> I'm not entirely sure what all of those values are supposed to be.
16:52:47 <toasterson> The devices only will need an upgrade once we have new drivers so should be unchanged. The others are just there to identify the os and release
16:52:58 <tsoome> sommerfeld aye.
16:56:08 <bahamat> Yeah, I copied the omnios one and only changed lines 4-9 
16:56:46 <bahamat> But I'm not sure if vendor should be all lower case, or if it's allowed to have spaces
16:56:55 <danmcd> @sommerfeld I'm just saying I'm glad mine are old enough to not have to deal with it now.  (To paraphrase the French knights.  "We already got some... it's very nice!")
16:57:12 <bahamat> and the os id, could be http://smartos.org/live/rolling, if they don't like http://smartos.org/smartos/rolling
16:59:44 <bahamat> Let me know if you need anything else. I turned on notifications for that ticket, but I'm not sure how those are supposed to come to me (I would presume email...)
17:30:01 <jclulow> toasterson: I found the osinfo experience very frustrating.  I just want what they have for Linux, a generic distro-less baseline 
18:16:40 <toasterson> bahamat: You get mails yes. It's ok like this and probably wont need you involved further.
18:17:07 <toasterson> jclulow: I can get why. They seems to have their own idea. Unfortunately I am rather resistant to this kinds of frustrations.
18:18:01 <toasterson> Let's see if we can at least get some definitions in.
18:23:01 <bahamat> Yeah, hopefully we'll get something at least.
18:33:58 <jclulow> I just send people the gist lol
18:34:08 <jclulow> A one man osinfo-db overlay 
18:34:24 <toasterson> Hahahahaha, gistoverlay
18:34:29 <toasterson> gist an overlay
19:24:18 <pmooney> tsoome: could you run another wsdiff report, but this time against only the proto areas (old vs new) for 15290?
19:24:46 <richlowe> jperkin: danmcd asks that you look at https://code.illumos.org/c/illumos-gate/+/2620 for the gstrip fix
19:24:48 <fenix> → CODE REVIEW 2620: 15361 ld doesn't fill out PT_DYNAMIC sufficiently for binutils 2.40 (NEW) | https://www.illumos.org/issues/15361
19:24:52 <pmooney> it should cut the size down significantly and make it easier to review (and probably small enough to include in the ticket)
19:25:09 <tsoome> sure, just need to build one first:)
19:25:33 <pmooney> Since the ultimate artifacts which we care about are in the proto area, it should mean adequate coverage
19:25:38 <pmooney> and a lot less noise
19:25:56 <pmooney> thanks
19:39:07 <toasterson> jclulow: Question about your image-builder the password you use in the noconfig template. is that simply <Enter>?
19:39:19 <richlowe> yes
21:03:49 <tsoome> pmooney now it was small enough to get attached to the issue
21:03:58 <pmooney> tsoome: perfect, thanks
21:04:04 <pmooney> I'll take a look at that shortly
21:04:26 <tsoome> thanks!
21:44:20 <toasterson> Welp.... I never though I could'nt write our cloud init because of a service dependency problem in illumos-gate.... 
21:47:04 <toasterson> Does somebody know when exactly we mount datasets like /export/home?
21:48:35 <toasterson> filesystem/local it seems
21:54:31 <toasterson> Welll... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/692c2a34fe8b25f95de0ac9ea39fd312d90c2d96>)
21:56:31 <tsoome> ah, good old svc:/system/illumos/metadata
21:57:36 <toasterson> no thats not that service :)
21:57:37 <richlowe> if you're using jclulow's image builder, it feels like you pulled in cloud bits only partially?
21:58:05 <richlowe> noconfig should have no config.
21:58:49 <toasterson> richlowe Iam, but I needed to modify the manifest to make sure zfs filesystems are mounted before we start other it can't add users
21:59:11 <toasterson> the manifest of metadata agent
22:00:46 <toasterson> And it's not the first time we get this loop. you somehow can't properly insert a service before network but after filesystem local
22:00:46 <jclulow> err
22:00:52 <jclulow> so, no, we should not do that
22:00:57 <jclulow> necessarily
22:01:09 <jclulow> we might need multiple stages
22:01:30 <jclulow> The metadata agent is currently very carefully arranged to happen before networking and host identity stuff kicks off, which is all very early
22:01:50 <toasterson> thats the alternative. but I do not see why zfs mount -a requires network
22:01:51 <jclulow> That's part of why the user-script is punted to a separate service that runs _much_ later (maybe after multi-user)
22:02:13 * jclulow shrug
22:02:59 <toasterson> err should single user already require networking?
22:03:03 <jclulow> No
22:03:04 <richlowe> no
22:03:16 <jclulow> single user is for unbreaking things like networking
22:03:23 <richlowe> and I think zfs does because when the stuff mounts the share* properties will come alive, and if the network is down that won't work right.
22:03:39 <toasterson> let me verify then quickly
22:03:41 <jclulow> Yeah, if you want to create users or what have you, I think that should all happen much later
22:03:42 <richlowe> but it's been a long time, and I'm not sure
22:03:54 <richlowe> if you're dealing with users, that needs to happen at multi-user-server or so
22:04:01 <jclulow> Right
22:04:18 <richlowe> jclulow: I said I'd send you a branch yesterday then didn't, I might get to it today
22:04:35 <jclulow> That's where https://github.com/illumos/metadata-agent/blob/master/userscript.xml runs, and is probably where things like user creation should run too
22:04:47 <jclulow> richlowe: rgr!
22:06:18 <toasterson> so: single user does depend on network/physical once directly and once via system/identity both with optional_all
22:06:26 <toasterson> SO i guess it's only optional
22:07:43 <toasterson> Well, not so optional... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/7968cdc78e100c287f369a5c240c9ebb352cce40>)
22:08:32 <toasterson> so network has to run for single-user if I reas this correctly
22:09:53 <jclulow> no it can also be broken
22:10:06 <jclulow> or unable to start
22:10:21 <jclulow> "or do not run without administrative action"
22:10:44 <jclulow> i.e., in maintenance, or disabled, or cannot start because of something else which is broken
22:10:51 <toasterson> ah, ok
22:11:12 <toasterson> What was the idea behind optional_all?
22:11:35 <jclulow> I believe the intent is to allow for sequencing without hard failures
22:11:49 <jclulow> i.e., if this other thing is starting up, we'll wait for it to try; if it fails, we'll drive on anyway
22:12:01 <toasterson> yeah but then it's sequenced after networking
22:12:30 <jclulow> yes but if networking is disabled, or depends on something else that can't start, it doesn't prevent us getting to single user, critically
22:12:53 <jclulow> (or if networking goes into maintenance because of some bug or illegal configuration)
22:13:42 <toasterson> ok, but we can not insert any new service before fs-local and after networking then. THat means I need to split metadata agent
22:15:46 <jclulow> Right
22:16:12 <jclulow> That's why I suggested we might need multiple stages
22:16:51 <jclulow> A lot of what I suspect people do with cloud-init should likely happen around the same time as the user-script anyway (i.e., much later)
22:16:58 <jclulow> e.g., if you're installing packages
22:17:05 <jclulow> or downloading files or whatever it is
22:17:20 <jclulow> I try to avoid cloud-init where I can so I'm not sure the full extent of it :P
22:17:33 <toasterson> Yep I am just a bit stubborn with wanting it in that spot :)
22:17:58 <jclulow> The metadata agent is, to be honest, architected as a rejection of the complexity of cloud-init
22:18:11 <jclulow> Really I suspect you could do things like user management in a user-script
22:18:50 <toasterson> Complexity is one thing... Having a ton of undocumented fetures is my main concern
22:19:13 <jclulow> In cloud-init, or the metadata-agent?
22:19:14 <toasterson> I simply skip them :)
22:19:22 <toasterson> cloud-init
22:19:38 <jclulow> Yeah, I mean, I think the only way to be cloud-init compatible is to run cloud-init
22:20:56 <jclulow> Unless there is a secret cloud-init specification and verification suite that I've missed haha
22:21:01 <toasterson> the cloud-config format was the only one I wanted since on both linux and illumos would have the same format
22:21:02 <toasterson> and you can generate it from data without having to template a shellscript
22:21:58 <toasterson> There is a documentation that works but well...
22:22:38 <toasterson> I guess I can also skip user configuration and simply allow root password change and ssh key deployment. then all features I need are covered
22:22:55 <toasterson> The rest I can handle with the autoinstaller
22:23:01 <toasterson> which will be it's own thing
22:23:49 <jclulow> It might help to make the changes in phases like that yeah
22:24:00 <toasterson> technically I can also bug our sysding for a couple of things