Bug 30470 - Installation fails, FAT contains 12-bit entries
Summary: Installation fails, FAT contains 12-bit entries
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 6.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Michael Fulbright
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-03-03 15:48 UTC by Need Real Name
Modified: 2007-04-18 16:31 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-04-03 14:42:08 UTC
Embargoed:


Attachments (Terms of Use)

Description Need Real Name 2001-03-03 15:48:37 UTC
I am trying to do a partitionless install on an IBM Aptiva, onto a DOS 
partition that is 2,000 Megabytes long.  It is NOT a FAT32, it is a FAT16 
partition, but the installer seems to treat is like a FAT12 partition.  
First, when asking how to apportion file space, it says that the maximum 
total is 115 Megabytes.  If I continue anyway, it creates two files, but 
the FAT entries for those files are 12 bits long, not 16.  I have checked 
the boot-sector, and it has all the correct data; in particular, it 
says "F8" at offset 15 (hex).  Also, Windows is happy to read and write 
files on that partition (until the Linux installer hashes the FAT).

Comment 1 Michael Fulbright 2001-03-04 01:52:54 UTC
What is the partition type of the drive (use the linux fdisk command to find
out)?

Comment 2 Need Real Name 2001-03-04 18:19:26 UTC
I cannot run Linux fdisk, since I can't install Linux.
Windows fdisk calls the partition "PRI DOS".  The actual byte
in the partition table is a 6.


Comment 3 Michael Fulbright 2001-03-05 22:41:42 UTC
How much free space is on the FAT partition?

Comment 4 Need Real Name 2001-03-05 23:56:55 UTC
The partition is empty.  There are 2,000 Megabytes of free space, and the FAT 
reflects this.  Specifically, the partition boot track specifies: 239 (EF hex) 
sectors of FAT (239 for EACH of the 2 copies); there are 64 (40 hex) sectors 
per cluster; there are 32 (20 hex) sectors of root directory.  The root 
directory is empty (all 0's) except for a label (attributes = 28 hex).  The FAT 
is all 0's except for the first 2 entries (which are for clusters 0 & 1, 
unused).  That's for the first copy of the FAT; I haven't looked at the second 
copy of the FAT, but that seems unlikely to be the problem here.

Comment 5 Need Real Name 2001-03-06 03:00:13 UTC
MORE:  Your question prompted me to try re-formatting the partition, this time 
using DOS.  That changed the size of the FAT (to FB hex), and the installation 
now runs.  I don't understand this, because I tried it with a FAT size of 100 
(hex), and it didn't work.  Perhaps something else changed, but I couldn't find 
anything.  If you have any understanding of this problem, tell me.  In any 
event, thanks for your help.


Comment 6 Michael Fulbright 2001-03-09 16:23:19 UTC
What do you mean by FAT size? I'm not sure I know what that is.

Comment 7 Need Real Name 2001-03-11 15:31:57 UTC
One of the entries in the partition boot record is the length of (one copy of) 
the FAT, in sectors.  Also in the partition boot record is a FAT-type byte (at 
offset 15 hex), and I assumed that the the Linux installer would look there to 
decide what size FAT entries to use, but apparently it looks somewhere else.  
There are various possibilities.  I am curious as to where it looks to make 
that decision, but it's not of any great importance, since it all works now.

Comment 8 Michael Fulbright 2001-04-02 15:55:52 UTC
For a partitionless install, the installer mounts the FAT partition using the
'vfat' option to the linux mount command. The kernel, I'm assuming, then tries
to figure out the details of the filesystem. The installer does not actually do
this, it occurs at a lower level.

I've never heard of this problem before, so I'm curious. How was the original
partition formatted?  Was it a  really old copy of DOS or Windows perhaps?

Comment 9 Need Real Name 2001-04-03 14:42:05 UTC
Actually, the partition was originally formatted by me, by hand, by editing the 
relevant sectors in binary.  That's why I'm curious about where the system 
looks to decided what size FAT entries to use -- I'd like to understand where I 
went wrong in doing the formatting.  This is not enormously important, now that 
it's working; I'm just curious.

Comment 10 Michael Fulbright 2001-04-11 15:48:06 UTC
Glad to hear its working.


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