hrm..

anyone familiar with SPC-4? :)

i think the sd transport for fwflash misunderstands what the READ BUFFER descriptor value means

it's treating the BUFFER CAPACITY as the maximum firmware size, when I think it's really the maximum chunk size you can transfer

though it doesn't do a good job of making that clear

(it == standard)

jbk: I was in it in the past. Happy to look at something in particular if useful.

rmustacc: well mostly it seems like the logic surrounding sizing is wrong (or perhaps out of date)

it assumes that the descriptor size from READ BUFFER is the maximum _total_ size you can send to the device

while SPC-4 (and SAT-5) all don't actually say that, but seem to imply (it would be nice if they were explicit) that it is merely the max# you can send in one WRITE BUFFER request

i guess kinda like a bounce buffer

jbk: OK. I'll take a look again at that. It was probably my fault last time in there.

Does anybody know what could be wrong if a system says cannot mount root on /pseudo/lofi@1:b fstype zfs?

Does this picture upload work for people on IRC btw?

Yes

arent you on matrix?

I use Matrix, but not to access IRC

ah, ok so it's working good to know :)

the image is created with your image builder BTW. openindiana-noconfig

toasterson: The sequence of messages you have there implies to me that: [1] the firmware allowed the boot loader to read the kernel and boot archive and start booting, [2] the kernel did a full device scan because "/pseudo/lofi@1:b" is not a valid devices path for the pool it wants, [3] the kernel could not find the root disk because it's missing a driver or the driver (or something else) is

broken

I guess the lofi device path comes from the build process, so it should still find the disk though

We have virtio in the drivers right?

and driver/misc/virtio is installed in the image

Yes we have vioblk and recently vioscsi, though not everybody is installing the latter one yet probably

What kind of device is it emulating?

Yes, the lofi path comes from the image building process

sadly libvirt only has one virtio option

and it doesn't say which it is

but vioscsi did not get installed

What does the XML say

for the domain

Also what system profile are you using here

You might want to look at gist.github.com/jclulow/8e6a6dc530f5f6a0f5d0d9f9efa1b40b

I guess that's ... _probably_ vioblk?

It might be that your domain is not set up for legacy virtio or whatever

we don't do the 1.0+ thing yet

would help to get into kmdb and look at ::prtconf and ::msgbuf and so on probably

oh, I need to start making myself a sheatsheet of those. Specially for ARM :)

*cheatsheet

Yeah my guess is it is vioscsi that is needed even though it's named virtio in the xml

I'll try rebuilding the VM with your OSinfo

jclulow: yep it must have been a virtio scsi device. Using your xml to base of worked.

metadata agent starts :)

well if fstyp outputs volume_id, then searching for volume_label might not work.....

jclulow: thanks, that helped debug things.