01:03:17 hrm.. 01:04:56 anyone familiar with SPC-4? :) 01:07:47 i think the sd transport for fwflash misunderstands what the READ BUFFER descriptor value means 01:08:49 it's treating the BUFFER CAPACITY as the maximum firmware size, when I think it's really the maximum chunk size you can transfer 01:09:00 though it doesn't do a good job of making that clear 01:09:11 (it == standard) 04:35:34 jbk: I was in it in the past. Happy to look at something in particular if useful. 19:41:10 rmustacc: well mostly it seems like the logic surrounding sizing is wrong (or perhaps out of date) 19:43:42 it assumes that the descriptor size from READ BUFFER is the maximum _total_ size you can send to the device 19:44:32 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 19:45:09 i guess kinda like a bounce buffer 20:03:49 jbk: OK. I'll take a look again at that. It was probably my fault last time in there. 23:08:17 Does anybody know what could be wrong if a system says cannot mount root on /pseudo/lofi@1:b fstype zfs? 23:08:21 * toasterson uploaded an image: (117KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/zBGjUNdRFetGAHdcqcuecuig/image.png > 23:08:44 Does this picture upload work for people on IRC btw? 23:16:28 Yes 23:16:52 arent you on matrix? 23:17:02 I use Matrix, but not to access IRC 23:17:32 ah, ok so it's working good to know :) 23:18:04 the image is created with your image builder BTW. openindiana-noconfig 23:18:41 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 23:18:43 broken 23:20:10 I guess the lofi device path comes from the build process, so it should still find the disk though 23:20:42 We have virtio in the drivers right? 23:21:57 and driver/misc/virtio is installed in the image 23:22:17 Yes we have vioblk and recently vioscsi, though not everybody is installing the latter one yet probably 23:22:30 What kind of device is it emulating? 23:22:51 Yes, the lofi path comes from the image building process 23:23:10 sadly libvirt only has one virtio option 23:23:25 and it doesn't say which it is 23:23:38 but vioscsi did not get installed 23:24:07 What does the XML say 23:24:09 for the domain 23:24:24 Also what system profile are you using here 23:24:49 You might want to look at https://gist.github.com/jclulow/8e6a6dc530f5f6a0f5d0d9f9efa1b40b 23:24:56 * toasterson sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/6a8c8be0d89a7d44521e08ac55b3015119b9643f 23:26:45 I guess that's ... _probably_ vioblk? 23:27:10 It might be that your domain is not set up for legacy virtio or whatever 23:27:15 we don't do the 1.0+ thing yet 23:27:31 would help to get into kmdb and look at ::prtconf and ::msgbuf and so on probably 23:28:18 oh, I need to start making myself a sheatsheet of those. Specially for ARM :) 23:28:30 *cheatsheet 23:36:47 Yeah my guess is it is vioscsi that is needed even though it's named virtio in the xml 23:37:20 I'll try rebuilding the VM with your OSinfo 23:42:16 jclulow: yep it must have been a virtio scsi device. Using your xml to base of worked. 23:42:25 metadata agent starts :) 23:47:05 well if fstyp outputs volume_id, then searching for volume_label might not work..... 23:50:35 jclulow: thanks, that helped debug things.