The following was filed automatically by anaconda: anaconda 13.36 exception report Traceback (most recent call first): File "/usr/lib/anaconda/storage/formats/fs.py", line 471, in doResize raise FSResizeError("resize failed: %s" % rc, self.device) File "/usr/lib/anaconda/storage/deviceaction.py", line 348, in execute self.device.format.doResize(intf=intf) File "/usr/lib/anaconda/storage/devicetree.py", line 672, in processActions action.execute(intf=self.intf) File "/usr/lib/anaconda/storage/__init__.py", line 290, in doIt self.devicetree.processActions() File "/usr/lib/anaconda/packages.py", line 109, in turnOnFilesystems anaconda.storage.doIt() File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/dispatch.py", line 126, in gotoNext self.moveStep() File "/usr/lib/anaconda/gui.py", line 1313, in nextClicked self.anaconda.dispatch.gotoNext() FSResizeError: ('resize failed: 1', '/dev/sda2')
Created attachment 401946 [details] Attached traceback automatically from anaconda.
steps: 1. Virt-install f13-beta-tc1 with the following partitioning: sda1 /boot --fstype ext4 --size 200 sda2 / --fstype ext3 --size 3000 sda3 swap --fstype swap --size 500 2. Install it again with sda2 shrinked. 3. Error occurred.
The second time I tried, it hanged at: Creating device /dev/mapper/VolGroup-lv_root and couldn't turn to other ttys.
Adamw reminded me that we don't have explicit criteria listed for partition resize, since it was deemed too fragile to hold up a release for when the release criteria were proposed. I'm going to change this to F13Blocker until we know a bit more about this failure. Looking at the debug log attached, it seems like you might be resizing the partition to a value too small (67M)? 02:46:12,263 INFO program: Running... resize2fs -p /dev/sda2 67M 02:46:12,308 ERROR program: resize2fs 1.41.10 (10-Feb-2009) 02:46:12,317 ERROR program: resize2fs: New size smaller than minimum (206434) 02:46:12,321 ERROR program: In order to determine if this is specific to the this test, or a general problem affecting all resizes, can you try another resize test? Can you start with an 6 or 8G '/' partition with a minimal install. Then try to resize that partition to 4G?
(In reply to comment #4) > Adamw reminded me that we don't have explicit criteria listed for partition > resize, since it was deemed too fragile to hold up a release for when the > release criteria were proposed. I'm going to change this to F13Blocker until > we know a bit more about this failure. > > Looking at the debug log attached, it seems like you might be resizing the > partition to a value too small (67M)? > > 02:46:12,263 INFO program: Running... resize2fs -p /dev/sda2 67M > 02:46:12,308 ERROR program: resize2fs 1.41.10 (10-Feb-2009) > 02:46:12,317 ERROR program: resize2fs: New size smaller than minimum (206434) > 02:46:12,321 ERROR program: 67M is the auto detected size when choose shrinking sda2. but yes, it's a little extreme. > > In order to determine if this is specific to the this test, or a general > problem affecting all resizes, can you try another resize test? > > Can you start with an 6 or 8G '/' partition with a minimal install. Then try > to resize that partition to 4G? This time I tried as you suggested, it passed.
I am unable to reproduce this using F13-Beta-TC1-Live-i686, instead I end up hitting #576710 What image did you use for this test?
(In reply to comment #6) > I am unable to reproduce this using F13-Beta-TC1-Live-i686, instead I end up > hitting #576710 > > What image did you use for this test? This was discovered using the http://serverbeach1.fedoraproject.org/pub/alt/stage/13-Beta.TC1 images. Looking at the attached anacdump.txt, it appears to be a DVD or disc1 iso. 06:40:26,138 INFO loader: stage2 url is cdrom:///dev/sr0:/mnt/stage2
I am unable to reproduce this with both the Fedora-13-Beta-i386-netinst.iso and Fedora-13-Beta-i386-disc1.iso images and cannot reproduce this. They are using Anaconda 13.37 When I resize it < 250M I get a warning dialog, but can continue past creating the partitions. Resizing > 250M works fine as well. When I get the dialog and go back to resize again it won't let me, so I remove it and create a new partition and hit bug 576710, so I think whatever this one was has been fixed.
Created attachment 403411 [details] Attached traceback automatically from anaconda.
Steps the same as comment 2: 1. Minimal Virt-install f13-beta-rc1 with the following partitioning: sda1 /boot --fstype ext4 --size 200 sda2 / --fstype ext3 --size 3000 sda3 swap --fstype swap --size 500 2. Install it again with sda2 shrinked (Use what it suggested). 3. Error occurred.
Something I didn't know -- resize2fs is only run if you don't select format for the partition you are resizing. So to reproduce the problem you have to make sure resize is checked and format is not checked.
Created attachment 403806 [details] dumpe2fs and resize2fs -P output on an unclean fs This shows the state of the filesystem after the virtual was turned off with 'force off' so that the fs was not unmounted. Note that it says clean, but has needs_recovery in the Filesystem features line.
Created attachment 403807 [details] Output of dumpe2fs and resize2fs -P after running e2fsck -f -p -C0 /dev/sda2 This shows the proper filesystem state and proper minimum size for the filesystem.
Here is what is happening: resize2fs doesn't report the correct minimum size if the partition wasn't unmounted properly. It requires an e2fsck of the fs before it can calculate it correctly. This can be duplicated by doing a virt install and turning off the virt at the package selection screen, then rebooting and trying to shrink the partition. The minimum that is suggested is much lower than it should be. Looking at the filesystem state using dumpe2fs shows that the clean flag is still set, but that there is a 'needs_recovery' flag set in the Filesystem features.
This sounds like a combination of bugs; resize2fs -P should refuse to give an answer on a mounted or needs_recovery fs, because it has no consistent view of the fs. And then resize2fs should refuse to shrink a needs_recovery fs, if it doesn't already... But it also sounds like anaconda will need to check for this result and handle it. the root cause here was that the install was trying to manipulate an unclean/unrecovered filesystem image, yes? -Eric
Ok, resize2fs already won't touch the dirty fs it seems, that's good. # resize4fs myimage3 75623 resize4fs 1.41.9 (22-Aug-2009) Please run 'e4fsck -f myimage3' first. We should give the same error for resize2fs -P
I've sent a patch upstream to make resize2fs -P error out on a dirty fs. http://marc.info/?l=linux-ext4&m=127006372921936&w=2 With that patch, resize2fs -P will say "please run e2fsck..." and exit with non-0 status. Anaconda will need to cope with this, though. -Eric
I have committed a workaround for this to rawhide. bug 578955, anaconda commit 96445547da4dd5d92aa37a46b95472d63671888f It re-checks the minimum size after running e2fsck on the partition before running resize2fs on it and adjusts the target size accordingly if it is too small.
Are both fixes planned for F13 as well?
The patch linked in comment #17 should be extN-agnostic for all values of N. Can't speak to the anaconda change :) -Eric
A patch to work around this has been committed to anaconda's master and f13-branch. As comment 17 says, when the e2fsprogs patch comes through there will need to be another patch to anaconda to deal with the new return code.
(In reply to comment #21) > As comment 17 says, when the e2fsprogs patch comes through there will need to > be another patch to anaconda to deal with the new return code. I doubt I'll push it pre-F13; it's not upstream yet, and it'd just be more churn for anaconda. So if it's ok with you guys, you can just not worry about it until F14 :) -Eric
Sounds like a good plan to me.
Discussed at today's blocker meeting. If we're understanding this correctly, the issue is actually okay in F13 at present. As long as e2fsprogs is not 'fixed' for F13, anaconda will behave correctly. So as we understand it, the best course of action is to have the correct fix in both e2fsprogs and anaconda for F14, and leave F13 exactly as it is right now. Removing from f13blocker on this basis. Eric, please confirm that you will not apply the fix to e2fsprogs for F13. Everyone, please advise if we're reading this wrong :) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #24) > Discussed at today's blocker meeting. If we're understanding this correctly, > the issue is actually okay in F13 at present. As long as e2fsprogs is not > 'fixed' for F13, anaconda will behave correctly. May be fixed post-GA for e2fsprogs but anaconda won't care (hrm but then later spins might care...) Well, we'll deal with that when/if it comes. > Eric, please confirm that you will not > apply the fix to e2fsprogs for F13. Not prior to GA anyway. -Eric
Ok, patch exists upstream. I'm going to change this to NEXTRELEASE and close it, hopefully anaconda will be ready by F14 ;) -Eric From: Eric Sandeen <sandeen> Date: Wed, 31 Mar 2010 19:28:42 +0000 (-0500) Subject: resize2fs: don't print minimum size if fs is not clean X-Git-Url: http://git.kernel.org/?p=fs%2Fext2%2Fe2fsprogs.git;a=commitdiff_plain;h=5fa92bc76888404b161b3fd0fd7e6b63e064badf resize2fs: don't print minimum size if fs is not clean Right now, resize2fs -P on a dirty filesystem will give you a number; however, it's probably wrong if the fs is not clean: # resize2fs -P myimage.img resize2fs 1.41.9 (22-Aug-2009) Estimated minimum size of the filesystem: 75623 # e2fsck -fy myimage.img e2fsck 1.41.9 (22-Aug-2009) myimage.img: recovering journal Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information myimage.img: ***** FILE SYSTEM WAS MODIFIED ***** myimage.img: 9530/53760 files (0.1% non-contiguous), 24737/98304 blocks # resize2fs -P myimage.img resize2fs 1.41.9 (22-Aug-2009) Estimated minimum size of the filesystem: 32165 We should issue the same "Please run e2fsck ..." message for -P as we do for an actual resize request. Signed-off-by: Eric Sandeen <sandeen> Signed-off-by: Theodore Ts'o <tytso> --- diff --git a/resize/main.c b/resize/main.c index 220c192..ddcfc99 100644 --- a/resize/main.c +++ b/resize/main.c @@ -345,6 +345,14 @@ int main (int argc, char ** argv) min_size = calculate_minimum_resize_size(fs); if (print_min_size) { + if (!force && ((fs->super->s_lastcheck < fs->super->s_mtime) || + (fs->super->s_state & EXT2_ERROR_FS) || + ((fs->super->s_state & EXT2_VALID_FS) == 0))) { + fprintf(stderr, + _("Please run 'e2fsck -f %s' first.\n\n"), + device_name); + exit(1); + } printf(_("Estimated minimum size of the filesystem: %u\n"), min_size); exit(0);
(In reply to comment #24) > Discussed at today's blocker meeting. If we're understanding this correctly, > the issue is actually okay in F13 at present. As long as e2fsprogs is not > 'fixed' for F13, anaconda will behave correctly. NO, is not correct :D See my attachment
Created attachment 418404 [details] anaconda log
That's clearly a different bug: this is about e2resize (which resizes ext* partitions), but from your log, you were trying to resize an NTFS partition. Please file a separate bug. Thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers