Creating new BE’s using snapshots and clones can get messy with dependencies all over the place. I had an epiphany the other day, why not create a snapshot on the current dataset, send that snapshot to a new dataset within the same zpool (or elsewhere), and subsequently destroy the (two!) snapshots?
Instant transfer of data, and no strings attached to either dataset once the snapshots have been removed. Continue reading Cloning a ZFS dataset using only
zfs send, and
The 20150220 entry in
/usr/ports/UPDATING contains no instructions for upgrading
lang/php56, at least not for us compiling our own ports.
I learned the hard way using
portupgrade what needs to be done. I have summarised my steps into the script below. Use the script as a guide, and if you do run my script, then you’re on your own. To save you some effort, here’s the script ready for downloading. Continue reading Upgrading
A couple of postings ago, I complained a lot about the endless patch cycle when starting and quitting Star Trek Online over the last few weeks. With today’s release, Season 10, The Iconian War, all that hassle is gone, completely.
However, I’m still of the opinion that the continous pre- and post-patching of the game’s files prior to launching a new season is counterproductive and wastes precious user bandwith. Why not add an option to the STO Launcher giving the user the choice between staying ahead of future changes and patching only what’s necessary to play the current game? While you’re at it, why not add to the STO Launcher a brief description of what’s being patched, while it’s being patched, and why?
To much appreciation, the previous Sector Blocks are replaced with Quadrant Blocks. In other words, you can travel directly from Federation space to Klingon space or to Romulan space in one go. The quantum slipstream drive is quite handy. I noticed some new sectors has appeared in “the south” of the galaxy map.
If you’re into Star Trek and haven’t tried Star Trek Online, then you probably should.
Intel Dual Band Wireless-AC 7260 fails to notify Windows 7 when the SSID changes. The result is that the wireless interface retains the previous and possibly invalid IP addresses and other settings. The latest driver, A11, only a few days old, isn’t helpful at all.
I usually avoid installing Intel’s own utility for managing wireless connections, as I feel this should be left in the capable hands of the operating system and the driver. Maybe I should think twice about that.
The current solution is to manually force Windows into releasing and renewing the IP addresses after switching to a different SSID.
dns/bind910 gained native chroot support in r382109. Those of us who used to store the BIND files in
/var/named/etc/namedb and ran BIND with
/var/named as the chroot environment, must do five things:
- Rename the
/var/named directory to something else, like
/var/Named. This is to avoid upsetting
make -C /usr/src delete-old and still retain the meaning of the directory’s name.
- Rename the
/var/Named/etc/namedb directory to
/var/Named/usr/local/etc/namedb/named.conf to reflect that the BIND files now resides in
/usr/local/etc/namedb, as seen from within the chroot environment.
- Change the appropriate line in
/etc/rc.conf to read
- Restart BIND using
/usr/local/etc/rc.d/named restart, or start BIND using
/usr/local/etc/rc.d/named start if the former fails.
Since last night the Star Trek Online launcher has swung between patching 3808 KB, and patching 3034 MB, and in the latter case, the launcher stops when reaching about 1330 KB. It all began after patching the initial ~3 GB earlier last night. Endless patch cycles such as this one, was one of the reasons I left the game 5 years ago. A workaround can be found at the end of this posting. Continue reading Endless patch cycle in Star Trek Online
smartd sent me not one, but two emails today, regarding
/dev/ada1. Continue reading /dev/ada1 failing