While I reinstalled the FreeBSD on my FreeBSD box, I got the following error message:

Unable to find device node for /dev/ad0s1b in /dev!

I searched online and I found different solutions. The most popular one is about using the command, dd, to clean up the first and the last 35 blocks. However, this solution doesn’t always work.

The 35 block trick is mainly for GPT partition, which was created under Linux. However, my harddrive was used in FreeBSD last time. So the GPT problem doesn’t apply. Even I tried the solution to wipe out the first and the last 100 (which is more than 35) blocks, it didn’t work either. Therefore, I tried to wipe out the entire harddrive. It works.

1. Set up an environment such that you can use the command, dd, to wipe out your harddrive. You can either connect your harddrive to a working machine, or boot the system using Live CD.

2. Run the following command to determine the correct location of your harddrive:

su
fdisk -l

Let say, it is on /dev/sda

3. Find out how many partitions have been created in this harddrive:

ls /dev/sda*

Let say there are two: /dev/sda, /dev/sda1

4. Wipe out each partition one by one:

dd if=/dev/zero /dev/sda bs=512
dd if=/dev/zero /dev/sda1 bs=512

5. After everything is done, you can verify it by running fdisk again:

fdisk -l

and it should say something like partition table not found, which is what we expect.

That’s it! Try to install FreeBSD again and everything should be fine.

If you still experience any difficulties, try the following trick:

1. After defining the geometry, don’t press the “w” key.
2. After creating the partitions, don’t press the “w” key.
3. When selecting the media, instead of choosing CD, try to use Network.

That should avoid most possible potential issues.

–Derrick

Our sponsors:

I was trying to remove a folder at /var/empty with no success (Operation not permitted):

ls -al
dr-xr-xr-x  2 root     wheel     512B Jul 18  2010 empty
sudo rm -Rf empty
rm: /var/empty: Operation not permitted

So I decided to change the permission:

sudo chmod a+rw empty/

and it did not work either:

chmod: empty/: Operation not permitted

Finally, I gave chflags a try:

chflags -R noschg empty/
sudo rm -Rf empty/

Done!

–Derrick

Our sponsors:

In the last few days, my FreeBSD box drove me crazy with the kernel panic. The error message is shown below:

dev = ad14s1f, block = 1, fs = /usr
panic: ffs_blkfree: freeing free block
cpuid = 4
KDB: stack backtrace:
...

I am not sure what caused this kernel panic, but it happened few times a day for a week. Every time it happened, I had to reboot my machine manually. After some investigations, I found the following solution:

1. Boot into the single user mode.
2. Run the following command to force (-f) the system to check the system. It is likely that you will get a lot of error, so adding a -y option (which assume yes to all the questions) will make your life easier:

fsck -f -y

After the check is done, reboot the system to normal mode:

reboot

The reason why my system had this kind of issue was due to the filesystem inconsistency. Even the fsck was trigger after each system was crashed, it could not detect or repair the problem (fsck will not fix any problem on a mounted partition on a running system.). That’s why we need to do it in the single user mode.

–Derrick

Our sponsors:

I want to start a script when booting my FreeBSD box automatically. Unlike Linux, FreeBSD does not honor the script you put in /etc/rc.local. Usually it is recommended to use the rc service (See here for details), however I think it is too complicated to convert my script to a rc compatible version. I decide to explore more simple solutions. I found that it can be done via Cron.

Suppose I have a script in the following location. I decide to run it when booting the machine automatically:

/script/myscript.sh

First, I need to include this script in the Cron:

sudo nano /etc/crontab

And add the following to the end of the file:

@reboot root /script/myscript.sh

That will make the system to execute this script.

However, the system may not run your script correctly because the Cron job uses a different shell and the path information may be missing. You can fix it by modifying the SHELL and PATH variables in /etc/crontab:

In my case, I uses Bash and I like my script executed by Bash:

SHELL=/usr/local/bin/bash

And my script needs to execute some commands that locate in /usr/local/bin:

PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin

That’s it! Have fun with FreeBSD.

–Derrick

Our sponsors:

My FreeBSD box must be sick today. For some reasons, when I ran the portsnap command (i.e., portsnap fetch update), it removed the entire port directory (i.e., rm /usr/ports -Rf). Therefore, I decided to build the entire port tree:

sudo su
cd /var/db/portsnap
rm -Rf *
portsnap fetch extract

I decided to run portmaster to update my system, I got the following error:

===>>> The devel/automake110 port has been deleted: No longer required by any port
===>>> Aborting update
Terminated

Well, the problem looks pretty simple. FreeBSD found an out-dated package installed in my system, and it could not find any corresponding port (Already deleted in the repository), that’s why it stops there and doesn’t know what to do next.

To solve this problem, the solution is very simple:

First, let’s see what version of automake we have in our system:

pkg_info | grep auto

which return:

autoconf-2.62       Automatically configure source code on many Un*x platforms
autoconf-2.68       Automatically configure source code on many Un*x platforms
autoconf-wrapper-20101119 Wrapper script for GNU autoconf
automake-1.10.1     GNU Standards-compliant Makefile generator (1.10)
automake-1.11.1     GNU Standards-compliant Makefile generator (1.11)
automake-wrapper-20101119 Wrapper script for GNU automake

Apparently, the older version of autoconf and automake cause the issues. Why not remove them?

sudo pkg_delete autoconf-2.62 automake-1.10.1

I re-ran the portmaster to update the system. Everything worked fine again!

–Derrick

Our sponsors:

Today I found a very weird bug in JavaScript – The date function. I never expected to see a bug in the standard JavaScript implementation. Here is my code. It does nothing more than adding 21 days on the reference date:

var referenceDateObject	= new Date(2011, 9, 10);
var deliveryDateObj 	= new Date(referenceDateObject.getTime() + 24 * 60 * 60 * 1000 * 21);
var deliveryDateMonth	= parseInt(deliveryDateObj.getUTCMonth());
var deliveryDateString	= deliveryDateObj.getUTCFullYear() + '-' + deliveryDateMonth + '-' +  deliveryDateObj.getUTCDate();
alert(deliveryDateString);

Given a reference date of September 10, 2011, I expect the date should be October 1, 2011. However, it ends up returning me September 31, which doesn’t exist!

I test that on Firefox and Google Chrome, both give the same problem. A quick fix will be moving the date calculation to the server side.

P.S. MySQL date function automatically convert 9/31 to 10/1, so the data on the server looks fine.

Update – That’s my fault. The Date object treats the month from 0-11 instead of 1-12. Here is a corrected version:

var referenceDateObject	= new Date(2011, 8, 10);   //That's September 10, 2011, not August 10.
var deliveryDateObj 	= new Date(referenceDateObject.getTime() + 24 * 60 * 60 * 1000 * 21);
var deliveryDateMonth	= parseInt(deliveryDateObj.getUTCMonth()) + 1;
var deliveryDateString	= deliveryDateObj.getUTCFullYear() + '-' + deliveryDateMonth + '-' +  deliveryDateObj.getUTCDate();
alert(deliveryDateString);

That will do the trick.

–Derrick

Our sponsors:

Apache 2.2.21 was rolled out today. Since it has some security fixes, I decide to put a new version on my server farm. I didn’t know that it becomes a small headache today morning.

The upgrade was running smooth, no error messages, no complaints, until I restart the Apache server manually

sudo apachectl restart

And guess what, my website didn’t show up on the browser. Instead, I saw the following picture on my browser:

That was not fun at all. So I decided to investigate what was wrong to the upgrade.

sudo tail /var/log/httpd-error.log

And I found something interesting:

httpd: Syntax error on line 100 of /usr/local/etc/apache22/httpd.conf:
Cannot load /usr/local/libexec/apache22/mod_negotiation.so into server:
/usr/local/libexec/apache22/mod_negotiation.so: Undefined symbol "ap_set_accept_ranges"

Therefore, I edited my Apache configuration and commented out that module:

#LoadModule negotiation_module libexec/apache22/mod_negotiation.so

Saved the file and restarted the server again. Now the problem is gone!

sudo apachectl stop
sudo apachectl start

When I tried to visited the website again, I found that the speed is bit slow. I think it has something to do with the mod_negotiation.so. I decided to rebuild the Apache.

cd /usr/ports/www/apache22
sudo make config

Make sure that the Negotiation: Enable mod_negotiation is checked.

sudo make

Running sudo make is enough. You don’t need to re-run sudo make install or sudo make reinstall.

This will rebuild the necessary libraries including the missing mod_negotiation.so.

Go back to the configuration file and enable the module again:

LoadModule negotiation_module libexec/apache22/mod_negotiation.so

Restart the server:

sudo apachectl restart

That’s it! Happy Apaching!

–Derrick

Our sponsors:

Recently, I received a SPARC64 machine (Sun Blade 100) as a gift. If you are not sure what is SPARC64, it is a CPU primary manufactured by Sun/Oracle. It is quite different than Intel x86 / AMD 64, so anything that is compiled to run on these two platforms will not work on SPARC64. Besides, Sun/Oracle is currently shifting toward to Intel now, which means the SPARC64 will become less popular in the long run. Since I don’t want to let my Sun Blade becomes a paper-weight / foot stool, I decide to explore some options on what I can do with it.

Notice that this list only includes some popular operating systems I’ve tested only. I am pretty sure that there are lots of more choices available.

If you don’t want to go through the entire list, here are some quick recommendations:
Good: FreeBSD, NetBSD, OpenBSD, OpenSolaris
Okay: Debian
Avoid: Fedora, Ubuntu

The following operating system are listed in alphabetically:

Debian Linux

Recommendation: Yes if you don’t care about the performance
Support Status: Active
Comment: Although Debian provides a 64-bit version, the applications are run in 32-bit mode (Source). It can not only cause performance issue because the application does not utilize the full power of the CPU. For example, a 32-bit application can only handle unsigned integer from 0 to 2^31-1 (2147483647).

Fedora Linux

Recommendation: No
Support Status: Seems Discontinued.
Comment: As of today, the latest version of Fedora is 15. However, the latest version for SPARC is 12/13. Seems like the support in this architecture is inactive.
Source: Architectures/SPARC

FreeBSD

Recommendation: Yes
Support Status: Active
Comment: The command freebsd-update is not supported in SPARC64. In the other words, you have to rebuild the kernel from scratch in order to upgrade the system to a newer version

NetBSD

Recommendation: Yes
Support Status: Active
Download: Here

OpenBSD

Recommendation: Yes
Support Status: Active

OpenIndiana

Recommendation: Yes
Support Status: Active

OpenSolaris

Recommendation: No
Support Status: Discontinued

Ubuntu Linux

Recommendation: No
Support Status: Inactive
Comment: Ubuntu already dropped support to SPARC64. Forget about it.
Source: Ubuntu drops support for ia64 and sparc

Our sponsors:

I saw this message twice on two machines on two different days, end up using the same way to fix it.

Case 1: Samba

My Samba was down today, so I tried to start it manually:

/usr/local/etc/rc.d/samba start

And I got the following error message:

Removing stale Samba tdb files:  done
nmbd already running? (pid=1074).
Starting smbd.
/libexec/ld-elf.so.1: Shared object "libcups.so.2" not found, required by "smbd"
/usr/local/etc/rc.d/samba: WARNING: failed to start smbd

Initially, I thought the problem was about missing the file. So I did a search and soft-link it:

find / -name "libcups.so*"

Surprisingly, there is no such file in my system. I think I don’t have this file. So I tried to compile the Samba again:

cd /usr/ports/net/samba35
sudo make

and I got the following message:

===>  cups-client-1.4.8 is marked as broken: gnutls does not support threads yet disable the GNUTLS.
*** Error code 1

Stop in /usr/ports/print/cups-client.

Case 2: Upgrading Port

When I upgraded my FreeBSD system via portmaster, I found the following messages:

portmaster -Da
===>  cups-client-1.4.8 is marked as broken: gnutls does not support threads yet disable the GNUTLS.
*** Error code 1

Stop in /usr/ports/print/cups-client.

Initially, I tried to by-pass upgrading the cups-client using:

portmaster -Dai

However, it is very annoying to do it everyday, therefore I decide to solve this problem.

Solution

From the error message, it seems that the problem is caused by the additional option in cups-client: GNUTLS. So I decide to disable this option in the GNUTLS:

cd /usr/ports/print/cups-client
sudo make config

Uncheck “GNUTLS: Build with GNUTLS instead of OpenSSL”

and try to compile it again:

sudo make

Now re-run the portmaster:

sudo portmaster -Da

The problem is gone.

Our sponsors: