Red Hat Bugzilla – Bug 474269
Resize (shrink) old partition, but the filesystem data is not shrunk to match.
Last modified: 2009-02-16 15:32:51 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.)
Have not tried again.
Steps to Reproduce:
We definitely do shrink the filesystem as well. Can you attach /var/log/anaconda.log and /var/log/anaconda.syslog to this bug report?
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.
Created attachment 325636 [details]
There aren't any of the log messages that we definitely output on a resize. How did you select to do the resize?
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.
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.