More on adding hard disks
Gregory G. Woodbury
ggw at wolves.uucp
Tue Jun 5 14:07:01 AEST 1990
dougp at 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 at 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 at cds.duke.edu ggw%wolves at mcnc.mcnc.org
[The line eater is a boojum snark! ] <standard disclaimers apply>
More information about the Comp.unix.i386
mailing list