Short Attention Span Theatre

htop on FreeBSD

Installing htop on FreeBSD requires a particular directory under the linux com­pat­i­bil­i­ty tree be mounted, but I did not want linux com­pat­i­bil­i­ty installed. Luckily, I found a thread about htop on FreeBSD which covered that issue, and another which covered loading the linux kernel module.

Just create /compat/linux/proc, add the requisite entry to /etc/fstab, and # mount linproc. If you have problems, try putting linux_enable="YES" in your /etc/loader.conf.


Rebuilding NAStie

After a recent spat with NAStie (my home NAS built in building NAStie) and its grub in­fes­ta­tion, I decided to go back to FreeBSD for my home server needs. I like Linux, but mostly for desktop/remote server stuff. For home server on old hardware, I likes me some *BSD.

So, I started my research at my post about RAID1 on FreeBSD (FreeBSD 5.2.1 and cheap RAID1), learned about the RAID-1 options in FreeBSD, and needed to decide whether there was any use in trying for a volume management option.

Answer: NO.

As to why: In my home network server upgrades are driven not by space re­quire­ments, but by old continue.

Building mutt from mercurial repository on FreeBSD

Just a note to remind myself of the ports needed to build mutt from the mercurial repository on FreeBSD (because I recently had to figure that out again).

# portmaster --force-config devel/mercurial devel/automake \
    devel/gettext textproc/docbook-xml textproc/docbook-xsl \
    textproc/libxslt databases/tokyocabinet www/lynx \

There are other com­bi­na­tions which might do the job, but IWFM.

LFS coreutils test errors

A short note to remind me of the patch for coreutils 8.10 which allows its tests to pass when building Linux From Scratch (LFS) version 6.8.

LVM booted using grub2 in Arch

Unlike my previous experiment with building NAStie installing this variant of linux onto LVM-only partitions proved difficult. My attempts left my sleep schedule a bit tweaked, and my disgust for "au­to­mat­ed" con­fig­u­ra­tion-file-building-scripts found new purpose. That aside, what worked when I installed Arch linux on LVM partitions is below.

High resolution console earlier on FreeBSD

In High resolution console on FreeBSD I mentioned a particular way of setting the VESA mode for syscons, but a post on the freebsd-questions mailing list mentioned a different method. Instead of setting the allscreens_flags="MODE_325" in /etc/rc.conf, you use the /boot/device.hints file.

Putting the following items into /boot/device.hints puts syscons into MODE_325 (1280x1024x32 on my VirtualBox in­stal­la­tion)."isa""0x180""0x145"

This does not put FreeBSD into this mode as soon as the kernel starts booting, but it does as soon as the sc driver is loaded (which is much sooner than rc.conf is processed). As a result, a sig­nif­i­cant portion of your dmesg is available in your larger console.

Not critical, but continue.

Symantec LiveUpdate annoyance

Ever since installing Symantec Endpoint Protection in unmanaged mode LiveUpdate has been annoying me by updating itself once per day... that is not the annoyance, though. The annoyance is it creates a window on screen showing progress, and then requires user in­ter­ven­tion to make it go away!

I was just starting on my quest to find a way to change that behavior when I found someone had already done the homework. Far be it from me to be ungrateful and not use the results of his efforts (command-line used below). ;)

$ sudo symsched -d all
$ sudo symsched LiveUpdate "Update All Daily" 1 0 -daily 03:13  

The man from HEAD

To paraphrase myself on freebsd-questions: "What an in­ter­est­ing night of ex­per­i­men­ta­tion." Most of this post has already been tubified on the mailing list, but I want to get down some details, and make sure I can easily find the in­for­ma­tion later.

A small irritation about FreeBSD is man does not au­to­mat­i­cal­ly adjust its line-length to account for the number of columns currently displayed in a particular xterm. So, after weeks of in­ter­mit­tent frus­tra­tion and small, aborted attempts to determine why I could not get the man to do what I wanted, I decided a concerted effort was worth my time (that, and I asked for help ;)).

My continue.

Local ports on FreeBSD

When using FreeBSD, I always run into the problem of main­tain­ing local ports. Usually I find a way around the problem using some good-natured shell hijinks, or end up simply installing linux as a stop-gap (due to time pressure), but this time I think I have found a more permanent solution: Local ports which coexist with portsnap! In that thread there was actually another, similar solution, but I have stuck with the first for now. The only sig­nif­i­cant difference between the two was the use of categories.

I followed the in­struc­tions in the first link, leaving out any ports categories I did not need. Then continue.

NTPd configuration

During my brief brush with Arch a few years back I found their doc­u­men­ta­tion to be extremely well-done. Given that, I find it odd I have never stuck with that dis­tri­b­u­tion for long... Especially since I end up back at the Arch wiki for con­fig­u­ra­tion advice over and over again. This time I could not remember the different options I used for NTPd con­fig­u­ra­tion, and ended up back at the Arch Linux NTP article and the NTP pool web site.

Now it is saved here for safe-keeping, and I (hopefully) will not forget again. ;)

Previous » « Next
sast favicon