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
Created attachment 582690 [details] anaconda.log
Created attachment 582691 [details] program.log
Created attachment 582692 [details] storage.log
On second attempt exactly the same happened.
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.
The weird thing is that this happens in about the middle of the installation, during image copying.
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.
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.
Created attachment 583194 [details] another error screenshot
Created attachment 583195 [details] messages
Created attachment 583196 [details] dmesg
Created attachment 583197 [details] another set of anaconda logs related to dmesg and messages
If you try to reproduce this, make sure you use "Use all space" option. I always used that one.
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.
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.