From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 20:38:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F21ABADE for ; Fri, 31 Oct 2014 20:38:06 +0000 (UTC) Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr [80.12.242.123]) by mx1.freebsd.org (Postfix) with ESMTP id 65A7AE0A for ; Fri, 31 Oct 2014 20:38:05 +0000 (UTC) Received: from ninja.humanidyne.net ([92.145.2.167]) by mwinf5d53 with ME id 9wdx1p0033cC39G03wdxWn; Fri, 31 Oct 2014 21:37:57 +0100 X-ME-Helo: ninja.humanidyne.net X-ME-Auth: bWFydGluLm1hdG9Ab3JhbmdlLmZy X-ME-Date: Fri, 31 Oct 2014 21:37:57 +0100 X-ME-IP: 92.145.2.167 Message-ID: <5453F325.1030601@orange.fr> Date: Fri, 31 Oct 2014 21:37:57 +0100 From: Martin MATO User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <201410312000.s9VK0AWB002147@pozo.com> <5453F285.7060504@orange.fr> In-Reply-To: <5453F285.7060504@orange.fr> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 20:38:07 -0000 Le 31.10.2014 21:35, Martin MATO a écrit : > Le 31.10.2014 21:00, Manfred Antar a écrit : >> At 12:20 PM 10/31/2014, O. Hartmann wrote: >> >>> On all CURRENT systems I updated today (31.10.2014) I had massive filesystem corruption >>> after reboot. The systems do have >>> >>> FreeBSD 11.0-CURRENT #1 r273914: Fri Oct 31 19:40:04 CET 2014 amd64 >>> >>> and suffer without exception from the same breakage, quitting services and/or reporting >>> corrupted filesystems after a fresh reboot - even if I've performed a manual triggered >>> "fsck -fz" in single user mode on the console. >>> >>> All systems have GPT partion schemes. >>> >>> The problem is serious! I can not get rid via fsck of the problem of corrupted >>> filesystems. Services like OpenLDAP (Slapd), nslcd, dbus, hal or postgresql do not start >>> properly and need to be started manually after a reboot. >>> >>> What is wrong? The fact that several CURRENT boxes are affected the very same way (> 5 ) >>> make me confident this is a serious bug recently introduced. >>> >>> Oliver >>> >> With r273911 on amd64, after fresh build installworld. >> Upon reboot all of a sudden /var is mounted mfs. >> needless to say many problems with programs that store files in /var -- ie mysql clamav etc, etc >> I had to change the following in rc.conf to get system to work again. >> varmfs="AUTO" # Set to YES to always create an mfs /var, NO to never >> varsize="32m" # Size of mfs /var if created >> varmfs_flags="-S" # Extra mount options for the mfs /var >> populate_var="AUTO" # Set to YES to always (re)populate /var, NO to never >> cleanvar_enable="YES" # Clean the /var directory >> >> CHANGED TO : >> varmfs="NO" # Set to YES to always create an mfs /var, NO to never >> varsize="32m" # Size of mfs /var if created >> varmfs_flags="-S" # Extra mount options for the mfs /var >> populate_var="NO" # Set to YES to always (re)populate /var, NO to never >> cleanvar_enable="NO" # Clean the /var directory >> >> Not why all of a sudden /var/ was mounted mfs. >> Maybe something to do with the new random stuff, I did a mergemaster before rebooting >> Not sure if this is related to your problem >> Manfred >> >> ======================== >> || null@pozo.com || >> || || >> ======================== >> >> > Same things here. > It appears that the ld-elf.so.hints files are not generated ( ldconfig > not executed at boot); well at least in my case. > executing manually a 'service ldconfig start' generate them. >