On Wed, Sep 12, 2007, Ross S. W. Walker wrote:
>Karanbir Singh wrote:
>>
>> Bill Campbell wrote:
>> > How was I using the wrong tool when I was testing a
>> kickstart configuration
>> > file in interactive mode, which I figured would be safe as
>> it would allow
>> > me to exit before it wrote on the disk? I have done
>> similar testing of
>> > autoyast configuration files on many occassions without clobbering
>> > anything.
>>
>> anaconda-kickstart does not have a simulation mode. it might have been
>> well worth the time to investigate that before trying it out :)
>> assumption is dangerous. But then I suppose at this stage you might
>> point to me and say hindsight is an exacting science. Its
>> always easier
>> to say what one might have or should have done.
>>
>> virtual machine technology is fairly far along the road to stability,
>> thats always a good option when testing such stuff.
>>
>> Also, when you say interactive mode - what exactly do you mean by that
>> ? because Anaconda has two modes, Interactive and Kickstart scripted.
>> And as already been pointed out, you can skip portions out of the
>> kickstart ( its quite common to see the drive partitioning logic
>> commented out so that the person on $console might be able to do that
>> himself ), and anaconda will ask you about those questions.
>> But you cant
>> really have a complete interactive install session and also have a
>> kickstart script running alongside.
>>
>> > I would hardly call it venting. I've made a serious effort
>> not to say some
>> > of the things that come to mind (particularly when I found
>> that not only
>> > had it nuked my hard drive, but also nuked the external USB
>> drive that
>>
>> ok thats interesting. by default anaconda should not touch the drives
>> its not creating partitions on. Unless you expressly tell it to. did
>> /var/log/anaconda.log, /root/anaconda-ks.cfg, /root/*.log
>> have anything
>> interesting to say about why it might have nuked that other
>> drive as well ?
>
>Well actually there is the kickstart option 'clearpart --all'.
>
>If one specifies a 'clearpart -all' without specifying which drives then
>I believe the result is all partitions from all drives.
>
>Definitely a VERY dangerous option, I would say that that should have been
>clearly stated in the RHEL docs.
Agreed! Furthermore, I don't think that system-config-kickstart provides
any options to selectively clear partitions.
Perhaps it would have been safer had I specified a particular drive in the
partitioning section.
>I can sympathise with your situation Bill, but one should test carefully
>these scripted installs first either on a Xen VM or VMware VM, or on a
>bare-bones system that hasn't been customized yet.
Fortunately this machine was pretty bare-bones, and won't be installed at
our customer's until next Tuesday. It cost me about a half-day though in
reconsructing things, and can be considered a learning experience.
The external drive was a copy of another external that I had to make as it
originally had an xfs file system (which I was surprised to find that
CentOS doesn't support by default as I've been using for several years on
SuSE systems).
I don't mean to be harping on SuSE, it's just that's what I've been working
with primarily for the last six years or so, and it's what I know best. If
I were moving from CentOS/Red Hat to SuSE, I would probably be surprised by
things they support and SuSE doesn't.
Two things that I found different that affects our systems the most are (a)
lack of support for xfs and jfs file systems, and (b) lack of support for
ieee1394 external disks.
I've dabbled in gentoo, and ubuntu, but far prefer RPM based systems as
that's what I've used since I stared doing serious Linux work about 12
years ago. I'm not an acolyte of the Church of GNU, and get turned off a
bit by the religious ferver of the GNU/Linux crowd.
>If you want a descructive install may I recommend at least using
>'clearpart --linux' which only wipes Linux partitions.
That wouldn't have saved the external drive as that had an ext3 Linux file
system.
Bill
--
INTERNET: bill@xxxxxxxxxxxxx Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
Breathe fire, slay dragons, and take chances. Failure is temporary, regret
is eternal.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
