From owner-freebsd-current Sun Sep 20 12:29:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA20759 for freebsd-current-outgoing; Sun, 20 Sep 1998 12:29:26 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA20731 for ; Sun, 20 Sep 1998 12:29:13 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id FAA00683; Mon, 21 Sep 1998 05:28:35 +1000 Date: Mon, 21 Sep 1998 05:28:35 +1000 From: Bruce Evans Message-Id: <199809201928.FAA00683@godzilla.zeta.org.au> To: current@FreeBSD.ORG, finrod@ewox.org Subject: Re: Strange CAM panics [LONG] Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Another problem I have (which I think is softupdates related) is that >after a panic, the computer refuses to mount / even after 'fsck -p'. >After a second reboot, all file systems are reported clean and are >mounted properly. Here is a boot log: It's premature-compatibility-slice-avoidance related. fsck actually honours the devices specified in /etc/fstab. When the root device specified in /etc/fstab doesn't match reality, due to it being the compatibility slice but the kernel having mounted root on a real slice, fsck doesn't know that the specified root device is mounted and doesn't tell the kernel to reload it. This results in the copy in the kernel remaining inconsistent with the disk copy and unclean. mount(8) uses the buggy ROOTSLICE_HUNT hack to hide this problem. Fortunately, mount fails unless forced so the inconsistent state doesn't cause further damage. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message