Bug 870005 - kernel drops to rescue shell on boot after hardware failure
kernel drops to rescue shell on boot after hardware failure
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-25 06:54 EDT by Pentarh Udi
Modified: 2012-10-29 12:23 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-29 12:23:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Pentarh Udi 2012-10-25 06:54:19 EDT
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 08:01:20 EDT
We're well aware of the problem.  It doesn't sound like yours is related to this.
Comment 2 Yura Mints 2012-10-25 12:57:38 EDT
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 13:05:17 EDT
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 18:58:19 EDT
Okay, let it be just my hardware failure.
Comment 5 Eric Sandeen 2012-10-29 12:23:36 EDT
Ok, thanks - hardware problem, NOTABUG.

Note You need to log in before you can comment on or make changes to this bug.