After upgrading from 12-STABLE r352025 to r352200, the system no longer successfully boots, hanging at "Trying to mount root from ufs:/dev/da0p3 [rw]..." with no further messages. Reverting to r352025 boots normally. After posting on -stable https://lists.freebsd.org/pipermail/freebsd-stable/2019-September/091500.html another user reports the same issue with a smaller range of commits - r352139 works, r352194 hangs. I can provide access to the problem system if needed.
I'm seeing this behavior on stable/12 at r352201 on a super-common system: a BHyve VM using virtio-blk and virtio-net, booting from UFS. I would think it should be easy for anybody to reproduce.
I'm seeing the hang after successfully finding USB devices on 12-STABLE r352194 amd64 booting from zfs. r352139 worked ok.
Also having the same issue except mine hangs at trying to mount gmirror and after successfully finding USB devices as well.
(In reply to Jack from comment #3) If I attach a USB device after the hang, it is reported on the console. Likewise for detach. It seems as though there's an infinite wait somewhere before starting init.
(In reply to Terry Kennedy from comment #4) Yes, same behavior here also except it never actually mounts the filesystem as power cycling doesn't show the filesystem as dirty
I had the same problem last night on a remote ZFS system. :) I think the culprit is r352179. Can anyone confirm?
Do you have /proc in /etc/fstab? I wanted to test commenting out /proc from fstab but didn't get around to it. I'm going to try that on a remote system and see if it comes back.
(In reply to Herbert J. Skuhra from comment #6) Reverting that one commit yields a bootable system. Looking at the MFC, it seems that an extra "sx_xlock(&proctree_lock);" came along when it shouldn't have, but I'm not going to bisect further. I'll send an out-of-band notification to the committer to ask them to look at this PR.
Looks like not having /proc in fstab made no difference, still hangs on boot.
I had the same problem. Reverting r352179 alone (as Herbert J. Skuhra already noted) fixed the problem. Some details: r352118 was OK, and r352202 had problem. I went back to r352179 to bi-sect, and it DOES have problem, too. (The previous revision on stable/12 is r352118.) Updating source again to r352202 and manually reverting r352179 helped.
Assigning to the committer of r352179.
https://svnweb.freebsd.org/changeset/base/352217 is addressing issue of r352179.
Confirmed base r352217 fixes the issue for me.
(In reply to Li-Wen Hsu from comment #12) Looks good, thanks for the quick fix!
I've had the same problem in VMWare and 13-CURRENT for about a week. Wasn't sure it was a local problem or not. Now, the same issue exist in the latest VM snapshot VMDK.
(In reply to Johannes Lundberg from comment #15) I don't follow HEAD, but the commit (without the error that caused the problem on 12-STABLE) has been in HEAD for a month and a half. If your previous working system was newer than August 5th, I expect you're encountering something different.