From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (unknown [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 48A981381FA for ; Thu, 22 May 2014 12:43:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 58837E0AA1; Thu, 22 May 2014 12:43:14 +0000 (UTC) Received: from smtpq1.tb.mail.iss.as9143.net (smtpq1.tb.mail.iss.as9143.net [212.54.42.164]) by pigeon.gentoo.org (Postfix) with ESMTP id 31B4FE0A9A for ; Thu, 22 May 2014 12:43:13 +0000 (UTC) Received: from [212.54.42.135] (helo=smtp4.tb.mail.iss.as9143.net) by smtpq1.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1WnSL2-0006jJ-OK for gentoo-user@lists.gentoo.org; Thu, 22 May 2014 14:43:12 +0200 Received: from 53579160.cm-6-8c.dynamic.ziggo.nl ([83.87.145.96] helo=data.antarean.org) by smtp4.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1WnSL2-0007f7-EE for gentoo-user@lists.gentoo.org; Thu, 22 May 2014 14:43:12 +0200 Received: from andromeda.localnet (unknown [213.19.196.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by data.antarean.org (Postfix) with ESMTPSA id CCE754C for ; Thu, 22 May 2014 14:42:49 +0200 (CEST) From: "J. Roeleveld" To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Filesystem doesn't mount automatically after unclean shutdown Date: Thu, 22 May 2014 14:42:42 +0200 Message-ID: <4146224.JIzQIgy31e@andromeda> User-Agent: KMail/4.12.5 (Linux/3.12.13-gentoo; KDE/4.12.5; x86_64; ; ) In-Reply-To: <5113314.NtMx8i9yFJ@wstn> References: <5113314.NtMx8i9yFJ@wstn> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Ziggo-spambar: ---- X-Ziggo-spamscore: -4.9 X-Ziggo-spamreport: ALL_TRUSTED=-1,BAYES_00=-1.9,PROLO_TRUST_RDNS=-3,RDNS_DYNAMIC=0.982 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-Archives-Salt: 91325a78-accc-4cee-8853-00b710eee67c X-Archives-Hash: 49905ba3d6084a87d66bd058c46b41be On Friday, May 16, 2014 01:12:52 PM Peter Humphrey wrote: > On Wednesday 14 May 2014 22:29:46 Nikos Chantziaras wrote: > > I have this weird problem where a filesystem (Ext4) refuses to mount > > automatically after something like a power loss or forced shutdown. > > > > The fstab entry for it is: > > LABEL=Data /mnt/Data ext4 defaults,relatime,exec 0 2 > > > > During boot, this is what OpenRC tells me: > > Root: clean, 805088/6553600 files, 9129899/26214400 blocks > > Data: recovering journal > > Data: clean, 364344/61546496 files, 137312260/246156800 blocks [ ok ] > > * Mounting local filesystems ... [ ok ] > > * Remounting root filesystem read/write ... [ ok ] > > * Remounting filesystems ... [ ok ] > > * Updating /etc/mtab ... [ ok ] > > > > If I reboot the system again, then all works fine and the FS is mounted > > automatically. So this is a one-time thingy, happening only on the first > > boot after an unclean power-off. > > > > It would seem that I've stumbled across an OpenRC bug? There's no errors > > anywhere to be seem. According to the log output above, everything > > should be fine. I suspect that the "recovering journal" step is what > > causes this, but I don't know why. > > > > Anyone else encountered this? > > No, I can't say I have. I do occasionally have to use the reset button to > reboot (because the KDM shutdown process had hung), and the system just > restarts as Mick says. > > This is my root fstab entry: > > /dev/md5 / ext4 relatime 1 1 > > The other partitions are similar except for being mounted from /dev/md7. My (2.5 y/o) daughter occasionally presses the reset-button while sitting on my chair... (yes, the button is on a really bad location on the case). So it gets reset unintentionally regularly. Using 2 disks with 2 partitions. 1 with RAID-1 for /boot and the other with RAID-0 with LVM ontop where all the other partitions are inside LVM. Not had a bad start in a very long time. Last time it stopped for a manual fix was after the reset happened during a big emerge-session. -- Joost