[comp.unix.i386] Bugs, Bugs and more bugs

jgd@unix.UUCP (John G. De Armond) (10/13/89)

In article <1381@ctisbv.cti-software.nl> pim@cti-software.nl (Pim Zandbergen) writes:
>jgd@rsiatl.UUCP (John G. De Armond) writes:
>
>>Other problems you have not mentioned.  uugetty does not respect lock files.
>>I've seen it get in such a nice conversation with another login that
>>it locks all keyboard input, which means Big Red Switch time.
>
>At first I had the same problem with uugetty.
>
>This was because of a mistake in /etc/inittab:
>
>A3:234:respawn:/usr/lib/uucp/uugetty -r -t 60 /dev/ttyA3 19200
>
>I changed this to:
>
>A3:234:respawn:/usr/lib/uucp/uugetty -r -t 60 ttyA3 19200
>
>and everything works fine.


Hmm... Thanks for the information.  I'll give it a try.  I think I'll
ultimately keep using my uutty program because if for no other reason
I have the source.  Plus it is smarter than the supplied uugetty.

Now the question.  Is not the requirement to give a port as a relative
address a bug?  All my Unix documentation from other systems as
well as this one list the paths as absolute.  Plus the inittab lines 
in /etc/conf/default/asy (i think that's the path) list absolute paths.
Is the use of relative paths permitted or is this just another bug.

Speaking of bugs, check out the factor command.  Thanks to ke4zv, gary
for finding this one.  Factor is supposed to factor a number into its
primes.  IT seems to think many even numbers and most multiples of 8
are prime!  Try the number 662 for example.  Or 8.

here is the output for 662:

662
     662

Here is the output for 8:

8
     8
But it works for 10:

10
     5
     2

A question for you kernal hacks.  Is factor() used in computing
the encrypted password?   If so, is this a security problem.

---------------------------

next problem  

Has anybody noticed that diskverify does not work?  I have a large
but fairly bad scsi drive which has hundreds of known bad sectors.
Diskverify pauses on each but does not log any bad sectors.  And yet
the drive is obviously bad, as kernal messages tell me very loudly.
I could write a book on techniques I've used to identify these sectors
and feed them into mkpart.

----------------------------

Yet another gotcha.

I'm not sure if this could be classified as a bug but it sure is a trap
in using mkpart.  I recently reconfigured my system to have a small but
very reliable root system and the big scsi for the rest of the system.
After I had reconfigured, I restored /usr, /news and the other partitions
from tape.  I forgot that the old /etc/partitions was written back out
from tape.

One of my standard procedures after changing configuration is to make
a hard copy of configuration data.  I normally make a copy of the VTOCs
by using the -t option of mkpart that is supposed to only print out
VTOC statistics.  This time, when I issued the "mkpart -tvpa disk0"
command, mkpart responded with "Configuration does not match partitions -
attempting to reconfigure."  The system then crashed big-red-switch style
and when I tried to reboot, the root drive was trashed!  

If this is not a bug, then it is an open trap.  To me, for a status request,
which one would assume to be a read-only operation, to initiate potentially
destructive action with no asking for confirmation is totally unacceptable.

-----------------------------

Finally, anybody know how cpio detects end-of-tape in order to ask for the
next media?  Or for that matter, how does diskverify trap the bad sector
kernel messages in order to know when it has detected an error?  I have
RTFMed until my eyes have crossed.  Some experienced advice here would be
welcome.

Thanks,
John

-- 
John De Armond, WD4OQC                     | Manual? ... What manual ?!? 
Radiation Systems, Inc.     Atlanta, GA    | This is Unix, My son, You 
gatech!stiatl!rsiatl!jgd  **I am the NRA** | just GOTTA Know!!!