Problems booting my server - ext2 - e2fsck

07-24-2010, 07:57 PM

Hi there,

my server was running strait for 8 month now. I did updates regularly
but still used an 2.6.2x kernel. Never switched it of. Now someone from
houskeeping pulled the plug for the vacuum cleaner ...

Anyway the box won't boot anymore. grub starts up. Kernel boots. Then
there is checking root file system (or something like that).The message
is that my ext2 file system can not be read. That I might want to try
the alternativ superblock by running #e2fsck -b 8193 <device>

Well, I put the hdd in an external usb and conected it to my
workstation. As I thought hda3 (is /dev/sde3) is an ext3 filesystem.
Also badblocks and e2fsck did not show any problem with the hdd.

/etc/fstab is corect (i hope), too.

What am I missing? How can I get the server running, again?

Regards

kh

07-24-2010, 08:21 PM

On Saturday 24 July 2010 21:57:38 KH wrote:
> Hi there,
>
> my server was running strait for 8 month now. I did updates regularly
> but still used an 2.6.2x kernel. Never switched it of. Now someone from
> houskeeping pulled the plug for the vacuum cleaner ...
>
> Anyway the box won't boot anymore. grub starts up. Kernel boots. Then
> there is checking root file system (or something like that).The message
> is that my ext2 file system can not be read. That I might want to try
> the alternativ superblock by running #e2fsck -b 8193 <device>
>
> Well, I put the hdd in an external usb and conected it to my
> workstation. As I thought hda3 (is /dev/sde3) is an ext3 filesystem.
> Also badblocks and e2fsck did not show any problem with the hdd.
>
> /etc/fstab is corect (i hope), too.
>
> What am I missing? How can I get the server running, again?

You said you ran e2fsck and it was OK. What was the command?

Normally with an e2fsck on a journalled fs, the app will replay the journal
and make a few minor checks. This takes about 4 seconds, not the 40 minutes it
takes to do a ful ext2 check.

I think you might need to fsck without the journal. I know there's a way to do
this but a cursory glance at the man page didn't reveal it. Maybe an ext user
will chip in with the correct method

--
alan dot mckinnon at gmail dot com

07-24-2010, 08:25 PM

On Saturday 24 July 2010 21:57:38 KH wrote:
> Hi there,
>
> my server was running strait for 8 month now. I did updates regularly
> but still used an 2.6.2x kernel. Never switched it of. Now someone from
> houskeeping pulled the plug for the vacuum cleaner ...
>
> Anyway the box won't boot anymore. grub starts up. Kernel boots. Then
> there is checking root file system (or something like that).The message
> is that my ext2 file system can not be read. That I might want to try
> the alternativ superblock by running #e2fsck -b 8193 <device>
>
> Well, I put the hdd in an external usb and conected it to my
> workstation. As I thought hda3 (is /dev/sde3) is an ext3 filesystem.
> Also badblocks and e2fsck did not show any problem with the hdd.
>
> /etc/fstab is corect (i hope), too.
>
> What am I missing? How can I get the server running, again?

You said you ran e2fsck and it was OK. What was the command?

Normally with an e2fsck on a journalled fs, the app will replay the journal
and make a few minor checks. This takes about 4 seconds, not the 40 minutes it
takes to do a ful ext2 check.

I think you might need to fsck without the journal. I know there's a way to do
this but a cursory glance at the man page didn't reveal it. Maybe an ext user
will chip in with the correct method

--
alan dot mckinnon at gmail dot com

07-24-2010, 09:46 PM

On 7/24/2010 3:25 PM, Alan McKinnon wrote:

On Saturday 24 July 2010 21:57:38 KH wrote:

Hi there,

my server was running strait for 8 month now. I did updates regularly
but still used an 2.6.2x kernel. Never switched it of. Now someone from
houskeeping pulled the plug for the vacuum cleaner ...

Anyway the box won't boot anymore. grub starts up. Kernel boots. Then
there is checking root file system (or something like that).The message
is that my ext2 file system can not be read. That I might want to try
the alternativ superblock by running #e2fsck -b 8193<device>

Well, I put the hdd in an external usb and conected it to my
workstation. As I thought hda3 (is /dev/sde3) is an ext3 filesystem.
Also badblocks and e2fsck did not show any problem with the hdd.

/etc/fstab is corect (i hope), too.

What am I missing? How can I get the server running, again?

You said you ran e2fsck and it was OK. What was the command?

Normally with an e2fsck on a journalled fs, the app will replay the journal
and make a few minor checks. This takes about 4 seconds, not the 40 minutes it
takes to do a ful ext2 check.

I think you might need to fsck without the journal. I know there's a way to do
this but a cursory glance at the man page didn't reveal it. Maybe an ext user
will chip in with the correct method

Run e2fsck -f /dev/hda3 to force check a partition. I have had to do
that when my kids yanked all the drives out of a server that I was
setting up. :-)

--
No trees were harmed in the sending of this message. However, a large
number of electrons were terribly inconvenienced.

07-24-2010, 10:04 PM

On Sat, Jul 24, 2010 at 9:21 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> I think you might need to fsck without the journal. I know there's a way to do
> this but a cursory glance at the man page didn't reveal it. Maybe an ext user
> will chip in with the correct method

"e2fsck -f" should run the full system check after replaying the journal.

RobbieAB

07-25-2010, 04:57 AM

Am 24.07.2010 22:21, schrieb Alan McKinnon:
> On Saturday 24 July 2010 21:57:38 KH wrote:
>> Hi there,
[...]
>> Anyway the box won't boot anymore. grub starts up. Kernel boots. Then
>> there is checking root file system (or something like that).The message
>> is that my ext2 file system can not be read. That I might want to try
>> the alternativ superblock by running #e2fsck -b 8193 <device>
>>
>> Well, I put the hdd in an external usb and conected it to my
>> workstation. As I thought hda3 (is /dev/sde3) is an ext3 filesystem.
>> Also badblocks and e2fsck did not show any problem with the hdd.
>>
>> /etc/fstab is corect (i hope), too.
>>
>> What am I missing? How can I get the server running, again?
>
> You said you ran e2fsck and it was OK. What was the command?
>
> Normally with an e2fsck on a journalled fs, the app will replay the journal
> and make a few minor checks. This takes about 4 seconds, not the 40 minutes it
> takes to do a ful ext2 check.
>
> I think you might need to fsck without the journal. I know there's a way to do
> this but a cursory glance at the man page didn't reveal it. Maybe an ext user
> will chip in with the correct method
>
>
>

Hi,

I ran on the two partitions e2fsck /dev/sde3 as well as fsck.ext3
/dev/sde3 . Yes, it only took some seconds.

Regards
kh

Sun Jul 25 07:30:01 2010
Return-path: <advisory-board-bounces@lists.fedoraproject.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Sun, 25 Jul 2010 07:16:43 +0300
Received: from bastion02.fedoraproject.org ([209.132.181.3]:38559 helo=bastion.fedoraproject.org)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <advisory-board-bounces@lists.fedoraproject.org>)
id 1Ocsdn-0003mQ-DM
for tom@linux-archive.org; Sun, 25 Jul 2010 07:16:43 +0300
Received: from lists.fedoraproject.org (collab1.vpn.fedoraproject.org [192.168.1.21])
by bastion02.phx2.fedoraproject.org (Postfix) with ESMTP id EEAB410F9F3;
Sun, 25 Jul 2010 05:00:46 +0000 (UTC)
Received: from collab1.fedoraproject.org (localhost.localdomain [127.0.0.1])
by lists.fedoraproject.org (Postfix) with ESMTP id 90D9A32679E;
Sun, 25 Jul 2010 05:00:46 +0000 (UTC)
X-Original-To: advisory-board@lists.fedoraproject.org
Delivered-To: advisory-board@lists.fedoraproject.org
Received: from smtp-mm2.fedoraproject.org (smtp-mm2.fedoraproject.org
[66.35.62.164])
by lists.fedoraproject.org (Postfix) with ESMTP id E563E32677A
for <advisory-board@lists.fedoraproject.org>;
Sun, 25 Jul 2010 05:00:44 +0000 (UTC)
Received: from homiemail-a22.g.dreamhost.com (caiajhbdcaid.dreamhost.com
[208.97.132.83])
by smtp-mm2.fedoraproject.org (Postfix) with ESMTP id 90480E71E7
for <advisory-board@lists.fedoraproject.org>;
Sun, 25 Jul 2010 05:00:44 +0000 (UTC)
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 08E941A8071;
Sat, 24 Jul 2010 22:00:44 -0700 (PDT)
Received: from [173.124.25.114] (173-124-25-114.pools.spcsdns.net
[173.124.25.114])
(Authenticated sender: duffy.fedoraproject.org@linuxgrrl.com)
by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id C78F81A8069;
Sat, 24 Jul 2010 22:00:42 -0700 (PDT)
To: "=?utf-8?B?SmVmZiBTcGFsZXRh?=" <jspaleta@gmail.com>,
advisory-board@lists.fedoraproject.org
From: "=?utf-8?B?TcOhaXLDrW4gRHVmZnk=?="
<duffy.fedoraproject.org@linuxgrrl.com>
Subject: =?utf-8?B?UmU6IFNlYXJjaCBFbmdpbmUgb24gc3RhcnQuZmVkb3JhcH JvamVjdC5vcmc=?=
Date: Sun, 25 Jul 2010 01:00:58 -0400
MIME-Version: 1.0
Message-Id: <20100725050042.C78F81A8069@homiemail-a22.g.dreamhost.com>
X-BeenThere: advisory-board@lists.fedoraproject.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: advisory-board@lists.fedoraproject.org
List-Id: <advisory-board.lists.fedoraproject.org>
List-Unsubscribe: <https://admin.fedoraproject.org/mailman/listinfo/advisory-board>,
<mailto:advisory-board-request@lists.fedoraproject.org?subject=unsubscrib e>
List-Archive: <http://lists.fedoraproject.org/pipermail/advisory-board>
List-Post: <mailto:advisory-board@lists.fedoraproject.org>
List-Help: <mailto:advisory-board-request@lists.fedoraproject.org?subject=help>
List-Subscribe: <https://admin.fedoraproject.org/mailman/listinfo/advisory-board>,
<mailto:advisory-board-request@lists.fedoraproject.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1813866138299120486=="
Sender: advisory-board-bounces@lists.fedoraproject.org
Errors-To: advisory-board-bounces@lists.fedoraproject.org

--===============1813866138299120486==
Content-Type: multipart/alternative;
boundary="----=_Part_0_1280034058095"

------=_Part_0_1280034058095
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: base64
Content-Disposition: inline

SXMgdGhlcmUgYSByZWFzb24gZm9yIHdoYXQgSSBkZXRlY3QgdG 8gYmUgYSB0aW5nZSBvZiBwYXJh
bm9pYSBoZXJlPyBUaGVyZSBpcyBhIHdvcmxkIG9mIGRpZmZlcm VuY2UgYmV0d2VlbiBhIHdlbGwt
bWVhbmluZyBGTE9TUyBjb2RlIHVwc3RyZWFtIG1ha2luZyBhbi Bob25lc3QgbWlzdGFrZSBhbmQg
YSBwcm92aWRlciBseWluZyBhYm91dCB0aGVpciBGTE9TUy1uZX NzLiBJIGhlYXIgYWJvdXQgdGhl
IGZvcm1lciBhbGwgdGhlIHRpbWUsIHRoZSBsYXR0ZXIgLW5ldm VyLS4gSXMgaXQgcmVhbGx5IGEg
Y29uY2Vybj8KClBlcmZlY3Rpb24gdW5mb3J0dW5hdGVseSBpcy ByYXJlIGluIHRoaXMgd29ybGQg
YW5kIHRoaXMgaXMgbm8gbGVzcyB0cnVlIGluIG1hbmFnaW5nIG NvbXBsZXggY29tcHV0aW5nIHN5
c3RlbXMuIFRoZSB3aG9sZSBwb2ludCBvZiBhIHBvbGljeSBzaG 91bGQgbm90IGJlIHBlcmZlY3Rp
b24gc2luY2UgdGhhdCdkIGJlIGEgbG9zdCBjYXVzZSBhbmQgd2 hhdCB3b3VsZCBpdCBnYWluIHVz
IGJ1dCBmcnVzdHJhdGlvbj8gUmF0aGVyIEkgYmVsaWV2ZSB0aG UgcG9saWN5IHNob3VsZCBiZSB0
byB3b3JrIG9ubHkgd2l0aCB0aGlyZCBwYXJ0aWVzIHdobyBoYX ZlIGEgY2xlYXIgY29tbWl0dG1l
bnQgdG8gRkxPU1MgdGhhdCBpcyBpbiBhY2NvcmRhbmNlIHdpdG ggRmVkb3JhJ3Mgb3duIHZpZXdz
IG9uIGZyZWUgc29mdHdhcmUgd2hlbmV2ZXIgcG9zc2libGUuIF RvIG1lLCB0aGF0IHdvdWxkIGRp
c3F1YWxpZnkgR29vZ2xlIGFzIHRoZXkgc2VlbSBxdWl0ZSBjb2 50ZW50IHRvIGNvbnN1bWUgRkxP
U1MgaW4gdGhlaXIgd2ViIGFwcHMgd2l0aG91dCBwcm92aWRpbm cgc291cmNlLCBubyBxdWFsbXMg
YWJvdXQgaXQsIG5vIGF0dGVtcHQgdG8gZXZlbiBhcHBlYXIgdG 8gYmUgcnVubmluZyBGTE9TUyBh
cHBzLiAocGxlYXNlIGNvcnJlY3QgbWUgaWYgaSBhbSB3cm9uZy 4pCgpBbHNvIHJlOiB0aGUgQVBJ
IHN0dWZmIC0gaWYgYSB0aGlyZCBwYXJ0eSB3ZSBkZXBlbmQgb2 4gZ29lcyBieWVieWUsIHdlIGFy
ZSBzY3Jld2VkIG5vIG1hdHRlciB3aGF0LiBIb3cgaXMgaGF2aW 5nIHRvIGltcGxlbWVudCBvdXIg
b3duIHRoaW5nIHRvIGFuIEFQSSB3aXRoIGxpdHRsZSB3YXJuaW 5nIHdoaWxlIHdlIGJsZWVkIGEg
YmV0dGVyIHNpdHVhdGlvbiB0aGFuOiAKCi0gaW1wbGVtZW50aW 5nIG91ciBvd24gdGhpbmcgb24g
b3VyIG93biB0aW1lIHdpdGhvdXQgdGhlIG1lc3N5IHN0ZXAgb2 YgZXZlciBoYXZpbmcgdG8gcmVs
eSBvbiBhbnkgdGhpcmQgcGFydHkgcHJvcHJpZXRhcnluZXNzIG FuZCBoYXZpbmcgZGVwZW5kYW50
IHN5c3RlbXMgZG93biBmb3IgdW5rbm93biB0aW1lIHBlcmlvZH MKCi0gd29ya2luZyB3IGEgdGhp
cmQgcGFydHkgdmVuZG9yIHdobyB3ZSBkaXNjb3ZlciBkb2Vzbi d0IGhhdmUgMTAwJSBGTE9TUyB0
byBjb3JyZWN0IEZMT1NTIGlzc3VlcyBqdXN0IHRoZSBzYW1lIG FzIHdlIGRvIHcgcGtnIG1haW50
YWluZXJzIHRvZGF5PyAoSSB3b3VsZCByYXRoZXIgNTAlIEZMT1 NTIHRoYW4gMCUhIElmIHdlIG1p
c3MgYSBsaW5lIGRvIHdlIHJ1biBvZmYgc3RhZ2UgYW5kIHF1aX Qgc2luY2UgdGhlIHNob3cgaXMg
bm8gbG9uZ2VyIHdvcnRoIGZpbmlzaGluZz8pCgpBZ2FpbiByZT phcGlzIGFzIGNvbnNvbGF0aW9u
IC0gSWYgbXkgY2F0ZXJlciBkZWNpZGVzIHRoZSBtb3JuaW5nIG 9mIG15IGJhbnF1ZXQgdGhhdCB0
aGV5IGNhbid0IHByb3ZpZGUgdGhlIGZvb2QgYW55bW9yZSwgaG F2aW5nIHRoZSBpbnRlbmRlZCBy
ZWNpcGVzIGluIGhhbmQgaXMgbGl0dGxlIHNvbGFjZSB3aGVuIG 15IDIwMCBndWVzdHMgc3RhcnQg
c2hvd2luZyB1cCBodW5ncnkuLi4KCkhvbmVzdGx5LCBJJ20gbW 9yZSBjb21mb3J0YWJsZSB3aXRo
IE1pa2UncyBndXQgZmVlbGluZyBvbiBhIGRlY2lzaW9uIHVuZG Vyc3RhbmRpbmcgYSBzcGVjaWZp
YyBjb250ZXh0J3MgY29tcGxleGl0aWVzIHRoYW4gYSBibGFua2 V0IHBvbGljeSBjcmFmdGVkIHdp
dGhvdXQgYW55IHBvc3NpYmlsaXR5IG9mIGFjY291bnRpbmcgZm 9yIHRoZSBjb21wbGV4IHNjZW5h
cmlvcyB0aGF0IGF3YWl0IHVzLiBJZiBhIHBvbGljeSBpcyBuZW VkZWQgSSB0aGluayBpdCBzaG91
bGQgYmUgYm9hcmQgc2lnbm9mZiBvbiBpbmZyYXN0cnVjdHVyZS B0ZWFtIGNhbGxzIGludm9sdmlu
ZyB0aGlyZCBwYXJ0eSBzZXJ2aWNlcyBjYXNlLWJ5LWNhc2UuCg p+bQoKU2VudCBmcm9tIG15IEFu
ZHJvaWQKCg==

------=_Part_0_1280034058095
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: base64
Content-Disposition: inline

SXMgdGhlcmUgYSByZWFzb24gZm9yIHdoYXQgSSBkZXRlY3QgdG 8gYmUgYSB0aW5nZSBvZiBwYXJh
bm9pYSBoZXJlPyBUaGVyZSBpcyBhIHdvcmxkIG9mIGRpZmZlcm VuY2UgYmV0d2VlbiBhIHdlbGwt
bWVhbmluZyBGTE9TUyBjb2RlIHVwc3RyZWFtIG1ha2luZyBhbi Bob25lc3QgbWlzdGFrZSBhbmQg
YSBwcm92aWRlciBseWluZyBhYm91dCB0aGVpciBGTE9TUy1uZX NzLiBJIGhlYXIgYWJvdXQgdGhl
IGZvcm1lciBhbGwgdGhlIHRpbWUsIHRoZSBsYXR0ZXIgLW5ldm VyLS4gSXMgaXQgcmVhbGx5IGEg
Y29uY2Vybj88YnI+PGJyPlBlcmZlY3Rpb24gdW5mb3J0dW5hdG VseSBpcyByYXJlIGluIHRoaXMg
d29ybGQgYW5kIHRoaXMgaXMgbm8gbGVzcyB0cnVlIGluIG1hbm FnaW5nIGNvbXBsZXggY29tcHV0
aW5nIHN5c3RlbXMuIFRoZSB3aG9sZSBwb2ludCBvZiBhIHBvbG ljeSBzaG91bGQgbm90IGJlIHBl
cmZlY3Rpb24gc2luY2UgdGhhdCYjMzk7ZCBiZSBhIGxvc3QgY2 F1c2UgYW5kIHdoYXQgd291bGQg
aXQgZ2FpbiB1cyBidXQgZnJ1c3RyYXRpb24/IFJhdGhlciBJIGJlbGlldmUgdGhlIHBvbGljeSBz
aG91bGQgYmUgdG8gd29yayBvbmx5IHdpdGggdGhpcmQgcGFydG llcyB3aG8gaGF2ZSBhIGNsZWFy
IGNvbW1pdHRtZW50IHRvIEZMT1NTIHRoYXQgaXMgaW4gYWNjb3 JkYW5jZSB3aXRoIEZlZG9yYSYj
Mzk7cyBvd24gdmlld3Mgb24gZnJlZSBzb2Z0d2FyZSB3aGVuZX ZlciBwb3NzaWJsZS4gVG8gbWUs
IHRoYXQgd291bGQgZGlzcXVhbGlmeSBHb29nbGUgYXMgdGhleS BzZWVtIHF1aXRlIGNvbnRlbnQg
dG8gY29uc3VtZSBGTE9TUyBpbiB0aGVpciB3ZWIgYXBwcyB3aX Rob3V0IHByb3ZpZGluZyBzb3Vy
Y2UsIG5vIHF1YWxtcyBhYm91dCBpdCwgbm8gYXR0ZW1wdCB0by BldmVuIGFwcGVhciB0byBiZSBy
dW5uaW5nIEZMT1NTIGFwcHMuIChwbGVhc2UgY29ycmVjdCBtZS BpZiBpIGFtIHdyb25nLik8YnI+
PGJyPkFsc28gcmU6IHRoZSBBUEkgc3R1ZmYgLSBpZiBhIHRoaX JkIHBhcnR5IHdlIGRlcGVuZCBv
biBnb2VzIGJ5ZWJ5ZSwgd2UgYXJlIHNjcmV3ZWQgbm8gbWF0dG VyIHdoYXQuIEhvdyBpcyBoYXZp
bmcgdG8gaW1wbGVtZW50IG91ciBvd24gdGhpbmcgdG8gYW4gQV BJIHdpdGggbGl0dGxlIHdhcm5p
bmcgd2hpbGUgd2UgYmxlZWQgYSBiZXR0ZXIgc2l0dWF0aW9uIH RoYW46IDxicj48YnI+LSBpbXBs
ZW1lbnRpbmcgb3VyIG93biB0aGluZyBvbiBvdXIgb3duIHRpbW Ugd2l0aG91dCB0aGUgbWVzc3kg
c3RlcCBvZiBldmVyIGhhdmluZyB0byByZWx5IG9uIGFueSB0aG lyZCBwYXJ0eSBwcm9wcmlldGFy
eW5lc3MgYW5kIGhhdmluZyBkZXBlbmRhbnQgc3lzdGVtcyBkb3 duIGZvciB1bmtub3duIHRpbWUg
cGVyaW9kczxicj48YnI+LSB3b3JraW5nIHcgYSB0aGlyZCBwYX J0eSB2ZW5kb3Igd2hvIHdlIGRp
c2NvdmVyIGRvZXNuJiMzOTt0IGhhdmUgMTAwJSBGTE9TUyB0by Bjb3JyZWN0IEZMT1NTIGlzc3Vl
cyBqdXN0IHRoZSBzYW1lIGFzIHdlIGRvIHcgcGtnIG1haW50YW luZXJzIHRvZGF5PyAoSSB3b3Vs
ZCByYXRoZXIgNTAlIEZMT1NTIHRoYW4gMCUhIElmIHdlIG1pc3 MgYSBsaW5lIGRvIHdlIHJ1biBv
ZmYgc3RhZ2UgYW5kIHF1aXQgc2luY2UgdGhlIHNob3cgaXMgbm 8gbG9uZ2VyIHdvcnRoIGZpbmlz
aGluZz8pPGJyPjxicj5BZ2FpbiByZTphcGlzIGFzIGNvbnNvbG F0aW9uIC0gSWYgbXkgY2F0ZXJl
ciBkZWNpZGVzIHRoZSBtb3JuaW5nIG9mIG15IGJhbnF1ZXQgdG hhdCB0aGV5IGNhbiYjMzk7dCBw
cm92aWRlIHRoZSBmb29kIGFueW1vcmUsIGhhdmluZyB0aGUgaW 50ZW5kZWQgcmVjaXBlcyBpbiBo
YW5kIGlzIGxpdHRsZSBzb2xhY2Ugd2hlbiBteSAyMDAgZ3Vlc3 RzIHN0YXJ0IHNob3dpbmcgdXAg
aHVuZ3J5Li4uPGJyPjxicj5Ib25lc3RseSwgSSYjMzk7bSBtb3 JlIGNvbWZvcnRhYmxlIHdpdGgg
TWlrZSYjMzk7cyBndXQgZmVlbGluZyBvbiBhIGRlY2lzaW9uIH VuZGVyc3RhbmRpbmcgYSBzcGVj
aWZpYyBjb250ZXh0JiMzOTtzIGNvbXBsZXhpdGllcyB0aGFuIG EgYmxhbmtldCBwb2xpY3kgY3Jh
ZnRlZCB3aXRob3V0IGFueSBwb3NzaWJpbGl0eSBvZiBhY2NvdW 50aW5nIGZvciB0aGUgY29tcGxl
eCBzY2VuYXJpb3MgdGhhdCBhd2FpdCB1cy4gSWYgYSBwb2xpY3 kgaXMgbmVlZGVkIEkgdGhpbmsg
aXQgc2hvdWxkIGJlIGJvYXJkIHNpZ25vZmYgb24gaW5mcmFzdH J1Y3R1cmUgdGVhbSBjYWxscyBp
bnZvbHZpbmcgdGhpcmQgcGFydHkgc2VydmljZXMgY2FzZS1ieS 1jYXNlLjxicj48YnI+fm08YnI+
PGJyPlNlbnQgZnJvbSBteSBBbmRyb2lkPGJyPjxicj48YnI+PG JyPg==

------=_Part_0_1280034058095--

--===============1813866138299120486==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
advisory-board mailing list
advisory-board@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/advisory-board
--===============1813866138299120486==--

07-25-2010, 05:12 AM

Am 24.07.2010 23:46, schrieb James Wall:
> On 7/24/2010 3:25 PM, Alan McKinnon wrote:
>>
>> I think you might need to fsck without the journal. I know there's a
>> way to do
>> this but a cursory glance at the man page didn't reveal it. Maybe an
>> ext user
>> will chip in with the correct method
>
> Run e2fsck -f /dev/hda3 to force check a partition. I have had to do
> that when my kids yanked all the drives out of a server that I was
> setting up. :-)

Hi again,

# e2fsck -fv /dev/sde3

e2fsck 1.41.11 (14-Mar-2010)
Durchgang 1: Prüfe Inodes, Blocks, und Größen
Durchgang 2: Prüfe Verzeichnis Struktur
Durchgang 3: Prüfe Verzeichnis Verknüpfungen
Durchgang 4: Überprüfe die Referenzzähler
Durchgang 5: Überprüfe Gruppe Zusammenfassung

356415 inodes used (36.63%)
10396 non-contiguous files (2.9%)
236 non-contiguous directories (0.1%)
# von Inodes mit ind/dind/tind Blöcken: 7917/121/0
2191858 blocks used (56.32%)
0 bad blocks
1 large file

315130 regular files
31986 directories
1051 character device files
4089 block device files
1 fifo
2397 links
4147 symbolic links (4027 fast symbolic links)
2 sockets
--------
358803 files

Well this does not look bad, does it?

Regards kh

> No trees were harmed in the sending of this message. However, a large
> number of electrons were terribly inconvenienced.

cool sig!

07-25-2010, 07:49 AM

On Sunday 25 July 2010 06:57:43 KH wrote:
> > You said you ran e2fsck and it was OK. What was the command?
> >
> >
> >
> > Normally with an e2fsck on a journalled fs, the app will replay the
> > journal and make a few minor checks. This takes about 4 seconds, not
> > the 40 minutes it takes to do a ful ext2 check.
> >
> >
> >
> > I think you might need to fsck without the journal. I know there's a way
> > to do this but a cursory glance at the man page didn't reveal it. Maybe
> > an ext user will chip in with the correct method
> >
> >
> >
> >
>
> Hi,
>
> I ran on the two partitions e2fsck /dev/sde3 as well as fsck.ext3
> /dev/sde3 . Yes, it only took some seconds.

It's been a long time since I used ext3 so some of this might be wrong.

An fsck that takes a few seconds is using the journal, which might not uncover
deeper corruption. You should try disabling the journal (I couldn't find the
way to do that though), but this will also work:

Boot of a LiveCD, mount your root partition somewhere using type "ext2" and
fsck it. This will invalidate the journal but that's OK, it gets recreated on
the next proper boot. Let the fsck finish - it will take a while on a large
fs.

When done, reboot as normal and see if the machine boots up properly.

--
alan dot mckinnon at gmail dot com

07-25-2010, 08:18 AM

Alan McKinnon wrote:

On Sunday 25 July 2010 06:57:43 KH wrote:

You said you ran e2fsck and it was OK. What was the command?

Normally with an e2fsck on a journalled fs, the app will replay the
journal and make a few minor checks. This takes about 4 seconds, not
the 40 minutes it takes to do a ful ext2 check.

I think you might need to fsck without the journal. I know there's a way
to do this but a cursory glance at the man page didn't reveal it. Maybe
an ext user will chip in with the correct method

Hi,

I ran on the two partitions e2fsck /dev/sde3 as well as fsck.ext3
/dev/sde3 . Yes, it only took some seconds.

It's been a long time since I used ext3 so some of this might be wrong.

An fsck that takes a few seconds is using the journal, which might not uncover
deeper corruption. You should try disabling the journal (I couldn't find the
way to do that though), but this will also work:

Boot of a LiveCD, mount your root partition somewhere using type "ext2" and
fsck it. This will invalidate the journal but that's OK, it gets recreated on
the next proper boot. Let the fsck finish - it will take a while on a large
fs.

When done, reboot as normal and see if the machine boots up properly.

And I would stand guard to make sure housekeeping doesn't come around.
;-) Cutting power during all this wold not be good.

Dale

:-) :-)

07-25-2010, 01:57 PM

On Sunday 25 July 2010 09:18:33 Dale wrote:
> Alan McKinnon wrote:
> > On Sunday 25 July 2010 06:57:43 KH wrote:
> >>> You said you ran e2fsck and it was OK. What was the command?
> >>>
> >>>
> >>>
> >>> Normally with an e2fsck on a journalled fs, the app will replay the
> >>> journal and make a few minor checks. This takes about 4 seconds, not
> >>> the 40 minutes it takes to do a ful ext2 check.
> >>>
> >>>
> >>>
> >>> I think you might need to fsck without the journal. I know there's a
> >>> way to do this but a cursory glance at the man page didn't reveal it.
> >>> Maybe an ext user will chip in with the correct method
> >>
> >> Hi,
> >>
> >> I ran on the two partitions e2fsck /dev/sde3 as well as fsck.ext3
> >> /dev/sde3 . Yes, it only took some seconds.
> >
> > It's been a long time since I used ext3 so some of this might be wrong.
> >
> > An fsck that takes a few seconds is using the journal, which might not
> > uncover deeper corruption. You should try disabling the journal (I
> > couldn't find the way to do that though), but this will also work:
> >
> > Boot of a LiveCD, mount your root partition somewhere using type "ext2"
> > and fsck it. This will invalidate the journal but that's OK, it gets
> > recreated on the next proper boot. Let the fsck finish - it will take a
> > while on a large fs.
> >
> > When done, reboot as normal and see if the machine boots up properly.
>
> And I would stand guard to make sure housekeeping doesn't come around.
> ;-) Cutting power during all this wold not be good.

KH, I think that this may not be related to a fs error as such.

Yes, pulling the plug may have caused fs corruption. However, more likely is
that pulling the plug did not allow you to do something that you should have
done after you finished upgrading to grub-0.97-r9. The latest installation of
grub asks you to reinstall in the MBR and point its root to wherever your
/boot is. GRUB's fs and its drivers may have changed and therefore the old
boot loader code is looking for files that no longer exist.

So you'll probably be alright again if you boot with a fresh systemrescue
LiveCD and run grub and then root (hd....) and setup (hd0) before you quit and
reboot.

If that doesn't work then you most likely have a fs problem.

HTH.
--
Regards,
Mick