[Bug 206630] [Hyper-V]FreeBSD 10.2 on Windows 10 & 2016 server may not boot due to multiple invalid disks issue

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206630

            Bug ID: 206630
           Summary: [Hyper-V]FreeBSD 10.2 on Windows 10 & 2016 server may
                    not boot due to multiple invalid disks issue
           Product: Base System
           Version: 10.2-STABLE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: honzhan at microsoft.com
                CC: freebsd-amd64 at FreeBSD.org
                CC: freebsd-amd64 at FreeBSD.org

The problem can be reproduced for FreeBSD 10.2 installed on windows 10 and 2016
server.

The valid disk was randomly switched with invalid disk. For example, from da0
to da1 when restarting the VM. As a result, the boot process will hang because
system wants to load ufs on /dev/da0p2, but in fact it locates in an invalid
disk.

Both "camcontrol" and "dmesg" can be used to check whether this issue exist.

camcontrol command lists 16 disk, but only one is valid. See the output of
'camcontrol devlist' on windows 10.

root at honzhan-dev2:/usr/src # camcontrol devlist
 <Msft Virtual CD/ROM 1.0> at scbus0 target 0 lun 0 (cd0,pass0)
 <Msft Virtual Disk 1.0> at scbus1 target 0 lun 0 (da1,pass2)
 < > at scbus1 target 1 lun 1 (da0,pass1)
 < > at scbus2 target 0 lun 1 (da2,pass3)
 < > at scbus2 target 0 lun 2 (da4,pass5)
 < > at scbus2 target 0 lun 3 (da6,pass7)
 < > at scbus2 target 0 lun 4 (da8,pass9)
 < > at scbus2 target 0 lun 5 (da10,pass11)
 < > at scbus2 target 0 lun 6 (da12,pass13)
 < > at scbus2 target 0 lun 7 (da14,pass15)
 < > at scbus2 target 1 lun 1 (da3,pass4)
 < > at scbus2 target 1 lun 2 (da5,pass6)
 < > at scbus2 target 1 lun 3 (da7,pass8)
 < > at scbus2 target 1 lun 4 (da9,pass10)
 < > at scbus2 target 1 lun 5 (da11,pass12)
 < > at scbus2 target 1 lun 6 (da13,pass14)
 < > at scbus2 target 1 lun 7 (da15,pass16)

dmesg also shows us the similar information:

dmesg

da0 at blkvsc0 bus 0 scbus1 target 1 lun 1
 da0: < > Fixed Direct Access SCSI device
 da0: 300.000MB/s transfers
 da0: 0MB (0 512 byte sectors: 0H 0S/T 0C)
 da0: Delete methods: <NONE(*)>
 da1 at blkvsc0 bus 0 scbus1 target 0 lun 0
 da1: <Msft Virtual Disk 1.0> Fixed Direct Access SPC-3 SCSI device
 da1: 300.000MB/s transfers
 da1: 20480MB (41943040 512 byte sectors: 255H 63S/T 2610C)
 da2: < > Fixed Direct Access SCSI device
 da2: 300.000MB/s transfers
 da2: 0MB (0 512 byte sectors: 0H 0S/T 0C)
 da2: Delete methods: <NONE(*)>
 da3 at storvsc1 bus 0 scbus2 target 1 lun 1
 da3: < > Fixed Direct Access SCSI device
 da3: 300.000MB/s transfers
 da3: 0MB (0 512 byte sectors: 0H 0S/T 0C)
 da3: Delete methods: <NONE(*)>
 da5: < > Fixed Direct Access SCSI device
 da5: 300.000MB/s transfers
 da5: 0MB (0 512 byte sectors: 0H 0S/T 0C)
 da5: Delete methods: <NONE(*)>
 da4: < > Fixed Direct Access SCSI device
 da4: 300.000MB/s transfers
 da4: 0MB (0 512 byte sectors: 0H 0S/T 0C)
 da4: Delete methods: <NONE(*)>

-- 
You are receiving this mail because:
You are on the CC list for the bug.