Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!isis!ico!dougp From: dougp@ico.isc.com (Doug Pintar) Newsgroups: comp.unix.i386 Subject: More on adding hard disks Message-ID: <1990Jun4.213229.24087@ico.isc.com> Date: 4 Jun 90 21:32:29 GMT Reply-To: dougp@vail.ICO.ISC.COM (Doug Pintar) Organization: Interactive Systems Corp., Boulder CO Lines: 69 To anyone who was offended by the tone of my previous posting on adding hard disks under 386/ix 2.0.2, I would like to publicly apologize. I had hoped the smiley would forestall the flames, forgetting how frustrating it is when you're fighting with a system that seems hostile. I in no way meant to trivialize Gregory Woodbury's experiences with our software. However, I think there is a need to shed some light on his problems and his proposed solution. In article <1990Jun3.063727.10379@wolves.uucp> he writes: > As an early item in the thread noted, your "precious" little > sysadm scripts DID NOT WORK CORRECTLY! If the d*mned /etc/disk* > routines worked right (i.e. didn't assume something illegal about the > particular number of drives and which drive was being installed) then > none of this painful affair would have made it to the net in the first > place. The first article I found on this subject was <1990May27.092900.828@wolves.uucp> in which there is no mention of failures of the sysadm scripts. I have personally installed several add-on SCSI devices using sysadm. It hasn't failed me yet. I'm a little unclear on the comments that the /etc/disk* routines don't work right, as there is no documentation on how they are SUPPOSED to work. They are designed to be run from a script that knows exactly what each one of them does, NOT to be run by hand by someone unfamiliar with the processes involved. > Besides, I've probably forgotten more about the sysadm scripting > system than you ever knew. Quite possibly true. However, the issue here is setting up a disk, NOT how sysadm scripts are built. > final effective sequence: > > 1. /etc/diskconfig on /dev/dsk/c1d0p0 to get basic geometry > (be careful - some of the /etc/disk* commands will trash > /etc/partitions - make a backup!) > > 2. run fdisk /dev/dsk/c1d0p0 and make unix partitions > 3. put the basic disk "stanza" in /etc/partitions > 4. run mkpart -i diskNN to create initial vtoc > 5. backup /etc/partitions and run /etc/disksetup > this will fail! but partition stanzas will be placed in > /etc/partitions for your selected configuration. The problem here is that /etc/disksetup is the WRONG program to run at this point. 'disksetup' is designed to build things on BOOT disks, and hence scribbles on /etc/partitions with gleeful abandon. A glance through the sysadm addharddisk script shows it using '/etc/adddisk', which is the correct program. It writes the new disk's entries in /tmp/partitions. This file is appended to /etc/partitions as the final act of adding a new disk, so your original version of the file is safe until the process is completed. As for all the other operations in Gregory's list, they ARE performed by the sysadm addharddisk function. Each filesystem is labelled and has a lost+found directory created on it. > Its no wonder that ISC had a bad reputation for customer support > if you are an example of their finest. This is the second time that I > have found problems with pieces of ISC code and had absolutly no help > from ISC on the problem. As a matter of fact, I'm not an example of customer support at all! I'm a developer. I believe our customer service personnel are infinitely more patient and polite than I am. As for a problem with ISC code related to the adding of hard disks and controllers, if you could show me a real example of a problem (and not merely a perception of one) I'd be glad to pass it along to our support staff. Doug Pintar