|
|
NetBSD 문서:기타 FAQ 및 HOWTO |
이것은 C-셸 csh(1)과 그 파생 프로그램인 tcsh에만 해당됩니다. sh(1)와 파생 프로그램(bash2 같은)의 경우 올바른 문장은 다음과 같습니다:
주의사항: 아직 일부 메시지만 번역이 되어 있는 상태입니다. 시험하려면 LANG 변수를 설정하고 'cd /존재하지않는디렉터리' 명령을 내려보기 바랍니다.
groff -Tps -mandoc /usr/share/man/manX/manpage.XFor example to convert the ls(1) manpage into PostScript and send it directly to the default printer via lpr(1) you can use.
groff -Tps -mandoc /usr/share/man/man1/ls.1 |lprIf you wish to print on a different type of printer you may want to use the ghostscript package from pkgsrc.
hp690c:\
:hn:\
:ht=ether:\
:ip=192.168.0.10:\ <-- set to the desired IP of the JetDirect
:ha=00.60.b0.1d.04.d5:\ <-- Set to the MAC address of the JetDirect
:sm=255.255.255.0:\ <-- set to the desired netmask of the JetDirect
:sa=192.168.0.5:\ <-- set to the tftp server address (same machine
thats running TFTPD)
:gw=192.168.0.1:\ <-- set to your gateway address
:lg=192.168.0.5:\ <-- set to the log server address
:T144="hpnp/hp690c.cfg":\ <-- name of the JetDirect config file
:vm=rfc1048:
See bootptab(5) for more information on this file.
Make sure that tftpd and bootp are enabled in /etc/inetd.conf.
Note the argument to "-s" on the tftp line of /etc/inetd.conf. This is
the tftpd(8) root directory. For the rest of this example it is assumed that
the tftpd(8) root directory is set to /tftpboot.
Next create a Network Printer Inferface (NPI) configuration file. In this example, the file
is /tftpboot/hpnp/hp690c.cfg. This file should look something like:
name: printer name location: Location of the Printer contact: Contact Person idle-timeout: 1800 banner: 0If you made changed to /etc/inetd.conf, make sure inetd(8) re-reads inetd.conf(5) by doing kill -HUP `cat /var/run/inetd.pid`. When you reboot the JetDirect print server (or printer with HP JetDirect card), the server should get configured by BOOTP. On some printers, you may have to explicitly enable BOOTP configuration from the front panel.
Note: in versions of NetBSD before 1.4.2 the in kernel ss(4) scanner driver may cause problems with sane-backends and some scanners - the solution is either to recompile a kernel without ss(4) and use the uk(4) device, or to upgrade to 1.4.2 or later.
To use an common 1440 KB floppy in the first floppy drive, first (as root) format it:
fdformat -f /dev/rfd0aThen create a single partition on the disk using disklabel(8):
disklabel -rw /dev/rfd0a floppy3Creating a small filesystem optimized for space:
newfs -m 0 -o space -i 16384 -c 80 /dev/rfd0aNow the floppy disk can be mounted like any other disk.
mount -t msdos /dev/fd0a /mnt
However, rather than using floppies like normal (bigger) disks, it is often more convenient to bypass the filesystem altogether and just splat an archive of files directly to the raw device. E.g.:
tar cvfz /dev/rfd0a file1 file2 ...A variation of this can also be done with MS-DOS floppies using the mtools package which has the benefit of not going through the kernel buffer cache and thus not being exposed to the danger of the floppy being removed while a filesystem is mounted on it.
yui# dmesg | grep -i zip sd0 at atapibus0 drive 1: <IOMEGA ZIP 100 ATAPI, , 14.A> type 0 direct removableSeems it has one, and it's recognized as sd0, just like any SCSI disk. The fact that the ZIP here is an ATAPI one doesn't matter - a SCSI ZIP will show up here, too. The ZIP is marked as "removable", which means you can eject it with "eject sd0".
yui# disklabel sd0 # /dev/rsd0d: type: ATAPI ... 8 partitions: # size offset fstype [fsize bsize cpg] d: 196608 0 unused 0 0 # (Cyl. 0 - 95) h: 196576 32 MSDOS # (Cyl. 0*- 95) disklabel: boot block size 0 disklabel: super block size 0
yui# mount -t msdos /dev/sd0h /mnt yui#
yui# ls -la /mnt total 40809 drwxr-xr-x 1 root wheel 16384 Dec 31 1979 . drwxr-xr-x 28 root wheel 1024 Aug 2 22:06 .. -rwxr-xr-x 1 root wheel 1474560 Feb 23 1999 boot1.fs -rwxr-xr-x 1 root wheel 1474560 Feb 23 1999 boot2.fs -rwxr-xr-x 1 root wheel 548864 Feb 23 1999 boot3.fs -rwxr-xr-x 1 root wheel 38271173 Feb 23 1999 netbsd19990223.tar.gz
yui# umount /mnt yui#
yui# eject sd0 yui#
CD devices are named /dev/cd0a for both SCSI and IDE (ATAPI).
With this information, we can start:
# dmesg | grep ^cd
cd0 at atapibus0 drive 0: <CD-R/RW RW8040A, , 1.12> type 5 cdrom removable
cd0: 32-bit data port
cd0: drive supports PIO mode 4, DMA mode 0
cd0(pciide0:1:0): using PIO mode 0, DMA mode 0 (using DMA data transfers)
We have one drive here, "cd0". It's an IDE/ATAPI drive, as it's found
on atapibus0. Of course the drive (or better, it's medium) is
removable, i.e. you can eject it, see below.
# mount -t cd9660 /dev/cd0a /mnt
#
This command shouldn't print anything. It instructs the system to
mount the CD found on /dev/cd0a on /mnt, using the "cd9660"
filesystem. The mountpoint "/mnt" must be an existing directory.
# ls /mnt
INSTALL.html INSTALL.ps TRANS.TBL boot.catalog
INSTALL.more INSTALL.txt binary installation
#
Everything looks fine! This is a NetBSD CD, of course. :)
# umount /mnt
#
If the CD is still accessed (e.g. some other shell's still "cd"'d
into it), this will not work. If you shut down the system, the CD
will be unmounted automatically for you, there's nothing to worry
about there.
If you don't want to type the full "mount" command each time, you can put most of the values into a line in /etc/fstab:
# Device mountpoint filesystem mount options
/dev/cd0a /cdrom cd9660 rw,noauto
Make sure that the moutpoint - "/cdrom" in our example exists:
# mkdir /cdrom
#
Now you can mount the cd with the following command:
# mount /cdrom
#
Access and unmount as before.
The CD is not mounted at boot time due to the "noauto" mount option - this is useful as you'll probably not have a CD in the drive all the time. See mount(8) and mount_cd9660(8) for some other useful options.
# eject cd0
#
If the CD is still mounted, it will be unmounted if possible,
before being ejected.
Note: The user must own the mount point! So, for example:
cd
mkdir cdrom
This usually works well on both SCSI and IDE (ATAPI) CDROMs, CDRW and DVD drives.
# cdd -t 2 `pwd`
This will put a file called track-02.cda in the current directory.
# tosha -d CD-ROM-device -t 2 -o track-02.cda
$ cdparanoia -g /dev/rcd0d 2 track-02.wav
If you want to grab all files from a CD, cdparanoia's batch mode is useful:
$ cdparanoia -g /dev/rcd0d -B
# dd if=/dev/rcd0a of=filename.iso bs=2k
#
Alternatively, you can create a new ISO image yourself:
Put all the data you want to put on CD into one directory. Next you need to generate a disk-like ISO image of your data. The image stores the data in the same form as they're later put on CD, using the ISO 9660 format. The basic ISO9660 format only understands 8+3 filenames (max. eight letters for filename, plus three more for an extension). As this is not practical for Unix filenames, a so-called "Rockridge Extension" needs to be employed to get longer filenames. (A different set of such extension exists in the Microsoft world, to get their long filenames right; that's what's known as Joliet filesystem).
The ISO image is created using the mkisofs command, which is part of the cdrecord package.
Example: if you have your data in /usr/tmp/data, you can generate a ISO image file in /usr/tmp/data.iso with the following command:
$ cd /usr/tmp
$ mkisofs -o data.iso -r data
Using NETBS000.GZ;1 for data/binary/kernel/netbsd.INSTALL.gz (netbsd.INSTALL_TINY.gz)
Using NETBS001.GZ;1 for data/binary/kernel/netbsd.GENERIC.gz (netbsd.GENERIC_TINY.gz)
5.92% done, estimate finish Wed Sep 13 21:28:11 2000
11.83% done, estimate finish Wed Sep 13 21:28:03 2000
17.74% done, estimate finish Wed Sep 13 21:28:00 2000
23.64% done, estimate finish Wed Sep 13 21:28:03 2000
...
88.64% done, estimate finish Wed Sep 13 21:27:55 2000
94.53% done, estimate finish Wed Sep 13 21:27:55 2000
Total translation table size: 0
Total rockridge attributes bytes: 5395
Total directory bytes: 16384
Path table size(bytes): 110
Max brk space used 153c4
84625 extents written (165 Mb)
$
Please see the mkisofs(8) manpage for other options like noting
publisher and preparer. The Bootable CD ROM How-To explains how to
generate a bootable CD.
When you have the ISO image file, you just need to write it on a CD. This is done with the "cdrecord" command from the cdrecord package. Insert a blank CD-R, and off we go:
# cdrecord -v dev=/dev/rcd0d data.iso
...
#
After starting the command, 'cdrecord' shows you a lot of
information about your drive, the disk and the image you're about
to write. It then does a 10 seconds countdown, which is your last
chance to stop things - type ^C if you want to abort.
If you don't abort, the process will write the whole image to the
CD and return with a shell prompt.
Note that cdrecord(8) works on both SCSI and IDE (ATAPI) drives.
Mount the just-written CD and test it as you would do with any "normal" CD, see above.
The steps involved are:
# cdrecord -v dev=/dev/rcd0d -audio -pad *.wav
The steps involved here are:
$ mpg123 -w foo.wav foo.mp3Do this for all of the mp3 files that you want to have on your audio CD. The .wav filenames you use don't matter.
# cdrecord dev=/dev/rcd1d /dev/rcd0dHere the CD-ROM (cd0) contains the CD you want to copy, and the CD-R (cd1) contains the blank disk. Note that this only works with computer disks that contain some sort of data, it does not work with audio CDs! In practice you'll also want to add something like "speed=8" to make things a bit faster.
If you want to blank a CD-RW, you can do this with cdrecord's "blank" option:
# cdrecord dev=/dev/rcd0d blank=fastThere are several other ways to blank the CD-RW, call cdrecord(8) with "blank=help" for a list. See the cdrecord(8) manpage for more information.
DVDs, DivX and many avi files be played with ogle or gmplayer.
A relatively up-to-date list of all changes (including those in -current) is available.
There is also a CHANGES file in the top level directory of each release.
On other 64 bit capable CPUs, such as R4000 and newer MIPS (used by a number of ports) NetBSD runs in 32 bit mode though is in the process of being modified to 64 bit.
All NetBSD ports support 64 bit arithmetic, both in the kernel and in userland programs. In the kernel this is used for various counters and for FFS, which is the 64 bit 'Fast File System'.
See our features page for an idea of what opportunities NetBSD provides you with!NetBSD, in general, is meant as a "stable research platform" -- that is, a system that can be used for commercial, home, and research work... what _you_ do with it is up to you. In general, those of us working on NetBSD are trying to improve the system in whatever way we can -- support for more hardware, stability, performance, documentation...
% ls -ld /var/mail drwxrwxrwt 2 root wheel 512 Nov 6 08:21 /var/mailIf they are not, as root run 'chmod 1777 /var/mail'.
In the second case, dynamically linked binaries can usually be fixed by upgrading libkvm to match your new kernel. Statically linked binaries need to be replaced with more recent versions. Since they are statically linked, if you are going to recompile them yourself, you need to rebuild libkvm.a before you rebuild the program in question.
Thanks to John Wittkowski (jpw@netscape.com), here is a list of most of the programs (besides /bin/ps) that depend on libkvm (all of these are in /usr/bin):
If you get the "proc size mismatch" error and you determine
that you need to update your libs, here's what to do:
1. Get all the source code. If you're not willing to do this
and recompile things than you'll have to find someone who
will do it for you and you can try installing everything
by hand.
2. Make sure that your include files are up to date. Do
this by:
cd /usr/src
make includes
This will take a while. I had some trouble with this
because some of the Makefiles didn't have the INSTALL
variable defined. Whenever the "make includes" failed,
I went to the last directory listed and added the
following line to the Makefile:
INSTALL=/usr/bin/install
I had to do this several times before the make finished
without any errors.
(If you make sure that /usr/bin/make and all the files in
/usr/share/mk are up to date first, the above difficulties
can probably be avoided)
3. Rebuild the libkvm and install it:
cd /usr/src/lib/libkvm
make
make install
Note that in order to get the libkvm to compile on
my system I had to add the following link:
cd /usr/include/machine
ln -s ../m68k/kcore.h kcore.h
This may have been a quirk of my system so try
compiling without it first.
4. Then rebuild the binaries that are STATICALLY linked to
libkvm. The only statically linked program that I am
aware of is "/bin/ps". To rebuild ps, simply:
cd /usr/src/bin/ps
make
make install
5. You may or may not need to rebuild the binaries that
are dynamically linked to libkvm. This is because (I
think) if the major version number of the lib changes
then the old binaries will expect the old version
number and not work with the newer version of the lib.
For example, my old libkvm was libkvm.so.4.0. The new
one was libkvm.so.5.0. Without recompiling the
dynamically linked binaries, it would still complain
about "proc size mismatch" (if the 4.0 lib was still
there) or some lib missing error (if the 4.0 lib
had been removed from /usr/lib). If the version minor
number changes (4.0 to 4.1, for example), I think it
will run with a warning and so you may not need to
recompile all of these things.
The dynamically linked binaries that I am aware of
will give the "proc size mismatch" error (if the 4.0
lib was still there) or some lib missing error (if the
4.0 lib had been removed from /usr/lib). If the version
minor number changes (4.0 to 4.1, for example), I think
it will run with a warning, and you may not need to
recompile all of these things.
The dynamically linked binaries that I am aware of
are:
/usr/bin/fstat
/usr/bin/gdb
/usr/bin/ipcs
/usr/bin/netstat
/usr/bin/nfsstat
/usr/bin/systat
/usr/bin/uptime (linked to /usr/bin/w)
/usr/bin/vmstat
/usr/bin/w
Note that /usr/bin/uptime is a link to /usr/bin/w and
will be set up properly when you do the "make install"
for w.
To recompile these, do the following:
cd /usr/src/usr.bin/<cmd>
make
make install
For example, to recompile /usr/bin/vmstat:
cd /usr/src/usr.bin/vmstat
make
make install
A little background: the reason that these system utilities need to grovel through kernel memory to get information, including going through all the trouble mentioned above, is that this method also works on kernel crash dumps, which can be quite a useful feature when debugging kernels.
If you must log in as root, then you can edit your /etc/syslog.conf file and remove the necessary facilities to prevent the annoying messages. In most cases, it's sufficient to disable auth.debug in the line reading:
*.notice;auth.debug rootThis will eliminate those annoying portmap [pid]: connect from some.other.host ... messages. Be sure to kill -HUP the pid of your syslogd process.
You may also wish to look at the FAQ entry for using an xconsole.
There are a large number of editors available under the editors category in pkgsrc, including:
partition> e
Filesystem type [?] [unused]: 4.2BSD
Start offset [0c, 0s, 0M]:
Partition size ('$' for all remaining) [0c, 0s, 0M]: $
e: 234375000 0 4.2BSD 0 0 0 # (Cyl. 0 - 232514*)
partition> W
Label disk [n]? y
partition> Q
Inside disklabel -i you can use '?' for additional help.
To use it, do the following:
/dev/wd0e /usr ffs rw 1 2to:
/dev/wd0e /usr ffs rw,softdep 1 2
Paul Vixie has run a benchmark on storing and retrieving (in random order) 75.000 files into a directory, on both a system with and without softdep. The results show that file access time for both creating and locating files in large directories are generally better on systems with soft dependencies. (The softdep system in this case was FreeBSD 4.2, the non-softdep system was BSD/OS 3.1. Similar behaviour will be visible on a NetBSD system with and without softdep).
With softdeps running, you've got almost the same guarantee. With softdeps, you have the guarantee that you will get a consistent snapshot of the file system as it was at some particular point in time before the crash. So you don't know, as you did without softdeps, that, for example, if you did an atomic operation such as a rename of a lock file, the lock file will actually be there; but you do know that the directory it was in won't be trashed and you do know that ordering dependencies between that atomic operation and future atomic operations will have been preserved, so if you are depending on atomic operations to control, say, some database-like process (e.g. writing mail spool files in batches, gathering data from a transaction system, etc.) you can safely start back up where you appear to have left off.
NetBSD's ext2fs implementation gives you the traditional FFS guarantee about metadata (unlike the Linux implementation), so you can actually use it with more confidence than you can use the native ext2fs in Linux. The downside is that it's a bit slower, but that's because it actually does the right thing if the system crashes, instead of potentially eating your file system itself.
Under NetBSD there are three primary uses for swap space:
swap /tmp mfs rw,-s=SIZE 0 0where SIZE is in 512byte blocks. The space required is taken from the swap space as the filesystem is used.
The 'correct' value for swap is dependent on the usage of the system, but for some general rules:
There are three ways to add swap to a configured system:
/dev/DISKb none swap sw 0 0to your /etc/fstab file to automatically enable on boot. (Where DISK is the disk name such as 'sd1' or 'wd2').
To add 10 MBytes of swap space is as easy as selecting a filesystem with sufficient free space and:
# dd if=/dev/zero bs=1m count=10 of=/somefilesystem/swap # chmod 600 /somefilesystem/swap # swapctl -a -p 1 /somefilesystem/swapThe `dd(1)' command creates a 10 MByte file `/somefilesystem/swap'. This swap file needs to be chmod(1) 600 so that unprivileged users may not read its contents (swapctl(8) will reject world readable files). Then `swapctl(8)' command adds /somefilesystem/swap to the system swap space at priority 1. Priority 0 is the (default) highest priority, and since swapping to files is slightly slower we only want the system to use the file when conventional swap has all been used.
To make swapping to that file permanent and enable it on every reboot, put something like the following into /etc/fstab:
/somefilesystem/swap none swap sw,priority=1 0 0
- mkdir /newdev
- cd /newdev
- cp /dev/M* .
- sh MAKEDEV all
- cd /
- mv dev olddev; mv newdev dev
- rm -r olddev
There two different types of UPS interfaces, sometimes both are available on the same UPS. The 9-pin connector on the UPS is never a wired up as a normal PC-style rs-232. At best its a three-wire rs-232 interface, with the pins rearranged just to keep things interesting. At worst its a contact closure signal that is not even at the rs-232 signaling voltages and one must use a funny cable with level-translators in it to convert the voltages to something the rs-232 port can even see transitions on. The signal from the latter type of interface can only send out a one-bit (normal / powerfail) signal. It must be run into some modem-control line such as DCD and is then detected via a program that checks the status of that modem control line. Unless one is careful, its possible to confuse the modem-control-line-only cable that come with some UPS's as a real rs-232 cable.
Poking around APC web page, and a few promising altavista hits revealed that they have 3 basic interfaces. Low end UPS's ("back UPS") have only the modem-control line type interface. The two high end lines ("Back UPS Pro", "Smart UPS") have both combination modem control line and 3-wire rs-232 signals available. In both cases one needs to use one of two special cables. The cable for the modem control line interface has transistors and diodes in it to do the level shifting (and power grabbing from some of the other wires). It's a real kludge, with the word UGLY coming to mind as the correct modifier. The second type of cable will get the UPS talking serially, but some of the 3-rd party docs indicated that the UPS will only talk if you send 2 stop bits. The protocols don't appear to be officially documented and the back-UPS pro and smart UPS appear to talk different serial line protocols. Only the back-UPS pro line appears to have any 3-rd party support, and many of the details of the protocol are only guessed at.
Competitors all seem to have similar offerings (modem control line only, and proprietary serial line protocols with special cables). In no case could I find someone with an openly documented standard.
Once booted single-user you may find some of the following commands useful:
The system will boot up to multi-user mode, starting all kind of services, etc. Note that disks are not checked when going from single-user to multi-user mode!
However, the best way to do this is to go into multi-user mode by exiting from your single-user shell. This will mount all of the filesystems in /etc/fstab in whatever mode they are listed.
If you do make any changes to the filesystem using fsck, it is probably best to type 'reboot -n' to reboot the machine immediately without syncing the disks.
This is normally used by creating a '/proc' directory as root, then
adding the following to /etc/fstab (see fstab(5)):
/proc /proc procfs rw 0 0
The basic steps in creating an MPEG layer 3 (MP3) file from an audio CD (using software from the NetBSD packages collection) are:
This will convert track-02.cda in raw CD format to track-02.wav in WAV format, using signed 16-bit words with 2 channels at a sampling rate of 44100kHz.
This will encode track-02.wav into track-02.mp3 in MP3 format, using a bit rate if 128kBit/sec. The documentation for bladeenc describes bit-rates in more detail.
You may wish to use a lower quality, depending on your taste and hardware.
The resultant MP3 file can be played with any of the maplay, mpg123, or splay packages.
See the ccd(4) and ccdconfig(8) manpages for more information.
|
|
