Bug 30470
Summary: | Installation fails, FAT contains 12-bit entries | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <ppetit> |
Component: | anaconda | Assignee: | Michael Fulbright <msf> |
Status: | CLOSED WORKSFORME | QA Contact: | Brock Organ <borgan> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.2 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2001-04-03 14:42:08 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: |
Description
Need Real Name
2001-03-03 15:48:37 UTC
What is the partition type of the drive (use the linux fdisk command to find out)? 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. How much free space is on the FAT partition? 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. 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. What do you mean by FAT size? I'm not sure I know what that is. 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. 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? 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. Glad to hear its working. |