Return to BSD News archive
From: burgess@cynjut.neonramp.com (Dave Burgess)
Newsgroups: comp.unix.bsd.netbsd.announce,comp.unix.bsd.freebsd.announce,comp.answers,news.answers,comp.unix.openbsd.announce
Subject: [comp.unix.bsd] NetBSD, FreeBSD, and OpenBSD FAQ (Part 7 of 10)
Supersedes: <386bsd-faq-7-866185203@cynjut.neonramp.com>
Followup-To: comp.unix.bsd.netbsd.misc
Date: 27 Jun 1997 02:00:22 -0500
Organization: Dave's House in Omaha
Lines: 575
Approved: news-answers-request@MIT.Edu,cgd@sun-lamp.cs.berkeley.edu
Expires: 07/15/97 02:00:03 CDT
Message-ID: <386bsd-faq-7-867394803@cynjut.neonramp.com>
References: <386bsd-faq-1-867394803@cynjut.neonramp.com>
Reply-To: burgess@cynjut.neonramp.com (BSD FAQ Maintainer)
NNTP-Posting-Host: cynjut.neonramp.com
Keywords: FAQ 386bsd NetBSD FreeBSD !Linux
X-Posting-Frequency: Posted on/about the 13th and the 27th of every month.
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.Hawaii.Edu!news.lava.net!news.pixi.com!news1.best.com!su-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!news-peer.sprintlink.net!news-pull.sprintlink.net!news-in-east.sprintlink.net!news.sprintlink.net!Sprint!204.248.20.3!neonramp.com!cynjut.neonramp.com!cynjut.neonramp.com!not-for-mail
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.netbsd.announce:467 comp.unix.bsd.freebsd.announce:607 comp.answers:24742 news.answers:17611
Posted-By: auto-faq 3.1.1.2
Archive-name: 386bsd-faq/part7
Section 6. (Interaction with MS-DOS)
6.0 Working with DOS and BNR/2 related software.
This section is designed to cover some of the more common
problems that DOS will have when interacting with BNR/2.
There are other sections of the FAQ that deal with
indirectly with this . Try looking in sections 0, 1, and 2
to see if something in there (particularly when talking
about DOS and *BSD coexisting on a single drive).
6.1 Formatting a floppy
Formatting a floppy under NetBSD is possible through the the patch
file stored at ftp://cynjut.neonramp.com/pub/fdformat.patch
This patch appears to be for NetBSD 1.2 (release). Obviously,
use it at your own risk.
FreeBSD (and I think OpenBSD) both have floppy formatting built
into their systems in fairly recent versions.
6.2 Sharing the Disk with MS-DOS
There are a myriad of questions about how to share a disk between
*BSD and MS-DOS. They all boils down to one of the <n> following
questions:
1) How can I partition my drive for both MS-DOS and *BSD?
2) I can install using the whole disk, but I can't install when
I try to share the drive between *BSD and MS-DOS. Why?
3) I can use either MS-DOS or *BSD on my hard drive,
but shutdown -todos doesn't seem to work.
6.2.1 How can I partition my drive to support both MS-DOS and *bsd?
NOTE: Before attempting to install *bsd on a computer with an
active DOS partition, ALWAYS back up your hard drive. No one on
the net, no matter how talented, can help you recover a hosed
MS-DOS file system. If you lose all of your data, it is YOUR
fault.
During the install phase, you need to have un-allocated space left
on your disk drive. This allows the install program to correctly
install the *bsd partition in the partition table and DOS to
peacefully co-exist with *bsd.
If you do not have any space available on your hard drive, you will
not be able to install both. Re-fdisk your hard drive and make
sure you have left un-allocated space in the partition table.
This WILL wipe out your DOS partition - Permanently.
Even though the partition table procedure above may have worked,
there are still no guarantees that your system will boot after
the install. This problem most often manifests itself as one of
the endless reboot problems. You would normally be able to boot
DOS from the hard disk, but not *bsd (once that partition is
marked as active).
Once the partition table has been correctly defined with both
DOS and *bsd, there can still be problem. One of the most
common is that the disk drive works in some sort of translation
mode. This is particularly common with drives that physically have
more than 1024 cylinders. DOS cannot access a drive with more than
1024 cylinders. Translation mode will have to be turned off, usually
by redefining your hard drive in SETUP as one of the user definable
types. This change will normally trash your hard drive, or at least
render your DOS partition unreadable.
The solution to this problem is to install *bsd at the end of the
hard drive. While DOS cannot use cylinders above 1024, *bsd has
no such limitations, once it has booted. During the boot-up phase,
some of the newer boot blocks will refer to the BIOS for some
services. Specifically, the disk is checked for a bad sector map
on the last track. Since the BIOS cannot deal with cylinders
higher than 1024, your bad sector map will be incorrectly
identified as 1023 if the number of cylinders is larger than that.
This problem is being worked on, and I hope to change this section
with better news later.
NOTE: The only people that this problem will effect are those
MFM and ESDI users that have drives with more than 1023 tracks.
While drives of this type are not the overwhelming majority,
neither are they an anomaly. People are working on it.
As an example, if your hard disk physically has 8 heads, 16 sectors
per track, and 2000 cylinders (128M); you MUST use some sort of disk
translation in order to use the entire drive. An obvious geometry
for this drive (for DOS) would be 16 heads, 16 sectors, and 1000
cylinders. Unfortunately, *bsd operates using the disk drives
native geometry as reported during the probe phase of boot up. This
will probably be 8/16/2000, and will NOT agree with your translated
disk geometry. This causes an endless reboot cycle. If you change
the geometry so that the drive agrees with the disklabel, your DOS
partition is toast.
The best way to operate in this case would be to (for example)
split the disk in half. That leaves 64M for DOS, using a
geometry of 8 heads, 16 sectors per track, and the first 1000
cylinders for DOS. The second 1000 cylinders could then safely
be used for *bsd. The DOS partition table may even be capable of
showing this partition as it actually exists.
ACCESSING MS-DOS PARTITIONS FROM NetBSD-i386
First off, it's important to understand BSD disklabels. The
disklabel is a description of the Unix partition layout and other
disk parameters stored on-disk, usually somewhere in the first
couple of sectors. There is a maximum of 8 partitions, labelled
"a" thru "h". Typically partition "a" is assigned to the root
partition, partition "b" is configured as a swap area, and
partition "c" is defined as the whole disk. You can change these,
but it's a good idea to stick with this scheme, as many programs
assume that's the way things are going to be.
If you're whole disk is dedicated to Unix, then that's all you
need to know. But if you're sharing your disk with DOS, then
there are a few magical things happening.
DOS has it's own partitioning scheme. The way NetBSD co-exists
with this is to fit all of the Unix partitions into one DOS
partition. So partitions a-h all fit inside one DOS partition,
which has a partition type of 165 (each MS-DOS partition has a
"partition type" associated with it. The BSD partition type is
165). In this setup, partition "c" refers to the entire BSD
partition. But in this scheme, partition "d" refers to the ENTIRE
disk, MS-DOS partitions and all.
So, if you want to access your MS-DOS partition from NetBSD, first
you'll have to create a partition that points to the MS-DOS
partition. You'll want to run the command:
disklabel -e -r /dev/r??0d (fill in with your disk type).
You'll get popped into an editor with all the disklabel stuff in
it. Go down to the bottom. You should see something like:
6 partitions:
# size offset fstype [fsize bsize cpg]
a: 30720 409600 4.2BSD 1024 8192 16 # (Cyl...
b: 129024 440320 swap # (Cyl...
c: 1617920 409600 unused 0 0 # (Cyl...
d: 2029568 0 unused 0 0 # (Cyl...
e: 61440 569344 4.2BSD 1024 8192 16 # (Cyl...
f: 1396736 630784 4.2BSD 1024 8192 16 # (Cyl...
(or whatever it appropriate for your disk). Note that partition
"a" starts on cylinder 200. That's where my BSD partition starts
on my disk. Also note that partition "c" starts at 200 as well
and goes to the end of the disk. You'll also note that partition
"d" goes from sector 0 all the way to the end of the disk.
Add a new line that looks something like:
g: 409568 32 MS-DOS # (Cyl. 0*- 199*)
(The comment on the end isn't necessary. Only the partition
letter, size, offset, and partition type are needed. You can
put unused in instead of MS-DOS if you want).
*NOTE* Be sure to change the line that says "6 partitions" to the
new number of partitions that you have!!! Otherwise you'll get an
obscure error. In my case I'd change that line to be "7 partitions".
If you aren't sure what your MS-DOS partition size and offsets are,
you can use the NetBSD fdisk to find them out. Don't forget that
there's a maximum of 8 partitions.
Once you do that and you have MSDOSFS configured into your kernel,
you can just do something like "mount -t msdos /dev/sd0g /msdos".
Or you can put a line like this in your fstab:
/dev/sd0g /msdos msdos rw 0 0
If you want to access a DOS-only HD from NetBSD, here are some
instructions posted by Charles Hannum a while back. I haven't
tried them myself, but they seem like they would work.
Assuming you don't have something (like OS-BS) which uses the extra
sectors in the boot track, you can do the following:
1) Use the NetBSD `fdisk' or DOS `pfdisk' to create a NetBSD
partition in the MBR which spans the entire disk.
2) Save a copy of the MBR:
dd if=/dev/rsd0d of=my-mbr bs=1b count=1
3) Use `disklabel' to create a NetBSD label with the DOS partition
and whatnot. Answer `y' when it asks you if you want to `overwrite
[a] disk with [a] DOS partition table'.
4) Put back the saved copy of the MBR:
dd if=my-mbr of=/dev/rsd0d bs=1b count=1
This works for me. Your mileage may vary.
Luke Mewburn <zak@rmit.edu.au> has provided the following tutorial on
using the pfdisk program and making your *bsd/NetBSD partitions
peacefully coexist with DOS. While this is kind of a 'cookbook'
approach, please keep in mind that this is probably easily
transferable to all BNR derived Unices.
6.2.2 I can install using the whole disk, but I can't install when
I try to share the drive between *BSD and MS-DOS. Why?
This is an extension of the question above. The most common
reason for this is, once again, disk translation problems. If
the disklabel does not agree with the disk geometry, the install
will fail. Other incarnations of this problem are that you can
install DOS, then *BSD, and DOS will be hosed, or vice versa.
There are more than a couple of people who will blithely suggest
that this is a good thing, and you should install *BSD exclusively,
job not withstanding.
6.2.4 Is there any hope of ever running MS-DOS applications under any of
the free BSD systems?
There is currently a project in development to port the Windows
program environment to Linux and the *BSD systems. Here is an
excerpt from the original message announcing the project:
As many of you already know, we are in the process of creating a
Windows emulator. This emulator is similar to Sun's Wabi product,
but is being developed completely independent of them. Many of
you are anxious to hear the latest status of the project. I have
created a mailing list for those of you. To join the list, simply
send mail to:
wine-project-info@amscons.com
If your mailing address is not easy to deduce from the mail
headers, then place the following line in the body of the message
that you send.
Reply-To: youraddress@yourmachine
where youraddress@yourmachine should be replaced by your actual
mailing address.
6.2.5 How do I get Linux executables to run under NetBSD?
First, you need to make certain your kernel has LINUX_COMPAT as
one of the options for your kernel. Second, you will need the
libraries for Linux. You can find the Linux supporting binaries
for NetBSD i386 at ftp://ftp.enigma.net/pub/netbsd_i386. There
are instructions there to tell you how to get the libraries
working correctly.
With VERY new versions of NetBSD (NetBSD 1.3A and above) the
kernel option for Linux compatibility have changed. All ELF and
COFF executables, as well as native Linux executables will be
included as part of the same option.
6.3 Accessing the MS-DOS filesystem
One of the most common MS-DOS related questions (with the possible
exception of 6.2 above) is how to access the DOS disk partitions
from *BSD.
--------------------------------------------------------------------
How to mount your DOS partition from FreeBSD
1. First, be root. The following won't work as an ordinary user.
2. Second, use 'fdisk' to see where your DOS partition starts.
It will be labeled as type DOS. On my system, 'fdisk /dev/sd0d'
produces the following:
... (extraneous output, not of interest) ...
The data for partition 0 is:
sysid 6,(Primary 'big' DOS (> 32MB))
start 32, size 306400 (149 Meg), flag 0
beg: cyl 0/ sector 1/ head 1;
end: cyl 149/ sector 32/ head 39
This shows me that my DOS partition starts at sector 32, and
is 306400 (512 byte) sectors long.
NOTE: If you're trying to mount a DOS `EXTENDED' partition, then
you need to add the number of sectors per track to this start
address you got from fdisk in subsequent calculations, I.E. in
the above example (assuming it was an EXTENDED partition rather
than the Primary), you'd use `start 64, size 306400'.
[Ed.Note. This example assumes a SCSI disk. For disks with a
number of sectors per track which is different than 32, you will
probably see the 32s above replaced with your number of sectors
per track. IDE, MFM, and ESDI drives are all examples where the
number of sectors per track is likely to NOT be 32.]
3. Next, using this information, you craft a new disk entry in your
/etc/disktab file that assigns one of your unused "UNIX"
partitions to this DOS region. Again, using my system as a
default, you see I've created:
disk0|DEC 5501:\
:ty=winchester:dt=SCSI:se#512:nt#8:ns#256:nc#1001:rm#3600:\
:pa#956416:oa#307200:ba#8192:fa#1024:ta=4.2BSD:\
:pb#131072:ob#1263616:tb=swap:\
:pc#1087488:oc#307200:tc=UNUSED:\
:pe#306400:oe#32:te=MSDOS:
As you can see, partition 'e' now points to the DOS partition as
pointed out by fdisk.
[Ed.Note again. Remember what I said about the 32 above...]
Also, there may be a problem with some versions of disklabel
not recognizing the MSDOS (or MS-DOS, depending) in the te:
entry above. You may need to run a "disklabel -e" to get the
partition type to 'stick'.
4. Now we have to actually stick the label on the disk, which is done
with disklabel. Using my example, this would be:
disklabel -r -w sd0 disk0 SCSI /usr/mdec/sdboot /usr/mdec/bootsd
5. Reboot your system to see the new disk label.
6. Mount the DOS partition. I do:
mount -t pcfs /dev/sd0e /dos_c
Where /dos_c is just a convenient directory to mount it.
7. You're set!
With the exception that the '-t' option is msdos in NetBSD, these
instructions seem to work with the same facility for NetBSD. I
also received a note a couple of weeks ago (that I promptly deleted
because I new that I would remember what it said) that DOS extended
partitions are readable if you skip the first 'n' blocks in your
computations (where 'n' is your number of sectors per track). This
way, you skip over the 'new' part of the DOS file system. That means
that instead of the oe:32 above, you would need an oe:48 instead.
Also remember that the compressed file system in DOS 6 will probably
be completely Greek to your NetBSD/FreeBSD system. I seriously
doubt that you will be able to read the compressed DOS file system
anytime in the foreseeable future.
6.4 NFS/PC-NFS support
The problems normally associated with PC-NFS are also associated
with NFS in general.
6.4.1 Can I use 8K packets for NFS? When I try, I have all kinds of
problems. Specifically, I get 'ring buffer overflows' or the
performance is real bad.
In addition to the NE2000 card, this problem can also manifest
itself on other ISA networks cards that have a limited amount of
memory. Ken Raeburn (raeburn@cambridge.cygnus.com) has identified
a common problem with the NE2000 card and provided us with a work
around:
--------------------------------------------------------------------
I reported previously that I was seeing problems reading files over
NFS using the NE2000 driver; timeouts would eventually be reported, no
data would be read. Listing files and directories (small ones
anyway) were not a problem.
In the meantime, mounting NFS file systems with "rsize=1024" does get
rid of this problem.
Ken
--------------------------------------------------------------------
As a matter of policy, specifying "rsize=1024,wsize=1024" works
very well also, and makes the transfers seem to run faster. This
is probably because there are fewer collisions. The disadvantage
of this method comes from the kernel 'sync'ing after all NFS
writes. This can slow NFS accesses considerably. As with most
generalizations, this one too can do nearly as much harm as good.
If you have trouble, reduce your default packet size until the
problem goes away.
With the newer drivers (especially the ed driver) most of these
problems are solved automagically. If you are still using the
original 386bsd 0.1 release, you REALLY need to upgrade.
See section 6.4.5 on 'ring buffer overflows' and the 3C503 for
more discussion on this problem.
6.4.2 How do I get around the NFS "Permission denied" error?
The problem is not the configuration of the server (unless there is
no real requirement to run it in "secure" mode, and you happen to
be running it that way anyway). The problem is the fact that,
even though mount request are sent on a privileged port, NFS
connections are not.
6.4.3 What does the message "BAD MNT RPC: RPC Authentication error;
why = Invalid client credential" mean when I try to mount something
from another machine?
Hellmuth Michaelis (hm@hcshh.hcs.de) offers the solution to this
relatively common problem:
You have to make sure that the user "root" is not present in more
than 8 entries in the "/etc/group" - file on the *BSD machine.
Simply remove some entries and the NFS mounts will succeed.
6.4.4 What does the message "Bad MNT RPC: RPC: Authentication error;
why = Client credential too weak" mean when I try to mount something
from another machine?
This problem is a standard NFS problem; it simply means that your
user number is not one of the ones that can mount this NFS.
Normally, you will get this message when you are trying to mount
a filesystem from a machine that allows 'root' to mount an NFS,
but limits other users.
Another documented problem with "client credentials being too
weak" is the dichotomy of SunOS and 4.4 based systems. SunOS,
and other commercial systems, do not allow NFS commands to come
in on anything but a reserved port. There are several places
that need to be addressed if weak credentials are a problem.
The first is the mount command. The mount itself may work, but
all references to files in the NFS will fail. This is usually
the most common symptom of this problem. The solution for this
is to either include the '-o resvport' keyword pair on the mount
command, or the -P option. In addition to the resvport command
on the mount, it may become important to include an NFS volume
in your fstab. If this is the case, you will need to ensure
that the resvport keyword is added on the mount line in the
fstab. Finally, if you are using the automounter, you will need
to make absolutely certain that you have included the resvport
option in your automount maps as the default.
6.4.5 I get a lot of 'ring buffer overflow' messages using NFS and the
ed0 driver. Is there a problem?
David Greenman (davidg@implode.rain.com), the original author of
the ed0 driver, provides us with some insight into the inner
workings of the ed0 driver.
It always surprises me that people don't just ask the original
author these questions. :-) Anyway, the reason these are happening
is that the access to the 8bit boards shared memory simply isn't
fast enough to deal with full wire speeds...but the driver tries
hard...so even though packets get dropped, your performance only
drops to about what the ethernet board is capable of (should be
in the 400-600k range with an 8bit card). NFS is especially bad
because the UDP window is quite large (40k last time I looked),
so the overflow condition can happen easily. I've explained this
for the most part in the release notes for the driver, but these
didn't make it into either the FreeBSD or NetBSD releases (we
couldn't find an appropriate place to put them).
>From the release notes:
receive
-------
The 8390 implements a shared memory ring-buffer to store
incoming packets. The 8bit boards (3c503, and 8003) usually have
only 8k bytes of shared memory. This is only enough room for about
4 full size (1500 byte) packets. This can sometimes be a problem,
especially on the original WD8003E and 3c503. This is because these
boards' shared memory access speed is also quite slow compared to
newer boards - typically only about 1MB/second. The additional
overhead of this slow memory access, and the fact that there is
only room for 4 full-sized packets means that the ring-buffer
will occasionally overflow. When this happens, the board must
be reset to avoid a lockup problem in early revision 8390's.
Resetting the board will cause all of the data in the ring-buffer
to be lost - requiring it to be re-transmitted/received...slowing
things even further. Because of these problems, maximum throughput
on boards of this type is only about 400-600k per second. The 16bit
boards (8013 series), however, have 16k of memory as well as much
faster memory access speed. Typical memory access speed on these
boards is about 4MB/second. These boards generally have no problems
keeping up with full ethernet speed. The only problem I've seen
with these boards is related to the (slow) performance of the
system's malloc code when additional mbufs must be added to the
pool. This can sometimes increase the total time to remove a
packet enough for a ring-buffer overflow to occur.
With NFS, the problem is really bad, though. The 3c503 does not
have enough memory on the card to support the default 8k packets
that NFS and other protocols use as their default. The solution
for folks that are having a problem with ring buffer overflows
in NFS is for them to either use the -r and -w flags to limit
the packet size or use the define "NFS_BOOT_RWSIZE=8192". If
NFS doesn't work with this defined, the code will automatically
step down to the next smaller increment. If you KNOW that you
will always be running a 3c503, you can set this define to 4096
instead, just to make sure. This should eliminate the bulk of
the ring buffer overflows in NFS.
6.4.6 I am getting really poor performance out of my network,
especially when talking to older networks or when performing
short file transfers. What's the problem?
Try turning off rfc1323 support:
sysctl w net.inet.tcp.rfc1323=0
only in newer builds. In older versions you have to edit a kernel
config file. RFC1323 is not yet supported by all networks, and
can cause TCP performance degradation when tried. This, for
example, is a known problem on older Sun and VAX hosted
networks, and on many networks which are using Linux as an
intermediate host.
6.4.7 Is there any PC software that will allow me to use my enormous PC
with all of the unsupported hardware as a PC-NFS server?
Yes. It is called SOSS, and is available from MANY FTP sources.
You will need the aforementioned Clarkson Packet Drivers for it
to work, but that shouldn't cause too many problems for most
people.
6.5 How can I use mtools with the 'new' floppy naming convention?
With the adoption of BSD 4.4, there is a new way of accessing
the floppy disk drive types. The method uses the minor device
number to specify different media sizes and densities. These
densities are established by a table from the file
/usr/src/sys/arch/i386/isa/fd.c in NetBSD (your mileage may
vary). The table in FreeBSD's fd.c is likely to be slightly
different.
The order of the entries defines the order of the minor
numbers, so the table below has the following characteristics:
/dev/fd0a 0 /* default disk type */
/dev/fd0b 1 /* 1.44MB diskette */
/dev/fd0c 2 /* 1.2 MB AT-diskettes */
/dev/fd0d 3 /* 360KB in 1.2MB drive */
/dev/fd0e 4 /* 360KB PC diskettes */
/dev/fd0f 5 /* 3.5" 720KB diskette */
/dev/fd0g 6 /* 720KB in 1.2MB drive */
/dev/fd0h 7 /* 360KB in 720KB drive */
struct fd_type fd_types[] = {
{ 18,2,0xff,0xcf,0x1b,0x6c,80,2880,1,FDC_500KBPS,2,"1.44MB" },
{ 15,2,0xff,0xdf,0x1b,0x54,80,2400,1,FDC_500KBPS,2,"1.2MB" },
{ 9,2,0xff,0xdf,0x23,0x50,40, 720,2,FDC_300KBPS,2,"360KB/AT"},
{ 9,2,0xff,0xdf,0x2a,0x50,40, 720,1,FDC_250KBPS,2,"360KB/PC"},
{ 9,2,0xff,0xdf,0x2a,0x50,80,1440,1,FDC_250KBPS,2,"720KB" },
{ 9,2,0xff,0xdf,0x23,0x50,80,1440,1,FDC_300KBPS,2,"720KB/x" },
{ 9,2,0xff,0xdf,0x2a,0x50,40, 720,2,FDC_250KBPS,2,"360KB/x" },
};
In order to add a new device (such as a 2.44 Meg floppy) new
tables entries are theoretically all that would be needed. As
new entries are created, the minor device numbers would
increase and the associated device names would be added.
--
Dave Burgess Network Engineer - Nebraska On-Ramp, Inc.
*bsd FAQ Maintainer / SysAdmin for the NetBSD system in my spare bedroom
"Just because something is stupid doesn't mean there isn't someone that
doesn't want to do it...."