|
|
| May 2000 | Get BSD | New to BSD? | Search BSD | Submit News | FAQ | Contact Us | Join Us |
|
When it rains, it pours...
Many of you wrote in to point out my gaffe on last time's shutdown script question, as well as to flesh out other answers from last time and to answer a couple of the mailbag items. Also, we have some intriguing essay questions this month.
And The land of weird hardware returns!
I've got an /etc/rc.shutdown script here that works great, but you
said in your last column that no scripts were run during system shutdown.
Mysterious cc1 coredumps have not gone away! any other ideas?
Sharing disks with Windows: here's another option.
Mounting ISO9660 image files on FreeBSD, what's the scoop?
Printing to NT printers from BSD: any other ways?
Would you please explain that bit from your last column about "charging down" machines?
Can you point me to a "UNIX and Network Firewalls for Dummies" web site?
Why does BSD report fragmentation on the disks even after a fresh install?
I want to pretend I have another IP address,
so I can use my work machines from home.
I want to use amd which is already installed; how do I turn it on?
How can I share a Linux tape drive with a FreeBSD machine?
Why are BSD's more sensitive to overclocking than Linux?
Why is FreeBSD so awesome, I mean, why do I love it so much?
What's the latest news from the Land of Weird Hardware?
This month's mailbag has a cloud on one side, a flower on the other,
and a cute embroidered rainbow running around one end to connect them.
A:
Yeah, looks like I flat out goofed that one.
I've never needed to customize this on my systems, so I hadn't ever looked
before I saw that question.
I recall checking some man pages, but must have missed it somehow.
As I've now learned, the implementation varies quite a bit between the BSDs. Depending on your distribution, /etc/rc.shutdown will be run (if it exists) at some point in the shutdown/reboot/halt sequences, and you may have support for /etc/rc.shutdown.local too.
# grep -l rc.shutdown /etc/*This is the simplest way to get started finding your way around, and it's a generally useful technique. :)
Q:
Mysterious cc1 coredumps have not gone away! any other ideas?
A reader writes in:
A:
Another possible cause is that your L2 cache chip(s) are going bad.
To test for this, try compiling problem programs
(e.g. eval.c from guile)
both with and without external cache enabled in the BIOS.
Q:
Sharing disks with Windows: here's another option.
A reader writes in:
A:
I have done this successfully with the
NetBSD rumba package.
With this package installed, mounting Win95 disks is as easy as:
rumba //theothercomputer/theotherdisk /mnt
Q:
Mounting ISO9660 image files on FreeBSD - what's the scoop?
Numerous readers wrote in:
A:
FreeBSD vnconfig supplies a default geometry which is acceptable
to the cd9660 filesystem code, so the following "just works":
# vnconfig -c /dev/vn0 /mnt/image.iso # mount -t cd9660 /dev/vn0 /disk/cdrom ... use files in /disk/cdrom ... # umount /disk/cdrom # vnconfig -u /dev/vn0
Q:
Printing to NT printers from BSD - any other ways?
A:
A reader writes in:
I saw your answer in Answer Man regarding printing on NT servers from BSD. I have actually found that using NT's built-in lpd service, it is really easy to share an NT printer without having to install any Samba stuff, and just use BSD's native lpr commands.
A:
It has to do with the actual construction of semiconductors,
and the fact that designs are getting so huge and complicated that nobody
can really test them as completely as they probably need to be tested.
People have been accusing software of this for a long time,
but it happens with hardware too.
Certain types of design mistakes (or even aggressive design practices) in on-chip circuits can result in the accidental creation of things that behave like memory even though they're not supposed to. Like memory, these can get turned on in a stable way, either by software mistake or by running for a time while overclocked, or perhaps by plugging something into the back of the machine very incorrectly.
Since these unintended memory cells are not supposed to be there in the first place, there is nothing in the design to see that they get cleared on a reset, and if the conditions that set them are rare enough, normal product testing will never reveal their existence. They can even be caused by a marginal manufacturing run, in which case only a small group of units are actually vulnerable, and the chance of early discovery is even lower.
A simple example is two large wires that run over each other. These create a small capacitor, because that's what physics has found to be true of any conductors in close proximity to each other. Usually its capacitance is so small that the other circuits connected to it will swamp it out, and it won't have any effect. But if those circuits are marginal, or noise sensitive, then a good charge on that accidental capacitor will have an effect, which can snowball through the design until something observable happens.
When one of these things gets wedged, the hardware mysteriously begins to behave differently. I have personally observed a PC parallel port that didn't want to transmit data for days (windows gave some obscure error), and a VME single-board computer (since discontinued) that refused to run downloaded test programs for hours, and my weird file server freezing problem that plagued me for a month, all of which required a "charge down" to ultimately fix them. In all of these cases, regular flip-flip power cycles were insufficient, but the hardware recovered immediately after a long "charge down" procedure.
Why are these things so tenacious? Depending on their proximity to outside power sources, wedged memory cells may be able to maintain themselves as long as outside power reaches them, also due to how modern semiconductors work. Nearly all silicon-based integrated circuits are in some ways just a huge beach of electrical tidal pools that are all connected to the main silicon crystal (a big resistor) by diodes. Fortunately these diodes all point in the same direction, so if outside power is applied, every single diode becomes reverse-biased and won't let any current through. This keeps the individual circuits on the chip electrically isolated while something is running.
By unplugging everything from the PC that has its own power source (AC line cord, monitor, network, etc.) you remove all possible routes for fresh power to enter the machine and keep the "tidal pools" isolated from each other. This allows the power in the 'wedged' things to drain away, and eventually they will un-wedge themselves. When I suspect this kind of wedging, I check for it by powering off and waiting at least a minute; when I'm really paranoid, I leave something off for ten minutes or even overnight.
But what about clock chips that have their own internal battery? This is in principle a serious problem, but in practice it's not. Most clock chips are good at keeping their backup power from leaking out into the motherboard, to help them last in long-term storage. You're far more likely to have problems with stored settings getting corrupted than with the clock battery powering something on the motherboard and enabling it to stay wedged.
A:
It's being worked on.
We'd all like to have better documentation sooner,
but relatively few people step up to the plate to actually write it.
A NetBSD/mac68k user posted some tips in late March. A quick AltaVista search turned up a web site dedicated to FreeBSD tutorials, one of which covers firewalls.
I'm sure there are more; search engines are your friends.
Q:
Why does BSD report fragmentation on the disks even after a fresh install?
A:
Because fragmentation doesn't mean the same thing on BSD as it does on DOS.
BSD filesystems don't worry about making every file completely contiguous. Instead, they require that large files be allocated into medium sized (usually 16 or 8 sector) contiguous runs (aligned on their size) and try to keep them reasonably close to each other on the disk. These medium sized runs are the "block size" reported by disklabel and other filesystem commands.
Data for small files, and the last few sectors from the ends of large files, are combined together so that they fill up these contiguous runs also. When files grow, sectors will be moved around to allow more contiguous runs to be filled. This algorithm effectively self-defragments the filesystem during normal operation. It operates very well over a wide range of activity loads and is generally only foiled when the disk becomes almost totally full.
Depending on the exact mixture of file sizes on the disk, it won't always be possible to completely pack everything. And on disks that are not very full, space is typically pre-reserved for large files to grow into, rather than actually using it to store small files. (These pre-reservations get revoked when the disk starts to really fill up, of course.)
Because of all this, it is typical for a BSD filesystem to contain contiguous runs that are only partly full, and some portion of the free disk space is going to be located inside these. Fragmentation on BSD simply means this portion of the free disk space.
If your disks report fragmentation of 10% or less, ignore it.
A:
Sorry, but the ways you might try to do this won't actually work.
Nearly all home-to-work setups use proper IP routing, and the routers know who is on each side of the connection by looking at the IP address. Even if you did pretend to be another IP address (and you can), the return packets would go wherever the router thinks that machine is, and not to you.
In the case where your home machine is "transparently" on the office network, using the IP address of another live machine is dangerous because it can seriously confuse some programs and OSes, and cause other trouble that will make you regret trying.
At my day job we regularly work on borrowed pre-release hardware that needs to be added to the network. Whenever someone misprograms an IP address to cause a conflict, we see all kinds of weird behavior, and people send around emails asking for whoever is using IP address x.x.x.x to please stop it.
My personal take on IP spoofing is that it is only useful to criminals. For legitimate purposes, it tends to cause more problems than it solves.
Q:
I want to use amd which is already installed; how do I turn it on?
A:
Edit /etc/rc.conf.
Find the line that starts with:
amd=NOChange the NO to a YES. The next time you boot, amd will be started automatically.
You also need to create an /etc/amd.conf file. Your system should have at least one of /usr/share/examples/amd and /etc/amd.map, which you can look in for sample configurations.
A:
Check out
GNU cpio
and
rmt.
As for tar options, it's the same GNU tar you're used to on Linux. I generally use
# tar czf tarfile directoryto back things up, and
# tar xzpf tarfile directoryto restore. (Also use the B flag if you're piping into tar from somewhere.)
Q:
As a somewhat long-term user of Linux I am intrigued by 'REAL' UNIXes and in
talking with our office FreeBSD guru (you can tell he is, he hates the title),
it seems that BSDs don't suffer overclocking well.
Aside from the much over-publicized religious fight,
why is UNIX so intolerant of CPU and motherboard timings?
I solved my personal overclocking issue by getting an inexpensive
ABIT BP-6 dual 500 Mhz Celeron system
(not the fastest, but far more interesting).
Why are BSDs more sensitive to overclocking than Linux?
A:
The short answer is that (for better or for worse) UNIX expects people to
fix hardware when it isn't working right.
UNIX was originally designed and run on expensive high-quality hardware,
whereas PC operating systems were all born into a universe of hardware chaos.
The only time overclocking is safe is when the CPU was deliberately sold at a lower speed rating than the one for which it was manufactured and tested. Otherwise, overclocking runs the CPU at speeds that either were never tested, or were tested and failed.
Since the CPU failed a test (or might have failed it had the test been run), some operation or combination of operations on the chip is going to screw up. The stuff that fails first is often the most complicated, and thus happens less frequently. As you crank the speed up, simpler and simpler operations become unreliable, until finally the chip can't do anything without crashing itself.
But in the huge gray zone between the rated speed and the red line, your CPU is silently flipping bits a few times a minute. Sooner or later one or more of those flipped bits will cause trouble.
Getting back to your original question: UNIX is more sensitive to hardware errors because it freely uses sophisticated algorithms that trust the hardware to remember a lot of data correctly. This includes common performance boosters like managing smart hardware (like network and disk DMA engines) to offload tasks from the main CPU as much as possible.
When the hardware misbehaves, kernel assertions attempt to detect and diagnose the problem without causing undue drags on system performance. When corruption is found, the system is usually panic'd on the assumption that things will only go downhill from there. Severe corruption is far harder to debug than a clean crash.
IMHO overclocking is great for systems that don't need to be backed up. A dedicated game machine, for example. Otherwise, overclocking is a daily lottery of instability which is not worth the long-term headache.
Q:
Why is FreeBSD so awesome, I mean, why do I love it so much?
I love it more than a
mustang
at high speed! I LOVE FreeBSD!
Am I crazy? (Dunno, what's your doctor say? -toddpw)
A:
BSDs are awesome because they work.
And when they don't do what you expect, they always do something reasonable,
or at the very least something comprehensible.
BSDs try hard to prevent and eliminate internal conflicts in the design of the system. Such conflicts are responsible for most of the frustrating unpredictable behavior of many software systems.
BSDs don't waste resources in a futile effort to read the minds of countless individual users. Instead, they support teachable methods for getting things done, knowing they can rely on user education to close the gap between the crock of ``intuitively obvious'' and the practicality of knowing one's way around a toolbox (as opposed to puzzling through a swiss army knife of feature bloat).
BSDs don't try to be all things to all users. They make considered judgements about what the O/S should do, and then they focus on doing it well, leaving everything else to 3rd party software.
BSDs don't have chips on their shoulders. They don't rush code out the door just to say they've got something too. It's much better for things to really work the first time you release them.
BSDs aren't paranoid. With a license that explicitly allows people to totally desecrate their code, new BSD developers either get used to the meritocracy or they get out. Not unlike Adam Smith's invisible hand of capitalism, this is an incredibly powerful filter that keeps everyone developing sensibly.
BSDs prefer to learn from history, and shun the alternative. Their only ulterior motive is to make the most complicated things reasonable, even if that means doing something non-obvious, and it often does.
So while BSDs don't always want to work the way you thought they might, they always want to work.
Q:
What's the latest news from the Land of Weird Hardware?
A:
We return to the
Land of Weird Hardware
for a look at the newest member of the family: the
IBM WorkPad z50.
Apparently this was IBM's first Windows CE (oops, Pocket PC) device, and probably their last, since at a list price of $999 it was creamed in the marketplace by both the lack of insanely great software support and competition from fully-functional Celeron mini-laptops costing not much more, such as IBM's own ThinkPad 240 which even uses the same basic case design.
In mid-February web stores began dumping the WorkPad z50 at bargain prices and in March IBM quietly discontinued it. After a few canceled orders from other web stores, I managed to get one from outpost.com for $369. I eventually settled on Mobile Planet for my accessories:
The WorkPad z50 with 48 megs of ram and 183.5 megs of disk (192,000,000 bytes -- shoulda seen that coming, grr) is a pretty spiffy machine. You can pack an entire distribution of NetBSD/hpcmips from mid-March on it and still have some room left over. It's totally quiet (no moving parts) and weighs only a few pounds. The two batteries easily last for more than 5 and 10 hours of full use at normal LCD brightness.
Not all the hardware is supported yet; in particular the X server and the power management stuff is still in progress as I write this. But it's already useful enough that I'm taking it to meetings, and I've successfully used it to track my comic book collection (while I'm at the store!) so I can avoid buying the same back issue twice (argh...). And it's also nice to have the entire BSD games collection available any time I need a pleasant diversion. :)
Q.
This month's mailbag has a
cloud on one side,
a flower on the other, and a cute embroidered rainbow
running around one end to connect them.
Using Drive : 0 Partition 3and that's it... It hangs there. I have tried this on 3 different Compaq 1850's, all with the same result. Also, I can take the same CD and install OpenBSD on a desktop machine with IDE?
not ufs not ufs No /boot/loaderI tried both of the following:
0:ad(0,a)/kernel 0:ad(0,a)/boot/loaderThe error returned is:
not ufs no /kernelUsing the boot floppies I can verify that all these files do exist on the disk.
By the way, this Valuepoint (6384 N50) is also using Ontrack's latest disk manager, version 9.47. Even with the latest BIOS, the machine needs Ontrack. Still, the FreeBSD root partition ends well below cylinder 1,024. (Win 95 and NT 4.0 are on 2 other fdisk partitions which precede the FreeBSD slice. They boot up fine using the Boot manager that comes with FreeBSD and the NT Loader boot manager.)
Do you have questions for the BSD Answer Man?
Send them to
bsd-answerman@toddpw.org.
Any email sent to this address is assumed intended for publication and
will become the property of Dæmonnews.
That's all for this month, folks.
Until next time, remember: there's no shame in asking RTFM questions any more,
because these days, there is just too much FM to R.
Todd Whitesel has been grokking computers for fun since his first grade school Apple II in 1980, and doing it for a living since 1992, when he escaped from Caltech with a B.S. degree. He helps promote Japanese Animation in America by running Registration for Anime Expo, and helps promote NetBSD by way of his NetBSD Architecture Farm.