Bug 9452 - Incorrectly decides there's insufficient disk space for installation
Summary: Incorrectly decides there's insufficient disk space for installation
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: installer
Version: 6.2
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Erik Troan
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-02-15 02:33 UTC by Ken Martin
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-02-23 20:15:36 UTC
Embargoed:


Attachments (Terms of Use)

Description Ken Martin 2000-02-15 02:33:10 UTC
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
root@tuck:/home/fletcher#

Comment 1 Riley H Williams 2000-02-15 18:20:59 UTC
I presume you meant "signed int" when you said "unsigned int" ???

Comment 2 Ken Martin 2000-02-15 20:15:59 UTC
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-16 01:14:59 UTC
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 20:15:59 UTC
Attempted to reproduce with specified partition table and it works in latest
beta of installer.

Comment 5 Ken Martin 2000-02-24 18:20:59 UTC
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.