Last Friday I updated the Debian 7 installation on my homelab NAS box. Prior to that I had updated the firmware of its (IBM OEM) i340-T4 NIC with version 19.0 of the Intel “Ethernet Connections Boot Utility”, as explained earlier. After a reboot all of the i340 interfaces were gone. The card was listed in lspci and the dmesg output, but the driver wasn’t loaded. Manual loading didn’t work either:
Mar 21 15:40:58 labnas kernel: [ 2172.966771] Intel(R) Gigabit Ethernet Network Driver - version 3.2.10-k
Mar 21 15:40:58 labnas kernel: [ 2172.966774] Copyright (c) 2007-2011 Intel Corporation.
Mar 21 15:40:58 labnas kernel: [ 2172.966823] igb 0000:01:00.0: setting latency timer to 64
Mar 21 15:40:59 labnas kernel: [ 2173.790497] igb: probe of 0000:01:00.0 failed with error -13
Mar 21 15:40:59 labnas kernel: [ 2173.790519] igb 0000:01:00.1: setting latency timer to 64
Mar 21 15:41:00 labnas kernel: [ 2174.614178] igb: probe of 0000:01:00.1 failed with error -13
Mar 21 15:41:00 labnas kernel: [ 2174.614198] igb 0000:01:00.2: setting latency timer to 64
Mar 21 15:41:00 labnas kernel: [ 2175.437858] igb: probe of 0000:01:00.2 failed with error -13
Mar 21 15:41:00 labnas kernel: [ 2175.437880] igb 0000:01:00.3: setting latency timer to 64
Mar 21 15:41:01 labnas kernel: [ 2176.261527] igb: probe of 0000:01:00.3 failed with error -13
So it seems the updated igb driver from Debian 7.4 is broken. Continue reading
The last post was about a simple DNS server installation using Debian / Raspbian and bind. I already mentioned that this approach has the advantage of greater flexibility and more features than the DNS functionality that may come with your NAS or router. Particularly regarding IPv6, and that is what we are going to add to the DNS server now. Continue reading
The setup of my homelab, especially the IPv6-only configuration I’m running right now, requires a DNS server. To me as a Unix guy it was obvious that this basic infrastructure service needs to be deployed in any case. But some discussions on Twitter and especially with William Lam and on his blog indicated that this may not be a no-brainer for those who are VMware followers, but not that familiar with DNS. William pointed out that DNS is not a hard requirement, and I appreciate he takes the time to describe how to run VMware products without a DNS server. I fully trust him that this is possible (if there’s one person I would trust on that than it’s him!). But for many reasons, including the official VMware vSphere documentation, I still suggest to deploy a DNS server even for small homelab or test environments. Particularly if you’re trying to get familiar with IPv6. Continue reading
If you’re using a Linux system to provide IPv6 services, you may notice that some services don’t bind to a specific IPv6 address during system boot. Usually the symptom will be messages in the syslog where the daemons state “bind to port [#] on [IPv6 address] failed: Cannot assign requested address“, and that a simple restart of the service after booting has finished solves the problem.
In my case the issue occured with sshd and sometimes iscsi_trgt on the Debian Wheezy NAS system, which is also the DNS, DHCP, NTP, Kickstart etc server in my lab environment.
The reason is that the IPv6 addresses are not instantly up and usable once the interface is configured. One of the numerous new features of IPv6 are extended states and scopes of interfaces and addresses. Even static global IPv6 addresses go through a “tentative” phase, in which the uniqueness of the address is verified by the host, see RFC 4862. During this phase, which can take some seconds, the address is not finally assigned to an interface and therefore not usable. Daemons trying to bind to that address will fail with the mentioned error message. Continue reading
If you’re running a standard Linux on your homelab storage box with iSCSI (ietd, iscsi_trgt), you need to take some actions before deploying ESXi 5.5 in your environment. It seems the new ESXi release issues some SMART command on iSCSI targets, which hits a bug in iscsi_trgt. I’m using Debian 7.2 on my lab NAS which comes with iscsitarget 18.104.22.168. Once an ESXi 5.5 tried to access an iSCSI LUN, the iSCSI subsystem crashed completely. You’ll see messages like these: Continue reading