I now have 2 full years of metrics, and so can compare them and maybe learn a few things! First, let's see a fancy graph similar to the one produced by GitHub for my overall activity over 2024 and 2025:

Beside showing obvious periods of vacations, this view provide a few interesting metrics:

• The number of days with/without activity recorded for the full date range (578/731);
• The median duration of activity recorded by day (9:16:15)
• The total duration of activity recorded for the full date range (223 days 17:43:32)

First, keep in mind that wtr(1) count "days" as "24 hours days", not as "8 hours man days". So it happens that on a single day above (2025-05-28), wtr(1) recorded 1 day and a half of activity… How come?! Let's dig in and ask wtr(1) about what was worked on on that day:

romain@zappy ~ % wtr on 2024-05-28
wtr since 2024-05-28 until 2024-05-29

Blogreen                  5:44:20
Opus-Codium              16:28:30
Riemann                   8:21:10
Vox Pupuli                5:59:10
---------------------------------
Total             1 day  12:36:30

wtr(1) track time per project, and multiple projects can be active at the same time. So we can safely assume that while working on Opus-Codium infrastructure, I also had to touch my personal (Blogreen) infrastructure, some Riemann projects, and some Vox Pupuli modules… But wtr(1) will not be able to tell me more: it only tracks the time spend on each project, but cannot guess what is being done.

We know however in which project to look for activity, and see that I worked mostly on Opus-Codium infrastructure (as we guessed). Among the things I did, I worked on improving the monitoring of our ZFS pools in riemann-tools. Because this feature did not existed yet, the time I spent creating it was added to both Opus-Codium (the organization that needed the feature) and Riemann (the organization where the development took place). So it is not unusual to see more way more that 8 hours of activity if you track multiple projects.

The actual data

In wtr(1), I added a floss tag to Free-Software projects, so I can use this tag to report the total time spent on each project by year to compare 2025 to the previous year:

romain@zappy ~ % wtr last 2 years by year on +floss
wtr since 2024-01-01 until 2025-01-01

    ccin2p3                   3:31:20
    Choria            2 days  7:08:00
    Debian                      18:30
    FreeBSD           8 days  6:38:20
    OpenSearch        1 day   8:04:50
    Puppet            6 days 21:22:05
    Riemann           4 days 13:52:20
    syslog-ng         1 day  10:34:00
    Vox Pupuli        7 days  3:15:00
    wtr                      13:39:20
    ---------------------------------
    Total            32 days 16:23:45

wtr since 2025-01-01 until 2026-01-01

    ccin2p3                  22:36:00
    Choria                   12:56:50
    FreeBSD           9 days 15:57:20
    OpenSearch        2 days  6:45:00
    OpenVoxProject    9 days 12:46:50
    Puffy                     5:22:40
    Puppet                   17:38:40
    Riemann           2 days 18:52:20
    Rspamd                      59:20
    syslog-ng         1 day   6:18:50
    Vox Pupuli       10 days 19:24:40
    wtr               1 day   3:19:00
    ---------------------------------
    Total            39 days 22:57:30

I think that a few things are worth noticing, so let's break down this list (skipping some entries of lower interest) with the variation of work time recorded compared to the previous year.

Choria (-76.517 %)

While 2025 looks quite idle compared to 2024, in reality 2024 has been extra busy. I got kind of "sponsored" to spend some days refactoring and improving the Choria puppet modules to reduce the maintenance burden. Last year was therefore back to usual, only requiring a few hours of contributions.

Given the Puppet situation (see bellow) and the way Choria is evolving, I cannot yet predict how this will change in the next years.

FreeBSD (+16.772 %)

Activity on FreeBSD has been overall quite similar to the one of the previous year.

I expect similar figures for next year, or maybe a slight increase given that Perforce has stopped releasing Puppet versions but OpenVox packages are now being shipped (see bellow).

OpenSearch (+70.664 %)

I am quite surprised by this one. I needed some tooling for a customer, and started to monitor the time spent on this project wondering if adding it to wtr(1) was worth the time. It happens that the tooling has been so helpful I still continue to work on/with it on a regular basis to audit the OpenSearch clusters I manage.

Next year will probably see a decrease unless a customer hires me to tweak or setup a new cluster.

Puffy (n/a %)

Puffy is an old project with low maintenance needs, but I recently had to add a new feature so though it would make sense to track the time spent there because a few times a year, I have an edge-case that require a bit of work.

I do not expect activity to increase on this project in the next years as the goal of this project is to express firewall rules for a bunch of hosts in a network in an error-prone way, but the design of netfilter gets in the way when you try to bend it to fit in the clear and simple design of pf.

Puppet (-89.330 %) / Vox Pupuli (+51.481 %) / OpenVoxProject (+n/a %)

Big changes here! End of 2024, Perforce announced the end of the Open Source version of Puppet. Maintenance of Puppet by Perforce was already almost nonexistent, but as one would guess, the situation just degraded further. The Vox Pupuli community had to fork the project and created a new sub-community called OpenVoxProject, which I promptly added to my wtr(1) configuration. I now try to minimize the time I spend doing free work for Perfoce (which is easier to say that to do given that they own a bunch of "base" modules they do not maintain much and for which I can merge PRs and publish new versions. From time to time we have to fix bugs and do a release). I rather invest time in helping with the OpenVox fork.

In the next years, I will continue to work preferably on the community tooling of the OpenVox project and I would be happy to reduce further the time I spend on Puppet.

Riemann (-39.136 %)

Not much has changed in the Riemann ecosystem during the last year, but I have found a new thing to play with that may end-up with changes in the future. I try to normalize fields in logs I collect, and while it only scratch the surface, Elastic Common Schema (ECS) seems worth a try.

Depending on how we adopt it at $WORK, we might need to contribute some ECS bits to the Riemann ecosystem.

syslog-ng (-12.303 %)

While syslog-ng is mostly feature-complete, but from time to time a new edge case require some development (and the software regularly gains new capabilities). Last year was similar to the previous one on regard to this.

I would not be surprised that my ECS evaluation brings new needs for syslog-ng, and will be happy to work on them if so. On a side note, working with the syslog-ng folks is always a breeze.

wtr (+100.041 %)

The project is now almost 3 years old, and I realize that no release has even been tagged. I guess that I rely on it enough to consider it production ready, so a 1.0.0 release is due!

Conclusion

Not all projects I work on are configured in wtr(1), so this list is not exhaustive and some time has not been tracked. But globally, this tells that each year, I basically spend one full month contributing to Free Software. I feel like this has been quite stable in the past years, but wtr(1) will help me to track this in the future, and confirm if what I think matches the reality.

According to wtr(1), it took me ~5 hours to write this blog post. That feels a lot, and I am sure I could have spend less time rewording paragraphs, but this blog has been silent for almost 10 years and the front page highlighted the availability of some software that reached EOL 5 years ago, so an update was really needed! I secretly hope that I will be able to at least do a similar post each year, avoiding this website to look deader than an old movie of George Romero.

The following article describes how I used this ports to update to Puppet 5. If you try to update, please tell me if you succeeded or failed, and how to improve this!

Upgrade PostgreSQL to 9.6

Since I use PuppetDB, and Puppet 5.0 requires PuppetDB 5.0, and PuppetDB 5.0 requires PostgreSQL 9.6+, the first step was to update my PostgreSQL cluster (I was running PostgreSQL 9.4).

In my case, it's worth to know that postgresql96-client and postgresql94-contrib conflict. So I had to remove postgresql94-contrib before upgrading:

sudo -u pgsql pg_dumpall -f full-db-dump.sql
/usr/local/etc/rc.d/postgresql stop
echo "DEFAULT_VERSIONS+=      pgsql=9.6" >> /etc/make.conf
pkg delete -f postgresql94-contrib
portmaster -o databases/postgresql94-client databases/postgresql96-client
portmaster -o databases/postgresql94-server databases/postgresql96-server
portmaster databases/postgresql96-contrib

Now that PostgreSQL 9.6 is installed, the databases can be restored. PostgreSQL data directory was moved from /usr/local/pgsql/data to /var/db/postgres/data96, so you may have to copy your local configuration there. Morevover, there is now a postgres user which replaces the previous pgsql user:

/usr/local/etc/rc.d/postgresql initdb
# Adjust server configuration in ~postgres/data96
/usr/local/etc/rc.d/postgresql start
sudo -u postgres psql -f full-db-dump.sql

So, we have no all requirements ready for PuppetDB.

Upgrade PuppetDB and Puppet

We will start by stopping PuppetDB, which will make the Puppet Master unhappy, so we also want to stop that Puppet Master. In my case, this service is provided through Apache 2.4 so I will stop this service too:

service puppet stop
service apache24 stop
service puppetdb stop

Basically, for each foo/bar4 port, we want to install foo/bar5:

sudo portmaster -o sysutils/puppet5 sysutils/puppet4
sudo portmaster -o databases/puppetdb5 databases/puppetdb4
sudo portmaster -o databases/puppetdb-terminus5 databases/puppetdb-terminus4

Last step constist in restarting all services:

service puppetdb start
service apache24 start
service puppet start

Switching to C++ Facter

Facter used to be a Ruby program, but was rewritten in C++. For now, the default is still to use Facter 2.x (the Ruby one), but I have submitted a bunch of pull-requests to make it possible to use Facter 3.x (the C++ one) as a drop-in replacement to Facter 2.x.

You are therefore encouraged to switch to the C++ version of facter and report joy and depression:

sudo portmaster -o sysutils/facter sysutils/rubygem-facter

Thank you for your valuable feedback!

The device is viewed as a composite one consisting of a keyboard and a mouse. The mouse feature can be disabled/enabled using a mouse lock button on the remote.

Only problem, when the device wakes up from standby mode, the mouse device is always enabled and the cursor moves on screen, selecting whatever is below it… Pressing the mouse lock button stops the madness, but as the mouse enter standby mode after a few seconds of inactivity the same problems happen over and over again.

I fixed this by software. This was a 2 steps process:

1. Reduce the mouse sensitivity so that the cursor does not move when the device moves;
2. Trigger keypresses on mouse clicks.

Reducing the mouse sensitivity

The first idea that comes to mind is to reduce the mouse sensitivity in dramatic proportions so that important mouse motion produce a cursor move of no more than 0 pixels. This can be achieved by setting a custom transformation matrix to the mouse device. The default transformation matrix is an identity one (table 1).

Replacing it with the matrix from table 2 gives appropriate results.

This can be setup using the following Xorg configuration (for example in /usr/share/X11/xorg.conf.d/80-airmouse.conf on a GNU/Linux system):

Section "InputClass"
    Identifier "Air Mouse"
    MatchProduct "AliTV Remote V1 Airmouse"
    MatchIsPointer "on"
    Option "TransformationMatrix" "0.00000001 0 0 0 0.00000001 0 0 0 1"
EndSection

Triggering keypresses on mouse clicks

The OK and Return buttons do not behave the same way depending on the mouse lock status. When the mouse is enabled, they trigger left and right clicks, otherwise they trigger Return and Escape keypresses. Since the mouse is enabled when the device wakes up, it is necessary to remap mouse clicks to keyboard events, otherwise you still have to lock the cursor over and over again.

xbindkeys(1) is the tool of choice for this purpose. It can catch mouse events and trigger an action when then occur. xvkbd(1) can then be used to send keypress events. xbindkeys(1) is configured with the ~/.xbindkeysrc file as follows:

"xvkbd -text 'r'"
  b:1

"xvkbd -text 'e'"
  b:3

Button 1 (left click) will send a Return key keypress, and button 3 (right click) will send a Escape key keypress. Then we just have to start xbindkeys(1) when Kodi starts. This depends on the way Kodi starts on your system, in my case desktop application autostart is disabled so I achieved this throught simple a ~/.kodi/userdata/autoexec.py script:

import os
os.system('/usr/bin/xbindkeys')

I finally took the time to search for a solution. I post it here for two reasons: a) I might need this information at some point in the future and am more likely to find it that way and b) I might not be the only one here which faced this situation.

The first step was to modify my Xorg configuration to be a bit more verbose about the process of choosing a screen resolution when X starts to see if something was different with both drivers. This can be achieved by editing the Monitor section:

Section "Monitor"
    ...
    Option "ModeDebug" "TRUE"
EndSection

With the new driver, no section for Validating Mode "1920x1080", but when trying to validate other modes, the driver reported that it would be happier with EDID information from the screens:

217 (II) Feb 07 09:52:30 NVIDIA(GPU-0):   Validating Mode "640x350":
218 (II) Feb 07 09:52:30 NVIDIA(GPU-0):     640 x 350 @ 85 Hz
219 (II) Feb 07 09:52:30 NVIDIA(GPU-0):     Mode Source: X Server
220 (II) Feb 07 09:52:30 NVIDIA(GPU-0):       Pixel Clock      : 31.50 MHz
221 (II) Feb 07 09:52:30 NVIDIA(GPU-0):       HRes, HSyncStart :  640,  672
222 (II) Feb 07 09:52:30 NVIDIA(GPU-0):       HSyncEnd, HTotal :  736,  832
223 (II) Feb 07 09:52:30 NVIDIA(GPU-0):       VRes, VSyncStart :  350,  382
224 (II) Feb 07 09:52:30 NVIDIA(GPU-0):       VSyncEnd, VTotal :  385,  445
225 (II) Feb 07 09:52:30 NVIDIA(GPU-0):       H/V Polarity     : +/-
226 (WW) Feb 07 09:52:30 NVIDIA(GPU-0):     Mode is rejected: Only EDID-provided modes are allowed on
227 (WW) Feb 07 09:52:30 NVIDIA(GPU-0):     DFP-0.

I enabled EDID which was previously disabled because the screen reported invalid information:

Section "Device"
    ...
    #Option "IgnoreEDIDChecksum" "DFP-0, DFP-1"
EndSection

With the new driver, a Validating Mode "1920x1080" section appeared but with the very same Mode is rejected: Only EDID-provided modes are allowed on DFP-0. The old driver provided a bit more of information actually:

1822 (II) Feb 07 09:54:10 NVIDIA(GPU-0):   Validating Mode "1920x1080":
1823 (II) Feb 07 09:54:10 NVIDIA(GPU-0):     1920 x 1080 @ 50 Hz
1824 (II) Feb 07 09:54:10 NVIDIA(GPU-0):     Mode Source: EDID
1825 (II) Feb 07 09:54:10 NVIDIA(GPU-0):       Pixel Clock      : 148.50 MHz
1826 (II) Feb 07 09:54:10 NVIDIA(GPU-0):       HRes, HSyncStart : 1920, 2448
1827 (II) Feb 07 09:54:10 NVIDIA(GPU-0):       HSyncEnd, HTotal : 2492, 2640
1828 (II) Feb 07 09:54:10 NVIDIA(GPU-0):       VRes, VSyncStart : 1080, 1084
1829 (II) Feb 07 09:54:10 NVIDIA(GPU-0):       VSyncEnd, VTotal : 1089, 1125
1830 (II) Feb 07 09:54:10 NVIDIA(GPU-0):       H/V Polarity     : +/+
1831 (WW) Feb 07 09:54:10 NVIDIA(GPU-0): The EDID for Samsung SMBX2240 (DFP-1) contradicts itself: mode
1832 (WW) Feb 07 09:54:10 NVIDIA(GPU-0):     "1920x1080" is specified in the EDID; however, the EDID's
1833 (WW) Feb 07 09:54:10 NVIDIA(GPU-0):     valid VertRefresh range (56.000-75.000 Hz) would exclude
1834 (WW) Feb 07 09:54:10 NVIDIA(GPU-0):     this mode's VertRefresh (50.0 Hz); ignoring VertRefresh
1835 (WW) Feb 07 09:54:10 NVIDIA(GPU-0):     check for mode "1920x1080".
1836 (II) Feb 07 09:54:10 NVIDIA(GPU-0):     Viewport                 1920x1080+360+22
1837 (II) Feb 07 09:54:10 NVIDIA(GPU-0):       Horizontal Taps        0
1838 (II) Feb 07 09:54:10 NVIDIA(GPU-0):       Vertical Taps          0
1839 (II) Feb 07 09:54:10 NVIDIA(GPU-0):       Base SuperSample       x4
1840 (II) Feb 07 09:54:10 NVIDIA(GPU-0):       Base Depth             32
1841 (II) Feb 07 09:54:10 NVIDIA(GPU-0):       Distributed Rendering  1
1842 (II) Feb 07 09:54:10 NVIDIA(GPU-0):       Overlay Depth          32
1843 (II) Feb 07 09:54:10 NVIDIA(GPU-0):     Mode is valid.

Okay, since all this seems to be related to EDID, and because some major changes where introduced in version 302.xx of the NVidia driver, let's try to patch it! I could not find a tool to dump the EDID directly from FreeBSD, however when Xorg starts, it prints a hex dump of it so it is actually quite trivial to get it from the log file (don't want to code? Clone!).

sysutils/edid-decode can be used to easily locate relevant information from the EDID dump (monitor range), and spot inconsistencies:

Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   4c 2d 84 06 32 32 42 43 0e 15
version:         01 03
basic params:    80 30 1b 78 2a
chroma info:     78 f1 a6 55 48 9b 26 12 50 54
established:     bf ef 80
standard:        71 4f 81 00 81 40 81 80 95 00 b3 00 a9 40 95 0f
descriptor 1:    02 3a 80 18 71 38 2d 40 58 2c 45 00 dd 0c 11 00 00 1e
descriptor 2:    00 00 00 fd 00 38 4b 1e 51 11 00 0a 20 20 20 20 20 20
descriptor 3:    00 00 00 fc 00 53 4d 42 58 32 32 34 30 0a 20 20 20 20
descriptor 4:    00 00 00 ff 00 48 39 58 42 34 30 31 30 32 34 0a 20 20
extensions:      01
checksum:        b0

Manufacturer: SAM Model 684 Serial Number 1128411698
Made week 14 of 2011
EDID version: 1.3
Digital display
Maximum image size: 48 cm x 27 cm
Gamma: 2.20
DPMS levels: Off
Supported color formats: RGB 4:4:4, YCrCb 4:2:2
First detailed timing is preferred timing
Established timings supported:
720x400@70Hz
640x480@60Hz
640x480@67Hz
640x480@72Hz
640x480@75Hz
800x600@56Hz
800x600@60Hz
800x600@72Hz
800x600@75Hz
832x624@75Hz
1024x768@60Hz
1024x768@70Hz
1024x768@75Hz
1280x1024@75Hz
1152x870@75Hz
Standard timings supported:
1152x864@75Hz
1280x800@60Hz
1280x960@60Hz
1280x1024@60Hz
1440x900@60Hz
1680x1050@60Hz
1600x1200@60Hz
1440x900@75Hz
Detailed mode: Clock 148.500 MHz, 477 mm x 268 mm
1920 2008 2052 2200 hborder 0
1080 1084 1089 1125 vborder 0
+hsync +vsync
Monitor ranges (GTF): 56-75Hz V, 30-81kHz H, max dotclock 170MHz
Monitor name: SMBX2240
Serial number: H9XB401024
Has 1 extension blocks
Checksum: 0xb0 (valid)

CEA extension block
Extension version: 1
0 8-byte timing descriptors
Detailed mode: Clock 148.500 MHz, 477 mm x 268 mm
1920 2448 2492 2640 hborder 0
1080 1084 1089 1125 vborder 0
+hsync +vsync
Detailed mode: Clock 74.250 MHz, 477 mm x 268 mm
1280 1390 1430 1650 hborder 0
720  725  730  750 vborder 0
+hsync +vsync
Detailed mode: Clock 74.250 MHz, 277 mm x 286 mm
1280 1720 1760 1980 hborder 0
720  725  730  750 vborder 0
+hsync +vsync
Detailed mode: Clock 27.000 MHz, 477 mm x 286 mm
720  732  796  864 hborder 0
576  581  586  625 vborder 0
-hsync -vsync
Detailed mode: Clock 27.000 MHz, 477 mm x 286 mm
720  736  798  858 hborder 0
480  489  495  525 vborder 0
-hsync -vsync
Checksum: 0x0 (should be 0x99)

EDID block does not conform at all!
Block has broken checksum

After changing the lower limit of the vertical refresh rate from 56 Hz (0x38) to 50 Hz (0x32) and adjusting the checksums, it's time to see if the situation is improved. Once more we have to tweak xorg.conf to tell Xorg to use our dumps instead of querying the screens for EDID information:

Section "Device"
    ...
    Option "CustomEDID" "DFP-0:/usr/local/etc/X11/EDID-BX2240-FIXED; DFP-1:/usr/local/etc/X11/EDID-BX2240-FIXED"
EndSection

And suddenly, it worked!

February 11th, 2013 edit

I wrote an e-mail to the screen manufacturer (Samsung) asking for assistance. I will publish their response on this blog as soon as I get one. The sent message is basically:

Hi,

I own two BX2240 screens. These screens provide invalid EDID information (I wrote an article [1] about that) that makes them unusable with the prorietary NVidia driver version 302.xx and up. It is possible to workaround the problem at the OS level (I provide some instructions in my article) however it would be better to put valid information back into the screen so that they work out of the box.

However, you don't provide any information about this on your website. Can you please send me a technical notice providing information on flashing EDID information if it's possible, and if not, the location of the EEPROM containing the wrong EDID information so that I can replace it and continue to use my screens in proper conditions?

Please find attached to this message the fixed EDID information I use at the moment and want to flash back into my screens.

Kind regards,
Romain Tartière

References:

1. https://romain.blogreen.org/blog/2013/02/patching-screens-edid-information/

More recently (October 1st, 2012), I made major changes in the freebsd-texlive project to fix the long-standing problem of TeXLive shipping distfiles with no version in the filename and replacing them in place. After setting up a new mirror with renamed distfiles (sponsored by NFrance, a French hosting company using the FreeBSD operating system. Many thanks to them for providing hosting and bandwidth!), updating the program that creates and updates ports, updating the updating tools, switching to the new mirror and updating all ~2250 ports; all the caveats around this choice from the maintainers of the TeXLive distribution should be gone!

This change will however not be without consequences for users. Distfiles version numbers where created by using the date at which a file appeared or where updated on the upstream mirrors, but because of the mirroring delays, the file mtime could be earlier by more than one day. As a consequence, a file updated on 17th May, 2012 could have version number 20120518 (getting the real package version number in the distfile is a PITA). Because having the version in the distfile filename require consistent dates, the new ports use the date from the upstream distfile mtime, and many ports had their version going backwards… PORTEPOCH have so been bumped, and port management tools will want to update all these ports which are in fact unchanged.

It's the first time such a bad situation happen in the freebsd-texlive repository. I hope this will be the last and apologies to users who will be worried with this massive update.

Happy TeXing!

1. it was on some topics I had interests in but had not as much time as I would have liked to to dig in;
2. it was focussed on my main operating system.

I bought the book and although it was rather small (~140 pages) enjoyed learning quite a large amount of things about the FreeBSD kernel.

So, when I was contacted by No Stash Press to know if I would be interested in a review copy of their upcoming book FreeBSD Device Drivers by the same author in exchange of writing what I though about it, I had no hesitation and accepted the deal.

Just like the preceding book, this one is based on examples, each chapter focussing on a different aspect of device drivers, and going progressively further and further in the details of the kernel, explaining how things work and why they do work that way so that the reader can better understand the involved mechanisms, even if he is not an Operating Systems guru.

Precious information about the FreeBSD kernel (like what you have in The Design and Implementation of the FreeBSD Operating-System but in a more up-to-date and friendlier fashion) are spread all along the book, and — apart from the long C listings — the style is quite pleasant to read.

To sum-up, this book is definitively a must have for anybody interested in how are designed FreeBSD device drivers, not mentioning those who are interested in writing their very own ones for the FreeBSD operating system!

Many thanks Joseph for this awesome book!

On the next day, I eventually realised that an hard disk was logically missing on the system and the ZFS mirror it was belonging to was working in a degraded mode. This disk holding a swap partition, the panic quite makes sense: some data was stored there and could not be paged-out anymore.

# zpool list
NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
data   294G  68,2G   226G    23%  1.25x  DEGRADED  -
tank  1,81T   300G  1,52T    16%  1.06x  ONLINE  -

# zpool status data
  pool: data
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
        the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
   see: http://www.sun.com/msg/ZFS-8000-2Q
  scan: none requested
config:

NAME                                            STATE     READ WRITE CKSUM
data                                            DEGRADED     0     0     0
  mirror-0                                      DEGRADED     0     0     0
    gptid/36711e52-a69e-11de-8adf-0018f38af467  ONLINE       0     0     0
    15152536002702365387                        UNAVAIL      0     0     0  was /dev/gptid/602da1ae-c474-11de-960d-0008a14dbca1

errors: No known data errors

This disk already had problems in the past and I even had to improve sysutils/smartmontools periodic script to take into account SMART attributes that have been failing at some point in the past but have recovered since that time on that disk. This time, the disk is really dead, so no other choice than changing it. Hopefully, I have a brunch of spare heard disks on the shelve, so I took two 500 GB disks to replace the two 320 GB of the degraded ZFS pool.

I first replaced the broken disk with a new one, identified it using geom(8) and partitioned using basically the same settings I used when installing FreeBSD on full-ZFS:

# geom disk list ada1
Geom name: ada1
Providers:
1. Name: ada1
   Mediasize: 500107862016 (465G)
   Sectorsize: 512
   Mode: r2w2e3
   descr: ST3500418AS
   ident: (null)
   fwsectors: 63
   fwheads: 16

# geom part create -s GPT ada1
ada1 created
# geom part add -s 128 -t freebsd-boot ada1
ada1p1 added
# geom part add -s 4G -t freebsd-swap ada1
ada1p2 added
# geom part add -t freebsd-zfs ada1
ada1p3 added
# geom part show ada1
=>       34  976773101  ada1  GPT  (465G)
         34        128     1  freebsd-boot  (64k)
        162    8388608     2  freebsd-swap  (4.0G)
    8388770  968384365     3  freebsd-zfs  (461G)

# geom part bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1
bootcode written to ada1

I then replaced the unavailable ZFS partition with the new one:

# zpool replace data 15152536002702365387 ada1p3
Make sure to wait until resilver is done before rebooting.

If you boot from pool 'data', you may need to update
boot code on newly attached disk 'ada1p3'.

Assuming you use GPT partitioning and 'da0' is your new boot disk
you may use the following command:

gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0

… waited a few moments for resilvering to finish:

% zpool status data
  pool: data
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
	continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Mon Jan  2 19:26:44 2012
    330M scanned out of 68,2G at 4,07M/s, 4h44m to go
    329M resilvered, 0,47% done
config:

	NAME                                            STATE     READ WRITE CKSUM
	data                                            DEGRADED     0     0     0
	  mirror-0                                      DEGRADED     0     0     0
	    gptid/36711e52-a69e-11de-8adf-0018f38af467  ONLINE       0     0     0
	    replacing-1                                 UNAVAIL      0     0     0
	      15152536002702365387                      UNAVAIL      0     0     0  was /dev/gptid/602da1ae-c474-11de-960d-0008a14dbca1
	      ada1p3                                    ONLINE       0     0     0  (resilvering)

errors: No known data errors

… then shut the system down, replaced the working 320 GB disk by a new 500 GB one and booted into FreeBSD again:

% zpool status data
  pool: data
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
	the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
   see: http://www.sun.com/msg/ZFS-8000-2Q
  scan: resilvered 68,2G in 1h58m with 0 errors on Mon Jan  2 21:25:42 2012
config:

	NAME                     STATE     READ WRITE CKSUM
	data                     DEGRADED     0     0     0
	  mirror-0               DEGRADED     0     0     0
	  3635039039460500206    UNAVAIL      0     0     0  was /dev/gptid/36711e52-a69e-11de-8adf-0018f38af467
	    ada1p3               ONLINE       0     0     0

errors: No known data errors

Same story with the other disk:

geom part create -s GPT ada0
ada0 created
# geom part add -s 128 -t freebsd-boot ada0
ada0p1 added
# geom part add -s 4G -t freebsd-swap ada0
ada0p2 added
# geom part add -t freebsd-zfs ada0
ada0p3 added
# geom part show ada0
=>       34  976773101  ada0  GPT  (465G)
         34        128     1  freebsd-boot  (64k)
        162    8388608     2  freebsd-swap  (4.0G)
    8388770  968384365     3  freebsd-zfs  (461G)

# geom part bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
bootcode written to ada0
# zpool replace data 3635039039460500206 ada0p3
Make sure to wait until resilver is done before rebooting.

If you boot from pool 'data', you may need to update
boot code on newly attached disk 'ada0p3'.

Assuming you use GPT partitioning and 'da0' is your new boot disk
you may use the following command:

	gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0

When done, I saw that the available space on the data zpool was still the same:

# zpool list
NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
data   294G  65,3G   229G    22%  1.19x  ONLINE  -
tank  1,81T   300G  1,52T    16%  1.08x  ONLINE  -

This is due to the autoexpand property set to off by default and that should be set to on before replacing disks if this feature is desired.

# zpool set autoexpand=on data

Hopefully, it is possible to use the zpool(8)'s online command to make ZFS take into account the extra space available for the pools:

# zpool online -e data ada0p3

# zpool list
NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
data   460G  65,3G   395G    14%  1.20x  ONLINE  -
tank  1,81T   300G  1,52T    16%  1.06x  ONLINE  -

Location of Feature Keys on the ST2030.

I finally decided to configure these keys with proper numbers instead of browsing my directory each time I want to make a call. But the phone only ships with a single paper sheet to hand-write the names corresponding to the configured numbers and my hand-writing is somewhat like what would produce a drunk cow with Creutzfeldt–Jakob disease. I browsed the Internet for a sheet template to fill-in, print and cut, but was unable to find some.

So, I took Inkscape and did one myself. For your convenience, I make it available as the original SVG file (so that you can fill-it before printing) and a PDF file for those who like hand-writing:

• Thomson ST2030 Feature Key Sheet Template SVG;
• Thomson ST2030 Feature Key Sheet Template PDF.

If you don't have a precise idea of which numbers you call often, you can extract this information from Asterisk's log file. In my case, my calls come from the internal context so I just did this to get the top-20 of the numbers I call:

% cat /var/log/asterisk/cdr-csv/Master.csv | grep 'internal' | cut -d, -f3 | \
    sed -e 's|+33|0|' | sort | uniq -c | sort -nr | head -n 20

The show is called Les aventures du comte de Malamanteau (French for Earl Malamanteau's Adventures), and is mostly music centered: during one hour, a selection of music from a given country (a different one for each issue) is aired. So far, we have visited South Africa, Kenya, Tunisia, Lebanon, Ukraine and Finland.

A website has been setup for listeners to have access to broadcasted shows and gathering more information about the music we chose and location we visited: malamanteau.fr.

The website is generated using Blogreen, a project I started bazillon years ago and that recently reached a form that makes it usable (after being re-thought from scratch a couple times). Basically, Blogreen is a tool for building websites from free-form XML data. If you consider your data to be some models, regarding the facts that the system expects you to provide views, Blogreen is basically the controller of an XSLT MVC data processing system.

The documentation is currently somewhat sparse, so if you are interested in the project, you'd better subscribe to the blogreen-announce mailing-list to be informed of major news (documentation availability, releases (maybe one day), …) or if you are interested in how it works, to the blogreen-devel mailing-list for commit messages.

In order to help users who don't want to install the whole TeXLive collection (~2000 ports), a basic script has been developed to ease-up finding which port provides some file required by a given package.

As usual, feedback is welcomed!