Re: Bug in clearpart --drives 7.3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> My kickstart file currently looks like this:
> clearpart --drives hda
> part / --fstype ext3 --size 3000 --ondisk hda
> part swap --size 2000 --ondisk hda
> part /inst --size 1000 --grow --ondisk hda
> part /local/stage1 --fstype ext3 --noformat --onpart hdb1
> part /local/stage2 --fstype ext3 --noformat --onpart hdd1
> 
> ---------------------------------------------------
> I get the error message in this case that partitions hdb1 and
> hdd1 can't be found.
> 
> Is there a bug in the clearpart command?  If we do
> clearpart --drives hda, shouldn't we be able to put any partition
> structure on there we want?

I have experienced this behavior using the "clearpart --drives" option in
the kickstart configuration for a 2 SCSI disk 7.2 system where all 
partitions/filesystems on sda were to be destroyed, while the
partition/filesystem on sdb was to be preserved.  Removing the 
"clearpart" option from the configuration file, and manually zeroing out 
the partition table (actually, all of the first sector) of the drive to
be repartitioned (sda) in the %pre section seemed to solve the problem:
 
%pre
#!/bin/sh
mknod /dev/sda b 8 0
dd if=/dev/zero of=/dev/sda count=1 bs=512

Note that mknod is called to create /dev/sda: many devices don't exist in 
/dev in the default installation environment (you could also try adding the 
device file to initrd.img and removing the mknod call).
Replace all occurences of /dev/sda above with the proper device (/dev/hda
in your case), and make sure the correct major and minor numbers are passed
to mknod.  

Then, you can issue your "part" directives as usual, in your case:
part / --fstype ext3 --size 3000 --ondisk hda
...
part /local/stage1 --fstype ext3 --noformat --onpart hdb1
...

Note that if the above %pre script is used, you should probably specify the 
"zerombr yes" directive in your kickstart configuration, as not to receive 
an interactive prompt.  It is also important to note that I haven't used
the procedure I've described in a production environment (only in a
test environment), so it would be wise to test it on a non-critical machine
which has been backed up.

Lastly, I've examined the anaconda-7.2-7 source and found the following 
anomaly in "doClearPart()" in kickstart.py:

	for n in args:
            (str, arg) = n
            if str == '--linux':
                type = CLEARPART_TYPE_LINUX
            elif str == '--all':
                type = CLEARPART_TYPE_ALL
            elif str == '--drive':
                drives = arg
            elif str == '--initlabel':
                initAll = 1

Notice the " elif str == '--drive' " line... this should probably be
"elif str == '--drives' ", as it is in the RedHat 8.0 anaconda source.
Could this be causing the "clearpart --drives" failures?

Chris





[Index of Archives]     [Red Hat General]     [CentOS Users]     [Fedora Users]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux