Bug 77245

Summary: installer crashes when add large vfat partition
Product: [Retired] Red Hat Linux Reporter: Scott Otterson <scotto>
Component: installerAssignee: Michael Fulbright <msf>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: high Docs Contact:
Priority: medium    
Version: 8.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-03-13 21:11:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Scott Otterson 2002-11-04 06:15:23 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020408

Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:
Didn't try

Steps to Reproduce:
1.Existing ntfs 5G partition; 35G free space (ntfs probably irrelevant)
2.allowed installer to automatically pick partitions
3.went back to disk druid and reduced the size of the largest partion
4.added a new 22G vfat partition in the ext section
5.continued with install

Actual Results:  Installation crashes with a bunch of error messages that I
didn't catch.  However, when I restarted the installation, I saw that diskdruid
had created vfat16 partitions, which cannot handle 22G.

Additional info:  I assume that this is what caused the crash.  Reformatting
everything now.

Comment 1 Michael Fulbright 2002-11-04 21:41:02 UTC
You added an existing 22G vfat partition as a mount point with disk druid?

As far as I can tell we don't allow you to create a > 2G vfat partition from
scratch via the disk druid interface.

Comment 2 Scott Otterson 2002-11-05 22:04:26 UTC
I did this late at night a couple of days ago so I don't recall the exact steps
but it went something like this:  

1.) start linux installer
2.) select automatic partitioning and let linux pick the boundaries
3.) push the "back" button and go into disk druid
4.) in disk druid, shrink the large user partition (not boot or swap) to about 10G
5.) in disk druid, add a new VFAT partition with the "expand to maximum" (or
whatever it was called) box clicked.  This partition filled the 22G space left
over after shrinking the partition in step 4.)
6.) resume install, which resulted in a crash when the installer started copying
things from the cdrom

When I restarted the installer, I looked at the partitions with disk druid and
saw that the new one was VFAT16 -- it should have been VFAT32.  Actually, I
don't understand how VFAT16/VFAT32 is selected, as the only option in disk druid
is "VFAT".

Anyway, the disk was pretty screwed up after that -- Partition Magic couldn't
edit it.  However, I was able BootIt, from TerraByte, to delete all of the Linux
partitions and explicitly install a VFAT32 partition.  Unfortunately, this wiped
out all the forensic evidence.  I hope the info I have available now is useful
to you.

Comment 3 Michael Fulbright 2003-03-13 21:11:40 UTC
I believe this issue has been resolved.