Bug 474269

Summary: Resize (shrink) old partition, but the filesystem data is not shrunk to match.
Product: [Fedora] Fedora Reporter: Donald Arseneau <asnd>
Component: anacondaAssignee: Jeremy Katz <katzj>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 10CC: anaconda-maint-list
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-16 20:32:51 UTC Type: ---
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
anaconda.syslog none

Description Donald Arseneau 2008-12-03 01:44:13 UTC 
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:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Chris Lumens 2008-12-03 14:53:08 UTC 
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-04 04:26:40 UTC 
Created attachment 325635 [details]
anaconda.log

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-04 04:27:56 UTC 
Created attachment 325636 [details]
anaconda.syslog
Comment 4 Jeremy Katz 2008-12-08 18:04:50 UTC 
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-09 04:58:56 UTC 
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
resize
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 21:16:09 UTC 
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.