Adventures with Linux

One of the areas that I’m weak with when it comes to is IT. Sure, I’ve done some basic things with RaspPi, and I can do some ESXI stuff, but by and large, I’m pretty lost when it comes to Linux.

Since the best way to learn something is to jump right in, over the weekend I installed Debian on my main laptop. My primary use of my laptop is RDP when I travel (over a VPN of course) to my main desktop, so this was a low-risk move. However, it would give me the option to really dig into it.

Right off the bat, I hit some difficulties. Debian doesn’t include WiFi drivers for my wireless card (an Intel one). I had to download those from Debian’s site and drop them on my USB key. That was a bit of a surprise.

However, once I was past that, the rest of the install went smoothly. Once I was in and set up, I spent some time getting all the things set up the way I liked.

All the other drivers seemed to be set up automatically. I remember (years ago) having to fight with display drivers, but all that was seamless.

I then started installing the software that I wanted to use. Since I use O365 for most everything, I just ran that through the browser, and called it day. Same with WhatsApp. However, I saw that Slack had an app, so I used that instead.

Just for fun, I installed Steam. I was surprise to see the amount of supported games that they had added. I did some reading, and it looks like a lot of them run using emulators. I’ll have to do some testing on that at a later date. While my laptop isn’t much for gaming, I’ve always enjoyed playing simpler games on it, like Darkest Dungeon, Sunless Seas, and Stardew Valley.

I’ll be adding more writings on this as I go.

OpenHAB on Raspberry Pi Part 1

For Christmas, I got a Raspberry Pi 3 B. I’ve been wanting to set up a homegrown smarthome, and am planning on using this as a base for that. I’ll be running OpenHAB on the Raspbian OS.

I already have some smarthome equipment, including a SmartThings Hub, some HUE lights, and several Alexa’s. I’d prefer to run as much as I can inhouse, without relying on cloud services. Obviously, (and especially with the Alexa’s), that isn’t entirely possible, but I want to do as much as I can.

I’ve not spent much time with Linux, know nothing about Python, and my electrical/circuitry knowledge is what I can remember from a kids book of experiments from my childhood. This will very much be a learning experience for me, and should broaden my knowledge about those subjects a great deal.

As it stands now, I’ve got Raspbian running, OpenHAB deployed via Docker, and am ready to start configuring over the coming days. I’ve not used Docker before either, but it seems pretty cool.

Let’s see what the coming days bring!

StorageSpace Oddity

So, I’ve been trying to figure out a weird issue with how drives in my Storage Space pool are being displayed. I first noticed this using Server Manager.

First, for background, my pool is a 2-way mirror with 17 drives, and weighs in at 23.6 TB formatted.

However, in this screenshot of server manager, you can see that Windows thinks it is 4 drives less than that. Disregard the retired drive, that’s removing currently.

If I go to just the basic drives view in server manager, I see some of the missing drives, as well as a few that are reflecting in the storage pool.

At this point, I was growing concerned, but figured it could be a GUI glitch. So I went to Powershell to pull out the list of drives associated with the pool. That showed exactly what I expected, all 17 drives:

I figured, since I was good there, I’d just verify that the visible disks to Windows showed correctly. I ran a get-disk, which shows the disks visible to the OS. This shouldn’t show the Storage Spaces drive, since they are abstracted by Windows. However, I can see a similar set of drives to what I saw in Server Manager, as you can see below.

Honestly, I have no idea what is causing this behavior. The storage spaces rebuild as expected after a drive failure. All pool health is returned as healthy. Just some drives show both in pool and visible to Windows.

Anyone seen this behavior before?

Moved to Storage Spaces Entirely

For the past few years, my home server has been running two different arrays. One 8 disk RAID10 array, and a large storage spaces array. As I’ve gotten other drives over the years, I’ve stuck them in the storage spaces array for anything that doesn’t require a lot of speed.

I was using the RAID10 array for files that I wanted to access quickly, but I was running into a few quirks. Mainly, since I was using consumer drives, I’d periodically hit an issue where the controller stops responding waiting for a drive to respond. This would then crash my server, causing me much annoyance.

Since I never saw this issue on my storage spaces array, I decided to relocate all the files on my RAID10 to another drive short-term so that I could wipe the array and get the individual drives back to storage spaces.

My storage controller for RAID is a RocketRaid 2720, so I set the drives up to be JBOD and off I went. Injected them into StorageSpaces, and moved the data on over.

However, I noticed that it was still a little quirky. Did some checking on the manufacturer’s website, and realized that I should have flashed it as a plain non-raid controller.

Since I had already moved the data over, I wasn’t sure if this was feasible, so I did some tests. I moved a drive from the this array to another port that wasn’t on the controller to see if storage spaces could read it. I mainly wanted to make sure that the rocketraid wasn’t doing anything funny with the drive. Amazingly, it showed right up.

I then reflashed it to be a simple storage controller with no RAID options. After I did that, I immediately had an issue where none of the drives for showing up. I run Hyper-V server as my Hypervisor, so I had to dig into it to see what was up, while panicking that I may have wiped out a bunch of data accidentally.

Turns out, I didn’t install the drivers for the reflash. Whoops! Installed those, and all the drives showed up in storage spaces, and everything has been stable for about a week now.


On Hitachi Reliability

I was out of town last week visiting Colorado Springs. Towards the end of my trip, I got the alarming email alert that a drive in my RAID array was dead.

I use RAID10 for my main array since I use mainly consumer drives, and the risk with parity raid is too high to risk using them.

I ordered a replacement drive (WD Red) so that I could swap when I got home. Everything went fine.

Here’s what I replaced. Not a bad lifespan for 24×7 usage. Here’s hoping I get similar life from my RED drive. And that my 3 other Hitachi drives don’t die en masse.

On Random Yet Consistently Timed Crashes

The past few weeks, I’ve been dealing with hard crashes on my Hyper-V server. They all happened at around the same time. Essentially, the VM would stop responding to any services past pings. If I try to use the Hyper-V console to bring it up, it would just crash. If I tried to reboot or stop the VM it would crash the host.

So, I went through the event logs on the host, and came across a bunch of errors on my Highpoint 2720 controller relating to ports not responding and driver not responding. I have a scheduled drive pair verify that was running around the time of the crash, so I assumed that there may be a chance that I had an issue with the drives on the pair.

I ran a full drive scan on the two drive pairs, and both succeeded without errors, nor were there any crashes. After that, I ran a drive pair validate, but at a different time of the day. This one succeeded as well.

Feeling thoroughly confused, I went through the event logs again, and came across an error in the host log that also coincided with the same timestamps. This error was sourced from my PCIe network card, so at that point, I start trying to figure out what could cause two PCIe cards to stop responding at the same time.

I got through the logs on the VM again, and notice some errors with the ID 129 but no details given due to a missing component. I do some Googling, and find an ancient MS forum post about this error. It was traced to an issue with VSS and similar issues with crashing VMs.

I then remember that I had a Windows Server Backup running on the VM around the same time that this was running. Disabled that, and suddenly the crashes stop.


Rosewill RNG-407-Dualv2 Thoughts

A few weeks ago, I picked up a Rosewill RNG-407-Dualv2 for my home server. It’s a dual gigabit NIC, that Amazon had for less than $40. Thanks to Hyper-V and an Ubiquiti managed switch, I was able to quickly set up port channel, which gave me some extra speed on network operation, as well as separating my VI network traffic from my management traffic.

Since they were so affordable, I decided to pick one up for my desktop as well. My desktop runs Windows 10 Pro, with Hyper-V. I figured I’d set it up the opposite way from server, with the desktop getting the port channel 2 gbps connection, and my VM’s getting my existing onboard 1 gbps connection. Little did I know that this was going to be a bit more of a hassle.

As any decent IT guy would do, I tossed aside the provided driver CD, and jumped online to grab the latest drivers. And then the fun started.

Rosewill’s drivers installed as expected and I suddenly had two LAN interfaces as expected. However, Microsoft does not support teaming in Windows 10 natively. That was probably something I should have investigated before buying this, but what’s a home tech project that doesn’t have a few surprises?

I did some checking on Rosewill’s site, however, it was sparse on details and instructions. There was a diagnostic driver that had a folder called teaming, however attempting to install it was blocked by Windows due to incompatibilities.

At this point, I was starting to get concerned, so I decided to check with the chipset manufacturer and see what generic drivers they had. Fortunately, the network chip is a Realtek product, so they had several driver options on their website.

I download the latest Windows 10 drivers, and install. They are more recent than the Rosewill ones, so I had high initial hopes for them. Alas, there was still no way to configure teaming from the driver side.

Realtek had a diagnostic driver, so I attempted an install of that. Everything seemed great. Network cards showed up in network devices with Realtek Teaming driver, and no alerts anywhere. So, I fire up the Realtek Diagnostic Tool, and it fails with a protocol error. I do some Googling, and turn up an old driver on AsRock’s site of all places that claims teaming abilities.

Deciding that I have nothing left to lose, I download and install the driver pack. I try to load the teaming utility, and it comes right up. I am then able to set up network teaming through the rather archaic looking utility. After a quick port channel config on the switch, I’m able to get connected.

As a test, I start copying some large files to two separate systems to maximize speed. Right away, I hit 1.5gbps, which is exactly what I want to see.

For now, I’m satisfied, however, I suspect I’ll be trying the Realtek Diagnostic drivers again, since I’m not sure why those wouldn’t work, but an older AsRock driver for Realtek would.