Path: utzoo!attcan!uunet!wuarchive!texbell!cs.utexas.edu!rutgers!mcnc!wolves!ggw From: ggw@wolves.uucp (Gregory G. Woodbury) Newsgroups: comp.unix.i386 Subject: Re: More on adding hard disks Message-ID: <1990Jun5.040701.5981@wolves.uucp> Date: 5 Jun 90 04:07:01 GMT References: <1990Jun4.213229.24087@ico.isc.com> Reply-To: ggw@wolves.UUCP (Gregory G. Woodbury) Organization: Wolves Den UNIX Lines: 87 dougp@vail.ICO.ISC.COM (Doug Pintar) writes: >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. Accepted, and in turn, I apologize for the particular harshness with which I responded. It is not fair to stigmatize all of ISC for a careless remark. I should not assume that just because you work at a place that you represent the place (type that 1000 times, no cut and paste! ;-). >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. Let me suggest then that they should be in /usr/lbin rather than /etc. lbin was made specifically for sysadm as distinct from a local bin of some sort and stuff there is sysadm specific. > the issue here is setting up a disk, NOT how >sysadm scripts are built. Since you claim that the functionality is totally contained in the sysadm script, the structure might be an issue. >> 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. And, this is where my attempt to use "addharddisk" failed when I tried it. (Yes, I did look to sysadm first! When it didn't work I made some bad assumptions about its correctness. i.e. it was not correct, don't pay attention to it ;-(( ) > 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. > > 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. Gladly. The first attempt to use the "addharddisk" command failed to identify the disk or access it. I elected initially to not format or surface analyze the disk (since there were partitions and filesystems from another system that we wanted to access.) A little bit of information (or its lack) goes a long way here and I knew that the system could see the disk properly in one sense (it fsck'd okay and a cat of the device sections showed the data - fsdb even worked!) it just wouldn't mount the darn thing! The "Maintenance procedures" section has a few mentions of using the sysadm procedure, but it also does not provide much guidance for unusual cases. [additionally, on page 61, the paragraph numbered 4 (December 88 printing of manual) is just plain confusing - even if you know what you are doing.] Given that there was a problem with the sysadm command, I decided to "wing it" and the obvious 2nd choice (the /etc/diskadd script) also has a direct bug if you are trying to add something like disk10. (around line 96 of 196) [Excuse me, /etc/diskadd is probably not supported and undocumented, if its not supposed to be used, then please remove it!] In any case, between a bit of blind pride on my part, and some very unclear documentation on ISC's part (I mean, who actually reads the manuals or indexes ;-) it took me several days to do something that should have only taken a few hours. -- Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC UUCP: ...dukcds!wolves!ggw ...mcnc!wolves!ggw [use the maps!] Domain: ggw@cds.duke.edu ggw%wolves@mcnc.mcnc.org [The line eater is a boojum snark! ]