HDTenEightyP/NetNews huggingface dataset:
From: phk@data.fls.dk (Poul-Henning Kamp)
Newsgroups: comp.unix.bsd
Subject: 386BSD 0.1: disklabel problems, another case...
Date: 21 Jul 92 21:27:27 GMT
Organization: FLS Data A/S, Valby, Copenhagen, Denmark.

Hello everybody, (and a big thanx to the Jolitz'ses !)

Machine: 486 33 Mhz AMI bios 8Mb RAM 256 cache. (UM 82C480 Chipset)
(all funny configurations tried: no difference).

Disk: Western Digital AP4200 "Piranha" IDE
	1263 cyl, 8 heads, 41 sect.

The bios is set to the true params, on the variable disktype 47,
(stored either at 0:300 or 640K-1k, makes no diff).

If I use the complete disk for 386BSD things work, if I have one or two
dos partitions (3.30, don't ask, I'm forced to !) I cannot boot from the
harddisk, the dist.fs and fixit.fs boots OK and finds the harddisk without
problems.  But when I boot from the "install"'ed hard-disk the result
is this:

    ...
    wd0 <WDC AP4200> at 0x1f0 irq 14 on isa
    ...
    wd0: cannot find label (no disk label)
    panic: cannot mount root

The machine did run 0.0 sans problems.  

Anybody know what's wrong ?

Could this be related to the BIOS-params being in RAM instead of EPROM ?
As far as I have checked the boot, the params are indeed copied up below
640K, but could it be too late at that time if the params are in RAM ?

Is there any way I can turn on debugging to find out what's going on ?

How about a debug.fs distribution in which all possible (relevant) debuging
was turned on to debug boot-problems... ?

summary of combinations tried:

BIOS param	dos part	386bsd		Status
1024 cyl	none		whole disk	OK
1263 cyl	none		whole disk	OK
1263 cyl	199 cyl		rest of disk	hangs early in boot with fs+hd
		(32636 kb)			lights active, before any text
						has been put on the video
1263 cyl	100 cyl		rest of disk 	Panics as descr. above
1263 cyl	10 cyl		rest of disk 	Panics as descr. above
-- 
phk@data.fls.dk		  || If you can't join 'em -- beat 'em !
Poul-Henning Kamp	  ||			the Danish foreign minister
FLS DATA A/S		  ||
Phone: (+45) 36 18 12 35  ||
Newsgroups: comp.unix.bsd
From: randy@chinet.chi.il.us (Randy Suess)
Subject: Re: More booting problems... (Bus mouse?)
Date: Tue, 21 Jul 1992 13:19:12 GMT
Organization: Chinet - Public Access UNIX

In article <1992Jul20.194749.10441@gateway.novell.com> terry@thisbe.npd.Novell.COM (Terry Lambert) writes:
>Anybody have a machine with a built-in bus mouse that works?  Did you have to
>change anything (jumpers, CMOS, etc.)?  Did the default kernel (TinyBSD) boot
>for you without modification?
>

	Yes, I have a Packard Bell 386sx-20 laptop with 8 megs memory
	and a 80 meg drive, and a PS/2 style mouse port. (same style
	as on the 6386WGS machines), and 0.1 runs just fine on it.
	No problems booting, or installing along side msdos.
	Now, if someone would just come up with a Xircom driver,
	it could be a usefull network machine....

-- 
	I am created Shiva the Destroyer; Death, the shatterer of worlds!
	Who is this dog meat who stands before me now?
	That's the biz, sweetheart.
Randy Suess					 randy@chinet.chi.il.us
Newsgroups: comp.unix.bsd
From: Havard.Eidnes@runit.sintef.no (Havard Eidnes)
Subject: netstat from NET2 ported
Originator: he@spurv.runit.sintef.no
Organization: Computing Center at the University of Trondheim, Norway
Date: Tue, 21 Jul 92 21:57:16 GMT

Hi,

I've ported netstat from NET2 to 386bsd version 0.1. The changes are mostly
involved with inserting #ifdefs for ISO, NS and IMP at the relevant places
("removing" that code, essentially), not compiling some of the modules
(although the source remains toghether with comments in the Makefile) plus
modifying the "unixpr()" routine in unix.c to traverse the open file table
the new way.  The "netstat -r" output looks a bit odd (although I guess this
is the "new way"?), but gives the right information.

The source and binary is available with anonymous ftp from ugle.unit.no (for
lack of a better place) in the pub/unix/386bsd/ directory as netstat-bin.tar.Z 
and netstat-src.tar.Z.  Unpack the source from /usr/src and the binary and
formatted man page (as root) from /.  Use binaries at own risk ;-)

- Havard
Newsgroups: comp.unix.bsd
From: lidl@rodan.UU.NET (Kurt J. Lidl)
Newsgroups: comp.unix.bsd
Subject: Re: Removing 386BSD from the hard disk
Date: 28 Jul 1992 16:37:16 -0400
Organization: AlterNet -- Falls Church, Virginia, USA
NNTP-Posting-Host: rodan.uu.net
Keywords: 386BSD

 wutcd@hrz.tu-chemnitz.de (Joerg Wunsch) writes:
>Kwan-Seng Law advised to low-level format the disk. If you don't want to
>do this (on an IDE, about 10 % of IDE drives are problematically with this),
>write a simple DOS program which nullifies all sectors of the first tracks
>(via BIOS hard disk interrupt); i'm sure this will help, at least when done
>on the whole disk.

And under 386bsd, you would use "dd".

As in: "dd if=/386bsd of=/dev/rwd0c obs=8192 count=1" %%

That ought to pretty much blow away the first track or so...

Much simpler than having to go in and actually *touch* code that
mucks about with BIOS calls.

(I did that once.  A screaming nightmare inside of DEBUG that I
shall remember for a long time, representing most, if not all
the things that I really, really, really, dislike about doing
*anything under DOS!)

-Kurt

%% if you have something other than the start of the hard disk at
the beginning of the c partition (like you are running with dos
co-existing on the same hard drive), this will not work for you, I
think.
-- 
/* Kurt J. Lidl (lidl@uunet.uu.net)   | Unix is the answer, but only if you */
/*                                    | phrase the question very carefully. */
/* Don't even think of confusing my opinions with my employer's opinions!   */
Newsgroups: comp.unix.bsd
Subject: Re: AT&T sues BSDI
From: campo@sunthpi3.difi.unipi.it (Massimo Campostrini)
Date: 24 Jul 92 11:17:26 +0100
Reply-To: campo@sunthpi3.difi.unipi.it
 <1821@adagio.UUCP> <1992Jul24.064922.8448@newshost.anu.edu.au>
Distribution: world
Organization: Istituto Nazionale di Fisica Nucleare, Pisa, Italy

Should we rename this newsgroup
comp.unix(*).bsd.(*)UNIX.is.a.trade.mark.of.AT&T ?

-- 
        Massimo Campostrini, 
Istituto Nazionale di Fisica Nucleare, Sezione di Pisa,
Piazza Torricelli 2, I-56126 Pisa, Italy  ||  Phone: (+39)(50)42093
Internet: campo@sunthpi3.difi.unipi.it    ||  Fax:   (+39)(50)48277
Newsgroups: comp.unix.bsd
From: steve@endgame.gsfc.nasa.gov (Steve Rezsutek)
Subject: Re: Pax (was Re: Sorry, everyone, but I'm cpio clueless...)
Organization: none
	<1992Jul20.152650.4070@gateway.novell.com>
	<DJM.92Jul20122506@frob.eng.umd.edu>
	<1992Jul21.200827.14598@NeoSoft.com>
	<1992Jul21.232122.19086@cti-software.nl>
Date: Wed, 22 Jul 1992 15:15:04 GMT

pim@cti-software.nl (Pim Zandbergen) writes:
   karl@NeoSoft.com (Karl Lehenbauer) writes:

   >It was funded by Usenix, and can be found about anywhere on the net.
   >It's also /usr/5bin/pax on your Sun, /usr/bin/pax under SCO.

   It's also /usr/lbin/pax in ISC Unix, and /usr/bin/pax in AIX 3.2
   for the IBM RS/6000.

Ok, I'll jump in here...

; whatis pax
/usr/apollo/bin/pax
; 

Add Domain/OS (SR10.3) to the list.

---
Steven Rezsutek				steve@asylum.gsfc.nasa.gov
From: nanda@kuhub.cc.ukans.edu
Newsgroups: comp.unix.bsd
Subject: please help!
Date: 21 Jul 92 11:39:48 CDT
Organization: University of Kansas Academic Computing Services

HI! I am new to this group. Could someone tell me how to subscribe to this
group?

thanks in advance

Nanda@kuhub.cc.ukans.edu
From: kaneko@ICSI.Berkeley.EDU (Seiji Kaneko)
Newsgroups: comp.unix.bsd
Subject: Re: install 0.1 problems
Date: 22 Jul 1992 01:33:47 GMT
Organization: international computer science institute
Distribution: usa
NNTP-Posting-Host: axiom.icsi.berkeley.edu

In article <1992Jul21.211019.6250@thyme.jpl.nasa.gov> kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) writes:
>1.  I attempted to reinstall OS/2.  386BSD seems to have usurped the boot
>    sector on the disk.  It appears that I'm going to have low level format 
>    my disk :-(  I didn't anticipate this from the install notes.  Even
>    agreeing to let the 386BSD take the whole disk shouldn't be this unkind
>    to my disk.

I tried it, and in my case, bsd install program detected free space
correctly. But I failed to boot OS/2 after installing 386bsd, too.

My partition: made by OS/2 fdisk
1M : boot manager
4M : DOS
30M : OS/2 system
90M : free, not assigned as extend/primary partition of DOS -> 386bsd

The point is, I think, do not format space for 386bsd as Dos or OS/2
partition. Leave it as free space before running 386bsd install.
But 386bsd DO overwrite boot sector, and 386bsd seems to be 
incompatible with os/2 boot manager. Therefore after 386bsd
installation, I can't make os/2 bootable yet. I'm trying to fix it.
-- 
Seiji Kaneko  kaneko@icsi.Berkeley.EDU,kaneko@sdl.hitachi.co.jp
.................................... 76270.2466@compuserve.com
From: hlu@phys1.physics.wsu.edu (Hongjiu Lu)
Newsgroups: comp.unix.bsd
Subject: Re: STDIO Mode "a+" screwed up
Date: 27 Jul 92 23:50:32 GMT
Organization: Washington State University

In article <39897@gremlin.nrtc.northrop.com>, dec@lazarus.nrtc.northrop.com (Dwight E. Cass) writes:
|> Hi folks,
|> 
|>    I have just spent the weekend trying to find out why rogue crashes
|> when it attempts to update its score file and have found the problem:
|> 
|>    In: /usr/src/lib/libc/stdio/flags.c - Mode "a+" translates to an
|>        open flag with O_APPEND (in __sflags()).  This means that if
|>        you seek the file to the beginning and start writting, all the
|>        written will be APPENDED to the end of the file - rather than
|>        updating the top of the file as specified by the plus sign.
|> 
|>    What's the cure - ouch.  It seems that __sflags() is called by all of
|> the open routines and that there is not a clean way of passing back
|> the fact that append is desired (why pass it back - you have to seek
|> to the bottom of the file [lseek (fd, 0, SEEK_END)] after the file
|> is opened (i.e., after you have returned from __sflags()).  So - my
|> proposal (which I will implement tonight and send patches for
|> tommorrow), add one more flag to the ->flags work in the FILE *
|> structure.  This flag, __SUPD 0x4000, will indicate that the file
|> has been opened in an append mode (i.e., I will always set this flag
|> for "a", "a+", "ab+", and look at it rather than O_APPEND to make the
|> decision as to whether to lseek or not.)  We will see what
|> side-effects this has.
|> 

I think that is the right behavior according to ANSI C. Unfortunately some
UNICES screw up on this one.

-- 
H.J.
Gcc/libc maintainer for Linux.
From: andrew@alice.att.com (Andrew Hume)
Newsgroups: comp.unix.bsd
Subject: Re: AT&T vs. BSDI --> 4.3BSD-NET2 distribution requires AT&T license!
Summary: if you protest, protest effectively
Date: 24 Jul 92 18:51:47 GMT
Article-I.D.: alice.23309
Organization: AT&T Bell Laboratories, Murray Hill NJ



	let me say up front that i work for at&t. i neither work for,
nor have any influence on, USL. the opinions expressed below are my
own and not at&t's.

	i am not a lawyer but although USL's suit is arguably outrageous,
and certainly hamfisted, its main point seems plausible. USL has a lot
vested in the trademark UNIX and it is simply prudent to protect that.
BSDI asserts that its source is at&t-free; USL asserts it isn't at&t-free
(or even usl-free). this kind of dispute is settled by suits all the time
so it is disingenuous to claim USL shouldn't do so simply because it is
big and BSDI is small. one might ask why USL didn't go after CSRG or UCB
but again there is a plausible reason why BSDI is it; it is the first do
attempt to make money from the NET-2 source (as far as i know).

	if you agree with me that the big issue is whether or not the NET-2
release is free of any licensing concerns, what can be done about that?
you can either try to influence the (technical) decision in court or
try to induce USL to drop the suit. (note that the latter simply leaves
the issue unresolved until next time.) there have been numerous posts
about the former (amicus briefs, supporting bsdi financially etc).
there have been a bunch of posts on teh latter, mostly of uncertain value.

	attempting to affect USL through AT&T seems problematic. USL was setup
solely to make it less connected to at&t. an embargo against system V would
seem more directed and effective (although i certainly can't advocate that).
an embargo against plan 9, as some have proposed, would be utterly pointless.
do you seriously think for a femtosecond that USL gives a damn about you
using plan 9? (i'm sure they are indifferent but if they had an opinion, they
are probably glad you aren't using plan 9.)


	attempting to sum up, people who want to do something should figure
out what they are concerned about befor ethey do it.

		andrew hume
From: vixie@pa.dec.com (Paul A Vixie)
Newsgroups: comp.unix.bsd
Subject: Re: Latest 386BSD Distribution on DEC TK50 tape?
Date: 31 Jul 92 16:48:32 GMT
Organization: DEC Network Software Lab

I'll make tapes for anybody, and I've got a TK50(95MB) to do it with.
I've also got 8MM(2GB or 5GB), 4MM(1GB RDAT), TK70(295MB), QIC(60MB, 150MB,
and 525MB), and 9-track(1600 or 6250).

Terms are as follows: send me a tape and a stamped, self-addressed return
mailer (I will NOT reuse the mailer you use to get it to me and I will NOT
lick any stamps for you).  Somewhere on the tape write "386BSD 0.1".  Do
not include any notes, money, or special requests.  Tapes arriving that
deviate from those terms in any way are mine to keep with no notice to you.
Mail all this junk to: Paul Vixie, 3477 South Court, Palo Alto, CA, 94306.

In article <5416@ucsbcsl.ucsb.edu> dburr@sbphy.physics.ucsb.edu (Donald Burr) writes:
Path: pa.dec.com!decwrl!mips!swrinde!network.ucsd.edu!ucsbcsl!sbphy.physics.ucsb.edu!dburr
   From: dburr@sbphy.physics.ucsb.edu (Donald Burr)
   Newsgroups: comp.unix.bsd
   Date: 30 Jul 92 23:19:22 GMT
   Sender: root@ucsbcsl.ucsb.edu
   Reply-To: dburr@sbphy.physics.ucsb.edu
   Organization: UCSB Physics Department
   Lines: 10

   Is there anyone out there who would be willing to put the latest 386BSD
   distribution onto DEC TK50 tape for me?  Our site does not have Internet
   access, but we have many students who are eager for a UNIX operating
   system to run on their home computers (so they can do work at home,
   etc.)  Please get back to me through Email if you can.  Thanks.

   : Donald Burr, Coordinator          : dburr@sbphy.physics.ucsb.edu   INTERNET :
   : Santa Barbara Area Network(SBANET): dburr@gnu.ai.mit.edu (Backup)  ======== :
   : Santa Barbara, CA  USA            : DonaldBurr@aol.com (AOL gateway)        :
   : uunet!dsc.com!dschub!sbanet!dburr : America OnLine: DonaldBurr              :
--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Don't be a rebel, or a conformist;
<vixie@pa.dec.com> decwrl!vixie		they're the same thing, anyway.  Find
<paul@vix.com>     vixie!paul		your own path, and stay on it."  -me
Newsgroups: comp.unix.bsd
From: randy@chinet.chi.il.us (Randy Suess)
Subject: Re: tape drive problems
Date: Tue, 21 Jul 1992 13:06:23 GMT
Organization: Chinet - Public Access UNIX

In article <1992Jul21.044227.5511@zip.eecs.umich.edu> dmuntz@dip.eecs.umich.edu (Daniel A Muntz) writes:
>In article <1992Jul21.015910.3456@chinet.chi.il.us> randy@chinet.chi.il.us (Randy Suess) writes:
>>	I have not been able to get the tape device (/dev/rwt0)
>>	to work properly on 0.1.  
>Try using the block device /dev/wt0.  

	Hmmm.  No /dev/wt0 on my system, just rwt0 major 10, minor 0.
	Mr Jolitz sent me email saying not to use the -B option for cpio
	because of a bug in the wt driver, but that didn't help.
	I will look around to see why wt0 is missing.
	Thanks!

>I don't think you'll be pleased with the performance if you do get it working...

	Hey, an overnite backup is better than no backup!
-- 
	I am created Shiva the Destroyer; Death, the shatterer of worlds!
	Who is this dog meat who stands before me now?
	That's the biz, sweetheart.
Randy Suess					 randy@chinet.chi.il.us
From: kwan@netcom.com (Kwan-Seng Low)
Newsgroups: comp.unix.bsd
Subject: tip com2 prob on 386bsd0.1...
Keywords: 386bsd, tip
Date: 30 Jul 92 18:13:38 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

Sorry if this question has been asked before...
I'm still having prob. tip to com2 on a fully installed 386bsd0.1
tip com2 or tip com02
file lock: no such file or directory
all ports are busy

I've com2 define in my /etc/remote.
If this is the same question that's been asked before, would someone please
post the answer. Thanks in advance...

Kwan-Seng Low
From: paradis@sousa.ltn.dec.com (Jim Paradis)
Newsgroups: comp.unix.bsd
Subject: Re: using mtools to access dos partitions
Date: 23 Jul 92 17:03:14 GMT
Organization: Digital Equipment Corporation, Littleton, MA

mitchemt@silver.ucs.indiana.edu (Terrence Mitchem) writes:
: 
: 	Can anyone tell me how to set up the devices.c file that comes with
: mtools in order to access dos partitions on  hard drive? Which devices in /dev
: correspond to the partitions on the disk?  Does it make any difference if I am
: using a scsi controller (adaptec 1542b)?  All help is appreciated.

With the new "wd" driver that uses the "a5" partition for the BSD partition...
none of the devices in "/dev" correspond to the DOS partition.

HOWEVER:  the escape hatch is via /dev/wd0d.  The "d" partition covers the
*WHOLE* hard disk, whereas the "c" partition covers only the *whole*
386bsd area.

To build a devices.c file that lets you access the DOS partition, you
need to know the byte offset of the DOS partition from the start of
the hard disk.  You would then add an entry to the devices[] array
as follows:

	{'C', "/dev/wd0d", <byteoffset>L, 16, 0, (int (*) ()) 0, 0, 0, 0},

So, f'rinstance, if your DOS partition starts at the beginning of the disk,
you'd have:

	{'C', "/dev/wd0d", 0L, 16, 0, (int (*) ()) 0, 0, 0, 0},

On the other hand, if your DOS partition starts 32Mb into the disk, you'd
say something like:

	{'C', "/dev/wd0d", (32768L * 1024L), 16, 0, (int (*) ()) 0, 0, 0, 0},

Make sense?

-- 
Jim Paradis (paradis@tallis.enet.dec.com) 
Working for DEC, speaking for myself.
Newsgroups: comp.unix.bsd,comp.os.linux,comp.periphs.scsi
From: adrie@ica.philips.nl (Adrie Koolen)
Subject: Re: Query: Drivers for AHA >1522< ?
Organization: Philips Consumer Electronics, Eindhoven, The Netherlands
Date: Fri, 31 Jul 1992 06:42:43 GMT

In article <1992Jul29.204834.20882@adaptx1.UUCP> neese@adaptx1.UUCP (Roy Neese) writes:
>In article <1992Jul23.232138.20172@colorado.edu> drew@ophelia.cs.colorado.edu (Drew Eckhardt) writes:
>> If you're talking about sustained transfer rate, it's going to be 
>> faster to do polled I/O because you don't have the couple of clock
>> cycles associated with each bus on period - you just crank data 
>> across the AT bus topspeed, 16 bits at a time.
>
>Nope.  Polled I/O can never be faster than bus master DMA as it takes
>twicw as many cycles to move each word doing polled I/O as it does for a
>bus master to move the same word.
>The overhead you speak of is for acquiring the bus, wchi takes 2 cycles
>and then of course it takes another 2 cylces to release the bus.  But to
>show a more subjective view.  Let's make some assumptions, good
>assumptions.  Let's say 1 cycle per word for bus master DMA and 2 cycles
>per word for polled I/O (you have to do a read and write for polled I/O,
>whereas bus masters do either a read or a write).  Now let's move 512
>bytes of data.  Let's see,... for polled that would be 1024 cycles and
>for a bus master 512 + 2 + 2 = 516.  Nuff' said.

Unless I misunderstand the conditions of your example transfer, I have to
disagree.

I assume that you mean "AT-bus cycle" when you talk about cycles. Clearly,
you can't transfer one word over the AT-bus in only one cycle. I was under
the impression that it takes some 6 or 8 cycles.

That would seem to be a bigger advantage for bus mastering controllers, but
you're wrong in the assumption that the write into (or read from) memory
is done over the AT-bus. Normally, this is done over the local CPU bus
(33 MHz?), which is much faster than the AT-bus (8 MHz?).

Furthermore, it would be unwise to take the AT-bus for 512 cycles. Under
normal 1542b operation, the bus freed after some 7 cycles, so the overhead
of getting and releasing the bus is bigger.

I agree that bus mastering I/O is faster than polled I/O over the AT-bus,
but not with the factor you indicate.
 
Adrie Koolen (adrie@ica.philips.nl)
Philips Consumer Electronics, Eindhoven, the Netherlands
From: osynw@warp.mhd.montana.edu (Nate Williams)
Newsgroups: comp.unix.bsd
Subject: Re: Beginner's problems with 386BSD
Date: 27 Jul 92 01:17:12 GMT
Organization: /usr/local/lib/MYORG

In article <1992Jul26.232240.23004@cognos.com> dealwisb@cognos.com (Brian de Alwis) writes:
>In article <1992Jul26.174358.29102@coe.montana.edu> osynw@warp.mhd.montana.edu (Nate Williams) writes:
>>In article <712169547snx@rama.demon.co.uk> steve@rama.demon.co.uk (Steve Entwistle) writes:
>>>4) How do I configure the system for UK local time ? I tried symlinking
>>>   /etc/localtime to /usr/share/zoneinfo/GB-Eire, but this puts the clock
>>>   about 8 hours ahead.
>>
>>I wish someone could tell me how to get my clock correct too.  I have tried
>>various combinations of things, including re-linking the kernel with
>>the correct offset in the config file [...]
>
>Have you tried recompiling from scratch? (You may shudder, but make
>can't check files that are dependent on compilation flags - of which
>the offset is one!).
>-- 
>+++BdA  Brian de Alwis. Brain on loan to Cognos Inc, Ottawa, Ontario.
>	dealwisb@cognos.com, or bsdealwi@napier.{waterloo.edu,uwaterloo.ca}
>	"Nine out of ten men who tried camels said they preferred women"


Yep, I have tried everything I could think of.  I removed /usr/share/zoneinfo
and remade everything from scratch.  My machine is still one hour faster
than my real time clock.  I suspect a daylight savings time problem, 
but I am not sure why that would make a difference, because my BIOS
takes care of that autmatically.

Nate
-- 
osynw@terra.oscs.montana.edu |  A hacker w/out a home.  Anyone  interested
work: (406) 994-5991         |  in a used Sys. Admin., which alot of 
home: (406) 586-0579         |  good hacks left?
Newsgroups: comp.unix.bsd
From: julian@tfs.com (Julian Elischer)
Subject: Re: OS Boot Select 1.32 - yet another boot menu program
Organization: TRW Financial Systems
Date: Thu, 30 Jul 1992 16:58:20 GMT

In article <Y4K52MP@mailgzrz.tu-berlin.de> wolfaajj@w250zrzzrz.tu-berlin.de (Thomas Wolfram) writes:
>
>OS Boot Select is a replacement of the ordinary master boot
>program. It provides a customizable boot menu and customizable
>timeout and the abiltity to automatically set the active partition
>before booting. This avoids boot problems with some UNIX
>systems (ISC). Unlike the OS/2 2.0 boot manager it only requires
>the 512 byte of the master boot sector (sector 0) and no
>seperate partition. The program knows a lot of partition ID's
>(also 386BSD and BSDI BSD/386) but there is no restriction for
>the boot menu since you could give the boot menu lines your
>own names.
>OS Boot Select comes with a installation program running
>under DOS with a simple desktop for easy installation. It also
>creates a backup of the old master boot sector.
>
Sounds great, but how about something that we non DOS people can use?
could you post a UUENCODED version? What is LHA?
It looks like uuencode, but uudecode won't touch it.

>
>-- Thomas
>
>
>This is a self-extracting LHA archiv for DOS.
>------------------------CUT HERE-----------------------------
>begin 640 os-bs132.exe
>M35J9 00    "   0___P_P !     ?#_'         #K>2  3$A!)W,@4T98


+----------------------------------+       ______ _  __
|   __--_|\  Julian Elischer       |       \     U \/ / On assignment
|  /       \ julian@tfs.com        +------>x   USA    \ in a very strange
| (   OZ    ) 2118 Milvia st. Berkeley CA. \___   ___ | country !
+- X_.---._/  USA+(510) 704-3137(wk)           \_/   \\            
          v

Newsgroups: comp.unix.bsd