dougp@ico.isc.com (Doug Pintar) (06/05/90)
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 <gee Mom, I got flamed, and it wasn't even in talk.bizarre!>
ggw@wolves.uucp (Gregory G. Woodbury) (06/05/90)
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! ] <standard disclaimers apply>