Bug 154617 - Kickstart clears ntfs partition when --linux is specified in clearpart command
Kickstart clears ntfs partition when --linux is specified in clearpart command
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2005-04-12 22:18 EDT by Tom Diehl
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-17 17:48:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tom Diehl 2005-04-12 22:18:20 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040808 Firefox/0.9.3

Description of problem:
clearpart --linux --drives=hda clears not only the linux partitions but ntfs partitions as well, when run via kickstart.

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

How reproducible:
Didn't try

Steps to Reproduce:
1.Copy partitioning information from the anaconda-ks.cfg that was generated during the previous install.
2. Install today's rawhide via a kickstart.cfg file.
3.Install proceeded without errors

Actual Results:  Found ntfs partition that was previously approx 5 gig and located on hda1 to be replaced with an approx 100 Meg linux partitionvolgroup

Expected Results:  ntfs partition should have been left intact and linux installed on the remainder of the drive.

Additional info:

This is the revelant part of the ks.cfg file as was generated by anaconda during the previous FC3 install:
clearpart --linux --drives=hda
part /boot --fstype "ext3" --size=100 --ondisk=hda
part pv.3 --size=0 --grow --ondisk=hda
volgroup VolGroup00 pv.3
logvol /home --fstype ext3 --name=LogVol05 --vgname=VolGroup00 --size=5088
logvol /tmp --fstype ext3 --name=LogVol04 --vgname=VolGroup00 --size=512
logvol /var --fstype ext3 --name=LogVol03 --vgname=VolGroup00 --size=1024
logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=1024
logvol /usr/local --fstype ext3 --name=LogVol02 --vgname=VolGroup00 --size=224
logvol swap --fstype swap --name=LogVol06 --vgname=VolGroup00 --size=1024
logvol /usr --fstype ext3 --name=LogVol01 --vgname=VolGroup00 --size=5024

The docs indicate that using the --linux switch in the clearpart command will rm the linux partitions. It says nothing about rm'ing the ntfs partitions.

FWIW hardware is a dell inspiron 2650 laptop. I reinstalled XP and rawhide from scratch and looked at the resulting anaconda-ks.cfg and with the exception of the partition sizes and the following line they look the same.
The first line was generated by the FC3 installer the 2nd was generated by today's rawhide installer:

volgroup VolGroup00 --pesize=32768 pv.3
volgroup VolGroup00 pv.3

In addition XP was installed on hda1 before installing FC3 or rawhide.
Comment 1 Jeremy Katz 2005-04-13 11:30:03 EDT
Although this is probably going to be hard to tell now, could the ntfs partition
have looked like a linux partition in parted?  Do you happen to remember ever
running it and noticing?
Comment 2 Tom Diehl 2005-04-14 07:31:55 EDT
I never ran parted on it. If you tell me what parted commands you would like me
to run I will run them and try the kickstart again. There is nothing on the
machine so if I trash it again it is no problem. I do not know if it helps but
from fdisk it was marked as an ntfs partition. Does parted use something
different to tell if it is linux or not?
Comment 3 Jeremy Katz 2005-04-14 10:17:02 EDT
Run parted on the disk, type print.  But it's probably too late to tell what was
there before.  parted actually (mostly) ignores the partition ids and instead
looks at the signature of the filesystem on the disk.  This is a bit safer in
most circumstances as it's easy to get a partition id changed and most things
just won't care.  But every once in a while a funky filesystem comes along and
screws up sniffing fs types :/
Comment 4 Tom Diehl 2005-04-17 17:48:12 EDT
Sorry to bother you with this. Turns out the problem was operator error. 
Thanks for the help. At least I learned a little more about how anaconda and
kickstart work.

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