Created attachment 357438 [details] shrink bug - not reproducable in anaconda 12.15 Description of problem: If filesystem shrink (ext4 tested) selected during installation - anaconda fails. Version-Release number of selected component (if applicable): 12/7 How reproducible: always Steps to Reproduce: 1. Shrink file system during installation Actual results: Error appears - see attached screenshot Expected results: No error Additional info:
Could you attach storage.log to this report, please?
I couldn't exactly reproduce this bug on anaconda-12.15. Although another issue appeared here: Partitions before installation: Disk /dev/sda: 8589 MB, 8589934592 bytes 255 heads, 63 sectors/track, 1044 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x000154e4 Device Boot Start End Blocks Id System /dev/sda1 * 1 1008 8089600 83 Linux Partition 1 does not end on cylinder boundary. /dev/sda2 1008 1044 296298+ 83 Linux Steps to reproduce: 1. During installation select to shrink partitions 2. Select sda2 and shrink to 7000MB Actual results: Exception appears. See attached screenshot f12_shring_exception.png Expected results: Shrink of file system successful
Comment on attachment 357438 [details] shrink bug - not reproducable in anaconda 12.15 couldn't reproduce on anaconda-12.7
Comment on attachment 357438 [details] shrink bug - not reproducable in anaconda 12.15 Please ignore comment #3
Created attachment 357633 [details] f12_shrink_exception
Created attachment 357634 [details] storage.log from exception after shrink
Created attachment 357635 [details] anacdump.txt anaconda dump after exception after shrink
Created attachment 357637 [details] anaconda.log anaconda.log after shrink exception
*** Bug 523610 has been marked as a duplicate of this bug. ***
*** Bug 525613 has been marked as a duplicate of this bug. ***
This also failed on ppc
Tested on anaconda 12.36, shrink installed ext2 file system failed. output is: There was an error encountered while resizing the device /dev/sda2 Details resize failed:1
(In reply to comment #12) > Tested on anaconda 12.36, shrink installed ext2 file system failed. output is: > > There was an error encountered while resizing the device /dev/sda2 > Details > resize failed:1 Not only ext2, but also ext3, ext4 file have the same issue.
I'd like to address this bug in rawhide, which means at this point it's a bit too late for Fedora 12. However, I'd like to add something to the release notes explaining what this problem is. "Format failed: 4" means the filesystem resize operation failed because the errors discovered on the filesystem were not able to be automatically corrected. The installer does not try to force correction of these errors, as that could lead to data loss. Instead, you should boot in to rescue mode or another operating system and see what the problem with the filesystem is.
are we sure that's what happened to every reporter, including 12 and 13? liam, he, did the filesystems you were testing on have errors? did you get 'Format failed: 4' in the logs? also, I don't see the string 'format failed' in any of Miroslav's logs or screenshot, and he's talking about an exception, which seems different from a reported failure. I'm not convinced that what David talks about in comment #14 is what all the reporters are actually encountering. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
The main problem here is this bug is now acting as a catch all for anyone not able to shrink an existing filesystem to install. There are several issues showing up here. When I mentioned the 'format failed: 4' problem, people may see that if they try to shrink a filesystem and either fsck run fails. We run fsck before and after the resize operation to make sure the filesystem is safe to continue. Since fsck checks are part of a resize operation and fsck can fail with 'format failed: x', users would have the tendency to group that in with a resize failure. I put a patch in rawhide which makes those failure messages more descriptive and explains to the user that we cannot continue installation with the filesystem in that state. But, since that change breaks the string freeze and introduces new UI elements, it's too late for it to go in to F-12. That's why I wanted the release notes to indicate what 'format failed: x' messages really mean if users see them. It's not an installer failure, it means your filesystem needs some special care. On to the actual issue that this bug was opened for... I think the Fedora test case is entirely valid. But when I've done that locally, it works fine. The errors I'm seeing people report are for fsck failures that occur during a resize, hence wanting the explanation in the release notes for F-12 since it's too late to introduce those changes.
ah, sure, in that case I agree entirely it'd be good to add a release note. just wanted to clarify that it's not the only issue in play here, and adding the release note doesn't mean we can necessarily close the bug. is that how you see it too? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I view this bug as closable once these two things are done: 1) Verify the https://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_%28shrink%29_install test case 2) Add content to the F-12 release notes explaining what 'format failed: 4' really means and how it's not an installer error.
(In reply to comment #18) > I view this bug as closable once these two things are done: As Adam explained not all the reports here could be solved/worked around by that, since several other issues were merged into this bug and that are not fully represented by the original description. For a reproducible case of my report do : 1) create a fresh 2GB raw image disk file (to use as primary disk for a VM) 2) install fedora on it for a kvm/qemu emulated PC with 2GB of ram
david: note that the bugs from Liam Li and He Rui which were closed as dupes of this bug were caused when trying to do exactly your Step 1. From #525613: "Steps to Reproduce: https://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_%28shrink%29_install" All reports actually seemed to hit the exact same error message, and none of them were "format failed: 4", as far as I can see. Liam and He, can you re-run https://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_%28shrink%29_install with the current F12 tree and verify what happens - whether it works, or you hit this bug, or you hit a different bug? Thanks. If possible, please verify the filesystem is clean with fsck before testing. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Can anyone seeing "resize failed: 1" look at tty5 when that happens and check the error message as displayed by resize2fs. If you are unable to see tty5, grab /tmp/anaconda.log, /tmp/storage.log, and /tmp/program.log on the system you're installing on.
Created attachment 366206 [details] logs please see comment#12. I did not find errors at tty5, the last line is: resize2fs:New size smaller than minimum, Dropping master... I will attach the logs,please see below.
Created attachment 366753 [details] 0001-Fix-resize-failed-1-errors-for-ext2-ext3-ext4-5.patch This patch fixes the problem that I think everyone has been running in to. It was somewhat difficult to track down, but I got it. The log entry for the patch explains what is going on. I've submitted this patch for review by the rest of the installer team, but I wanted to post it here so other people could see what I found.
confirmed bug reported in 523610 still present after the fix (which I hope fixes the resizing problem that was reported here). can someone unlink this bug from that one, so that it can be handled independently?
Reviewed at the blocker bug meeting today: we accepted this on the basis the patch only touches ext resizing code, so it's very unlikely to cause regressions in any other function, and ext resizing is mostly broken without it. This will go into the next anaconda build, and can be re-tested at that point. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Arenas, can you be more clear on exactly how you tested with this fix? There is no anaconda 12.42 build available anywhere yet. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #26) > Arenas, can you be more clear on exactly how you tested with this fix? There is > no anaconda 12.42 build available anywhere yet. my bad, was using 12.41-1 as shown by the traceback on BUG523610, will retry once a new snapshot is available.
this is in the 12.42 build: http://koji.fedoraproject.org/koji/buildinfo?buildID=139122 tag request: https://fedorahosted.org/rel-eng/ticket/2942 -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This should be in tomorrow's (20091103) rawhide; please test that.
Alternatively, this can be tested using a rawhide live image even if the live image contains an older anaconda package.(In reply to comment #29) > This should be in tomorrow's (20091103) rawhide; please test that. Alternatively, this can be tested now using a rawhide live image even if the live image contains an older anaconda package. Boot the live image, then `yum update anaconda` to install the latest package.
I tested this with 12.43 and in a basic test scenario could not find any problem. Here's what I did: * created a blank 20GB disk for a virtual machine * booted a custom live build with anaconda 12.43 * installed (hostname 'testbed') with a custom partition layout: one 18GB ext4 partition, one 2GB swap partition * booted back to the live environment * installed again (hostname 'testbed2'), this time telling the installer to shrink the existing ext4 partition (/dev/vda1) to 9GB * completed the install * booted from disk: this booted testbed2 * adjusted testbed2's grub to also have a stanza for booting testbed * verified that I can now boot either testbed or testbed2 on demand * verified the partition layout is correct: /dev/sda1 is now 9GB in size, testbed2 stuck itself onto the typical LVM mess that anaconda creates, in the 9GB of free space created by shrinking /dev/sda1 I didn't test whether I had trouble trying to do the above with 12.41, but at least 12.43 is tested to work in this basic scenario. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Verified this issue fixed on anaconda 12.42 in rawhide-20091103-x86_64.
i think we can close this, then. I guess we can say, if your bug was closed as a dupe of this but you still have trouble with 12.42, please re-open your bug. If you have a problem trying to shrink an existing filesystem during install, and it's not a 'format failed: 4', probably file a new bug and mention it here. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Wow,I feel sorry to say that this issue happened again in anaconda 12.43 and the steps below is 100% reproducable in my machine: 1. Install f12 with minimal package install, clear all existing partitions and create new partitions like this: sda1 /boot ext4 200M sda2 / ext4 20G sda3 swap 512M the other settings is by default. (A ks.cfg was attached for this installation.) 2. Install another f12 on the same machine, in the partition step, choose 'shrink sda2' and click 'OK'. 3. Exception occurred saying 'ValueError: not enough free space in volume group' , see https://bugzilla.redhat.com/attachment.cgi?id=367578
Created attachment 367588 [details] ks.cfg for installing a f12 system to be shrunk. The nfs source need to be changed if using this ks.cfg.
He Rui - please see comment #33. You're getting a separate issue when resizing filesystems, not the "format failed: 4" business. Therefore, please open a separate bug. Thanks.
re-closing this one then. rui, please file a new one and let us know where it is, thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
In Comment #9, Bug 523610, which has been closed as a duplicate of this bug, is actually reproduced by my steps. So I reopen Bug 523610 for the problem.