Bug 32 - Hard drive install failure
Hard drive install failure
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: installer (Show other bugs)
5.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Matt Wilson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1998-11-10 20:49 EST by dominic
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:
Environment:
Last Closed: 1999-01-04 11:49:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description dominic 1998-11-10 20:49:01 EST
The problem is as follow.  When the installation program
asks to specify the partition where are located /RedHat/RPMS
and /RedHat/base and where it be found, the program fails
with an error message that the tree does not appear to be a
RedHat tree.  I repeated the installation steps many times
without success.

The last trial, when it failed I swicthed to the prompt and
unmounted /tmp/hda1 where was located /RedHat/RPMS and
/RedHat/base.  I then went to the upgrade step and
everything went fine.

I can't what is wrong, however there is a small problem
there for this installation methods.

Now I have installed Redhat 5.2 without any problem other
than the one just mentionned above.

Thanks
Comment 1 David Lawrence 1998-11-17 14:14:59 EST
I have been able to replicate this problem with 5.2. I was not able to
get suggested workaround by user to work.
Comment 2 Matt Wilson 1998-12-09 17:17:59 EST
*** Bug 32 has been marked as a duplicate of this bug. ***
This is possibly a duplicate of bug #32 (it wasn't precise
enough for me to be sure)

I was installing on a laptop were the pcmcia-cs package
on RH 5.2 wasn't recent enough to work with the pcmcia
controller. So, I copied the whole distribution to a FAT32
partition via SMB and tried to do an install using the
distribution on that partition.
It failed with the error message saying that it couldn't
find the distribution files/directories, so the quick
workaround I used was to copy the whole install tree from
the FAT32 partition to an ext2 partition, and fixed the case
of the RPMS directory. This turned out to be a way overkill
as some investigating showed.

I spent several hours today trying to find out exactly what
the problem was, and how it could be fixed, so that others
could benefit from those findings and so that you could fix
it for RH 6.0

Let's see what's exactly happening:
RPMS is a name less than 8 chars, fully in uppercase.
Windows stores is as an "old" 8+3 name. The problem is that
linux's vfat system is based on the fat subsystem, which
shows such names in lowercase because it just "looks nicer"
on linux.
Once running under linux, you can actually do mv rpms tmp;
mv tmp RPMS and then you'll see the directory in uppercase
in linux, but the way this is done is by storing this as a
long filename.

Workaround:
once RH complains about not finding the installation tree,
if /tmp/hdimage is umounted, mknod hda1; mount -t vfat
hdimage
If it is mounted, I think it has to be unmounted (the
floppy's mount doesn't seem to support mount -wo remount
/tmp/hdimage) first, and then remounted
Then: cd /dir/to/RedHat; mv rpms tmp; mv tmp RPMS
and after that the installation should work as planned

Ugly fix:
Patch the installer to look both in RedHat/rpms and
RedHat/RPMS. A better fix would be to have a mount option to
give to the vfat module and tell it to leave filenames
without an aossociated LFN in uppercase.


------- Additional Comments From dkl@redhat.com  11/29/98 20:33 -------
This bug has been verified. We are currently working on a solution.

------- Additional Comments From bryner@uiuc.edu  11/30/98 09:24 -------
I didn't even get to the point where you can specify the directory to
look in -- the FAT32 partition did not appear on the list of available
partitions to install from at all.  Possibly related to the fact that
Disk Druid didn't seem to recognize the partition type id (showed the
hex code, which fdisk said corresponded to "Win95 FAT32").  I used the
extremely ugly workaround of temporarily changing the partition type
id to fat16.
Comment 3 David Lawrence 1998-12-13 17:50:59 EST
*** Bug 32 has been marked as a duplicate of this bug. ***
Choosing to insall from a hard drive gives recommendations
for copying the CD-ROM files from a CD to a (implied)dos
partition then the screen where they are selected to
install from suggests with a forward facing slash that it
is a LINUX type drive. By the way neither worked and I
tried it as a msdos drive and then changing it to a linus
type. I didn't really expect the later to work. All of the
directories mentioned it the online screen were present as
were thoes mentioned in the documentation.
The install program was unable to install from the hard
disk drive. I was attempting to use hdb1
My system is a Radio shack 486 DX2-50 w/ 20 meg of ram, 2
Western digital hard drives installes with their Disk
manager 1 gig(boot) and 405 meg. The first drive was
partitioned 990 meg boot and 42 meg swap and the hdb was
formatted msdos, Sony CD-ROM CDU-535(not recognized by 5.2
and submitted on bug #388), ZIP 100 drive recognized during
install attempt.
Comment 4 Matt Wilson 1999-01-04 11:49:59 EST
New boot disks are out.  See
http://www.redhat.com/support/docs/rhl/rh52-errata-general.html

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