|
|
| Author |
Message |
| 25 new of 547 responses total. |
jep
|
|
response 271 of 547:
| 
May 19 03:04 UTC 2003 |
re the responses to resp:246: I'm not going to embarrass anyone by
posting the messages I got in response to my e-mail to staff, and I
think some were humorously intended anyway. It took me 18 minutes to
get an e-mailed response with the address of Grex.
I was asked to not post the address. With all due respect, I think
it's not a meaningful request. However, I do have a lot of respect
for the Grex staff and since they asked, I won't post it.
Certainly, anyone wishing to obtain anything from Grex could do so
much more easily and certainly than by trying to recover data from a
formatted hard disk. Eric's concerns were well-intended but not a
realistic concern.
If anyone really wants anything from the old Grex hard disks, enough
to use data recovery techniques, Grex might entertain competitive
bids. If they gave Grex half the money they'd otherwise have to
spend, there would never again be a financial crisis. The staff could
be paid, the Board could be paid, and if I were given an appropriate
commission for coming up with the idea, I would never have another
financial concern.
|
cross
|
|
response 272 of 547:
|
May 19 04:16 UTC 2003 |
Yeah, true. Also, Joe earlier posted some odds for getting data off
of a scrubbed disk. He made it clear he was doing so without real
data, but I want to get those numbers closer to reality; he said
something like 15% odds of getting something good for a casual attacker,
30% for a determined attacker. However, in both cases, the attacker
isn't expending a lot of financial resources; only time and clevernes.
No access to fancy clean-rooms or the like. In that case, I'd give
a casual attacker something like 0.00001%, and a determined attacker
something like 0.0001%. Note that determination gives you an order
of magnitude advantage.
Those numbers are probably conservative; real numbers are probably
a lot closer to zero.
|
janc
|
|
response 273 of 547:
|
May 19 04:38 UTC 2003 |
Well, we had another Next Grex Meeting, somewhat sparsely attended - Mark
Conger, Joe Gelinas, John Remmers, Valerie Mates, Jan Wolter. Steves Weiss
and Andre' called to say they couldn't make it. Mark brought along the Next
Grex, which we set up temporarily and tried booting off an OpenBSD boot floppy
that John had brought along. Mostly looked good, but although it found the
SCSI controller, it did not find the SCSI drives. So we went about the proper
businesses of sitting around and talking about the computer.
After everyone left, I moved the machine down to my office, where it can be
plugged into the LAN and tried various things. Second thing I tried was one
of the other OpenBSD boot floppies. There are three in the distribution.
One for standard systems, one with extra drivers for SCSI and raid and gigabit
ethernet, one for laptops. John's was the second one, the one with SCSI
stuff. I tried the standard one, floppy33.fs, and that found the SCSI drives
without a problem.
I have volunteered to take a first cut at partitioning the drives and
installing OpenBSD. When I've done that, I'll get it on my LAN, open an
SSH portal to in through my firewall, and advertize it to staff.
I'm currently scratching my head of partitioning options, having had somewhat
less input from others than I would like, but I'll do something plausible.
If it stinks, we'll redo it.
|
aruba
|
|
response 274 of 547:
|
May 19 04:44 UTC 2003 |
Thanks Jan - enjoy those seven fans. :)
|
cross
|
|
response 275 of 547:
|
May 19 05:56 UTC 2003 |
Suggestions regarding partitioning. This is what I would do:
(a) Use RAIDframe across all the SCSI disks. Partition them
thusly:
32MB sd[0-2]a (The second-stage bootstrap and kernel)
1024MB sd[0-2]b (Swap, striped across 3 disks)
rest sd[0-2]d (Everything else)
Set up the RAIDframe partitions on sd[0-2]d.
Use RAID-5 with an interleave size of 64KB
(the size of an FFS1 ``extent'').
(b) Configure the following filesystems. You'll have to use
disklabel, but it's not particularly hard:
512MB / raid0a
2048MB /usr raid0d
4096MB /usr/local raid0e
4096MB /var raid0f
4096MB /grex raid0g
512MB /tmp raid0h
rest /u raid0i
80GB /scratch wd0d
(Yes, OpenBSD supports disklabels with more than 8
partitions on them....)
(c) Put mail in $home/Mailbox; that does away with the need
for a seperate /var/mail partition.
(d) Merge /suidbin into /. / in 4.4BSD doesn't contain nearly
as much ``non-system'' stuff as did / in 4.3BSD and prior
versions. It's easiest to think of it as a ``system''
partition with a minimum of non-system related stuff in it;
having suid tools in /, if one restricts it to system purposes,
is just fine. In this configuration / can remain the only
partition that has suid binaries on it, and it can remain
writable. This has some advantages: (i) All the suid tools
are available in single user mode. (ii) It's writable, which
means that a bug in a suid program can be quickly corrected
by staff. (iii) It cleanly keeps all ``system'' related
files in one place.
(e) Create symbolic links from /usr/src and /usr/obj to
/var/src and /var/obj, respectively. Also, create a
/var/local hierarchy. Create symbolic links from
writable places in /usr/local to /var/local. By doing
this, you're able to (i) make both /usr and /usr/local
read-only most of the time, while (ii) retaining the
ability to keep the system sources up to date.
(f) Move the BBS and associated files into /grex; this is
the place for grex-specific software. Party, the BBS,
etc can go in there.
I'd further do the following:
(a) Split /suidbin into /suid/bin and /suid/sbin. This breaks
up functionality a bit; user-software that is used by
general users can go into /suid/bin. Sysadmin stuff goes
into /suid/sbin.
(b) Create /local; put local stuff that's useful in single user
mode in here. Ie, Kerberos, Kerberized sudo, SSH, maybe a
shell or something, etc.
(c) Remove some of the goofy symlinks from /; why is /b a symlink
to bbs?
(d) Change the startup scripts to newfs /tmp every time the
system boots.
The biggest changes here are putting more stuff in /, and doing away with
/var/mail. The latter is for security and convenience; the former is
purely for convenience.
Oh, a node on the difference between sd[0-2]a and raid0a. The OpenBSD
RAID software can get its root filesystem from raid, but cannot read the
kernel upon boot out of a RAID partition. sd0a would be a *really*
small partition, mirrored on sd1a and sd2a as well, that contains the
second-stage bootstrap and the kernel to boot from. A copy of the
exact same kernel would be in /; once the system started booting, it
would be transparent. The system can be booted off of any disk, and
the loss of any single drive wouldn't impact grex much. It could be
swapped out and the parity rebuilt while the system was operating.
|
janc
|
|
response 276 of 547:
|
May 19 12:52 UTC 2003 |
Dan - Thanks. Looks like I'm going to have to read up more on RAID.
One note of possible concern: It's not clear how well our SCSI controller
is supported by OpenBSD 3.3. We have an Adaptec 29160 controller which
apparantly stars the 7899G chipset. In the OpenBSD 3.3 file INSTALL.i386
it says the following in the list of supported hardware:
Adaptec AIC-789[29] chips and products like the
AHA-29160 based upon it which do 160MB/sec SCSI. [C]
(However, the 7899G card is currently not supported with
more than one device attached)
Well, we have more than one device on our card. Web searches show lots of
messages from people who had problems with OpenBSD and the 29160. For some
of them, using only one device on the controller worked fine. These messages
generally had followups saying that these problems were fixed in later
releases. This is a fairly popular card, and you'd expect getting it to
work would have been a priority for someone. However, as you see, they
didn't delete the note saying it didn't work with multiple devices from the
install document.
I'm guessing/hoping that this is just a reflection of their poor document
maintenance. Though the 386 install document seems to me to be the single
most important document to maintain, it seems to be fraught with errors,
mainly places where it appears not to have been updated when the software
was. In the section quoted above, for example, the [C] indicates that the
driver is not included on install floppy C. However, it appeared not to work
on install floppy B either, and there is no [B] there.
Hmm...raid support is on floppy C, our SCSI driver support is on B. Could
be an annoyance if we try to build a RAID system.
|
cross
|
|
response 277 of 547:
|
May 19 13:26 UTC 2003 |
Sure thing, Jan. I'm not sure what to say about the 7899G based card,
other than, ``try it and see if it works.'' I do see that a few
people on various mailing lists say things like, ``I beat the living
snot out of a 7899G with 20 drives on it and it worked just fine.''
(http://archives.neohapsis.com/archives/openbsd/2002-12/0019.html).
It seems they probably cut and pasted the supported hardware list from
the architecture specific hardware web page into the install document;
I'd suggest that you're correct in guessing it's an artifact of a less
than perfect document update process.
btw- Just because it's absent from the floppy doesn't mean it's absent
from the CD boot media. For instance, the drivers for both the SCSI
card and RAID should be on ftp://ftp.openbsd.org/pub/OpenBSD/3.3/cdrom33.fs
|
janc
|
|
response 278 of 547:
|
May 19 14:00 UTC 2003 |
OK, just starting to read about RAID. Looks like the Promise RAID controller
on the motherboard is for IDE only (and may not be supported by OpenBSD
anyway) so we are talking about software RAID, which in the case of OpenBSD
is RAIDframe. Apparantly OpenBSD 3.1 and later do support having the
root partition mirrored on RAID.
RAIDframe supports RAID levels 0, 1, 4 and 5 and miscellaneous other things.
It's not in the generic kernal. We'd need to rebuild with it. There are a
huge number of options here, just beginning with the question of which RAID
level to use.
My feeling is that RAID is a sensible answer for Grex. It can win us
performance gains and added data security in the case of a disk crash.
It wastes a lot of disk space, but we have the space to waste. It does
not protect us from someone accidentally deleting files, so it is no
substitute for backups.
However, going the RAID route means (1) spending some time weighing which
RAID configuration (if any) is right for Grex, and (2) spending some time
getting it all set up. Doing this right is going to require a lot of time
and a lot of staff members in the loop. I don't want to stall bringing
the system on line for code porting and other development while we do
this. Maybe I should do an OpenBSD install onto the IDE disk. We can
work there, build a raid kernal, configure RAID on the SCSI disks then
boot off that.
This may be the best choice right now. It gets the system to a state where
I can do what I know a lot about (software), and defers the decisions about
disk setup a little longer to give other staff time to chime in if they want.
If I'm going to implement Dan's plan, then I'll need to do it in two stages
anyway, since it doesn't look like you can get a RAID system straight off the
CD.
The minus with doing the OpenBSD install on the IDE disk is that it doesn't
give the three SCSI drives on the 29160 controller a good work-out, and that's
questionable enough to be worth beating on. However, I can create some
temporary partitions there, and start a program reading/writing stuff to them,
just to give them a workout.
|
cross
|
|
response 279 of 547:
|
May 19 15:05 UTC 2003 |
The last time I did an OpenBSD install into RAIDframe, I think I did
something like the following:
(1) Installed onto a single drive.
(2) Recompiled the kernel and tested it.
(3) Booted single-user.
(4) Dumped /usr, /usr/local, /var and all the
partitions I was RAID'ing to temp space
somewhere.
(5) Reclaimed the space of all the partitions
I wanted to RAID'ify into one big partition
using disklabel.
(6) Configured and started up RAID.
(7) Edited the RAID set disklabel and set up my
partitions.
(8) Rebuilt the new RAID set's parity (which went
surprisingly quickly).
(9) newfs'ed the new partitions and mounted them.
(10)restored the earlier dumps to the new, RAIDed
partitions.
This is slightly more complex, but I think you could do something similar
to get RAID working on the SCSI disks. Certainly, installing onto the
IDE disk gives you the manueverability to bootstrap the SCSI drives.
Of course, that doesn't resolve the issue of deciding on an optimal
configuration.
Some more suggestions: Use RAID level 5. You only have three disks;
if you had four, I'd suggest using 1+0, that's out. Anyway, RAID 5 will
give decent performance (particularly if coupled with soft updates on all
partitions), will protect against dropping a disk, and won't waste *too*
much disk space. With only three disks, you don't have much else in the
way of choices for RAID levels. Striping won't but you any reliability,
RAID 4 is just dumb, and you don't have enough disk for mirroring.
The last real question is how big to set the interleaves. I'd say 64KB,
and the reason for that is that 4.4BSD's FFS implementation defines a
weak concept of an ``extent''; basically, it'll try to read or write up
to 64KB in a single burst from/to the disk, if it can. A 64KB interleave
size matches up with that idea of an extent as used by the filesystem,
and should give pretty good performance.
|
cross
|
|
response 280 of 547:
|
May 19 15:06 UTC 2003 |
Oh, PS- Didn't remmers donate an OpenBSD machine that could be used
for software porting and things of that nature, leaving time to get
the nextgrex configuration right?
|
janc
|
|
response 281 of 547:
|
May 19 16:09 UTC 2003 |
Yup, he did.
Well, ran into another snag in the OpenBSD install. OpenBSD can't find
a network interface.
During the boot up, when it is polling the PCI bus, it lists:
Broadcom BCM5702X rev 0x02 at pci0 dev 8 function 0 not configured.
That means it sees it, but doesn't have a driver for it. On th list of
supported hardware it says:
# Broadcom BCM570x (a.k.a. Tigon3) based PCI adapters (bge): (A) (B) (C)
The (A) (B) (C) business means that the driver isn't on any of the install
floppies.
I think this means I need the CD to do the install. I can't very easily do
an ftp install without a network driver.
|
cross
|
|
response 282 of 547:
|
May 19 18:38 UTC 2003 |
Wait; if you burn a CD with the CD-ROM boot image on it, does that have
the driver? You should be able to boot with it and perform an installation
from there.
|
cross
|
|
response 283 of 547:
|
May 19 18:39 UTC 2003 |
(PS- to Clarify. The CD boot image is different from the OpenBSD CD
distribution, and can be downloaded from the OpenBSD web site. Given
that there's a CD burner in Nextgrex, it shouldn't be hard to do. The
URL for the CD-ROM image is: ftp://ftp.openbsd.org/pub/OpenBSD/3.3/cdrom33.f
s
|
janc
|
|
response 284 of 547:
|
May 19 19:06 UTC 2003 |
Right. Unfortunately, I blew away the Windows98 install Mark did on Next
Grex, so I'd need to first install something on NextGrex that can fetch
that file over the network and can burn a CD. I have a number of different
old OS's on CDs that I could try, but none are painless. I don't have another
computer with a CD burner.
The real live OpenBSD 3.3 bsd was shipped from Alberta on Tuesday, apparantly.
It should arrive in the next few days. There are also probably lots of people
who could make me a CD with that file on it. Either of these two paths seem
much easier than reinstalling Windows98 on NextGrex.
|
aruba
|
|
response 285 of 547:
|
May 19 19:20 UTC 2003 |
We don't know for sure if our CDs shipped Tuesday, only that our credit card
was charged then. I sent mail to the shipping guy at openbsd.org to ask if
they really did ship.
But anyway, dang offered to make Jan a CD, and he'll bring it over tonight.
|
remmers
|
|
response 286 of 547:
|
May 19 22:24 UTC 2003 |
Re #280: My machine is still online and available to any staffer who
wants access. It's currently running OpenBSD 3.2. If it's going to be
used to test out software, I should upgrade it to 3.3. If I have time
to do that in the next couple of days I will, but to be honest free time
is in somewhat short supply this week. I'll see how it goes. Dang
installed a CVS server on it, the idea being to use that to document
our work. The CVS server hasn't been used yet, and nothing much else
has been done with the machine yet either, so it might not be too
unreasonable to use the OpenBSD CDs, when they arrive, to install 3.3
from scratch on my machine, then ask dang politely to re-install the
CVS server...
|
janc
|
|
response 287 of 547:
|
May 20 00:49 UTC 2003 |
Turns out Valerie can burn CD's. I should have known that. So I've got a
working boot CD now.
I tried logging into John's machine and failed. I should give him a call and
see what I've got wrong.
|
janc
|
|
response 288 of 547:
|
May 20 01:54 UTC 2003 |
Hmmm. Got it installed on the disk, but boot from the disk seems to be
hanging when the kernel tries to initialize the audio drivers. I'll
investigate more later tonight and report back.
|
aruba
|
|
response 289 of 547:
|
May 20 03:11 UTC 2003 |
I had a little trouble with the audio in Windows 98, actually. It mostly
worked, but occasionally produced static when it should have been playing a
sound. I figured it was because I needed a different version of the driver,
or it needed to be reinstalled.
|
other
|
|
response 290 of 547:
|
May 20 03:22 UTC 2003 |
Why are we worrying about making the audio drivers on the next Grex
machine work?
|
janc
|
|
response 291 of 547:
|
May 20 03:31 UTC 2003 |
OK, some details. As the kernal starts up, it prints out lots of messages
describing the various devices. When booting from the CD or floppy, it finds
the audio device, but doesn't have a driver for it (of course, since this is
a install disk and it doesn't need audio), so it says:
"VIA VT8233 AC97 Audio" rev 0x50 at pci0 dev 17 function 5 not configured
When we boot from the hard disk, it finds the device, and has a driver, but
the driver seems to fail to initialize. It types the following, and then
hangs forever with the cursor at the end of the line:
auvia0 at pci0 dev 17 function 5 "VIA VT8233 AC97 Audio" rev 0x50_
It should go on to finish the line by typing something like
auvia0 at pci0 dev 17 function 5 "VIA VT8233 AC97 Audio" rev 0x50: irq 9
We never get the ": irq 9" part. (It is IRQ 9, according to the bios).
One fix would be to build a kernal without the audio driver. It's not like
Grex needs audio. Any better ideas?
|
janc
|
|
response 292 of 547:
|
May 20 03:39 UTC 2003 |
Eric slipped in. I don't care very much about making them work. Right now
they are keeping us from booting, which I do care about. I'd slightly prefer
to know what is causing it to fail.
We are going to have to do an OpenBSD install on this machine every year or
so. We need to figure out how to do it smoothly. It's worth a little effort
to find the *best* way to deal with problems, not just some workaround kludge.
|
cross
|
|
response 293 of 547:
|
May 20 03:42 UTC 2003 |
Hmm; can you disable the onboard audio in the BIOS? It sounds like
it's hanging in the probe routine; perhaps it's having difficulties
disambiguating the audio device from something else it might share
an interupt line with? Maybe there's a bug allocating an IRQ?
Weird.
|
janc
|
|
response 294 of 547:
|
May 20 03:45 UTC 2003 |
Found this:
http://www.netsys.com/openbsd-misc/2003/01/msg00734.html
Appears to be someone having the same problem.
|
janc
|
|
response 295 of 547:
|
May 20 04:26 UTC 2003 |
The discussion of this problem above didn't find any sensible solutions, so
I'm willing to just disable the device. Looks like there are two ways to do
this without recompiling the the kernal.
http://www.openbsd.org/cgi-bin/man.cgi?query=boot_config&sektion=8&arch=i38
6
To make this work, you need to tell it to boot "/bsd -c" instead of /bsd.
However, it doesn't prompt for a kernal to boot, and I don't know how to
make it do so.
http://www.openbsd.org/cgi-bin/man.cgi?query=config&sektion=8&arch=i386
To make this work, I need a reasonably running system. Booting off the
CD and mounting the / partition under /mnt doesn't do it. The config program
is not on the install CD and the copy on the hard disk wants ld.so which it
can't seem to find while booted off the CD. I might be able to figure out
how to make this work, if I was less sleepy.
Either way, I just need to do "disable auvia" and that should kill the
audio card.
I'm going to bed.
|
