Bug 819563 - ext4 filesystem check failure on /dev/mapper/vg-lv_root
Summary: ext4 filesystem check failure on /dev/mapper/vg-lv_root
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: F17Blocker, F17FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2012-05-07 14:41 UTC by Kamil Páral
Modified: 2012-05-10 12:53 UTC (History)
5 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2012-05-09 17:33:12 UTC


Attachments (Terms of Use)
screenshot (57.21 KB, image/png)
2012-05-07 14:41 UTC, Kamil Páral
no flags Details
anaconda.log (9.11 KB, text/plain)
2012-05-07 14:42 UTC, Kamil Páral
no flags Details
program.log (116.00 KB, text/plain)
2012-05-07 14:42 UTC, Kamil Páral
no flags Details
storage.log (294.10 KB, text/plain)
2012-05-07 14:42 UTC, Kamil Páral
no flags Details
another error screenshot (62.06 KB, image/png)
2012-05-09 09:06 UTC, Kamil Páral
no flags Details
messages (205.32 KB, text/plain)
2012-05-09 09:06 UTC, Kamil Páral
no flags Details
dmesg (58.39 KB, text/plain)
2012-05-09 09:06 UTC, 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 09:07 UTC, Kamil Páral
no flags Details

Description Kamil Páral 2012-05-07 14:41:58 UTC
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 14:42:20 UTC
Created attachment 582690 [details]
anaconda.log

Comment 2 Kamil Páral 2012-05-07 14:42:24 UTC
Created attachment 582691 [details]
program.log

Comment 3 Kamil Páral 2012-05-07 14:42:28 UTC
Created attachment 582692 [details]
storage.log

Comment 4 Kamil Páral 2012-05-07 14:48:04 UTC
On second attempt exactly the same happened.

Comment 5 Kamil Páral 2012-05-07 14:55:11 UTC
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 15:09:05 UTC
The weird thing is that this happens in about the middle of the installation, during image copying.

Comment 7 Brian Lane 2012-05-07 16:11:27 UTC
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 09:05:39 UTC
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 09:06:05 UTC
Created attachment 583194 [details]
another error screenshot

Comment 10 Kamil Páral 2012-05-09 09:06:20 UTC
Created attachment 583195 [details]
messages

Comment 11 Kamil Páral 2012-05-09 09:06:24 UTC
Created attachment 583196 [details]
dmesg

Comment 12 Kamil Páral 2012-05-09 09:07:45 UTC
Created attachment 583197 [details]
another set of anaconda logs related to dmesg and messages

Comment 13 Kamil Páral 2012-05-09 09:09:22 UTC
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 17:33:12 UTC
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 12:53:35 UTC
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.