Bug 9452 - Incorrectly decides there's insufficient disk space for installation
Incorrectly decides there's insufficient disk space for installation
Product: Red Hat Linux
Classification: Retired
Component: installer (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Erik Troan
Depends On:
  Show dependency treegraph
Reported: 2000-02-14 21:33 EST by Ken Martin
Modified: 2008-05-01 11:37 EDT (History)
0 users

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

Attachments (Terms of Use)

  None (edit)
Description Ken Martin 2000-02-14 21:33:10 EST
When doing a full install of RH 6.1.92, it erroneously told me I had
insufficient disk space.  My guess is that it's using an unsigned int for
size of partition, and since I've got a /usr partition of 2.4gb, it thinks
I've got negative disk space in /usr.

The RH6.1 install worked fine, and I was able to upgrade from that to
6.1.92 with no trouble.  I tried tracking the problem down in source code,
but don't understand python well enough to be able to find it.  Sorry.

My disklabel looks like:

root@tuck:/home/fletcher# fdisk /dev/hda

Command (m for help): p

Disk /dev/hda: 255 heads, 63 sectors, 784 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1             1        33    265041   83  Linux
/dev/hda2            34       784   6032407+   5  Extended
/dev/hda5            34        78    361431   82  Linux swap
/dev/hda6            79       111    265041   83  Linux
/dev/hda7           112       412   2417751   83  Linux
/dev/hda8           413       478    530113+  83  Linux
/dev/hda9           479       751   2192841   83  Linux
/dev/hda10          752       784    265041   83  Linux

Command (m for help): q

root@tuck:/home/fletcher# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda1               256667     34312    209103  14% /
/dev/hda6               256667        43    243372   0% /tmp
/dev/hda7              2379700   1538108    720708  68% /usr
/dev/hda8               521748     19620    475624   4% /var
/dev/hda9              2158384    473060   1575684  23% /usr/local
/dev/hda10              256667      2580    240835   1% /home
Comment 1 Riley H Williams 2000-02-15 13:20:59 EST
I presume you meant "signed int" when you said "unsigned int" ???
Comment 2 Ken Martin 2000-02-15 15:15:59 EST
Yes, I meant 'signed'.  Sorry 'bout that.

I'll start looking into the source code for this more deeply tomorrow (2/16/00)
evening when I get the chance.  Hopefully python won't confuse me as much as
I've already confused myself.  :)
Comment 3 Jay Turner 2000-02-15 20:14:59 EST
There is a pretty good chance this is what is happening.  We found a similiar
bug in the RAID code which resulted in much of the same behavior.  I will also
be playing around in the lab with this setup, so hopefully one of the two of us
will be able to shed light on this matter.
Comment 4 Michael Fulbright 2000-02-23 15:15:59 EST
Attempted to reproduce with specified partition table and it works in latest
beta of installer.
Comment 5 Ken Martin 2000-02-24 13:20:59 EST
So, which "latest beta of installer" did you try, and where can I get it to try
it out and ensure that this bug's been fixed?

I did spend about 3 hours looking through the Anaconda source, and got
thoroughly lost.

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