Dynamic module loading via modload has a couple of issues with a NetBSD domU kernel, so it is not possible to modload iscsi.kmod.
In order to enable in-kernel iSCSI support, you’ll have to add the following lines to your kernel configuration and rebuild it:
dmesg should show this line:
You’ll then be able to start iscsid and manage your targets using iscsictl.
At ${DAYWORK}, I happen to use IBM’s cloud: SoftLayer. It has all the features you’d expect from such a platform, and can instantiate pretty much any major GNU/Linux distribution you’d think of; but here’s the thing, we also use NetBSD for some infrastructure services, and as you’d guess, there’s no NetBSD support at all on SoftLayer.
I had to reverse some bits of their provisioning system to understand how to achieve NetBSD installation, but most of all, automatic provisioning.
I recently had the need to mount an UFS2 (NetBSD) partition under GNU/Linux, and while this is surprising, a standard Linux distro, Debian in my case, is not able to mount it in read/write mode.
I came across this project https://github.com/DanielO/fuse-ufs2 which has basic UFS2 read/write support. It is not very stable, I made it crash a couple of times while using vim on the mounted partition, but it does support simple operations like cp, rm and such.
A while ago, I had my ${DAYWORK} workstation running NetBSD, and honestly, it did pretty well. Things began to become more painful when there was no more DRI acceleration with the radeon driver, it then did an okay-ish job, but the overall desktop became somewhat laggy.
It was told someone was working on porting KMS/GEM, that was more than a year ago, and as of today, that work -and I guess it is not an easy one- isn’t mature enough to be used as a workstation, I need my desktop to run various tools, and not only terminal-based ones.
A while ago, I had my ${DAYWORK} workstation running NetBSD, and honestly, it did pretty well. Things began to become more painful when there was no more DRI acceleration with the radeon driver, it then did an okay-ish job, but the overall desktop became somewhat laggy.
It was told someone was working on porting KMS/GEM, that was more than a year ago, and as of today, that work -and I guess it is not an easy one- isn’t mature enough to be used as a workstation, I need my desktop to run various tools, and not only terminal-based ones.
Comme je l’expliquais dans le post précédent, je suis passé chez SFR/neuf avec un forfait fibre. La box de l’opérateur, la neufbox donc, ne supportant pas de mode bridgé, quelques opérations sont nécessaires à une intégration cohérente dans votre réseau domestique.
Je me suis grandement inspiré de cette excellente documentation pour réaliser le bypass de la neufbox, cependant plusieurs éléments du tutoriel ne sont plus d’actualité. Je ne rentrerai donc pas dans le détail théorique puisque l’article de neufbox4.org est parfaitement explicite, mais focaliserai sur les méthodes à mettre en œuvre pour faire rentrer votre neufbox dans votre réseau local.
I need vacations, I really do.
Yesterday night, I decided to upgrade my home’s Internet gateway from NetBSD 6.0 to 6.1. As I already had some success with jmmv’s sysupgrade, I simply ran
… on an i386 machine. That obviously lead to massive failure such as:
As I still had an SSH session opened on that server, my first thought was to use /rescue’s binaries, which are statically linked, but guess what, /rescue is also part of base.tgz, the first set installed by sysupgrade(8). Doomed? not yet. I remembered that my gateway mounts /usr/pkgsrc over NFS, from my NetBSD NAS. So I fetched i386’s base.tgz on the NFS server, extracted /rescue/sh and /rescue/tar, copied them to /usr/pkgsrc and made sh suid root so I could call tar with the -C / flag in order to replace amd64 binaries. For some reason, rescue’s tar would not gunzip base.tgz, I really was not brave enough to dig into this, so I gunzipped it on the NFS server.
I’ve been obsessed with SaltStack for over a week. This infrastructure management suite is exactly what I needed for both my personal and professional servers: simple but modular, written in python, not depending on a thousand unnecessary complex messaging stacks as it bundles zeromq, capable of both orchestration and configuration management, all this through comprehensive, well documented API and commands.
Only drawback was it had poor NetBSD support. Was :)
It’s been a long time since I’ve dug into python, so it took me a little bit of effort, but Salt now has full support of pkgin in its generic packaging functions, knows how to handle NetBSD services and is capable of dealing with NetBSD’s sysctl(8) and sysctl.conf.
I know about estd for a while, that daemon “dynamically sets the CPU-frequency on Enhanced SpeedStep, PowerNow, and APCI P-States-enabled CPUs depending on current cpu-utilization” (manpage excerpt). Thing is, I’ve never seen any CPU changing from its current speed while monitoring the machdep.powernow.frequency.current sysctl.
In order to understand what was happening, I started estd with the -o flag, which outputs the CPU-frequencies as they are set. I then realized that the “ligh watermark percentage” and “low watermark percentage” default values were way too high (respectively 40 and 80) and were never reached, so the CPU speed was never changed.
And voila, I knew this was going to happen, I finally switched to tmux. I will not explain here why this software is better than GNU screen, simply put, tmux is now part of the base system of nearly all BSD derivative operating systems (NetBSD among them), and it makes my life easier.
Instead, I’ll point out here all the resources that helped me switching rather quickly:
tmux -2) http://benjaminthomas.org/2012-03-28/256-colors-in-tmux.htmlHere’s my ~/.tmux.conf, which is pretty much the standard screen-keys.conf available with the package, with only some small customizations like the status bar and some fixes: