Bug 1162215 - partition resize does not check filesystem minimum size
Summary: partition resize does not check filesystem minimum size
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Keywords: Reopened
Depends On:
Blocks: F21FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2014-11-10 14:43 UTC by Kamil Páral
Modified: 2016-11-02 06:27 UTC (History)
12 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2014-12-05 03:26:33 UTC


Attachments (Terms of Use)
bug video demonstration (1.73 MB, application/ogg)
2014-11-10 14:44 UTC, Kamil Páral
no flags Details
anaconda.log (42.01 KB, text/plain)
2014-11-10 14:44 UTC, Kamil Páral
no flags Details
program.log (32.75 KB, text/plain)
2014-11-10 14:44 UTC, Kamil Páral
no flags Details
storage.log (348.71 KB, text/plain)
2014-11-10 14:44 UTC, Kamil Páral
no flags Details
proposed patch (3.77 KB, patch)
2014-11-26 15:01 UTC, Vratislav Podzimek
no flags Details | Diff
fixed version of the proposed patch (3.79 KB, patch)
2014-11-27 09:42 UTC, Vratislav Podzimek
no flags Details | Diff
final version of the patch (5.32 KB, patch)
2014-11-27 15:14 UTC, Vratislav Podzimek
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1163410 None None None Never
Red Hat Bugzilla 1163694 None None None Never
Red Hat Bugzilla 1170803 None None None Never

Internal Trackers: 1163410 1163694 1170803

Description Kamil Páral 2014-11-10 14:43:22 UTC
Description of problem:
I tried to shrink an LV in custom partitioning dialog, and then use the VG and the freed space to create installation target partitions for F21. I've found out that I can shrink the existing LVs to an arbitrary low value, regardless of how much free space is really available in the filesystem. Anaconda then "crashes" in the first step of the installation (it doesn't exactly crash, it should announces the resize failed and exits).

Please see video.

Version-Release number of selected component (if applicable):
anaconda 21.48.13-1

How reproducible:
always

Steps to Reproduce:
1. have an existing VG with LV with some data (I used root partition from a previous Fedora installation)
2. boot up anaconda, go to custom part
3. try to resize the LV to a very small size (smaller than the actual contents)
4. see that anaconda does not complain
5. create the rest of the layout
6. start installation
7. see "crash"

Expected results:
anaconda should check the filesystem min size when shrinking LV in custom part

Comment 1 Kamil Páral 2014-11-10 14:44:13 UTC
Created attachment 955842 [details]
bug video demonstration

Comment 2 Kamil Páral 2014-11-10 14:44:25 UTC
Created attachment 955843 [details]
anaconda.log

Comment 3 Kamil Páral 2014-11-10 14:44:27 UTC
Created attachment 955844 [details]
program.log

Comment 4 Kamil Páral 2014-11-10 14:44:32 UTC
Created attachment 955845 [details]
storage.log

Comment 5 Kamil Páral 2014-11-10 15:43:56 UTC
A summary of our findings from #anaconda: It seems that resize2fs in certain circumstances (maybe always?) requires e2fsck to be run first. Which anaconda doesn't seem to take into account at the moment. If you run e2fsck on the partition before starting anaconda, the resize works correctly, and anaconda gui does not allow you to set below-minimum target size.

Comment 6 Kamil Páral 2014-11-10 15:54:07 UTC
I guess this violates " Reject or disallow invalid disk and volume configurations without crashing. " criterion from https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria#Custom_partitioning . It did not crash per-say, but the end result is the same.

Please note that in my case, I haven't lost any data. The resize operation, which failed, was the first one scheduled. So anaconda didn't touch my disk at all. But this might have been just a lucky situation, and in other cases some operations might run before shrinking. Anaconda devs can say more.

Comment 7 Adam Williamson 2014-11-11 03:44:28 UTC
well, we kind of explicitly worded the shrink criterion quite restrictively:

"Any installer mechanism for resizing storage volumes must correctly attempt the requested operation."

I think to exclude issues like this. It does try to check whether the volume needs fsck'ing in certain situations, I think, but I'm not sure we want to block on it.

Comment 8 Kamil Páral 2014-11-11 08:50:52 UTC
More information: "resize2fs -P" (to print the minimum filesystem size) does not require running e2fsck first only if a) the filesystem is mounted, or b) e2fsck was the *last operation* on it (mounting and unmounting after running e2fsck makes resize2fs request e2fsck again). So in real life, filesystem check will be most probably requested in 99% of cases. This might be a recent change in resize2fs, and anaconda has not adjusted yet.

At the moment, if e2fsck is required, anaconda allows to set an arbitrary low value when resizing. David Lehman has a patch that simply disallows resizing in such a case, which is sub-optimal (the user has no idea why it can't be done), but still an improvement. At least this should be covered a blocker bug, I believe. And it seems to be this violates the criterion as written, because the resize operation is not correctly attempted at the moment (if you try to shrink a full 1 GB filesystem down to 1 MB, it's not a correct operation).

David has a second patch which allows shrinking only down to the minimum size, but not lower, which is the optimal solution. But I've found a problem in it yesterday - I kept the lowest minimum size offered and resize2fs said it was too small. I guess there was some rounding problem. Waiting for David to find a bug and post an updated updates.img.

Comment 9 Josef Skladanka 2014-11-11 09:34:16 UTC
Just FYI - I tried resizing with pure EXT4 partition (no LVM in play), and the guided partitioning.
Created 5G partion with 1G file on it. The guided partitioning then allowed me to shrink the partition below 1G (selected 500M), which then resulted in an error in the installing process.

Comment 10 David Lehman 2014-11-11 15:42:40 UTC
Kamil, I need the storage.log and program.log showing the resize2fs failure in order to see exactly what happened.

Comment 11 David Lehman 2014-11-11 15:44:18 UTC
To be clear, this is a change to resize2fs. This worked correctly in F20 at least, and we did not force an fsck before obtaining min size there either.

Comment 12 Kamil Páral 2014-11-12 09:49:36 UTC
(In reply to David Lehman from comment #11)
> To be clear, this is a change to resize2fs. This worked correctly in F20 at
> least, and we did not force an fsck before obtaining min size there either.

Looking at my IRC history, this should be it:
http://paste.fedoraproject.org/149421/64036014/
http://paste.fedoraproject.org/149440/44178141/
If it wasn't, I can reproduce again.

Comment 13 David Lehman 2014-11-12 15:30:46 UTC
(In reply to Kamil Páral from comment #12)
> (In reply to David Lehman from comment #11)
> > To be clear, this is a change to resize2fs. This worked correctly in F20 at
> > least, and we did not force an fsck before obtaining min size there either.
> 
> Looking at my IRC history, this should be it:
> http://paste.fedoraproject.org/149421/64036014/
> http://paste.fedoraproject.org/149440/44178141/
> If it wasn't, I can reproduce again.

Please open a separate bug for that failure. I will have a patch for it soon.

Comment 14 Kamil Páral 2014-11-12 16:25:29 UTC
Discussed at today's blocker review meeting [1]. Accepted as a blocker. This bug is a clear violation of the Final criterion: "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation." [2] 

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-12/
[2] https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria#Storage_volume_resize

Comment 15 David Lehman 2014-11-13 20:28:47 UTC
I notice that on TC2 resize2fs does not require an e2fsck prior.

Comment 16 Kamil Páral 2014-11-14 13:11:07 UTC
(In reply to David Lehman from comment #15)
> I notice that on TC2 resize2fs does not require an e2fsck prior.

In my testing, it does:

[root@localhost ~]# resize2fs -P /dev/vda1
resize2fs 1.42.11 (09-Jul-2014)
Please run 'e2fsck -f /dev/vda1' first.
[root@localhost ~]# e2fsck -f /dev/vda1
e2fsck 1.42.11 (09-Jul-2014)
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
data: 12/488640 files (0.0% non-contiguous), 323737/1953125 blocks
[root@localhost ~]# resize2fs -P /dev/vda1
resize2fs 1.42.11 (09-Jul-2014)
Estimated minimum size of the filesystem: 563802
[root@localhost ~]# mount /dev/vda1 /mnt
[root@localhost ~]# umount /mnt
[root@localhost ~]# resize2fs -P /dev/vda1
resize2fs 1.42.11 (09-Jul-2014)
Please run 'e2fsck -f /dev/vda1' first.

Maybe you had it mounted?

Comment 17 Fedora Update System 2014-11-19 01:56:49 UTC
anaconda-21.48.15-1.fc21, python-blivet-0.61.10-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/python-blivet-0.61.10-1.fc21,anaconda-21.48.15-1.fc21

Comment 18 Kamil Páral 2014-11-19 13:20:58 UTC
Verified fixed with the update above.

Comment 19 Kamil Páral 2014-11-24 11:57:02 UTC
That update was already superseded, closing bug.

Comment 20 Fedora Update System 2014-11-25 03:06:17 UTC
python-blivet-0.61.10-1.fc21, anaconda-21.48.16-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 21 Brian Lane 2014-11-25 19:53:50 UTC
There are a couple problems with the fix for this:

bug 1167959 is a side-effect of it, dosfsck is being run and getting stuck (it should use -n).

But also we have e2fsck running with '-f -p -C 0' which tells it to fix the easy problems. I'm not sure it is a good idea to run this on every disk on the system, I think it should be limited to disks selected by the user.

In addition to changing things unexpectedly it will slow things down on those systems with piles of small disks attached.

Comment 22 Vratislav Podzimek 2014-11-26 15:01:14 UTC
Created attachment 961689 [details]
proposed patch

What about this patch? It should make sure that the FS check is run only if necessary.

Comment 23 Vratislav Podzimek 2014-11-26 15:02:46 UTC
(In reply to Vratislav Podzimek from comment #22)
> Created attachment 961689 [details]
> proposed patch
> 
> What about this patch? It should make sure that the FS check is run only if
> necessary.
Link to an updates.img with the patch:
http://vpodzime.fedorapeople.org/1162215_updates.img

Kamil, could you please verify that it still works?

Comment 24 Vratislav Podzimek 2014-11-27 09:42:25 UTC
Created attachment 961934 [details]
fixed version of the proposed patch

The new version of the proposed patch with a fix for a bug causing traceback ('errors' not being set if everything went fine).

Comment 25 Kamil Páral 2014-11-27 11:17:43 UTC
I tested with https://vpodzime.fedorapeople.org/ultimate_f21_updates.img and unfortunately it breaks the possibility to shrink a partition in custom partitioning - the size field value is always reverted to the current size value.

Comment 26 Kamil Páral 2014-11-27 12:30:08 UTC
A new version of the patch (same url) fixed the problem. It seems to work OK now.

Comment 27 Vratislav Podzimek 2014-11-27 15:14:09 UTC
Created attachment 962111 [details]
final version of the patch

Just for the record

Comment 28 Fedora Update System 2014-11-27 17:22:24 UTC
anaconda-21.48.18-1.fc21,python-blivet-0.61.12-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/anaconda-21.48.18-1.fc21,python-blivet-0.61.12-1.fc21

Comment 29 Fedora Update System 2014-11-27 23:59:22 UTC
pyparted-3.10.2-1.fc21, python-blivet-0.61.12-1.fc21, anaconda-21.48.18-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/FEDORA-2014-15910/pyparted-3.10.2-1.fc21,python-blivet-0.61.12-1.fc21,anaconda-21.48.18-1.fc21

Comment 30 Fedora Update System 2014-11-29 20:59:15 UTC
Package pyparted-3.10.2-1.fc21, python-blivet-0.61.12-1.fc21, anaconda-21.48.18-1.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing pyparted-3.10.2-1.fc21 python-blivet-0.61.12-1.fc21 anaconda-21.48.18-1.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-15910/pyparted-3.10.2-1.fc21,python-blivet-0.61.12-1.fc21,anaconda-21.48.18-1.fc21
then log in and leave karma (feedback).

Comment 31 Kamil Páral 2014-12-01 10:37:22 UTC
This works well in RC1.

Comment 32 Fedora Update System 2014-12-05 03:26:33 UTC
anaconda-21.48.21-1.fc21, python-blivet-0.61.13-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 33 Adam Williamson 2014-12-08 20:37:34 UTC
I think this change may be behind https://bugzilla.redhat.com/show_bug.cgi?id=1170803 .


Note You need to log in before you can comment on or make changes to this bug.