Bug 819563 - ext4 filesystem check failure on /dev/mapper/vg-lv_root
ext4 filesystem check failure on /dev/mapper/vg-lv_root
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F17Blocker/F17FinalBlocker
  Show dependency treegraph
 
Reported: 2012-05-07 10:41 EDT by Kamil Páral
Modified: 2012-05-10 08:53 EDT (History)
5 users (show)

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


Attachments (Terms of Use)
screenshot (57.21 KB, image/png)
2012-05-07 10:41 EDT, Kamil Páral
no flags Details
anaconda.log (9.11 KB, text/plain)
2012-05-07 10:42 EDT, Kamil Páral
no flags Details
program.log (116.00 KB, text/plain)
2012-05-07 10:42 EDT, Kamil Páral
no flags Details
storage.log (294.10 KB, text/plain)
2012-05-07 10:42 EDT, Kamil Páral
no flags Details
another error screenshot (62.06 KB, image/png)
2012-05-09 05:06 EDT, Kamil Páral
no flags Details
messages (205.32 KB, text/plain)
2012-05-09 05:06 EDT, Kamil Páral
no flags Details
dmesg (58.39 KB, text/plain)
2012-05-09 05:06 EDT, Kamil Páral
no flags Details
another set of anaconda logs related to dmesg and messages (440.00 KB, application/x-tar)
2012-05-09 05:07 EDT, Kamil Páral
no flags Details

  None (edit)
Description Kamil Páral 2012-05-07 10:41:58 EDT
Created attachment 582689 [details]
screenshot

Description of problem:
I received this error while installing F17 TC3 i686 Live in VM.

> ext4 filesystem check failure on /dev/mapper/vg-lv_root: 
> 
> File system errors left uncorrected.
> 
> Errors like this usually mean there is a problem with the filesystem that will require user interaction to repair.  Before restarting installation, reboot to rescue mode or another system that allows you to repair the filesystem interactively.  Restart installation after you have corrected the problems on the filesystem.

In the partitioning step I chose "use all space".

Version-Release number of selected component (if applicable):
anaconda 17.25
F17 TC3 Live i686

How reproducible:
unknown
Comment 1 Kamil Páral 2012-05-07 10:42:20 EDT
Created attachment 582690 [details]
anaconda.log
Comment 2 Kamil Páral 2012-05-07 10:42:24 EDT
Created attachment 582691 [details]
program.log
Comment 3 Kamil Páral 2012-05-07 10:42:28 EDT
Created attachment 582692 [details]
storage.log
Comment 4 Kamil Páral 2012-05-07 10:48:04 EDT
On second attempt exactly the same happened.
Comment 5 Kamil Páral 2012-05-07 10:55:11 EDT
And the same happened for the third time in a different VM machine. Proposing as a blocker just to be sure, until we learn more about it. It might be a problem just for me, or it may influence many more people.
Comment 6 Kamil Páral 2012-05-07 11:09:05 EDT
The weird thing is that this happens in about the middle of the installation, during image copying.
Comment 7 Brian Lane 2012-05-07 12:11:27 EDT
Could you attach /var/log/messages?

I've tried to reproduce with the i686 TC3 desktop live and qemu-kvm -cpu kvm32 and don't see it exiting early or throwing any ext4 errors.
Comment 8 Kamil Páral 2012-05-09 05:05:39 EDT
On Monday I have seen it 3 times out of 3 attempts. Today I could reproduce it only 2 times out of 6 attempts. The rest of the installations completed fine.

Attaching another screenshot and logs. Please notice the screenshot looks very weird, the installation is only half-way done, but it already displays pop-up about post-installation changes.

In the logs there are some squashfs error. I have checked my TC3 i686 Live image and its checksum matches, therefore it is not corrupted.
Comment 9 Kamil Páral 2012-05-09 05:06:05 EDT
Created attachment 583194 [details]
another error screenshot
Comment 10 Kamil Páral 2012-05-09 05:06:20 EDT
Created attachment 583195 [details]
messages
Comment 11 Kamil Páral 2012-05-09 05:06:24 EDT
Created attachment 583196 [details]
dmesg
Comment 12 Kamil Páral 2012-05-09 05:07:45 EDT
Created attachment 583197 [details]
another set of anaconda logs related to dmesg and messages
Comment 13 Kamil Páral 2012-05-09 05:09:22 EDT
If you try to reproduce this, make sure you use "Use all space" option. I always used that one.
Comment 14 Brian Lane 2012-05-09 13:33:12 EDT
Something is wrong with your system, or maybe with KVM. With squashfs errors in the logs there is no telling what kinds of strange things could happen:

May  9 04:47:39 localhost kernel: [   70.974044] SQUASHFS error: xz_dec_run error, data probably corrupt
May  9 04:47:39 localhost kernel: [   70.974049] SQUASHFS error: squashfs_read_data failed to read block 0x1e735eb0
May  9 04:47:39 localhost kernel: [   70.974051] SQUASHFS error: Unable to read data cache entry [1e735eb0]
May  9 04:47:39 localhost kernel: [   70.974053] SQUASHFS error: Unable to read page, block 1e735eb0, size 14cc
May  9 04:47:39 localhost kernel: [   70.974064] SQUASHFS error: Unable to read data cache entry [1e735eb0]
May  9 04:47:39 localhost kernel: [   70.974065] SQUASHFS error: Unable to read page, block 1e735eb0, size 14cc

There are also a bunch of udisk errors, not sure if these mean anything at all:

May  9 04:47:39 localhost udisksd[1162]: Error opening /etc/crypttab file: Failed to open file '/etc/crypttab': No such file or directory (g-file-error-quark, 4)

I'd start by running a memory test on the host, then check the disk that is hosting the .iso file connected to the kvm.
Comment 15 Kamil Páral 2012-05-10 08:53:35 EDT
I'm not sure what was wrong. I ran several hours of tests on my host machine also a memtest inside the virtual machine, all OK. But I can no longer reproduce it with TC4 (tried 6-8 times), so let's say... a glitch.

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