KDM Fails to Login in FreeBSD

After installing FreeBSD 7.1/amd64, X and KDE4, I finally decided to try using a display manager and I went with KDM (instead of simply XDM). It ran successfully but whenever I tried to login, the KDM would take my login and then throw me back at the login screen.

Just to get started, here's what you need to do to install it:
1) In /etc/ttys change the XDM line to
# ttyv8 "/usr/local/kde4/bin/kdm -nodaemon" xterm on secure

2) Link for session manager
# ln -s ~/.xinitrc ~/.xsession

3) Restart ttys
# kill -HUP 1

You should have the login screen (KDM) up and running...and here's where the problem happened. This was the error message I was getting

Apr 11 13:01:28 media kdm-bin: :0[1131]: Cannot open ConsoleKit session: Unable to open session: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory

I still haven't tracked the exact cause of the issue but if you enable dbus with the Gnome Hardware Abstraction Layer (HAL) then KDM will work.

1) Add to /etc/rc.conf
# dbus_enable="YES"
# hald_enable="YES"

2) Reboot or start the services
# /usr/local/etc/rc.d/dbus start
# /usr/local/etc/rc.d/hald start

You should be able to enjoy your display manager now just like in any desktop system.

KDE4, GTK20 and Portsdb Fail Due to Missing Ports

I had a few more problems while installing some basic ports. And in the end the issue was due to cvsup not pulling all the necessary ports due to my refuse file.

First, after installing portupgrade I ran
# portsdb -Uu

But it failed with:
perl: not found

I found some tips online and most of them pointed to a possible use of the refuse file by cvsup. I still didn't want to pull ports that I possibly wouldn't use so I manually installed Perl and, in this case, solved the problem.

Then it came up a second time while installing KDE4. At some point during installation, it stopped with an error at GTK20. The error message suggested running gnomeanalyser.sh to diagnose the problem.

I ran that script but it wasn't able to diagnose the problem and suggested removing the refuse file and re-running cvsup. So this time I did remove my entries (not the language ones) from the refuse file and ran cvsup again.

After all the ports were updated, I installed KDE4 again and it ran without a problem.

FreeBSD/amd64 Failed installworld btxlsd

In my last build of FreeBSD/amd64, installworld failed with the following error:
btxld:No such file or directory

It was a little cryptic, specially because it was a fresh install, but after a little internet search I found a possible cause/solution for the issue. The date/time was out of sync...and that was indeed the cause!

You can check the date/time by simply running this:
# date

To sync it I ran:
# adjkerntz -i

Then I re-installed world and everything went fine.

FreeBSD and Intel Core 2 Quad

This was a very silly mistake but since I always ran FreeBSD on Pentium machines then I always installed the i386 version; however, if you have an Intel Core 2 Quad CPU don't do that!!!

Intel Core 2 Quad is a 64-bit architecture and in order to take advantage of the four CPUs then you must install FreeBSD/amd64! You also need to have SMP enabled in the Kernel (which is already a standard in all the latest releases).

For more info, please read the FreeBSD hardware requirements page.

How to fix FreeBSD "Can't work out which disk we are booting from"

I had just installed a fresh FreeBSD 7.0-RELEASE, cvsup the latest sources and ports and followed my standard procedure to build and install a new world and kernel (without any big changes).

Everything ran beautifully and after installworld I was ready to reboot and here's where the problem started. Upon reboot, the system wouldn't load!

It was getting stuck with the following error:
Can't work out which disk we are booting from.
Guessed BIOS device 0xffffffff not found by probes, defaulting to disk0

After some online research I found a lead to fix the problem...well, at least to get your system started again.

Here's what you'll need to get started:
1) The installation CD/DVD that you had just used to install this release
2) A LiveFS CD/DVD. You can get it from the FreeBSD site. I'm a i386 so here's the direct link
ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.0/

Now time to get to work:
1) Boot from your installation CD/DVD
2) Select your region which will you take you to the usual sysinstall screen
3) Select the Fixit option to repair an installation
4) Select the CD/DVD option (#2) and it will ask you to insert the LiveFS CD/DVD
5) You should now be on the #fixit: prompt
6) Make a directory where we will mount the old root FS
# mkdir /old
7) I assume you know your drive and where you had installed your FreeBSD partition. If you need a little reminder, you can run the command below to see your drives. I only have one at "ad0"
# dmesg
8) And to verify you can look at /dev
# ls /dev
9) The root partition ends with an 'a'. So let's mount it.
# mount -t ufs /dev/ad0s1a /old
10) We will now replace the faulty /boot/loader (also back it up just in case)
# cd /old/boot
# cp loader loader.bad
# cp loader.old loader
# exit

Now just exit the sysinstall screen, remove the LiveFS CD/DVD and your system should boot up normally.

I found this Wiki to be helpful and it also provides a patch which I haven't tried yet.
http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues

Dealing with FreeBSD MountRoot Prompt

You will bump into a FreeBSD <mountroot> prompt if your system failed to correctly mount your root device. This normally happens when you modify your hardware and the disk configuration changes.

It's actually very simple to solve this situation and to get your system up and running again. If you're not familiar with the mount command then this a great time to familiarize yourself. You can read the man page at http://www.freebsd.org/cgi/man.cgi?query=mount&apropos=0&sektion=0&manpath=FreeBSD+6.2-RELEASE&format=html.

Solving the problem. When you get the <mountroot> prompt, the dmesg info displayed right above it will pretty much tell you all that you need to know.

First, the message will probably be something like it 'couldn't mount root from ufs:/dev/ad8s1a' (or whatever your disk was). And above it, you should see your new disks set up (i.e. ad0 19877 Seagate, ad1 19871 Maxtor, etc). You should be able to recognize your old drive by HD size+brand or some other subtle difference (here we will assume that your drive became ad0 from ad8).

At the <mountroot> prompt you can type '?' to get a list of devices which should also display 'ad0s1a'. And that's what we are looking for. Then type (you'll be taken to single-user mode so that you can fix the rest)
ufs:/dev/ad0s1a

In single-user mode, you can look at your current fstab file where the mount devices are specified.
# cat /etc/fstab

Then mount your /var, /tmp, /usr just like in your fstab but changing the disk number
# mount -t ufs /dev/ad0s1d /var
# mount -t ufs /dev/ad0s1e /tmp
# mount -t ufs /dev/ad0s1f /usr

You can confirm your mounts by typing either of these two commands:
# df
# mount -p

Make root writable so that you can update fstab
# mount -uw /

Update fstab with the correct disk IDs.
# vi /etc/fstab
Save it and reboot

Welcome back to your system! :)