Larry E Kollar wrote:
> 
> Batching up a few responses -- thanks to all for your suggestions!
> 
> Colin:
> >I've seen this same problem.  There is absolutely _no_ damage involved.
> 
> Um, I had several dozen binaries in /usr/bin and /usr/games go sour on
> me.  I first noticed the problem when I logged into my non-root account
> and the shell complained about "fortune" -- the executable bits got
> turned off for about 10-20 consecutive binaries.  When I turned them
> back on & tried to run any of them, NetBSD would complain about "invalid
> architecture" or something like that (it had to do with architecture).
> These executables *did* work until very recently.  It's not only the
> games; important stuff like telnet is shot too.

I firmly believe that what you are seeing with this filesystem corruption
is completely unrelated to lost binaries.  The corrupted binaries indicate
a real problem in the SCSI driver.  Which one are you using, btw?
 
> I could live without df; comparing "du -s /usr" with the partition sizes
> that I wrote down would suffice.  But having standard utilities go away
> without warning is another matter. :-(

On my IIci w/ Quantum 730MB drive (a machine that seems prone to this
little problem), I keep a copy of the base distribution around so that I
can reinstall whenever I have this kind of thing happen.  Of course, you
might also want to make sure that you have a copy of tar around as well.

> >I'm not quite sure where the problem is, but I think that
> >it results from having your first usr partition at `g', and the next one
> >at `e'.
> 
> Isn't that how it's supposed to work???  First usr partition is 'g', then
> 'e', 'f', 'h', etc....  I would think that putting five partitions on a
> 1GB drive would be fairly common.

Yes, it is how it is supposed to work.  That doesn't mean that there isn't
a bug in how we do our calculations for `df', tho.  All of NetBSD is
_supposed_ to work, but there are definitely still some bugs ;-)

> SUNAGAWA Keiki:
> >It seems that your df doesn't know larger disk.  BSD df
> >shows blocks in 512 bytes blocks for default, so I think
> >your df isn't stock df.
> 
> Do the standard tarballs come with more than one version of df?  I
> haven't installed any other versions.  Next time I start NetBSD,
> I'll find out which directory it's in.  But df *did* show the right
> information for the last (and largest) partition -- it's just the
> two in the middle that are wrong.

You might be doing "df -k", I have this aliased in my startup files.

> 
> Christoph Badura:
> >Have you tried filling in the fsize, bsize and cpg fields in the disklabel
> >or did you give that information manually?
> 
> I haven't written the disklabel at all.  I need to look up those fields in
> the manpage & see what they do.  But I don't think that modifying the disk-
> label is going to fix the problem; it already has accurate block counts of
> each partition.  The block counts displayed by fsck are also correct.

You can't actually modify the real disklabel, anyway.  We don't support
native diskabels.  The only one that exists is created dynamically in the
kernel at boot time.

> 
> A general question -- is anyone else running with five BSD partitions (plus
> one MacOS) on a single disk drive?  If so, how well does it work?  (My
> original plan was to have only /home and /var writeable once I got every-
> thing set up how I wanted it... I thought it would make the system more
> stable.  Sheesh.)

I'm running with 6 NetBSD partitions (plus 1 swap partition) and 1 HFS
partition on a 4GB drive.  Here's my disklabel output:

# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: fictitious
flags:
bytes/sector: 512
sectors/track: 111
tracks/cylinder: 19
sectors/cylinder: 2109
cylinders: 3956
total sectors: 8388315
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # milliseconds
track-to-track seek: 0  # milliseconds
drivedata: 0 

12 partitions:
#        size   offset    fstype   [fsize bsize   cpg]
  a:    51200   204896      4.2BSD        0     0     0   # (Cyl.   97*-  121*)
  b:   204800       96        swap                        # (Cyl.    0*-  97*)
  c:  8388315        0      unused        0     0         # (Cyl.    0 -  3977*)
  d:   204800   512096      4.2BSD        0     0     0   # (Cyl.  242*- 339*)
  e:   102400   716896      4.2BSD        0     0     0   # (Cyl.  339*- 388*)
  f:  2516582   819296      4.2BSD        0     0     0   # (Cyl.  388*- 1581*)
  g:   256000   256096      4.2BSD        0     0     0   # (Cyl.  121*- 242*)
  h:  2936012  3335878      4.2BSD        0     0     0   # (Cyl. 1581*- 2973*)
disklabel: boot block size 0
disklabel: super block size 0
disklabel: warning, number of partitions (12) > MAXPARTITIONS (8)
disklabel: warning, partition j: size 0, but offset 1


All those sizes are in 512 byte blocks I believe.  Here's a "df" output:

Filesystem  512-blocks     Used    Avail Capacity  Mounted on
/dev/sd0a        48606    36304     7440    83%    /
/dev/sd0g       295612   242456    23594    91%    /usr
/dev/sd0d       493978   297212   147368    67%    /var
/dev/sd0e       592504   521626    11626    98%    /home
/dev/sd0f      3032252  1443558  1285468    53%    /u1
/dev/sd0h      5878628  3580400  1710364    68%    /u2

If you'll notice, they don't quite match up.  I honestly think we're
adding the numbers up wrong due to having the partitions out of order on
the disk.  Keep in mind that I have had _no_ problems with this disk
(other than it not liking to run if I attach an external drive,
termination problems maybe?) even with these screwy numbers.

I hope this helps clear things up a bit.

Later.

-- 
Colin Wood                                 cwood@ichips.intel.com
Component Design Engineer - MD6                 Intel Corporation
-----------------------------------------------------------------
I speak only on my own behalf, not for my employer.