• mckusick's avatar
    Normally when an attempt is made to mount a UFS/FFS filesystem whose · 2c9178ed
    mckusick authored
    superblock has a check-hash error, an error message noting the
    superblock check-hash failure is printed and the mount fails. The
    administrator then runs fsck to repair the filesystem and when
    successful, the filesystem can once again be mounted.
    
    This approach fails if the filesystem in question is a root filesystem
    from which you are trying to boot. Here, the loader fails when trying
    to access the filesystem to get the kernel to boot. So it is necessary
    to allow the loader to ignore the superblock check-hash error and make
    a best effort to read the kernel. The filesystem may be suffiently
    corrupted that the read attempt fails, but there is no harm in trying
    since the loader makes no attempt to write to the filesystem.
    
    Once the kernel is loaded and starts to run, it attempts to mount its
    root filesystem. Once again, failure means that it breaks to its prompt
    to ask where to get its root filesystem. Unless you have an alternate
    root filesystem, you are stuck.
    
    Since the root filesystem is initially mounted read-only, it is
    safe to make an attempt to mount the root filesystem with the failed
    superblock check-hash. Thus, when asked to mount a root filesystem
    with a failed superblock check-hash, the kernel prints a warning
    message that the root filesystem superblock check-hash needs repair,
    but notes that it is ignoring the error and proceeding. It does
    mark the filesystem as needing an fsck which prevents it from being
    enabled for writing until fsck has been run on it. The net effect
    is that the reboot fails to single user, but at least at that point
    the administrator has the tools at hand to fix the problem.
    
    Reported by:    Rick Macklem (rmacklem@)
    Discussed with: Warner Losh (imp@)
    Sponsored by:   Netflix
    2c9178ed