Bug 211136

Summary: [Hyper-V]mount root may fail because vfs' mount starts early than VMBUS
Product: Base System Reporter: Hongjiang <honzhan>
Component: kernAssignee: Bugmeister <bugmeister>
Status: Closed Overcome By Events    
Severity: Affects Many People CC: dave, decui, kyliel, sephe, weh, whu
Priority: ---    
Version: CURRENT   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
boot error log
none
fix mountroot hyper-v in 11-stable none

Description Hongjiang 2016-07-15 07:40:21 UTC
FreeBSD 10.3/head on Azure may fail to boot for the failure of "mount root". The reason is vfs's mounting starts early than storage driver attaching (included in VMBUS).

If it happened, the error looks like:
VMBUS: Total online cpus 8, assign perf channel 2 to vcpu 7, cpu 7
VMBUS get multi-channel offer, rel=18,sub=1
VMBUS: new multi-channel offer <0xfffff80011719c00>, its primary channel is <0xfffff80011766c00>.
VMBUS: channel <0xfffff80011719c00> open success.
Trying to mount root from ufs:/dev/da0p2 [rw]...
mountroot: waiting for device /dev/da0p2 ...
Mounting from ufs:/dev/da0p2 failed with error 19.

Loader variables:
  vfs.root.mountfrom=ufs:/dev/da0p2
  vfs.root.mountfrom.options=rw

Manual root filesystem specification:
  <fstype>:<device> [options]
      Mount <device> using filesystem <fstype>
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:tank
        cd9660:/dev/acd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
  <empty line>    Abort manual input

mountroot>
Comment 1 Hongjiang 2016-07-15 07:41:17 UTC
Created attachment 172546 [details]
boot error log
Comment 2 David Marker 2017-05-14 16:05:34 UTC
Created attachment 182594 [details]
fix mountroot hyper-v in 11-stable
Comment 3 David Marker 2017-05-14 16:08:09 UTC
I had the same problem in 11-stable. The issue is that storvsc root_mount_hold() happens after ZFS tried to mount root.

Adding it to the bus fixed it (see patch). I found this a little more satisfying than the busy wait suggested in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208882
Comment 4 David Marker 2017-05-30 17:49:43 UTC
Well an update to Windows 10 workstation and simple patch fails now too. ZFS doesn't wait. I suspect I'm hitting cleanup for some Hyper-V service like kvpair or something. At any rate the patch I added no longer works for me (with no upgrade to my kernel) so at the very least it is not reliable.
Comment 5 Hongjiang 2017-05-31 01:48:52 UTC
(In reply to David Marker from comment #4)
If you do not use ZFS, the mount failure should not occur on 11-stable if you set a relative long waiting time: "vfs.mountroot.timeout=30". On Azure, I used "vfs.mountroot.timeout=300" and this error never happen.

If you want to use ZFS, the current workable solution is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208882.
Comment 6 Mark Linimon freebsd_committer freebsd_triage 2023-12-31 02:10:17 UTC
^Triage: close as OBE.

I'm sorry that this PR never got looked at, but by now, 11.X is long out of support.