Raspi 4

While looking at some Raspberry Pi cases the day before yesterday, I looked at this "case" that comes with a fan that plugs into the GPIO pins, which I found quite interesting, since I had never thought to look at the pinout for the GPIO or to use GPIO to power the fan. I was planning on redoing the wiring yesterday, but my best friend had a day off, so I went to his place instead.

I had a small fan from somewhere (I think it was one of the fans from the old XBox?) that I had set aside for a while, and this morning, I was looking at it to see if I was able to use it instead of an 80mm case fan, and I was definitely able to. I pulled out some parts to begin making a mount for it before I realized that the shroud would make it quite annoying to access the GPIO pins to plug the fan into.

I then looked around to see if there was something I could make a new case out of, and saw the tin that my Tool Logic credit-card sized multi-tool thing came in. While I could have made a full case with it, that would be a lot more work than I was willing to put into it, and so I used the lid, since it was shallow enough to not block any ports; it also had enough leftover space to make it easy to figure out how/where to mount the fan.

After figuring out how to position the Raspi, I made the fan mount with two break-off PCI slot covers, using titanium wire to tie one part together (after drilling the holes to mount the fan), and using a couple wraps of clear tape to hold the other side together.

You can partially see the tape on the bottom joint of the fan mount.

I had actually forgotten to drill the holes to mount the fan bracket to the lid, but I was still able to drill the holes without too much of a problem. The lid gave me a bit of a problem drilling into - since the metal was kinda thin, the hole didn't get drilled out cleanly, but I was able to clean it up enough to where it works. I used two bolts to mount the fan to the bracket and two bolts to mount the bracket to the lid, and while I could have cut most of the excess off of the bolts, I didn't feel like expending the extra energy to do so, since it didn't matter either way.

The leftmost bolt was the most annoying to tighten, since I was just barely able to get a 10mm combination wrench (open end) to hold the nut (I didn't feel like finding an adjustable wrench).

I reused the screws that I used as feet from the old "case", since the heads to the mounting bolts are obviously not flush against the bottom. I also had to cut part of the tin to accommodate the power cord - which is a USB A to mini-B cord with a mini-B to micro-B adapter attached to it. I also trimmed a part of the top ESD foam that wasn't necessary off, wedging it between the bottom ESD foam and the plug opening to kind of hold the plug a bit.

The metal warped, since it was thin, which you can see here.

I had thought I was done, when I realized the board still had a bit of free movement (the ESD foam has permanent dents that partially prevent it from sliding around, which isn't enough to hold it securely. After about half a minute, I remembered that I thought of using another bolt from the fan-mounting hole to hold the board down. The bolt I used was originally quite long, and I was going to use two nuts to position it, but that proved to be very awkward to tighten properly at the correct height, so I just measured and cut it to length instead (which saves me a nut). I used part of the piece I cut from the lid to make a flat surface for the bolt to transfer the pressure onto, and trimmed a bit of the blue rubber to match the size.

"Front" view and holding bolt closeup.

While it works, I'm worried that the stress might cause the fan assembly to crack and break, but I'm hoping that doesn't happen. The airflow is pretty much directly on the SoC and the LAN IC, which will keep it relatively cool, though it's not entirely necessary.

Top view (angled). The angled cut on the bottom ESD foam was to facilitate having it in the corner, but wasn't the best layout.

I think I'll buy another Raspi since the second revision of the B model has mounting holes, which will make it much easier to attach to this "case" and allow me to remove the board-holding bolt. When that happens, I'll get a case to toss this Raspi into and use it for something else.

It took about 5-6 hours to make this "case", but it was worth it, since it's a lot more open and all the ports are a lot more accessible. The only problem is that the "foot" placement wasn't great, so it doesn't stand on the switch properly - oh well.

SSH

After tinkering with the Raspi, I decided to try to learn a bit of  SSH, and though what I've learned is basic and limited to the LAN, it's enough for the moment.

One thing I've learned is that anything that can be done in terminal can be done with SSH, since it's accessing another machine with a runlevel 3 interface.

Last night, I decided to boot openSUSE 13.2 to runlevel 3 on Triela and try to SSH into her to run updates, but I had no such luck; I tried again with Lie-chan a couple hours ago and still had the same problem.

After poking around on the net, I found the problem. The first was that the firewall was blocking SSH (port 22), and the second was that the daemon wasn't running or set to run on boot.

Once I get the chance to (probably tonight when I update Melty), I'll be able to boot any machine to runlevel 3 and remotely update it and shut it down.

Oh, when I was tinkering with the Raspi, I sent a halt signal (sudo halt) which wasn't the best idea, since the terminal session hung - oops! I found out a couple hours ago with Triela that I should type sudo init 6 to reboot, and with Lie-chan I sent sudo init 0 with SSH to shut her down. Sending init 0 over SSH to the target machine does a proper shutdown which then sends a logout signal to the SSH client from the target machine, making it a much cleaner experience.

I tried to SSH into Taiga, but found that I was unable to since the dependencies for openssh-server were broken, so the server wasn't installed. I'll see if there's a way to fix it, though I think Debian PowerPC might make it problematic.


Things I've learned:

• Check to make sure SSH daemon is running/scheduled to run on boot
• Check to make sure firewall doesn't block incoming SSH signals
• Use sudo init 0 to shut down machine instead of sudo halt
• SSH is quite useful and I should have taken the time to learn it earlier

Raspi 3

I decided to tinker with the Raspi again, thinking of using it as a very low-powered FTP machine for transferring small files since the Raspi's ethernet is 10/100 and not gigabit.

Once it booted up, I got to some sort of weird display manager and had to grab the mouse to move the cursor so I could type in the login and password fields, but was unable to successfully log in for whatever reason. I was about to download Raspian, but then decided to look at the size of the ARM version of openSUSE. Since it was much smaller than Raspian, I tried openSUSE 13.2 first, but ended up with errors, so I went with 13.1 instead and got to the login without any problems.

I finished up setting up the FTP daemon before looking around on the internet a bit to learn how to SSH into the Raspi - to which I was successful. I then cleared out the SSH "known hosts" file and set up a static IP for the Raspi before playing with SSH a bit more.

What's nice is that I can just set up the Raspi with the bare minimum (power, ethernet, and usb drive) and then leave it alone - no need to login to it locally.

The only thing is that the Raspi is still a bit slow, even through SSH, but it's nowhere as bad as trying to run Chromium in Raspian.

I haven't set it up yet, since I'd have to rearrange the layout of the switch for the NAS and Melty, but I'll probably do it fairly soon.

Mei-chan 8

Yesterday, I turned Mei-chan on, and after booting into openSUSE, Firefox loaded and immediately crashed. I rebooted and Firefox was fine after that.

Later on, I was transferring some files over from Taiga to Mei-chan and did a bit of spot-checking on the files, and the last two groups I was spot-checking had some erroneous checksums. With the last group, however, I kept getting different checksums, so I gave up and went to bed after finding out that bad RAM is one possible cause of inconsistent checksums.

This morning, after doing a bit of stuff on Melty, I transferred some files from Mei-chan to Melty before turning Melty off (probably for the rest of today). I then pulled out all the RAM from Mei-chan and put the first two sticks back in and ran Memtest86+. I got a lot of test errors and after a while of poking around in Memtest86+ and the net, I figured out what I needed to do and what to look for.

I ran one pass (and a bunch of other partial passes) with both sticks; one pass with stick 1 (and a few other partial passes while changing the voltage slightly, as well as trying bank 2); one pass with sticks 2, 3, and 4; then finally one pass with 3 and 4. Looks like the memory fault was located only on stick 1, which isn't bad.

After testing, I left sticks 3 and 4 in Mei-chan and proceeded to retest the last two groups of files that I gave up on and got matching checksums for the first group, and a couple bad checksums for the second group, which was remedied by redownloading the files from Taiga.

I then tested out stick 2 in the Dell and it seemed to work just fine, though it was running at DDR2 667 speeds instead of 800 speeds, but that was expected. Therefore, if I decided to give Lie-chan a new set of RAM (2x2GB), I can certainly put the old set into the Dell. I probably won't though, seeing the Dell doesn't really need that much RAM anyway.

Eventually I'll contact Corsair to get replacement RAM since it's not a major priority, as it's only one bad stick and 4GB of RAM is plenty to run Mei-chan with. Out of the 24 sticks of Corsair RAM that I've bought, I've only had one bad stick, which isn't too bad of a rate (4.167%).

To a point, I do wish that I had found the faulty stick sooner, since it would've been a lot easier to get a replacement than to have to live with the bad stick even though it never gave me any major problems until openSUSE 13.1, but as they say "What's done is done."

I could also install Windows on Mei-chan, but I don't think it'd really be all that worth it, since the only reason to would be to be able to play a couple games. Besides the fact that it'd be a major headache to redo the partitioning schemes and whatnot, it'd be hard for me to get comfortable with a long gaming session, as I'm usually either sitting on the bed or on a "cushion" on the floor. There's also the fact that I don't really use Mei-chan year-round, since she can raise the room temperature quite effectively in the summer (it can take her a bit longer in the winter, but she still does heat the room).

There's a bit of a load off of my shoulders, now that I know Mei-chan is stable, but the entire load will be off once I get and verify the replacement RAM.

Network Attached Storage 3

Last Saturday, I was backing up my files onto my NAS to allow me to access a spreadsheet I had made from my best friend's house, and I had stepped into the restroom to relieve myself. A couple minutes later I heard beeping and I ran though what it could be from, and after about half a minute, I figured out it was the NAS.

I checked the fans to make sure they were still spinning, and they were. Once I was back in the chair, I saw that the backup had stalled, and I tried to access the NAS via Firefox to no avail (I might have not waited long enough). I then grab my phone and use the DS Finder application to see what was going on, and it told me that volume 1 has crashed.

I tried restarting the NAS and it didn't work very smoothly, but it didn't help, so I decided to shut it down and pull the disk out. Since I had a bit of trouble pulling the disk out, I moved the NAS itself, removing the cables attached to it, and realized I was pushing on the lock tab down instead of up. I decided to clean the dust out and then connected disk 1 to the Dell to look at the SMART info with Parted Magic.

I found that the "Current pending sector count" had a value of 4, and it was considered a "pre-failure" value. I tried to run the short SMART test, but it hung on 90%. I tried to use MultiSystem to run the SMART test, but the disk utility in it was weird and didn't seem to properly start the test.

I found that there was some sort of systemctl bug that made the SMART test hang at 90% and that it was fixed in December 2013. Unfortunately for me, Parted Magic is dated for August 2013 and MultiSystem for September. I'll eventually download Gparted Live, since I'll need something a bit more updated.

The good news is that I can still use the NAS with a drive missing, though the power button flashes orange when the NAS is awake. I'm grateful for using RAID 1, since it allows for the array to continue to be used until the drive is replaced; I'm sure that if I was using any parity-based RAID array, the array would be unusable until I replaced the drive.

Once I get the newer ISO of Gparted Live, I'll try running the short SMART test again and see what it comes up with. I'll probably format it and try to use it for something else - the hard drive doesn't sound right when reading, so I'd rather not format it and stick it back into the NAS just to have it fail again.

I'll update once I get it tested.

Mei-chan 7

I've been lazy to update about Mei-chan, but since I'm logged in, I might as well update.

Firefox continually crashed to the point where I decided to do a clean install of openSUSE 13.2 to see if it was some sort of weird segmentation fault, but after a couple days, Firefox crashed again.

I figured it had to be the faulty address(es) in the RAM, and looked for some possible meanings of inconsistent memtest results, but didn't really find anything conclusive that I could apply. What I decided to do, however, was to poke around with the RAM settings in BIOS - compromising with turning off the "RAM compatibility" setting and manually setting the RAM speed to DDR2 400.

So far, Firefox has been stable, but if it happens again, I have a plan to take half the RAM out from Mei-chan and give it to Lie-chan - giving Lie-chan's RAM to the Dell and hoping the Dell can use it. Hopefully I won't have to go through that headache.

Linux VM on a Chromebook

The specific article I read is: Chromebooks Can Now Run Linux in Its Own Window.

Three days ago I saw the article (may have not been that specific one) come up in my "GNU/Linux" news feed in Google Play Newsstand, and I wasn't really too surprised, since I had found something similar to it when looking to find instructions for installing Linux (overwriting Chrome OS) on a Chromebook/Chromebox. I had actually just disregarded the article, since it wasn't interesting enough for me to read about it.

Two days ago, when I loaded up the "GNU/Linux" news feed again, I saw it was at the top of the feed again, but scrolled down to make sure there wasn't some other article buried below, and.... There was a total of five - five! - articles about it in a row. While I can understand different people from different sites write about the same thing, a news feed application should have some sort of way to filter out duplicate and/or similar articles, and though I say this, this has been the first instance of this happing (more than 2 similar/duplicate articles).

Yesterday, I thought there was only two, but when I scrolled further down, I found the five from before, making it a total of seven articles. Okay Newsstand, I get the point, please give me something else instead.

I was debating about posting about this, and originally decided not to, but since I was already logged into my Google account, I figured I might as well (skipping uploading the imperfect screenshots).

There's really not much to the article, as there's really not a whole lot to say about it, since it's just making the Linux VM more accessible through a window instead of having to switch between it and Chrome OS.

Honestly though, I think it would be better to just overwrite Chrome OS with any Linux, since Linux will utilize more of the machine's potential than Chrome OS will - though this applies more toward Chromebooks/Chromboxes with x86_64 architecture processors rather than ARM SoCs since Linux  distributions for ARM chips are a bit spotty (either with availability or package availability).

---

Happy new year to all!