Bug 32

I have been able to replicate this problem with 5.2. I was not able to
get suggested workaround by user to work.

*** 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  11/29/98 20:33 -------
This bug has been verified. We are currently working on a solution.

------- Additional Comments From bryner  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.

*** 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.

New boot disks are out.  See
http://www.redhat.com/support/docs/rhl/rh52-errata-general.html