These are various little things I've found, that don't seem to be in the FAQs, and required a bit of searching--or, in the case of the A7A266 Motherboard, a lot of searching, to solve. So here they are, in no particular order
In July of 2003 I added the section on using 5.x. Some of it is simply a repeat of my cvsup page but there are a few extras here.
On boot, a bunch of error messages that UDMA mode isn't working, dropping to PIO mode.
This one is pretty common. It's almost always fixed by replacing your IDE cable with shielded, 80 pin ATA 100 cable. Most computers, even more expensive ones, come with 40 pin cable these days.
Interestingly enough, finding this out made me more closely examine various Linux distro dmesg's. I found that they were showing CRC errors (which also stopped when the cable was replaced).
The mouse pointer jumps all over the place and you receive a bunch of messages about it being out of sync
This happens with a KVM switch. Last time I looked on deja, it seemed as if the developer working on the problem was on the edge of dropping it. There are various solutions around, such as recompiling the kernel with some flag in there (I've forgotten which, as it didn't work for me) but in general, the trick is to start the box with the KVM switch focused on it. The KVM switch has to be focused on the box from boot through starting X. Once X is started, you can go back and forth between other boxes on the switch. Others have had differing results with this, but my experience seems to be the most common.
While I'm discussing the mouse, I might as well mention that, at least with XFree 4.x an Intellimouse, on a KVM should have its protocol set to "Auto". (xfconfig will set it to Intellimouse, which doesn't seem to work well)
Upgrading to OpenSSH-3.4
Since the various warnings of SSH exploits, everyone has been wanting to upgrade to OpenSSH-3.4. If you simply install it from ports, you'll find that the old version is still running--there's been various discussion about this on the FreeBSD-questions--the pkg-message gives one method, however, I find the easier way is to do it this way.
First install it.
cd /usr/ports/security/openssh-portable
make install
(The concensus is that portable is better than /security/openssh)
You'll now find a file called /usr/local/etc/rc.d/sshd.sh.sample. Rename it to sshd.sh
cd /usr/local/etc/rc.d
mv sshd.sh.sample sshd.sh
Edit /etc/rc.conf. This is where there was some debate and my method disagrees with the pkg-message--it's up to you, I think this way is easier. In /etc/rc.conf change the enable_sshd line from "YES to "NO", or even remove it entirely. Then stop sshd. Start /usr/local/sbin/sshd and you should be good. However, unless you do edit your PATH to put /usr/local/sbin before /usr/sbin doing a which sshd will give you the /usr/sbin one. Also, doing sshd -V will show you the old version number. However, the one running will be the /usr/local/sbin/sshd. If the wrong answer to which and wrong version number annoy you and you don't feel like editing your path, you can simply rename /usr/sbin/sshd to /usr/sbin/sshd_old and that will fix things. However, you may have to do it again next time you do a make world
XFree86-4 with various ASUS Motherboards
This one took a lot of digging. At first, I thought the problem was with a video card I had, a Voodoo5. However, even after downgrading to a G200, I still found that when I installed XFree 4.x, when I tried to start X, the machine would spontaneously reboot.
Now I began to suspect the motherboard, an ASUS A7A266. A bit more research showed that this had been noted as a problem since 4.3 RELEASE. It is listed as PR 28418 and can be viewed here.
It's been fixed and doing cvsup and building and installing
world will fix it. However, if you haven't done that yet, or don't
have time or inclination at pressent then Mr. Malone has made a
patch--however, I did something wrong and it didn't apply properly.
However, here's the trick, given me by Bill Triplett. Just open up
/usr/src/sys/i386/i368/i686_mem.c with your favorite text editor.
Around line 269 (in vi, it's easy to find--just do :269 while in
command mode), you'll see
u_int cr4save; mrd = sc->mr_desc;
Between those two lines, insert a line
return;
That's it. Putting in the word return, followed by a semi colon will keep X from doing whatever it's doing with the MTRR, which is what is causing the ASUS boards to lock up when XFree 4.x is started.
Then of course, you have to recompile your kernel. So, say your kernel is called MYKERN (Sorry for the lack of originality, but I'm sleepy)
cd /usr/src/sys/i386/conf
config MYKERN
You will then see the thing something like source is
../../compile/MYKERN
Don't forget to do make depend
So
cd ../../compile/MYKERN
make depend; make; make install
Reboot and you should be good to go.
OpenOffice
While one can compile OpenOffice from ports you need a lot of disk space and it also takes a great deal of time. (On a PIII 500 with 192 megs of RAM it took twelve hours.) There are FreeBSD binaries on openoffice.org but, at least the last time I looked, they were only for 4.x
However, binaries for 5.x are available at projects.imp.ch/openoffice.
The 1.1 beta is available. However others as well as myself have had trouble getting it working. I didn't go to that much trouble, did a quick google and found no solutions so said the the heck with it and downloaded the 1.0 version which worked as expected. For awhile, they didn't have that binary up there, but I suspect that more people than myself had trouble with the beta, which may be why it's back there.
(Quick update on this--at one point or another, they put up 1.1rc5 which does work for me without problems.)
On a clean install of 5.x you have no /proc. This can cause problems with OpenOffice, so you might want to add the following to /etc/fstab
proc /proc procfs rw 0 0 |
With this, everything worked.
Some of the problems I've mentioned above, such as the ASUS board and X are now fixed. (X by the way is up to 4.3 something and gives the option for Auto for the mouse protocol.) However, once again, I had a problem that seemed specific to ASUS boards. This time it was relatively minor, a shutdown -p wouldn't power off the machine, it would simply stop it and there would be a message that the system had halted, press any key to reboot.
I posted the problem on CURRENT and a gentleman named Stefan gave me his solution, which worked for me. I added this to /etc/sysctl.conf
hw.acpi.disable_on_poweroff=0 |
That fixed that problem nicely.
Another issue, that I don't think is specific to 5.x is java in a web browser. I've found that if one does a cvsup and updates their linux_base for Linux emulation, then installs the latest version of linux-opera (as opposed to FreeBSD Native) and installs the /usr/ports/java/linux-blackdown-jdk14 Jave works without any problem. I did find that the latest linux-sun-jdk14 didn't work. I haven't researched this, and additionally, if one uses blackdown, make install will download the source for you. If you use sun-jdk14 you have to download them yourself, which is a nuisance.
An addition to this. At some point in 2004 blackdown-jdk14 was updated and java no longer worked. I assume you can still use jdk13 but haven't tested it. I have the old port tarballed here. (Thanks to my friend Josh Glover for providing the web space).
This page is fairly disorganized, as I just add little problems that I find and fix as I go along. Here's another one. If you use amsn the graphic amsn client, you'll find, the first time you start it that you'll get a message something like "You have wish version 8.3 installed, blah blah." You have to look at the /usr/local/bin/amsn file. You'll see that it points to /usr/local/bin/wish. You'll have to change that to whatever version of wish that you have, for example change it to read
/usr/local/bin/wish8.3 |