Red Hat Bugzilla – Bug 211
Installation from vfat partition fails (with fix and workaround)
Last modified: 2008-05-01 11:37:48 EDT
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"
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
once RH complains about not finding the installation tree,
if /tmp/hdimage is umounted, mknod hda1; mount -t vfat
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
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.
This bug has been verified. We are currently working on a solution.
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.
A fix is in testing.
*** This bug has been marked as a duplicate of 32 ***