Bug 870005

Summary:	kernel drops to rescue shell on boot after hardware failure
Product:	[Fedora] Fedora	Reporter:	Pentarh Udi <pentarh>
Component:	kernel	Assignee:	Eric Sandeen <esandeen>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	17	CC:	dr.sexx, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-10-29 16:23:36 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Pentarh Udi 2012-10-25 10:54:19 UTC

Description of problem:
Please investigate current kernel against this issue
https://lkml.org/lkml/2012/10/23/690

Personally I have a HW problem with SATA bus, so from time to time it remounts my partitions in RO and then PC hangs.

Normally after reboot partitions checked automatically by fsck and system boots ok.

This time (having kernel-3.6.2-4.fc17.x86_64) it dropped me to rescue shell during boot. I had to fix various ext4 errors by fsck manually.

If anyone will check this issue against ext4 bug report i will appreciate https://lkml.org/lkml/2012/10/23/690

Version-Release number of selected component (if applicable):
kernel-3.6.2-4.fc17.x86_64

How reproducible:
Hard poweroff working machine with hdd write load. Instead of normal boot with automatic fsck, it drops to rescue shell.

Steps to Reproduce:
1. Hard poweroff working machine with hdd write load
2. Power on, wait boot
3. See rescue shell
  
Actual results:
System unable to fix ext4 errors automatically

Expected results:
System able to fix ext4 errors automatically

Additional info:

Comment 1 Josh Boyer 2012-10-25 12:01:20 UTC

We're well aware of the problem.  It doesn't sound like yours is related to this.

Comment 2 Yura Mints 2012-10-25 16:57:38 UTC

So, what do U recommend, roll-back the kernel to older release or just wait the new kernel in repo?
I think this problem is not critical for Desktop, but are very important for servers with KVM for example.
I know it's a hard question, but approximately how long the patch to be ready?
PS: I have a 5 VMs + server + Desktop under Fedora 17 with latest updates & ext4 ... So it's important
Thanks a lot

Comment 3 Eric Sandeen 2012-10-25 17:05:17 UTC

Please don't confuse your bug with the different one generating noise upstream.

Upstream, there is not even a confirmed bug yet, let alone a root cause or solutuion, just a lot of noise so far.

If you have a problem, file a bug about *that*; otherwise, we're aware of the problem with 1 or 2 users upstream, and it's being handled there.

I've changed this bug subject to reflect your problem, not someone else's.

If you have flakey hardware then the filesystem cannot guarantee consistency, so this is likely a NOTABUG, but:

* What hardware problems / kernel messages did you see
* What messages did you see at boot time prior to the rescue shell
* What mount options are you using on the filesystem in question
* What did e2fsck find in the rescue shell?

-Eric

Comment 4 Pentarh Udi 2012-10-25 22:58:19 UTC

Okay, let it be just my hardware failure.

Comment 5 Eric Sandeen 2012-10-29 16:23:36 UTC

Ok, thanks - hardware problem, NOTABUG.