[Bug 256511] UFS assertion failure when shutting down from single-user mode

From: <bugzilla-noreply_at_freebsd.org>
Date: Tue, 15 Jun 2021 13:13:39 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256511

Robert Wing <rew@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rew@FreeBSD.org

--- Comment #4 from Robert Wing <rew@FreeBSD.org> ---
Created attachment 225827
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=225827&action=edit
fix panic on shutdown

There appears to be a couple issues here:

One issue is /dev/gpt/rootfs vs gpt/rootfs. The second is that the soft
dependency code doesn't properly clean up after a namei lookup failure.

At the mountroot prompt, devfs is mounted on the root so the namei lookup      
                                       for 'gpt/rootfs' works. devfs is then
remounted to /dev and the init process begins.                                 
                                                                               
       Then comes time to mount 'gpt/rootfs', but devfs is no longer at the
root, so the                                             namei lookup fails.
The system then drops into single-user mode with a readonly filesystem.         

The panic is caused because the soft dependency code gets set up (via
softdep_mount()), but doesn't clean up after itself following the namei lookup
failure (in ffs_mount()). The lookup failure causes the filesystem to not get
mounted 'rw' (i.e., without soft updates). On shutdown, the system doesn't
recognize that the filesystem is mounted with soft updates (because it isn't),
and skips the clean up code (being softdep_unmount()). By skipping the clean-up
clode, ump->um_softdep doesn't get set to NULL and fails on `MPASS()`.          

/dev/gpt/rootfs works at the mountprompt because when devfs is mounted on the
root, a symlink is also created for '/dev' that points to '/'.                  


I've attached a patched that fixes the panic - on its own, it doesn't address
the real problem.                                                               

I think the real problem is that if the namei lookup succeeds at the
mountprompt, then namei should also succeed when it tries to mount the root
filesystem 'rw'. One solution might be to prefix '/dev/' to the device string
if its passed to the mountprompt without it..? 

Any thoughts?

-- 
You are receiving this mail because:
You are the assignee for the bug.