MidnightBSD Developer Journal

If  you are running BIND 9.7  or 9.8 from mports, please update to the latest release.  There is a security issue affecting these versions which is rather serious.  See the ISC website for details.

Over the weekend, I updated the amdtemp(4) driver to support the sensors framework.  This serves the same function as kate(4) in OpenBSD and DragonFly, but it supports K10 and K11 AMD CPUs as well. I based some of the design on how the coretemp(4) works, but it's exposed differently in hw.sensors because of the bus it's on. 

We've got a news mention discussing 0.4-CURRENT in this month's issue of BSD Magazine. 

Right after the release, I focused on getting some contrib software up-to-date.  While writing the release notes for 0.3, it was apparent that we needed to get on the ball.  

OpenSSL, OpenSSH, file, GNU sort, awk, sqlite, tcsh, BIND and sudo have all been updated in the last month.  I've added it(4) and lm(4) to work with the sensors framework introduced in 0.3.  eeemon(4) was recently added for hardware monitoring on some Asus eee PCs.  alc(4) was introduced for atheros gigabit lan cards.  ale, alc, ae were all added to GENERIC in current.  

Intel coretemp(4) monitor was modified to work with the sensors framework. It's now possible to monitor the CPU temp with sensorsd on Intel CPUs.  I'm working on adding similar functionality to amdtemp.  

A locking fix was introduced today on the route code related to ICMP traffic.  

I just posted a non security update to the 0.3 branch.  sqlite 3 was misreporting it's version in the pkg-config script.  This has been corrected.  It shouldn't have any real impact on the base system or packages shipped with MidnightBSD. 

I also fixed the example cvsup file so that it checks out RELENG_0_3 on that branch.

In mports, autotools meta port along with libtool, libltdl, automake and autoconf were updated to newer versions.  We're no longer using an insane number of autoconf ports.  

It appears autoconf now "knows" about MIdnightBSD as well.  That's great news.

mports/emulators/wine was updated to 1.3.12 today.

In 0.4-CURRENT src, we now have tcsh 6.17.00.  0.3 has 6.15.00.   

I've uploaded the AMD64 release of MidnightBSD 0.3.  It should be available on the mirrors shortly.  Distrowatch and freshmeat have the release announcements now. 

I'm starting the build process for 0.3-RELEASE i386 now.  Hopefully, we'll have some nice ISOs available by this evening.

There is a new i386 snapshot on the FTP server.  It includes packages.  This will probably be very similar to the final release.   

Awhile back, I imported the sensors framework into MidnightBSD.  For more information on it, visit these sites:

http://kerneltrap.org/OpenBSD/BSDCan_2008_Hardware_Sensors_Framework 

http://www.openbsd.org/papers/bsdcan08-sensors.pdf

http://wiki.freebsd.org/GSoC2007/cnst-sensors

0.3-release will include the core patch, and 0.4-CURRENT includes three devices using it so far. (including intel cpu temp monitoring)

I'm attempting to build a snapshot with a package split right now.  If everything goes according to plan, we'll have our first test build for 0.3-RELEASE tomorrow.

I've published the preliminary packages for amd64 to the FTP server.  The symlinks need to be setup yet for pkg_add -r to work.  There's roughly 2420 packages available.

i386 is still building. 

This is the run for AMD64 that I intend to use for the 0.3-RELEASE. Some of the failed packages can be safely built outside of magus and I'll post those on the FTP server later.   210 might be the i386 run depending on the results. 

• pass: 2447 
• untested: 96 
• skip: 57 
• fail: 79 
• ready: 0
•  
•  

The amd64 package run is complete and we're in a ports freeze right now until the release is completed.  Currently waiting on i386 packages.   I plan to create a snapshot with packages for testing before the branch is tagged.  I'll post it on the FTP server for public testing.

Several little bugs were fixed yesterday with some newer functionality and with the check-old target.  

This is the current status of mports on amd64 arch for 0.3-prerelease.  We're getting close now.  I'm not going for 100% pass, but several of the fails must be fixed before release.

• untested: 155 
• pass: 2388 
• skip: 58 
• fail: 76 
• warn: 1 
• ready: 0

 mports look much better.  Here are the latest amd64 results:  2355 is the highest pass rate we've had in some time.  Part of qt4 is working again and we're starting to get a good part of gnome 2.30 ready.

• untested: 168 
• pass: 2355 
• fail: 92 
• skip: 60 
• warn: 1 
• ready: 0

We're working on stabalizing mports for the next release.  There are several ports known to be broken that are important.  Currently, we've got about 2200 ports building on amd64 and a little less on i386 (although that environment is using the new mport tools).  

When KDE 3 and a good part of gnome are stable, we'll do RE.  Now is the time to look for security updates or to help with port fixes for 0.3.  Also, any issues with 0.3 (src) should be noted.

There has been some concern raised about the possibility of a backdoor in the IPSEC implementation of OpenBSD.  As OpenBSD's implementation was the basis of FreeBSD's IPSEC code and we use the same code,  I want to make others aware of this issue.

http://marc.info/?l=openbsd-tech&m=129236621626462&w=2

 I have not audited this code so I don't know if this is true, but I find it unlikely.  I will defer to others in the BSD community to audit the code in OpenBSD before taking any actions.  

I have never been approached about adding a backdoor into MidnightBSD. To the best of my knowledge, none exists.

I'm attempting to get a WD EARS drive working properly in one of my servers.  There are a number of issues using one of these new advanced format drives.

1. The default alignment causes significant performance problems.  Some users have reported 1-8Mbps read speeds.

2. sysinstall doesn't let you change the offset in bsdlabel in a convenient way.

3. Many people have problems with these drives, but few people have good solutions under BSD.

Things I've found out so far:

An offset of 1 is helpful (so it's on 64 instead of 63 for the first partition).  Most people trying to use these things are going for one large drive for data.  I need to boot off this thing which means bsdlabel has several entries.  I haven't found anyone trying this yet.  

First, I thought I'd get clever and try gpart/gpt.  I actually got the drive setup and some testing showed decent performance but I forgot that I hadn't ported the boot code yet.  Doh!  

Next, I went to plan b.  I used fdisk as normal and instead focused on making appropriate changes in bsdlabel.  WD says that as long as sectors are divisible by 8 you are ok, but an interesting analysis showed performance improvements by using a block size o 32768, sector size of 4096 (with newfs).  That meant I had to be a little more careful during bsdlabel so that everything lined up nicely.  

DES looked into this for FreeBSD and wrote a handy utility to test called phybs.  It doesn't do performance testing, but you can see the affect on alignment.  

Using that utility, I found that the fdisk setup was slower than gpt for some reason and i suspect things are still not optimal.  However, a quick and dirty test of moving some files around showed it was running better than the horror stories I've read.

One test of copying files from a 7200 RPM seagate HDD to two different green drives (a samsung and the WD) showed that the samsung drive was slightly faster (1MBps).  diskinfo shows the WD drive faster on the inner part of the disk but slightly slower on the outer part.  

I'll post real numbers up later.. it's 3 am.  

here's the results under GPT

./phybs -r /dev/ad8p1

   count    size  offset    step        msec     tps    kBps

  131072    1024       0    4096       18198    7202    7202

  131072    1024     512    4096       18026    7271    7271

   65536    2048       0    8192       10233    6404   12808

   65536    2048     512    8192       11135    5885   11770

   65536    2048    1024    8192       11304    5797   11594

   32768    4096       0   16384        7508    4364   17456

   32768    4096     512   16384        8394    3903   15613

   32768    4096    1024   16384        8789    3728   14913

   32768    4096    2048   16384        8458    3873   15495

   16384    8192       0   32768        5672    2888   23107

   16384    8192     512   32768        5723    2862   22900

   16384    8192    1024   32768        5999    2730   21846

   16384    8192    2048   32768        5867    2792   22337

   16384    8192    4096   32768        5735    2856   22852

# gpart show

=>        34  1953525101  ad8  GPT  (1000.2GB)

          34        2014       - free -  (1031.2KB)

        2048     2097136    1  freebsd-ufs  (1073.7MB)

     2099184    16572032    2  freebsd-swap  (8.5GB)

    18671216     2097136    3  freebsd-ufs  (1073.7MB)

    20768352   268435456    4  freebsd-ufs  (137.4GB)

   289203808  1664320808    5  freebsd-ufs  (852.1GB)

  1953524616         519       - free -  (265.7KB)

Here's some rsync data for the samsung drive:

sent 4858801691 bytes  received 41302 bytes  28497612.86 bytes/sec

total size is 4858055400  speedup is 1.00

51.771u 35.499s 2:50.08 51.3% 459+1906k 41623+36549io 4pf+0w

rsync for wd:

sent 4858801691 bytes  received 41302 bytes  27685715.06 bytes/sec

total size is 4858055400  speedup is 1.00

55.324u 36.006s 2:54.74 52.2% 457+1899k 41572+36276io 0pf+0w

This is not scientific at all..  i was copying tarballs from the last magus run.

fdisk for the drive:

 fdisk -v ad8

******* Working on device /dev/ad8 *******

parameters extracted from in-core disklabel are:

cylinders=1938021 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1

parameters to be used for BIOS calculations are:

cylinders=1938021 heads=16 sectors/track=63 (1008 blks/cyl)

Media sector size is 512

Warning: BIOS sector numbering starts with sector 1

Information from DOS bootblock is:

The data for partition 1 is:

sysid 165 (0xa5),(FreeBSD/MidnightBSD/NetBSD/386BSD)

    start 64, size 1953525105 (953869 Meg), flag 80 (active)

beg: cyl 0/ head 1/ sector 2;

end: cyl 613/ head 0/ sector 1

The data for partition 2 is:

<UNUSED>

The data for partition 3 is:

<UNUSED>

The data for partition 4 is:

<UNUSED>