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

*one

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.

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.

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

just reading SPC-4 on it's own i did find it less than straighforward on that bit

(I kept going back and forth between SAT-5 READ/WRITE BUFFER and SPC-4 READ/WRITE BUFFER)

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.

Just given how the older modes worked

Does it help for me to adjust that at all or you'll manage that.

i can manage.. still tracking down some other bits on this yak shaving adventure :)

i just want to be sure i didn't miss anything

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

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

You can run an arm illumos under qemu now, it's being actively worked on.

psydroid: It already is but needs some more advertising so people find it :)

toasterson - do you know if qemu in OI has been fixed yet? If not I should maybe do a PR there

I haven't gotten around to it yet. SO a PR would be welcome

Toasterson, you can advertise it to me for a start :)

The rest works via a cross compile toolchain hosted at github.com/richlowe/arm64-gate

I'm more familiar with ARM and RISC-V than with x86

thanks

and downloads.omnios.org/media/braich for a mini-omnios based on that arm64-gate work.

The disk image there is updated every week or so with more userland packages

psydroid: In that case grep for `XXXARM` in this repo and start helping with whatever you know github.com/richlowe/illumos-gate

psydroid: Better use the omnios image then thats a bit further with packages

I will take a look at it, thanks

I need to become familiar with Illumos kernel architecture at last

psydroid: illumos.org/books/wdd/bookinfo.html#bookinfo

Toasterson, that's great, I'll go back to my cave and start reading

jclulow: 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.

toasterson, jclulow: Should SmartOS also be added to that?

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

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.

Wow: Accumulated power on time, hours:minutes 30877:38 [1852658 minutes]

That drive's been around the block a few times.

So this bit here: gist.github.com/Smithx10/029858ade4…d528df#file-gistfile1-txt-L534-L568

If we can compare with several disks we might be able to figure it out.

In particular, I'm looking at these:

attached initiator port: ssp=0 stp=0 smp=0

attached target port: ssp=0 stp=0 smp=1

attached phy identifier = 6

phy identifier = 1

ill iterate over all the drives and grab that info

attached SAS address = 0x0

attached phy identifier = 0

bahamat: Cool, will wait for that

If any of those are changing on every drive, then I think that might be it.

@bahamat gist.github.com/Smithx10/0b8dc8bec6f95ebb0d63dd98fa9c9990

Holy shit, sorry folks. I thought that was all going into private message :-(

and now all the secrets are out... or something. :-P

Not secret or anything, but I was pasting stuff, which I generally try to avoid

tsoome: is there somewhere you can post the wsdiff report from 15290? (you mentioned it's too large for redmine)

I'd like to look at that before approving

sure, a min...

rgr

have to remember how to use webrev:D

I'm looking for the wsdiff output, not webrev

ou, stupid me:D

I blame this stuff my kid got us (running nose and barking cough)

Ouch.

Nice things about having 20-year-olds is that they are no longer bringing things like that home. :)

eh, well, you can hope:)

I wont tell how old one born at '71 is... :P

Two years younger than me.

pmooney 148-52-235-80.sta.estpak.ee/report.txt

tsoome: got it, thanks

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." ncbi.nlm.nih.gov/pmc/articles/PMC9388132

toasterson: I think this will do it? gist.github.com/bahamat/a5e08922a597982177a64588a4add6fa

I'm not entirely sure what all of those values are supposed to be.

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

sommerfeld aye.

Yeah, I copied the omnios one and only changed lines 4-9

But I'm not sure if vendor should be all lower case, or if it's allowed to have spaces

@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!")

and the os id, could be smartos.org/live/rolling, if they don't like smartos.org/smartos/rolling

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

toasterson: I found the osinfo experience very frustrating. I just want what they have for Linux, a generic distro-less baseline

bahamat: You get mails yes. It's ok like this and probably wont need you involved further.

jclulow: I can get why. They seems to have their own idea. Unfortunately I am rather resistant to this kinds of frustrations.

Let's see if we can at least get some definitions in.

Yeah, hopefully we'll get something at least.

I just send people the gist lol

A one man osinfo-db overlay

Hahahahaha, gistoverlay

gist an overlay

tsoome: could you run another wsdiff report, but this time against only the proto areas (old vs new) for 15290?

jperkin: danmcd asks that you look at code.illumos.org/c/illumos-gate/+/2620 for the gstrip fix

→ CODE REVIEW 2620: 15361 ld doesn't fill out PT_DYNAMIC sufficiently for binutils 2.40 (NEW) | illumos.org/issues/15361

it should cut the size down significantly and make it easier to review (and probably small enough to include in the ticket)

sure, just need to build one first:)

Since the ultimate artifacts which we care about are in the proto area, it should mean adequate coverage

and a lot less noise

thanks

jclulow: Question about your image-builder the password you use in the noconfig template. is that simply <Enter>?

yes

pmooney now it was small enough to get attached to the issue

tsoome: perfect, thanks

I'll take a look at that shortly

thanks!

Welp.... I never though I could'nt write our cloud init because of a service dependency problem in illumos-gate....

Does somebody know when exactly we mount datasets like /export/home?

filesystem/local it seems

Welll... (full message at <libera.ems.host/_matrix/media/v3/do…a34fe8b25f95de0ac9ea39fd312d90c2d96>)

ah, good old svc:/system/illumos/metadata

no thats not that service :)

if you're using jclulow's image builder, it feels like you pulled in cloud bits only partially?

noconfig should have no config.

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

the manifest of metadata agent

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

err

so, no, we should not do that

necessarily

we might need multiple stages

The metadata agent is currently very carefully arranged to happen before networking and host identity stuff kicks off, which is all very early

thats the alternative. but I do not see why zfs mount -a requires network

That's part of why the user-script is punted to a separate service that runs _much_ later (maybe after multi-user)

err should single user already require networking?

No

no

single user is for unbreaking things like networking

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.

let me verify then quickly

Yeah, if you want to create users or what have you, I think that should all happen much later

but it's been a long time, and I'm not sure

if you're dealing with users, that needs to happen at multi-user-server or so

Right

jclulow: I said I'd send you a branch yesterday then didn't, I might get to it today

That's where github.com/illumos/metadata-agent/blob/master/userscript.xml runs, and is probably where things like user creation should run too

richlowe: rgr!

so: single user does depend on network/physical once directly and once via system/identity both with optional_all

SO i guess it's only optional

Well, not so optional... (full message at <libera.ems.host/_matrix/media/v3/do…dc78e100c287f369a5c240c9ebb352cce40>)

so network has to run for single-user if I reas this correctly

no it can also be broken

or unable to start

"or do not run without administrative action"

i.e., in maintenance, or disabled, or cannot start because of something else which is broken

ah, ok

What was the idea behind optional_all?

I believe the intent is to allow for sequencing without hard failures

i.e., if this other thing is starting up, we'll wait for it to try; if it fails, we'll drive on anyway

yeah but then it's sequenced after networking

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

(or if networking goes into maintenance because of some bug or illegal configuration)

ok, but we can not insert any new service before fs-local and after networking then. THat means I need to split metadata agent

Right

That's why I suggested we might need multiple stages

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)

e.g., if you're installing packages

or downloading files or whatever it is

I try to avoid cloud-init where I can so I'm not sure the full extent of it :P

Yep I am just a bit stubborn with wanting it in that spot :)

The metadata agent is, to be honest, architected as a rejection of the complexity of cloud-init

Really I suspect you could do things like user management in a user-script

Complexity is one thing... Having a ton of undocumented fetures is my main concern

In cloud-init, or the metadata-agent?

I simply skip them :)

cloud-init

Yeah, I mean, I think the only way to be cloud-init compatible is to run cloud-init

Unless there is a secret cloud-init specification and verification suite that I've missed haha

the cloud-config format was the only one I wanted since on both linux and illumos would have the same format

and you can generate it from data without having to template a shellscript

There is a documentation that works but well...

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

The rest I can handle with the autoinstaller

which will be it's own thing

It might help to make the changes in phases like that yeah

technically I can also bug our sysding for a couple of things