I have to say that I was more that a bit surprised, if not to say dismayed when I booted a system with CentOS 5 installed to test a kickstart CD in interactive mode, took it to the custom partitioning screen, then rebooted without saving anything only to come up with a grub prompt, and the disk's partition table wiped. The ks.cfg file did say to wipe the disk when installing, but I would expect that it wouldn't do this in interactive mode until one told it to start the installation.
I have been installing Linux systems for well over a decade, starting with Caldera Network Desktop 1.0, all versions of Caldera through 2001, and SuSE from 8.1 through SLES10, and never have I seen an installation procedure that would write to anything on the hard drive without asking first.
This certainly violates the Principle of Least Surprise.
Bill -- INTERNET: bill@celestial.com 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
When dealing with any spammer, one must always keep in mind that you are dealing with someone who makes their living through forgery, fraud, theft, subterfuge and obfuscation. Stated simply, spammers lie. David Ritz dritz@primenet.com
On 9/12/07, Bill Campbell centos@celestial.com wrote:
I have to say that I was more that a bit surprised, if not to say dismayed when I booted a system with CentOS 5 installed to test a kickstart CD in interactive mode, took it to the custom partitioning screen, then rebooted without saving anything only to come up with a grub prompt, and the disk's partition table wiped. The ks.cfg file did say to wipe the disk when installing, but I would expect that it wouldn't do this in interactive mode until one told it to start the installation.
Anything that's in the kickstart file gets done without interaction. You can leave parts of the kickstart file out, and it'll prompt you for these things once it gets to this stage. If you told the ks.cfg to wipe the disk, it will happily do this without asking questions.
I suppose it would help if I finished the reply before sending.....
On 9/12/07, Bill Campbell centos@celestial.com wrote:
I have been installing Linux systems for well over a decade, starting with Caldera Network Desktop 1.0, all versions of Caldera through 2001, and SuSE from 8.1 through SLES10, and never have I seen an installation procedure that would write to anything on the hard drive without asking first.
The whole idea behind kickstart is that it does not ask questions. It's for automated installs. Think pxe setup, or a computer lab, or hundreds of identical workstations. Why answer questions on all of them, when you can automate the process and go get a coffee?
This certainly violates the Principle of Least Surprise.
Not really. The tool works as expected. You're just unfamiliar with it. Not trying to sound snippy with this, so please don't take it this way.
On Wed, Sep 12, 2007, Jim Perrin wrote:
I suppose it would help if I finished the reply before sending.....
On 9/12/07, Bill Campbell centos@celestial.com wrote:
I have been installing Linux systems for well over a decade, starting with Caldera Network Desktop 1.0, all versions of Caldera through 2001, and SuSE from 8.1 through SLES10, and never have I seen an installation procedure that would write to anything on the hard drive without asking first.
The whole idea behind kickstart is that it does not ask questions. It's for automated installs. Think pxe setup, or a computer lab, or hundreds of identical workstations. Why answer questions on all of them, when you can automate the process and go get a coffee?
I understand what kickstart is for. I've been doing autoyast installs on SuSE for quite a while to build identical systems.
IHMO, If you're going to have an interactive option, then it should be interactive, gathering information to do the install, and not start scribbling on the hard drive until all that information is complete.
This certainly violates the Principle of Least Surprise.
Not really. The tool works as expected. You're just unfamiliar with it. Not trying to sound snippy with this, so please don't take it this way.
I guess my expectations are a bit different than yours.
Yes, I'm unfamiliar with Anaconda and kickstart (and I'm trying very hard to be polite and not be viewed as a troll). I'm new to CentOS, and have had little experience with Red Hat systems.
I've been designing computer systems now for over 40 years, Unix systems since 1982, and Linux since 1995. I've always tried to design software as bullet-proof (idiot proof :-) as possible, and not to do irreversible things accidentally (measure twice, cut once).
It just happens that I'm reading a very interesting book somewhat related to this, Alan Cooper's ``The Inmates are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity''.
My primary purpose in the original message was to provide feedback from somebody who's pretty technical, but not steeped in Red Hat/CentOS.
Bill -- INTERNET: bill@celestial.com 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
Everybody is ignorant, only on different subjects. Will Rogers
Bill Campbell wrote:
My primary purpose in the original message was to provide feedback from somebody who's pretty technical, but not steeped in Red Hat/CentOS.
I have read that book you speak of, it was mildly entertaining - however, you are quoting that out of context here.
The problem you have is that you used the wrong tool for the wrong job, busted your own system - and are now looking for something / someone to blame. Thats fine. We all have a spleen, needs venting sometimes.
Besides that, since you said its all new to you, feel free to hang around - there is a fantastic knowledgebase here on the list. I am sure you would be most welcome :)
On Wed, Sep 12, 2007, Karanbir Singh wrote:
Bill Campbell wrote:
My primary purpose in the original message was to provide feedback from somebody who's pretty technical, but not steeped in Red Hat/CentOS.
I have read that book you speak of, it was mildly entertaining - however, you are quoting that out of context here.
The problem you have is that you used the wrong tool for the wrong job, busted your own system - and are now looking for something / someone to blame. Thats fine. We all have a spleen, needs venting sometimes.
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.
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 happened to be on at the time). If I were venting, I might make comments to the effect that if I wanted to run a system that would eat every drive on the system without asking, I would be running the Microsoft Virus, Windows :-).
Besides that, since you said its all new to you, feel free to hang around - there is a fantastic knowledgebase here on the list. I am sure you would be most welcome :)
Bill -- INTERNET: bill@celestial.com 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
People who relieve others of their money with guns are called robbers. It does not alter the immorality of the act when the income transfer is carried out by government.
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 ?
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.
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.
If you want a descructive install may I recommend at least using 'clearpart --linux' which only wipes Linux partitions.
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
Ross S. W. Walker wrote:
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
Well actually there is the kickstart option 'clearpart --all'.
that is what I meant when I said 'tell it to do that'.
On 9/12/07, Ross S. W. Walker rwalker@medallion.com wrote:
Definitely a VERY dangerous option, I would say that that should have been clearly stated in the RHEL docs.
This is one glaring area where anaconda could definitely use some improvement. There's a very distinct lack of 'user-friendly' documentation, both for install/kickstart options (which does have *some* documentation) and the iso building portion, which is something akin to voodoo where one must read the source to actually understand what's going on.
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@celestial.com 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.
On 9/12/07, Bill Campbell centos@celestial.com wrote:
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.
These are all supported in the centosplus kernel:
http://wiki.centos.org/Repositories/CentOSPlus
Akemi
On 9/12/07, Akemi Yagi amyagi@gmail.com wrote:
On 9/12/07, Bill Campbell centos@celestial.com wrote:
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.
Like there is pacman for SuSE, there are several repositories you may want to add to your yum repo list. See the wiki for details:
http://wiki.centos.org/Repositories
Akemi
On Thu, Sep 13, 2007, 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.
The kickstart configuration file and system-config-kickstart tool have an option for interactive kickstart installations, which I ass-u-me-d would work much the same way autoyast automatic installs do where I can abort the installation any time up to the point where it says start-install, do you really want to do this?
My approach to writing GUI sysadmin tools is to have the GUI collect the configuration parameters, then execute one or more command line tools to do the real work. One of the few things I really liked about AIX was that their SMIT tool displays the commands, and logs them as well which can be very useful to figure out what's going on under the hood. This is a bit easier than ``touching'' a file to create a timestamp, doing something with a GUI tool, the using ``find /etc -newer'' to figure out what the GUI tool is actually doing.
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 ?
That could be useful if I hadn't killed the install, only to find myself with two empty disks without partition tables.
I just finished reinstalling the system, and now installing all our OpenPKG based software on it. Doing this, I am reminded of something worth venting about -- the aliases on rm, mv, and cp to keep the children from doing dangerous things :-).
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn
Bill -- INTERNET: bill@celestial.com 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
No matter how much I may exaggerate it, it must have a certain amount of truth...Now rumor travels fast but it don't stay put as long as truth Will Rogers
Bill Campbell wrote:
On Thu, Sep 13, 2007, 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.
The kickstart configuration file and system-config-kickstart tool have an option for interactive kickstart installations, which I ass-u-me-d would work much the same way autoyast automatic installs do where I can abort the installation any time up to the point where it says start-install, do you really want to do this?
It does Bill, but the problem was that the partitioning wiping happened BEFORE the partition manager opened up and it happened successfully :-(
My approach to writing GUI sysadmin tools is to have the GUI collect the configuration parameters, then execute one or more command line tools to do the real work. One of the few things I really liked about AIX was that their SMIT tool displays the commands, and logs them as well which can be very useful to figure out what's going on under the hood. This is a bit easier than ``touching'' a file to create a timestamp, doing something with a GUI tool, the using ``find /etc -newer'' to figure out what the GUI tool is actually doing.
Most is done directly in Python these days, but a few things still are handled the goold ole way.
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 ?
That could be useful if I hadn't killed the install, only to find myself with two empty disks without partition tables.
I just finished reinstalling the system, and now installing all our OpenPKG based software on it. Doing this, I am reminded of something worth venting about -- the aliases on rm, mv, and cp to keep the children from doing dangerous things :-).
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn
Well there were enough complaints through the years to put in the child safety locks.
These are easily disabled though.
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
Bill Campbell spake the following on 9/12/2007 4:55 PM:
On Thu, Sep 13, 2007, 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.
The kickstart configuration file and system-config-kickstart tool have an option for interactive kickstart installations, which I ass-u-me-d would work much the same way autoyast automatic installs do where I can abort the installation any time up to the point where it says start-install, do you really want to do this?
My approach to writing GUI sysadmin tools is to have the GUI collect the configuration parameters, then execute one or more command line tools to do the real work. One of the few things I really liked about AIX was that their SMIT tool displays the commands, and logs them as well which can be very useful to figure out what's going on under the hood. This is a bit easier than ``touching'' a file to create a timestamp, doing something with a GUI tool, the using ``find /etc -newer'' to figure out what the GUI tool is actually doing.
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 ?
That could be useful if I hadn't killed the install, only to find myself with two empty disks without partition tables.
I just finished reinstalling the system, and now installing all our OpenPKG based software on it. Doing this, I am reminded of something worth venting about -- the aliases on rm, mv, and cp to keep the children from doing dangerous things :-).
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn
Sorry I chimed in too late, but there are tools that might have recovered your partitions without too much work if all that happened was zeroing out the partition table and not actually zeroing out the drive.
-
Akemi Yagi -
Bill Campbell -
Jim Perrin -
Karanbir Singh -
Ross S. W. Walker -
Scott Silva