So, illumos HCL.. would like to use USB3 to LAN gigabit adapter.. because no other to biy ATM. So how do I know it will work.. Even, will Solaris drivers still work for illumos and is there actual activity porting drivers to illumos, like a group for that?

neirac that is likely quite harmless, but ping Woodstock about it, he was looking on such errors recently.

nikolam: As long as the gigabit chip is supported the USB3 wont be a problem. It's only the cable

tsoome_ thanks!, but that error makes impossible to format a disk, well is a vm using vioscsi.

format as from format command submenu?

that is low level scsi format

thats something you practiaclly never want to use

and it probably does explain the error -- if vioscsi does not support low level format.

tsoome_ yes, that's correct. I tried to do that because creating a pool does not work, complains about using a specific slice and run fdisk, I also tried modifying/creating the partitions but fails writing the efi label

what error you get exactly?

tsoome_ ooh that's explains it all. But how do I make the disk ready to be able to create a pool?, the error I'm getting is on zpool create it says use a slice run fdisk(8), something like that, I'll reproduce it now again

with efi (GPT) label, you are supposed to have MBR in absolute sector 0, EFI label in absolute sector 1, and EFI table array in sectors 2 - 32 (with 512B sector size) AND, efi label + partition array mirrored at the end of the disk.

normally, you create boot pool with whole disk setup by using zpool create -B rpool diskname_without_slice

or data pool, you leave out -B

-B will tell zpool to create EFI system partition, so you can get bootable disk with UEFI

or if you want to have multiboot setup or data slice, you run format -e and enter fdisk menu fdisk, there you create 100% EFI partition, exit fdisk and create partition(s), and on write to disk, select efi type.

you can verify with mdb /dev/rdsk/c...p0; there enter: ::load disk_label, then you can enter ::mbr and ::gpt and ::vtoc commands to get information about partitioning on disk.

tsoome_ thanks!, I'm replicating now

with GPT, the MBR EFI partition is "fake" partition, to make sure the GPT unaware partitioning programs wont consider your disk unused.

(thats why its called protective mbr, or pmbr)

tsoome_ fdisk /dev/rdsk/c1t0d1p0 returns Error in ioctl DKIOCGMBOOT: I/O error ; zpool create -B zones /dev/rdsk/c1t0d1 returns cannot label 'c1t0d1': try using fdisk(8) and then provide a specific slice

c1t0d1 ? do you also have c1t0d0 ?

tsoome_ according to diskinfo I only have one disk SCSI c1t0d1 ORACLE BlockVolume

ok, can you test it with mdb? mdb /dev/rdsk/c1t0d1p0, then ::load disk_label, then ::mbr and ::gpt outputs

I wonder, what is the sector size reported for that disk?

tsoome_ for ::mbr mdb: failed to read MBR: cannot read past current end of file

tsoome_ for gpt mdb: failed to read GPT header: cannot read past current end of file

format -> verify should tell, but also device-blksize property from prtconf -v

I also tried zeroing the disk with dd if=/dev/null of=/dev/rdsk/c1t0d1p0 but still I have hte same errors trying to use it

hm, those are from device name ending with p0?

tsoome_ yes

that is something weird, p0 is supposed to be entire disk

currently the disk has dd the smartos usb img, to be able to boot the smartos installer,

ok, can you dd if=/dev/rdsk/c1t0d1p0 of=mbr.dd count=1 bs=512

this d1 is still weird, it means you have lun 1, but that hints that there should also be lun 0...

tsoome_ done, after doing dd I tried again mdb ::load disk_label but it returns the same errors for ::mbr and ::gpt

can you mail me that mbr.dd ?

ok, can you try mdb mbr.dd ; ::load disk_label and then ::mbr

or mdb mbr.dd and then ::dump

tsoome_ this is what I see paste.ec/paste/7oCYN6B1#7Fm-B++47/poFZAUkKzhqpzrMhi5TY4I4IOEjoRJ5iO

and 0,200::dump

tsoome_ here it is paste.ec/paste/nCfKvm-T#BlVSTg8jUnKnaPywwrelyAlSdtbREN6EcI+sUlsoDz+

how big is that file?

mbr.dd, I mean

tsoome_ the mbr.dd file gets created using those dmcds?, I see a mbr.dd that's 0 bytes

if mbr.dd is 0 bytes, it means dd failed to read from the disk

which is confirming errors from mdb /dev/rdsk/c1t0d1p0

so, there is something bad going on, we would expect we can read from the disk...

tsoome_ I saw this paste.ec/paste/GNqqm4oq#Oni7fJnPcUDsSsv5E8aYoixAV1BcjHeqc9+CBUxC52Y

yes, thats IO error, no data was read

tsoome_ just filling the disk with any data using dd could not cause an i/o error right ?

no, you are supposed to be able to read that data out

but, I wonder, if you were attempting the low level format, could it be that did confuse the VM?

it may be worth to check if vm restart will change anything.

tsoome_ let me restart it, and creating the pool after boot

the simple test would still be format -> verify -- this will attempt to read disk label and should present some meaningful output.

tsoome_ just restarting the vm I see WARNING: vioscsi0: request stuck, resetting target

tsoome_ I'll re-create the vm again

so there is something bad going on with that disk.

tsoome_ could the viosci driver?

can not tell:)

maybe the driver, maybe the vm engine is confused...

tsoome_ could be the driver according to the comments src.illumos.org/source/xref/illumos…io/vioscsi/vioscsi.c?r=06d7f587#272

ah, you meant the message - yes, that one is from the driver for sure.

but the reason, why the disk is stuck, is obviously elsewhere.

the code suggests it's polling... maybe it's not waiting long enough?

jbk I'll create the vm again as it stuck

I just rebooted, at least the vm now boots I paste.ec/paste/ZiLHIrxm#O1Xzt8OeRmvcKkgqS+6yDPIw-9nSqWpfhKHfWWvQ639

so, can it now [read] label?

tsoome_ no, same error doing mdb ::mbr

does prtconf -v report disk sector size (and disk size)?

tsoome_ here it is paste.ec/paste/42wDVhWh#S1tJqxivloNFdqE+xR1y7YSnDmmaZZxorokA+5+p7-A

disk, instance #0 is from DELL PERC

but seems this is your disk: unknown, instance #1 value='scsa,nodev' + 'scsiclass,1f.vQEMU.pQEMU_TARGET.r2_5_' + 'scsiclass,1f.vQEMU.pQEMU_TARGET' + 'scsiclass,1f' + 'scsiclass'

but no device-nblocks nor device-blksize properties are present

so, that device is not quite usable ...

-D will add driver name in output, but anyhow, it seems there must be problem with driver and this qemu interaction...

tsoome_ seems the driver is sd? paste.ec/paste/2OCLEHOb#80iAcORO8Vh2mEXLG6oN2QZyYmizGNqbTBh6CMu6G1W

jbk the no device-nblocks or device-blksize properties are setup by the virtioscsi driver or some other layer?

i don't know offhand

if it's for a specific target or lun, my guess is sd is setting it

though you could probably search the vioscsi code to see if that property shows up anywhere

veg: I don't know either, I've never been any real part of ZFS maintenance

neirac there seems to some sort of incompatibility; you have vioscsi, to vioscsi you have connected iport, but also something unknown (nulldriver) and disk (sd driver). disk with sd driver is providing device c1t0d1 with sector size 512 and device size 46GB. Yet for some reason, you are getting those IO errors while reading the disk...

neirac does fmadm faulty report anything by chance?

tsoome_ no there is no fault according to fmadm when the vm starts

does fmdump say anything?

wait, was that property with the literal "QEMU" in it actually literal?

have any of you used ::step out on an amd64 process target?

rmustacc?

I have before.

did it work?

It usually did something kind of like what I wanted, but was never super accurate in my memory.

ok, so

I think I have trained myself to no really use it, tbh.

those registers sure don't line up with their 64 bit equivs even

That woud explain a lot.

is it possible I should stop searching for magic, and instead assume it doesn't work right?

I would assume the amd64 version is busted.

I've found a few other i386 vs. amd64 issues there lately.

#512

sigh

#15288 fenix?

BUG 15288: mdb amd64 ::step out seems like it's busted (New)

↳ illumos.org/issues/15288

I'll see if the test suite stuff I'm doing right now can work easily to test that as well.

it's still possible there's magic I'm not understanding

rmustacc: do you want to take that bug for your testing stuff, or what? I'm confused now

If you want to take it, go for it.

Just if no one does, I can try to.

I just can't work out how to write a good automated test

which is where the relevance of what you said comes in

Ah. I am trying to figure that out myself, haha.

I don't have an answer yet.

using gerrit with a new keyboard is nerve wracking

especially when I screwed the bug already

was there some idea to teach wsdiff some to process debug info better?

ctf or dwarf?

I think I've filed bugs for both, actually

ah, ok

you might want to check though?

I'm just checking wsdiff report atm:D