07:06:22 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? 10:24:33 neirac that is likely quite harmless, but ping Woodstock about it, he was looking on such errors recently. 10:46:10 nikolam: As long as the gigabit chip is supported the USB3 wont be a problem. It's only the cable 12:14:31 tsoome_ thanks!, but that error makes impossible to format a disk, well is a vm using vioscsi. 12:15:00 format as from format command submenu? 12:15:08 that is low level scsi format 12:15:35 thats something you practiaclly never want to use 12:16:32 and it probably does explain the error -- if vioscsi does not support low level format. 12:16:45 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 12:17:21 what error you get exactly? 12:20:55 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 12:21:06 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. 12:21:48 normally, you create boot pool with whole disk setup by using zpool create -B rpool diskname_without_slice 12:22:04 or data pool, you leave out -B 12:22:28 -B will tell zpool to create EFI system partition, so you can get bootable disk with UEFI 12:30:08 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. 12:31:37 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. 12:33:19 tsoome_ thanks!, I'm replicating now 12:34:30 with GPT, the MBR EFI partition is "fake" partition, to make sure the GPT unaware partitioning programs wont consider your disk unused. 12:35:26 (thats why its called protective mbr, or pmbr) 13:27:57 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 13:28:41 c1t0d1 ? do you also have c1t0d0 ? 13:30:17 tsoome_ according to diskinfo I only have one disk SCSI c1t0d1 ORACLE BlockVolume 13:31:16 ok, can you test it with mdb? mdb /dev/rdsk/c1t0d1p0, then ::load disk_label, then ::mbr and ::gpt outputs 13:32:35 I wonder, what is the sector size reported for that disk? 13:33:29 tsoome_ for ::mbr mdb: failed to read MBR: cannot read past current end of file 13:33:48 tsoome_ for gpt mdb: failed to read GPT header: cannot read past current end of file 13:34:31 format -> verify should tell, but also device-blksize property from prtconf -v 13:34:45 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 13:34:50 hm, those are from device name ending with p0? 13:35:09 tsoome_ yes 13:35:34 that is something weird, p0 is supposed to be entire disk 13:36:27 currently the disk has dd the smartos usb img, to be able to boot the smartos installer, 13:36:28 ok, can you dd if=/dev/rdsk/c1t0d1p0 of=mbr.dd count=1 bs=512 13:37:41 this d1 is still weird, it means you have lun 1, but that hints that there should also be lun 0... 13:39:22 tsoome_ done, after doing dd I tried again mdb ::load disk_label but it returns the same errors for ::mbr and ::gpt 13:39:52 can you mail me that mbr.dd ? 13:40:31 ok, can you try mdb mbr.dd ; ::load disk_label and then ::mbr 13:41:20 or mdb mbr.dd and then ::dump 13:43:35 tsoome_ this is what I see https://paste.ec/paste/7oCYN6B1#7Fm-B++47/poFZAUkKzhqpzrMhi5TY4I4IOEjoRJ5iO 13:44:10 and 0,200::dump 13:45:25 tsoome_ here it is https://paste.ec/paste/nCfKvm-T#BlVSTg8jUnKnaPywwrelyAlSdtbREN6EcI+sUlsoDz+ 13:45:45 how big is that file? 13:46:48 mbr.dd, I mean 13:47:04 tsoome_ the mbr.dd file gets created using those dmcds?, I see a mbr.dd that's 0 bytes 13:47:24 if mbr.dd is 0 bytes, it means dd failed to read from the disk 13:47:47 which is confirming errors from mdb /dev/rdsk/c1t0d1p0 13:48:37 so, there is something bad going on, we would expect we can read from the disk... 13:49:17 tsoome_ I saw this https://paste.ec/paste/GNqqm4oq#Oni7fJnPcUDsSsv5E8aYoixAV1BcjHeqc9+CBUxC52Y 13:49:38 yes, thats IO error, no data was read 13:50:15 tsoome_ just filling the disk with any data using dd could not cause an i/o error right ? 13:50:39 no, you are supposed to be able to read that data out 13:51:37 but, I wonder, if you were attempting the low level format, could it be that did confuse the VM? 13:53:13 it may be worth to check if vm restart will change anything. 13:55:41 tsoome_ let me restart it, and creating the pool after boot 13:56:35 the simple test would still be format -> verify -- this will attempt to read disk label and should present some meaningful output. 13:58:12 tsoome_ just restarting the vm I see WARNING: vioscsi0: request stuck, resetting target 13:59:35 tsoome_ I'll re-create the vm again 14:00:01 so there is something bad going on with that disk. 14:00:54 tsoome_ could the viosci driver? 14:01:11 can not tell:) 14:01:46 maybe the driver, maybe the vm engine is confused... 14:04:10 tsoome_ could be the driver according to the comments https://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/io/vioscsi/vioscsi.c?r=06d7f587#272 14:04:45 ah, you meant the message - yes, that one is from the driver for sure. 14:05:14 but the reason, why the disk is stuck, is obviously elsewhere. 14:25:45 the code suggests it's polling... maybe it's not waiting long enough? 14:29:40 jbk I'll create the vm again as it stuck 15:10:00 I just rebooted, at least the vm now boots I https://paste.ec/paste/ZiLHIrxm#O1Xzt8OeRmvcKkgqS+6yDPIw-9nSqWpfhKHfWWvQ639 15:11:05 so, can it now [read] label? 15:13:43 tsoome_ no, same error doing mdb ::mbr 15:19:09 does prtconf -v report disk sector size (and disk size)? 15:24:51 tsoome_ here it is https://paste.ec/paste/42wDVhWh#S1tJqxivloNFdqE+xR1y7YSnDmmaZZxorokA+5+p7-A 15:26:05 disk, instance #0 is from DELL PERC 15:27:20 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' 15:27:56 but no device-nblocks nor device-blksize properties are present 15:28:12 so, that device is not quite usable ... 15:29:41 -D will add driver name in output, but anyhow, it seems there must be problem with driver and this qemu interaction... 15:35:50 tsoome_ seems the driver is sd? https://paste.ec/paste/2OCLEHOb#80iAcORO8Vh2mEXLG6oN2QZyYmizGNqbTBh6CMu6G1W 15:47:27 jbk the no device-nblocks or device-blksize properties are setup by the virtioscsi driver or some other layer? 15:51:32 i don't know offhand 15:52:09 if it's for a specific target or lun, my guess is sd is setting it 15:52:24 though you could probably search the vioscsi code to see if that property shows up anywhere 18:18:52 veg: I don't know either, I've never been any real part of ZFS maintenance 18:33:53 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... 18:34:37 neirac does fmadm faulty report anything by chance? 19:09:11 tsoome_ no there is no fault according to fmadm when the vm starts 19:20:27 does fmdump say anything? 19:26:26 wait, was that property with the literal "QEMU" in it actually literal? 21:02:28 have any of you used ::step out on an amd64 process target? 21:02:33 rmustacc? 21:03:12 I have before. 21:03:20 did it work? 21:03:41 It usually did something kind of like what I wanted, but was never super accurate in my memory. 21:03:46 ok, so 21:04:01 I think I have trained myself to no really use it, tbh. 21:04:01 https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/mdb/intel/mdb/proc_amd64dep.c#L680 21:04:27 those registers sure don't line up with their 64 bit equivs even 21:04:42 That woud explain a lot. 21:04:59 is it possible I should stop searching for magic, and instead assume it doesn't work right? 21:05:32 I would assume the amd64 version is busted. 21:05:43 I've found a few other i386 vs. amd64 issues there lately. 21:07:28 #512 21:07:30 sigh 21:07:36 #15288 fenix? 21:07:37 BUG 15288: mdb amd64 ::step out seems like it's busted (New) 21:07:37 ↳ https://www.illumos.org/issues/15288 21:10:55 I'll see if the test suite stuff I'm doing right now can work easily to test that as well. 21:11:40 it's still possible there's magic I'm not understanding 21:23:07 rmustacc: do you want to take that bug for your testing stuff, or what? I'm confused now 21:23:48 If you want to take it, go for it. 21:23:52 Just if no one does, I can try to. 21:24:08 I just can't work out how to write a good automated test 21:24:34 which is where the relevance of what you said comes in 21:25:19 Ah. I am trying to figure that out myself, haha. 21:25:26 I don't have an answer yet. 21:28:05 using gerrit with a new keyboard is nerve wracking 21:28:12 especially when I screwed the bug already 21:30:23 was there some idea to teach wsdiff some to process debug info better? 21:30:34 ctf or dwarf? 21:30:45 I think I've filed bugs for both, actually 21:31:46 ah, ok 21:31:58 you might want to check though? 21:33:13 I'm just checking wsdiff report atm:D