Bug 240487 - Boot hangs at "Trying to mount root from ufs:/dev/da0p3 [rw]..." in recent 12-STABLE
Summary: Boot hangs at "Trying to mount root from ufs:/dev/da0p3 [rw]..." in recent 12...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.0-STABLE
Hardware: amd64 Any
: --- Affects Some People
Assignee: Mariusz Zaborski
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-11 04:25 UTC by Terry Kennedy
Modified: 2019-09-15 09:34 UTC (History)
13 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Terry Kennedy 2019-09-11 04:25:52 UTC
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.
Comment 1 Alan Somers freebsd_committer 2019-09-11 04:40:07 UTC
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.
Comment 2 wolfgang 2019-09-11 06:51:43 UTC
I'm seeing the hang after successfully finding USB devices on 12-STABLE r352194 amd64 booting from zfs. r352139 worked ok.
Comment 3 Jack 2019-09-11 08:43:26 UTC
Also having the same issue except mine hangs at trying to mount gmirror and after successfully finding USB devices as well.
Comment 4 Terry Kennedy 2019-09-11 09:29:23 UTC
(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.
Comment 5 Jack 2019-09-11 09:40:31 UTC
(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
Comment 6 Herbert J. Skuhra 2019-09-11 09:52:22 UTC
I had the same problem last night on a remote ZFS system. :) I think the culprit is r352179. Can anyone confirm?
Comment 7 Jack 2019-09-11 10:00:36 UTC
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.
Comment 8 Terry Kennedy 2019-09-11 10:09:22 UTC
(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.
Comment 9 Jack 2019-09-11 10:39:33 UTC
Looks like not having /proc in fstab made no difference, still hangs on boot.
Comment 10 Tomoaki AOKI 2019-09-11 12:01:04 UTC
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.
Comment 11 Alan Somers freebsd_committer 2019-09-11 14:58:35 UTC
Assigning to the committer of r352179.
Comment 12 Li-Wen Hsu freebsd_committer 2019-09-11 16:55:10 UTC
https://svnweb.freebsd.org/changeset/base/352217 is addressing issue of r352179.
Comment 13 Helge Oldach 2019-09-11 16:59:25 UTC
Confirmed base r352217 fixes the issue for me.
Comment 14 Terry Kennedy 2019-09-11 18:36:00 UTC
(In reply to Li-Wen Hsu from comment #12)

Looks good, thanks for the quick fix!
Comment 15 Johannes Lundberg freebsd_committer 2019-09-15 00:43:39 UTC
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.
Comment 16 Terry Kennedy 2019-09-15 09:34:12 UTC
(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.