Bug 812155

Summary: filesystem check failure in custom partition setup
Product: [Fedora] Fedora Reporter: Wolfgang Pirker <w_pirker>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 17CC: anaconda-maint-list, bugzilla, esandeen, g.kaviyarasu, jonathan, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-15 17:43:51 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:
Attachments:
Description Flags
anaconda log
none
messages log
none
program log
none
storage log none

Description Wolfgang Pirker 2012-04-12 22:32:46 UTC
Description of problem:
Anaconda reports a Unrecoverable Error at the end of the Fedora 17 installation: "ext4 filesystem check failure on /dev/sda9: Filesystem error left uncorrected [...]"


Steps to Reproduce:
1. in the anaconda installer choose "Create Custom Layout"
2. choose a root partition with type ext4 and format it, (I created also a 2 GB swap, and a encrypted home partition with filesystem type xfs)
3. finish the installation
  
Actual results:
at the end of the procedure "Copying live image to hard drive", it will very likely report this unrecoverable error. After clicking on OK it will reboot the computer automatically. I noticed also that it always reboots when the installer is closed (probably this bug is already reported or known). 

Additional info:
- used Fedora 17 pre-release: Beta RC4

Comment 1 Chris Murphy 2012-04-12 23:51:16 UTC
Please post anaconda logs. Suspect dupe of 804779.

Comment 2 Wolfgang Pirker 2012-04-13 12:18:26 UTC
Created attachment 577313 [details]
anaconda log

ok I attempted it again, without xfs partition and the same error happened again.
I post the logs: anaconda.log, messages, program.log, storage.log

Comment 3 Wolfgang Pirker 2012-04-13 12:19:08 UTC
Created attachment 577314 [details]
messages log

Comment 4 Wolfgang Pirker 2012-04-13 12:19:50 UTC
Created attachment 577315 [details]
program log

Comment 5 Wolfgang Pirker 2012-04-13 12:20:29 UTC
Created attachment 577316 [details]
storage log

Comment 6 Chris Murphy 2012-04-13 16:11:33 UTC
How was the install media (USB stick) created? dd, livecd-tools (version?), or the livecd-iso-to-disk that's on the RC4 LiveCD?

Maybe someone else can sort this out better, but I could use more detail on exactly what the custom partition layout looked like. I'm seeing ntfsresize being called. A 14G /boot on sda4? No sda6 but an sda7.

When sda4 is formatted ext4, the format fails with an error. A subsequent e2fsck on sda4 then also fails. This is not an encrypted partition. When reattempting to install, dumpe2fs also finds errors.

Comment 7 Wolfgang Pirker 2012-04-13 16:42:27 UTC
I used livecd-iso-to-disk to create the install media. 

the partition table output via parted:
Model: ATA SAMSUNG HM250JI (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: pmbr_boot

Number  Start   End     Size    File system     Name  Flags
 1      1049kB  32.1GB  32.1GB  ntfs                  hidden, msftres, legacy_boot
 2      32.1GB  59.6GB  27.5GB  ntfs
 3      59.6GB  59.6GB  1049kB                        bios_grub
 4      59.6GB  75.0GB  15.4GB  ext4
 5      75.0GB  123GB   48.5GB
 7      123GB   126GB   2147MB  linux-swap(v1)

I created the ntfs partitions via gnome-disk-utilty under the F17 live system.

Comment 8 Chris Murphy 2012-04-13 19:10:50 UTC
I'm virtually certain this is not an anaconda bug. I can't reproduce this, even with a 15G /boot (which really makes no sense, but it works for me). 

It's unclear why your anaconda log says you are starting out with 6 partitions when based on what you've written, you should have had two NTFS partitions and the rest free space. And it's not clear why you're missing sda6, so you must've deleted a partition at some point in anaconda. 

An exact step by step recipe of how you are reproducing this might be helpful because so far I can't reproduce it.

Comment 9 Wolfgang Pirker 2012-04-13 19:46:14 UTC
ok I will post a more accurate description later. 

this 15 GB partition is mounted as / not /boot

Comment 10 Chris Murphy 2012-04-13 22:39:40 UTC
You know what, before you go to the trouble, could you boot the LiveCD, and run
mke2fs -t ext4 /dev/sda4

program.log indicates this fails, and it's the subsequent 'e2fsck -f -p -C 0 /dev/sda4' failure that causes the error reported by anaconda.

Comment 11 Wolfgang Pirker 2012-04-14 00:29:55 UTC
ok after I went through the installation the command "e2fsck -f -p -C 0
/dev/sda4" fails indeed. But the command works if I format the partitions fresh in anaconda, after the partitions are formatted and before the copying to hard disk begun this command still worked. But at the and of the copy process it shows this unrecoverable error. And then also the command above show this output: 
"_Fedora-17-Beta-: Superblock last mount time (Tue Apr 10 01:06:12 2012,
	now = Mon Feb 20 14:04:50 2012) is in the future.


_Fedora-17-Beta-: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
	(i.e., without -a or -p options)"

oh damn. I didn't know that the time of the notebook is so wrong, I don't use it often. Probably that's the reason, I will try if I can reproduce the error even if the time is correct.

Comment 12 Chris Murphy 2012-04-14 00:51:21 UTC
It makes sense that e2fsck is going to be annoyed and fail, because the mke2fs command failed. The create file system cause is the one I'm curious about, why it's failing.

Sounds something like bug 522969. cc'ing Eric Sandeen. Still not sure this is anaconda.

Comment 13 Wolfgang Pirker 2012-04-14 01:00:08 UTC
yes with the corrected notebook time it installs successfully. 

Thanks for your help.

Comment 14 Chris Murphy 2012-04-14 02:02:11 UTC
Wow, not a graceful failure from an incorrectly set date! Not graceful at all. I'm able to reproduce this as well. Wonky. And certainly not an even remotely helpful error message at the end of the installation, to die the problem to date. This problem prevents the resizing of the file system, and the resulting installation is useless/not bootable.

Comment 15 Chris Lumens 2012-04-15 17:43:51 UTC

*** This bug has been marked as a duplicate of bug 811706 ***