Bug 474269 - Resize (shrink) old partition, but the filesystem data is not shrunk to match.
Resize (shrink) old partition, but the filesystem data is not shrunk to match.
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
i686 Linux
low Severity high
: ---
: ---
Assigned To: Jeremy Katz
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-12-02 20:44 EST by Donald Arseneau
Modified: 2009-02-16 15:32 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-02-16 15:32:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
anaconda.log (27.79 KB, text/plain)
2008-12-03 23:26 EST, Donald Arseneau
no flags Details
anaconda.syslog (48.34 KB, text/plain)
2008-12-03 23:27 EST, Donald Arseneau
no flags Details

  None (edit)
Description Donald Arseneau 2008-12-02 20:44:13 EST
During installation of a new Fedora-10 system, I shrunk an existing ext3 partition to make room for a new partition.  Old partition was 18% full and I shrunk it to half size.  Now the old filesystem is corrupt, and the superblock still wants the original size.The installer did not shrink the old filesystem, but only edited the partition table.

This is partition sda1 on a sata drive.  Most of the disk is under LVM,
but not this partition. 

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

(I'm not sure what the disk partitioning tool is during installation.  I selected "anaconda" as the component.)

How reproducible:

Have not tried again.

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Chris Lumens 2008-12-03 09:53:08 EST
We definitely do shrink the filesystem as well.  Can you attach /var/log/anaconda.log and /var/log/anaconda.syslog to this bug report?
Comment 2 Donald Arseneau 2008-12-03 23:26:40 EST
Created attachment 325635 [details]

Here is anaconda.log.  The file's time-stamp looks correct, 
but the times on each entry don't correspond to anything 
I know... maybe they are UTC time. 
I don't recognize any resizing or creation of partitions, 
but do see creation of filesystems.  

/dev/VolGroup00/LogVol03 is the new main partition, 
created from free space in the installation.

/dev/sda1 was an existing (non-LVM) partition that 
I shrunk, and which wound up damaged.

/dev/sda3 is the new /boot partition that I put into 
the space freed up by shrinking /dev/sda1.
Comment 3 Donald Arseneau 2008-12-03 23:27:56 EST
Created attachment 325636 [details]
Comment 4 Jeremy Katz 2008-12-08 13:04:50 EST
There aren't any of the log messages that we definitely output on a resize.  How did you select to do the resize?
Comment 5 Donald Arseneau 2008-12-08 23:58:56 EST
There is uncertainty in this because I was not keeping notes as I installed (of course).

I selected "Create Custom"
double-click on /dev/sda1
double-click on free space
select mountpoint /boot 
check-off Force primary (this would be /dev/sda3)
double-click free space in LVM section
select mount point / for it
click through warning about small /boot

But two (probably critical) disruptions happened, and I don't recall at what stage:

I had to "back" at one point

There was a complaint about the free space being not enough for the new /dev/sda3 boot partition, which surprised me a lot.  I clicked it smaller by one increment (whatever those increments are in the gui) and it then proceeded.
Comment 6 Jeremy Katz 2008-12-19 16:16:09 EST
The only thing I can think of is that possibly you got into a state where we changed teh size of the device but without changing the size of the partition.  I've put a couple of checks into the code so that hopefully if someone hits this case in the future, we'll at least raise an exception before something wrong happens.

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