Category: Linux

Posted on

Minecraft Server, Week 5: Wall of Java (Unsupported Management version)

Good Morning from My Robotics Lab! This is Shadow_8472, and today, I am continuing work on this server project I’m getting a little tired of. Let’s get started!

Timeline: This week was Thanksgiving, and I didn’t apply myself all day every day until Sabbath like I have the past two weeks. I’m also writing after the fact again.

Last week, I said I would drop the nuke. Well, I did. And the refugees I stored in my little silo gave me a world of trouble. All that trouble last week to preserve what I had, and something, somewhere was unaccounted for, and my little backup and restore scripts all for nothing but an exercise in shell scripting.

While I eventually resorted to a clean install, I learned a few lessons. First, tce-load does not like being run with sudo. I should have remembered this, and come up with some creative solution to install nano and anything else I want to download automatically, but I abandoned that venture before perusing it. Second, something with the login data didn’t copy over correctly. Again, I cut this off before figuring out what exactly was going on. One thing I did keep was the hidden .ssh file for my user account.

Speaking of user accounts, I have noticed that project distros tend to give you a two character login, probably so you can get in easily when you have ssh set up with proper keys. BlinkiePie has a default “pi” account as a nod to it being a Raspberry Pi, while Micro Core’s default user name is “tc” as a nod to the flagship version of the distro, Tiny Core. While doing my clean install, I enshrined my favorite boot codes in the as part of the installation script, and came out with no trace of the tc username in with the encrypted passwords.

With only a couple more obstacles, I loaded OpenJDK 8 on as that is the latest version available for “drag and drop” style installation unless I want to try making a .tcz file myself. I made a folder to test run the server .jar file and ran into an exception: “Unsupported Management Version.”

Those three words defined the rest of my week in relation to this project.

Online searches bring up several near misses, but only a single page even contained the error in its entirety. Sometimes it even shows up twice, and it still doesn’t have any answers.

Several people tried to help me across a few Discord servers. One of my earlier help sessions involved trying to execute a HelloWorld! program. It failed, but only because I actually had do this little thing called “compilation.” A copy was scp’ed (Secure cp (copy), a part of SSH) off to Blinkie for compilation, tested, and ran fine when it came back and I wasn’t just trying to execute the source again.

As a test, I tried copying a known good .jar file over from the intermediary server running on my father’s computer. I mounted the hard disk in the same case tried copying a .jar from a known good Spigot 1.13 server. Both gave slightly different versions of Unsupported Management version. The trace didn’t even lead to the same place!

Taking a closer look at version numbers, I found that I was dealing with a seemingly slightly older build of Java than most of my other computers. If so, it might explain why things aren’t working, as Java supposedly only runs on the same or later version as it was compiled for. Besides, I may want to run a plugin or two some time, and it would be easiest if all versions on the server are running off a single version.

Blinkie seems to have the oldest build of Java 8, so I went over there and started setting up Build Tools, a script used in the distribution of Minecraft Spigot. As with anything that tends to spew files everywhere, I contained it in a box (directory). I ran Build Tools, and got a message about low RAM. It needs more than a 32 bit OS can address, and Raspian is a 32 bit distro intended for a 64 bit machine.

Even though Micro Core doesn’t even seem to have a Java compiler available in its repository, I tried running Build Tools straight on Micro Core. I didn’t expect it to work, and it didn’t. At least it provided me with a third Unsupported Management version example to study. I was honestly expecting it to fail due to lack of a compiler.

From here on out, all I’ve done is research. I’ve poked this problem for days, I don’t know how to fix this yet. The first, and most obvious way would be to try Oracle JDK again, but I want to back everything up first, possibly by booting to Ubuntu, mounting Micro Core’s SSD, and using tar on the contents.

Another possibility is just scrapping everything and going with MineOS. It has all the features I’ll want, all packaged up nice and tidy. Backups, updates, premade start/stop scripts for (multiple?) servers. It even has security considerations I haven’t even begun making plans for yet. Anyone can use it with minimal effort. It’s perfect — except that it would feel like a cop out.

One of the reasons I’m doing this project is to learn whatever I need to function as an effective power user in Linux. I’ve learned so much on this one project, and I don’t want to take the easy way out this time. Even when looking at Build Tools again, I understand so much more than when

The other path I think I can develop is making a new .tcz file for a different version of OpenJDK. Since I don’t want to spend forever trying to do it on my own, I am going to try making an account on the Tiny Core forums. The development team reportedly patrols it, so if there’s any place I’m going to get help, that is it. It isn’t secure, so I’ll be using my password manager to generate a whopper for it.

Ultimately, this is a very niche problem. Normally, I like split the different parts when I have most of the plot threads tied off with progress made on the central thread. This post feels more frayed, but it’s a full week’s events. Happy Thanksgiving!

Final Question: Every kind of computer interface has its own set of required basic actions we take for granted after a while. What kind of basic, but not too basic features do you take for granted in your interface of choice?

Posted on

Minecraft Server, Week 4: Progress Backup

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I’m aiming a digital nuke at my progress on this project thus far. Let’s get started!

By the time this post goes up, I hope to have finished the whole project. As I write this post, it’s a little less than a day before part 2 goes live. I feel like I’ve made the least progress in terms of building a product, but I feel like I’ve made the most in terms of learning.

To recap: Part 1 was about assembling the hardware, Part 2 was about picking and installing Micro Core, and Part 3 was about trying to install Java and some of the things I learned that segment.

My goals for this statement only involved backup and later recovery, possibly in time for a quick transition to a working server. On one trip to Third Workshop, I spent a lot of time pacing and writing things down for what I want to save. I copied those over to a directory in a hard drive and even started on a script to automate their unpacking.

Back home, I found my files were missing. Lesson learned: Don’t trust Micro Core with things you want to keep unless you’ve finished setting it up. They will vanish unless protected.

I’d often have two or three topics I’d bounce around between. While looking for files to save, I went searching through the manual and found a more complete set of boot codes so a few things can live on my hard drive proper. While I’d love to do some possibly destructive testing around with the included file backup tool, I cannot risk it until I’ve finished my backup tools and mitigated the risk for when something breaks hideously.

The exact directory and file you can find your boot codes will vary depending on your bootloader. The Tiny Core Linux wiki has pages on a few of them, and if you ever need to know yours, try using the command “sudo ls -ra / | grep <loaderName>”. Sudo keeps you from getting a bunch of error messages from trying to look in a directory your default user account doesn’t have access to. The ls command forms the core upon which the rest of the command is built on. It means to list the stuff in your present working directory. Options come next with r meaning recursive, or all sub-directories, and a searches everything that’s hidden as well. The pipe symbol, |, acts like a funnel, taking the output of the ls command and feeding it into the next element, grep. Grep sorts long batches of data so it only displays lines containing <loaderName>.

I added a few more boot codes, tying several directories to the SSD. During this time, I learned a lot about what is supposed to go where. If I couldn’t find the answer to a question, I’d reach out to whatever help I could reach without making additional accounts. I almost made one for the Tiny Core forums, but I shied away when it would have involved logging in over an unsecured connection. My guess would have been that the site is so old they never bothered, but I think it’s just the admins not caring.

Progress overall was slow. It took me a day or two to figure out how to properly mount a drive and similarly “umount” it. (The n was left out in favor of a slightly shorter command to type.) It took a live chat session with a knowledgeable person to convince me I was looking at something in /mnt I now believe to be a mountpoint and not the automatically mounted drive.

With an ironically stabilizing system, I once again started development on my script. Each time I went to access it at /mnt/sdc1/restore.sh, I had to use sudo to get through an ownership blockade. Plus, with the geometry of the room, I wasn’t all too sure if one of our dogs was going to march right through the thumb drive. I also kept getting errors involving permission –and later ownership after I discovered the -p option– when trying to copy files there.

My next lesson was about how some disk formats don’t support Linux/Unix style ownership. FAT32 is apparently one of those formats that can, at best, only be faked. Since I was dealing with files owned by both Shadow_8472 and root, I’d need to empty off another thumb drive and research a format for them, or find another way to preserve permissions.

I must have reached out to three, four, maybe even five places for help. Somebody suggested I make a tar archive. I figured, “why not.” After all, I would be dealing with a tarball containing Java anyway.

Tar is an older piece of software with a bit of history. Its name stands for tape archive. Webcomic strip XKCD even ran a strip where they teased it for being so convoluted that sysadmins who have been using it for fifteen years still don’t know it by heart — and those commands were already fifteen years old when said admins started using them!

There are more than a few misconceptions surrounding tar. Just because something is archived, doesn’t mean it’s compressed. Zip files popularized that notion. Compression is basically squishing out repeated bit patterns for convenient transport. Archiving collects several files like papers ready to be bound into a single book. The two processes complement each other nicely, usually giving you a single file that takes up less space than the original files in their entirety.

I have no idea of the full power of tar. I just know that it has loads of features, but most of its users will never use them. I can’t help but wonder how many are totally obsolete, but included for lack of an update, or to maintain backwards compatibility.

Armed with these pieces of knowledge added to my collection, I wrote a pair of scripts to grab an arrangement of files I think I will need when I rebuild. I do have it setup to reinstall Nano and Opencss from the repository, but future versions, if needed, can be migrated to be part of the backup along with files that include things like encrypted passwords, boot codes, the whole Minecraft server directory, and more. It all gets copied into a temporary directory, turned into a tarball, and the temp directory removed.

During development of the backup and restore scripts, I stashed a copy or two on Blinky for safekeeping. I would have used one of my Windows machines, but it was just easier and had the same result to use scp to move the files over ssh between two Linux machines. I also noticed PuTTY having some interesting results when using the cat command to concatenate the contents of a file to the terminal. Normally, it keeps track of who you are logged in as to where and what directory you’re looking at right now. It would seem Raspian keeps track of that for you while Micro Core does not. I also found that using cat to show a binary that isn’t in text form could end up sending a command to PuTTY to change the window title, and even corrupt the header on the command line.

And that about brings things up to date. I changed permissions on the scripts so I have to run them as sudo, but while doing so, I accidentally removed one of them. I just so happened to have a backup courtesy of Nano… somehow. I ended up restoring from the Blinky backup, as it was more recent.

My next step is an irreversible one. I need to drop the nuke and start over with what I’ve saved. With any luck, the next post will be the full rebuild, ending with Minecraft running on Micro Core.

This (half)week’s idea sounded simple enough. Just copy the most important files away from the mess I created when I tried to install Java. One required skill snowballed into another, and before it, I had learned a whole slew of skills needed to slither along in the command line.

Final Question: I’ve been dealing with a lot of old computers lately. How old is the computer or other device you’re using right now?

Posted on

Minecraft Server, Week 3: Java

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am once again writing well ahead of the actual publication date. Let’s get started!

As I start this post, I’m still in week 2, and I might even finish this segment in week 2, depending on where a good stopping point is. The following events started early in week 2.

Last week’s post covered installing Micro Core, all the way up to and including a corrupt install of Java. I’m discouraged. I was just one… three… several steps away from finishing this project within my projected timespan of two weeks. I want this server up, but it’s more important to finish correctly. But timetables are near-impossible to stick to when you’re also learning how to use a computer again as if for the first time.

The command line is very different to using a GUI. It’s not toddler friendly, and it requires a ton of memorization. File systems, commands, command flags, file names; during one of my Third Workshop visits, I learned the man command, which brings up a manual for most commands. Micro Core has external documentation, likely for space concerns, so it’s off to the Internet for pretty much anything I don’t get.

Botching the Java install made a big, old mess, and having two copies of the Minecraft jar file made it more awkward when an obsolete backup got involved. I made the decision to nuke the OS and start over. But I didn’t want to just cut it off right there. If I need to start all over, possibly several times, I’m going to want to keep at least some of my progress, after all, I have SSH access from no fewer than three machines, all nicely set up with each one’s public key.

I took it under advisement to start writing a script to rapidly move back in case I need to redo my setup several times. Even if I never use it though, I’ve still learned a lot by dissecting my own work.

For starters, I spent an afternoon and early evening working at a trickle, writing down elements I needed to save. I moved them all to a thumb drive located at /mnt/sdc1, and found I had lost all my progress when I got home and plugged everything in. At least I have a picture of the tiny whiteboard I was taking notes on.

Mastering persistence is one of the greatest and most important challenges to working with the Tiny Core family, alongside finding someone who knows how to do the thing you’re trying to do in a close enough circumstance. With most available documentation aimed at baseline computer-literate GUI users, a GUI native lost in a CLI world has to sift through multiple forums and documents to find relevant answers. If I had to guess, I’d say it feels like a quarter of the Tiny Core help out there talks you through different menus of the default programs while maybe one out of sixteen is a Micro Core specific way of doing things. Note: I think it’s actually closer to one out of eight GUI special tutorials.

Investigating persistence, I learned a lot about the file structure: too much to regurgitate for review here all at once. I’m not even sure it’s even fully digested. The root file directory has a bunch of files, each with an intended purpose. When I reinstall Java, it’s going in /opt, for example. TCL has a special directory called tce where all the packages go for reinstalling everything on bootup. There’s also some network of links I haven’t even begun to explore; I just know they make it possible to pull off running the OS from a couple different files instead of having everything scattered everywhere.

Vanishing files had me for at least a couple days in parallel with other issues. I read that writing files to physical drives makes them persistent by nature. After my work went poof from my USB stick, I toyed with the umount command a bit more. Nothing worked. Eventually, I came across someone on a Discord server who gave me a working example, and made a whole day feel almost worthwhile. I was able to correctly mount my USB drive and edit its actual contents instead of filling a bubble in RAM somewhere to be flushed out when the power goes out.

Sometimes, I don’t even know if something is a general Linux question. My file system has both sda and sda1 as valid directories to look through, even though I have an sdb1 and so on, but no plain sdb, or a plain sdc when I plug a thumb drive in. This one, I don’t know for sure yet, but I think it has something to do with a bad bootcode, where I referenced sda. Now it’s in my fstab (file system table) file and it shows up every time I boot.

Things are all messed up. I just need to nuke it and start over.

Final question: Working with Micro Core has been fun so far, in the same way a video game can be fun, even if it’s super difficult, provided the rules stay the same the whole time. I can constantly feel success in my fingertips, only for the next challenge to pop up over the horizon. Have you ever applied skills you learned while at play in a more serious situation?

Posted on

Minecraft Server, Week 2: Installing Micro Core Linux

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I’m continuing work on a server that can take a bit better care of itself. Let’s get started!

Installing Micro Core was a whole unexpected challenge. I learned how to use a few of the boot options, but actually installing? The drive needed to be formatted, no doubt. I eventually gave in and turned to Ubuntu to format the drive. Doing my research, I went with ext4. I later found it was one of the top picks for SSD, but one of the worse ones for USB drives. I won’t pretend to fully understand it well enough to explain, but I think it has something to do with SSD having a limited number of read and write cycles per sector of the disk. The wrong format can overuse one part of the disk and wear it out prematurely.

Since I was booting from a USB drive, the installer I downloaded was having trouble finding the files to install — it may also be because the OS boots so fast, it doesn’t have time to wake up again after copying to RAM. I tried several approaches, including putting a separate disk image on the thumb drive and and failing to locate its path until I just told it to download the install files from the (N)et. Small joke was on me when Micro Core wanted to format its destination drive again.

While I was doing that, I took another look at just how much space I’d actually need, and an archive of several past servers was only 7GB. I removed the HDD with Ubuntu from any plans for this server and possibly onto another future project I’m not ready to announce.

Trying to learn Micro Core is like trying to learn Linux all over again. Imagine visiting a colony, be it a historic colony in the Americas or a futuristic colony on another planet. Each distro would be like a different family. Some distros are closely related so as to be in the same extended family, while others barely ever see each other in town hall meetings. Tiny Core, and by extension, Micro Core Linux feel like they’re across the town from members of the Debian and Ubuntu family I’ve previously met. While the file system feels similar, the shell and default text editor paint a completely unfamiliar face to look at. (Later edit: the Tiny Core family is a fork of a distro known as DSL, which is a fork of Debian, so the more I get to know the distro, the more familiar things show up.)

To date, I’m only familiar with the Bash shell and Nano text editor. Both provide a relatively open and friendly user experience for anyone not afraid of the command line. The Tiny Core family did not build its command line for people afraid of a text interface. With size and speed as priorities, ease of use isn’t given as much priority. The Ash shell is faster and slimmer, while Vim text editor provides a lot more customization opportunities.

Vim scares me. I had to spend hours just trying to figure out how to move around, and now, the only thing making me even consider keeping it around is the difficulty of adding Nano in.

Apt is the usual way you download programs in Linux setups I’m familiar with. Tce is its less well-known counterpart I have to work with. I’m having trouble learning it, likely because I’m looking first online and only looking through the PDF that came with that documents Tiny Core. It also doesn’t help that most TCL documentation seems to assume you’re working with a GUI.

Insuring Nano was properly installed was tough. I spent a whole evening trying to problem solve, thinking my install was corrupt. The best I could figure out was that I had installed Nano while booted to a thumb drive, but it saved to a different place. When I tried to fix it, tce told me Nano was already downloaded and installed while it was unavailable on the command line. A total of three drives were involved, including my first Linux project running Ubuntu MATE.

I tried bailing, but my attempt to wipe Micro Core failed due to the drive being mounted. I wasn’t able to “umount” it (note the lack of the expected first n in umount; that alone took me between half and a full hour to get). And here lies one of IT’s more haunting nightmares: things working when they reasonably shouldn’t. I came down before bed for a last shot at solving a possibly corrupted path somewhere, and Nano decided to work without either the Ubuntu HDD or the installation thumb drive. Nano has since been stable.

SSH is the next step, but I took a little cut in line for Java. I learned a lot during this period. Working with Micro Core, and I’d assume Tiny Core too, is all about managing persistent files. The OS is small enough to get away with basically reinstalling each time, so unless you protect your data, everything is effectively a temporary file. With that said, I doubt I’ll fully understand what all is where until I finish a second or third project. For all I know, this was just a case of Micro Core repairing itself.

From what I can tell, MCL is one of the few distros to ship without a SSH client. I’ll be using OpenSSH. After a full day of slow learning, I followed a list of directions, somewhat following what was supposed to be going on, only to mess up on the last one and have to start all over again. It went a bit faster this time, and I understood even more of what I was looking at.

Moving along into the final stretch of this week’s planned scheduled progress, I’ve downloaded the Minecraft 1.14.4 server file. Let me tell you: the world is not friendly to CLI denizens (denizen: person living in a place they are not a citizen). I had to search hard for how to download anything, and when I found a couple old blog pages pointing me to a little program called wget. They each provided an old URL that no longer works, even if you update the MC version numbers. The official server download page includes a 40 digit number in hexidecimal.

And here, I admit to cheating a tiny, little bit. After failing to manually copy the URL, I turned to my work on bringing SSH online. A quick paste, which for some reason works with a secondary mouse click to a PuTTY window, and the correct URL was woven into the command.

I realized I had only downloaded the Java installer. I spent the day trying to unpack the HTML for the download page as if it were the actual compressed Java tarball. The shell script I found directed me to a URL, and I thought that was the actual URL to plug into wget. The -O option I used robbed me of a vital clue by overwriting the file name and extension. Something worked, and I didn’t realize it was the wrong thing until I used Nano and read the code for myself.

I wasn’t too sure where to stash Java to make it go, so I put it in with the extensions so it wouldn’t disappear while rebooting. I don’t know what happened after that. I ended up with too many symbolic links between files, likely from recursion somewhere. A reboot broke Java. Things are just a little too messy now. I don’t know what’s what anymore. This job isn’t over.

Final Question: Have you ever gone out looking for instructions while the answer was there in front of you all along in manual form?

Posted on

New Priority: Minecraft Server

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I’m setting up another Minecraft server, but this time, I’m setting goals a bit higher than usual. Let’s get started!

I am after an automated, headless, dedicated Minecraft server. That means I want a machine that only runs Minecraft, and nothing else. The machine itself will live in a network closet or somewhere where it can have a power cord and Ethernet while I use SSH to get in to change things. I don’t want to have to babysit it, so I want to write a script or two to manage the whole server. The whole idea is to get the maximum amount of performance for Minecraft while spending as little as possible on the OS and other supporting software.

The main bottleneck is RAM. I have 8 GB to work with for now, and that’s fine for running a survival world and a creative world at the same time in Ubuntu, plus a couple tabs in a browser. Both this machine and Derpy have historically been used to host Minecraft servers, but I want to consolidate any running servers into a single machine. To that end, I’d like to see if I can comfortably run three or four servers at once.

Distribution choice is a little more important now. I’m after something as light weight as possible. Unlike the past several months, I’m actually doing progress reports as I go, so I don’t actually know what I’ll have when I’m done. I’m seriously looking at about six distros ranging from Ubuntu Server to Lubuntu to Puppy Linux.

A family Minecraft friend who will likely be playing on the server brought up Linux From Scratch. It’s a resource for compiling your very own distro. It looks fun; it looks educational. I looked up a couple video reviews of it and decided it looks one or two years down the line for me. My goal is two weeks here, and hardware challenges are starting to make me think I may already need to double that.

It turns out there are a bunch of tools for people who want a little more involvement with what’s in their operating system without wanting to go into source code level of detail. All the ones I looked at either have their domains up for grabs or are otherwise obsolete.

There was one more distro this friend brought up: Tiny Core Linux. It aims to provide you with only what you need to get started with a wide variety of projects. To paraphrase their stated goal: add what you need, not demolish what you didn’t ask for. After poking around a bit more, I found another version on their site that nixes the GUI. It’s not like I even wanted one for this project anyway. Micro Core it is until further notice.

I remembered how Derpy used to have this SSD it supposedly used to improve make things go faster. It’s not like it was being used, so I thought maybe I could use it as part of my little project. So I opened Derpy up and pulled it out.

Different computers with open architecture have different schemes of making sure everything stays where it’s supposed to. When I installed Derpy’s present SSD, I didn’t have the correct part to mount it on, so I just put it on what I had and let it be. With the HDD to SSD bracket being freed up, I went ahead and swapped things around. It just took a while to figure out how to get the bracket off.

With the brackets finally swapped, I moved Derpy’s old 60 GB drive to my project computer case and connected it with a SATA cable I had laying around. I think it may even be the one it originally came with. Power was similarly available within the case, but I had to remount the SSD to another position within its bracket so it could reach.

Trying to mount Derpy’s SSD with Puppy Linux

Backing up a little, before I started seriously considering Micro Core, I burned a Puppy Linux live CD. Puppy Linux is another one of those small distros that comfortably loads into RAM.

It’s funny how the sound of a CD drive made me smile. It used to be the sound occupying the boring period between when I started computer time, and when I started actually playing.

I rejected Puppy Linux after I saw office software as well as other stuff I didn’t need included, like a whole GUI environment. Nevertheless, I still used it to verify that I had everything hooked up correctly. It took a while, but I happened across a utility within Puppy that left no doubt. I spent a while trying to see if there’s anything on the drive before I eventually asked my father and he went ahead and told me to just format it.

I know I said I was going to do a more update-style post, but this is running into a longer entry, so I want to split this one. It provides a natural-ish breaking point about here. While I thought I was going to need about two weeks, as of this writing, I’m thinking either three or four weeks total work may be in order. If I break things up like this, I may end up with even more parts. That, or I just spend some of those weeks not doing much but learning what to do next.

Final Question: Have you ever messed around with otherwise junk to turn it into treasure?

Posted on

Programming a Pi to Deter Cats: Part 9.4

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am glad to say I have finally learned how to beat SSH keys into submission. Let’s get Started!

Computer security is important to get right. The moment you connect to the Internet, you potentially have a near infinite number of burgles trying to break into your device. That is why we have virus scanners and firewalls. SSH is an important and powerful tool for working with headless computers, but if mishandled, it can open a hole in your network security. That is why I always make sure I know what I’m doing and that someone else knows what I’m doing. Because if I don’t get things right, I may be looking at a dozen or so weeks learning about removing malware. If you are trying to learn any skills that can likely compromise your computer security, please seek supervision from someone who already knows how to do it safely.

I spent a lot of time in the workshop this week because I wanted to be sure I was being safe. Like my pile of sand a week or two ago, I had to learn a lot before the final pieces clicked.

SSH (Secure Shell) is a secure way of logging into another computer over a connection that can be assumed to have anyone may be listening in. When set up with SSH keys, a client program first asks the server for its host key. If the host key looks familiar, it’s probably the server the client thinks it’s connecting to. If not, the second layer of protection, host keys, let the client and host negotiate a way to scramble their conversation without eavesdroppers understanding.

Setting SSH up correctly is a bit more tricky to understand. I’ve heard there are lots of tutorials to disable the host key check because it’s annoying. Seat belts are annoying, but if they protect you even just once, they save you a lot of hurt in the long run. I don’t understand the differences between each host key, but from what I can tell, each computer, or at least each server, has one for each type of encryption. Blinky, my Raspberry Pi, came with at least six host keys.

Final Question: one of the challenges I had setting things up was being sure I was connecting to the server I was connecting to. Granted, it would have been safe in that instant to just click through. When was the last time you spent a lot of time figuring out why something works instead of just accepting it works for now and moving on?

Posted on

A Series of Reluctant Leads

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am bringing you another fragment on my journey to get my PiCamera working in a video call. Let’s get Started.

This week had a lot of progress, but no workable results. I did a lot of research on the problem, refining my understanding of the situation, but the solution always feels an hour or two away.

To recap, work last week finished with the Discord webapp playing nicely with my Blue Yeti microphone, but it wouldn’t even acknowledge my PiCamera, even when getting into the sound and video test page.

This week, one of my early findings was a driver, Video 4 Linux 2 (v4l2). I spent half a day believing something wrong with it, because v4l2 looked a lot like v412 because of the numbers before and after a lower case L. Long story short, after running a command:

sudo modprobe bcm2835-v4l2

The camera still didn’t work, but at least Discord tried to load an image from “Default” instead of insisting there wasn’t anything resembling a camera it could use

Fortunately, while researching why the camera still isn’t working, I noticed a forum where someone pointed out the command needed to be run after each reboot for the V4l2 driver to work. Other background information I picked up was that the problem might be something requesting a 0x0 feed to display.

I also noticed for the first time that the “raspistill” program’s output covered parts of the black boarder Raspbian leaves. It’s as if it’s on a separate layer in front of the OS’s video output. One of the options included making the camera output transparent, so I used that freedom of vision to try and share screens, but any screen sharing was from the desktop layer only.

I had a bunch of redundant/unfruitful research for a couple days, and I eventually ended up in the workshop again. I want to say I had about half my progress this week right there. It took a little while to review my progress so far, but after everyone understood things, we started playing around with narrowing the source of the problem farther. Many of my hunches about where the problem wasn’t were confirmed, though I did learn a bit about the Chromium hardware permission system and how some software repositories are left in a power saving state while not actively being used.

We managed to confirm the driver was working after arguing with a python prompt. It still requires adjustment, as in it threw up what looked like a blotchy, pixel for pixel view of the camera, and it was zoomed in. It covered up the black boarder entirely, so I’m hoping this isn’t just an educational dead end.

Final Question: most of my unfruitful research is quite unmemorable. This was just one of those weeks where my early work was mentally lumped in with last week’s work until I reviewed the actual blog post I made not covering it. When was the last time you forgot how recent your recent progress was?

Posted on

A Series of Dead Ends

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I don’t have much, but I’ll try to put something down. Let’s get started!

I went to the workshop again this week with a list of things I wanted to figure out how to do, starting with getting TightVNC to switch users. Nope. TightVNC servers are tied to a single log-in session. Without good communication, that piece of information took between thirty and sixty minutes to figure out. We did get a copy of the heater program working the Pi at 100%. Before I re-run the temperature experiment and risk damaging the case, I have another side project I want to try figuring out.

I have a friend I haven’t seen in a while and he lives in another State. I want to show off my ghost case (Now pictured), but I want to call on the Pi and hold up a mirror so he can see it with its own ‘eye.’

My first thought was to just download Discord and call it good. Oops. The Raspberry Pi may be 64 bits, and Discord want to run on 64 bits, but Raspbian doesn’t exist on 64 bits. I found a decent-looking forum post [LINK] that discusses 64 bit computation on the Pi 3 series. Long story short: 32 bit Pi computing has inertia. They don’t make 64 bit Raspbian because it would cost more utility than the few who seek it out would gain from it; it simply isn’t worth it for an official, 64 bit Raspbian to exist.

Jumping back in time to before I found the article, and I had just given up in the short term, I looked around to find that there are operating systems that can run on the Pi that use all 64 bits, but several comments seem to describe the wanting nature of either the setup process or trying to squeeze any additional performance. My thought is that such operating systems are often not optimized specifically for the Pi and take up what benefit they otherwise would have had with additional overhead. The extra bits are there if you need them and know how to use them.

At this point, a Discord client is looking like a no-go, but I did try to get a call set up in the browser. I haven’t gotten it to work yet, as I need to figure out how to get my Pi Camera and Blue Yeti to play nicely with the Discord site in the Chromium browser. It’s just something with the permissions, I hope. I remember seeing something about the Yeti not giving Linux a single thought in its advertising, but I think I remember seeing it show up in the Discord web page.

Final Question: Does anyone actually know if the Raspberry Pi will melt through a PLA case?

Posted on

Review and planning session

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am laying out my plans for the near future. Let’s get started!

I’m still figuring out the new setup with Derpy. The VNC client I set up on my main desktop isn’t sending keyboard shortcuts when remoting into Derpy, but my laptop does and I cannot find the setting to change it. It also seemed to prefer opening up programs for a local login (if present) if the remote server requested anything be open. I upgraded it to Ubuntu 18.04.1 LTS after trying to get some tech support over Discord.

In my last post, I believe I said I was now using GNOME 3. That was wrong. I’m on the Xfce desktop environment and I couldn’t tell the difference, especially while trying to elicit help. I’m willing to work with this desktop environment, as I hear it is supposed to be pretty stable, and it’s the only one I have to work with at the moment. Yes, I don’t have a way to switch desktop environments remotely. I tried logging out remotely, and the VNC session became unusable with that complex black and white “gray” pattern, replacing the desktop picture as I dragged lingering windows around. A reboot fixed the symptoms, but I still want to see about getting the root cause addressed sometime.

I have a few things I want to finish before going on with programming the Pi to detect and deter cats. Mostly the more intermediate Linux literacy skills, like getting WINE to run things reliably, or forcing a piece of hardware to work when it shouldn’t.

During my miscellaneous research this week, I found Rasbian is only a 32 bit operating system and the Raspberry Pi 3 family is all 64 bit based. I would like to explore benefits and drawbacks to finding a lightweight version of Linux to run on the Pi and running that for my cat program instead of just programming it for the board’s default OS.

Final Question: It’s hard to know what version of an otherwise identical product to go with, especially if you’ve never needed it before, especially software. I find a good word from someone I know goes a long way. How do you decide what version to use?


Posted on

Remote Access 1

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I have a lot of progress to report on remote accessing my computers from each other. Let’s get started!

I spent most of my time for the blog this week in that workshop I joined a few months ago. A lot happened, but I am not the main mind who put everything together, and I don’t fully understand everything that’s going on.

This week, I gained the ability to log into Derpy, my secondary Minecraft server/Linux testing platform, from another computer using TightVNC (Virtual Network Computer). TightVNC is one of many desktop viewing applications; most others cost while I’m working with a free version.

The first step was to set up a server on Derpy and get another computer to try and connect. We eventually ended up with a “gray” error screen with a black x pointer if we had everything working as best as was possible (it was actually a complex pattern of black and white pixels).

Part of the wonkeyness of remoting in involves screen parameters, like size and this one I know nothing much about called color depth. Something along the way likes a color depth of 24.

While we tried a few possible fixes, multiple places said to put GNOME on for the graphical interface. While I find the Cinnamon nice and convenient, I am more than willing to explore something new to find something that works… GNOME surprised me with that pesky zoom in thing I abandon Unity over.

I did a bit of research, and the popular Unity environment is built on GNOME. I hypothesized that Unity had changed something Cinnamon couldn’t care less about. None of the normal zoom in fixes worked, and the text had their smooth, vector based look, even though they were huge, so we knew the picture was at the correct resolution.

Over an hour of pointless guesswork later, I had outsourced the problem to a Linux support Discord server. After no response and someone else’s problem getting solved, I reuploaded along with a photo of the screen this time. Over the next three minutes or so, a couple users by the names of MotherM and ~> yay -s Superuser went back and forth trying to figure it out until a user by the name of PlasmaPower offered a command to restore the correct interface scale factor to 1 where Superuser had identified it as at a factor of 2.

gsettings set org.gnome.desktop.interface scaling-factor 1

With GNOME functioning properly, I was able to make a connection and even managed to open the Minecraft server remotely. However, any new graphical programs, including terminals, opened up in the host machine. It turns out, using TightVNC server hosts an extra login session, at least the way it was set up. Before I left the workshop, we got a script set up to automatically start the VNC server whenever the computer restarts.

Later, I figured out that if I logged out from the host machine, newly opened programs work as expected. I also eliminated one of my dual hypotheses. New programs prefer to open locally before yielding to remote sessions when dealing with multiple logins from the same username, not the first session started.

As it stands, the connection is stable. Future improvements may include sizing the resolution to fit my secondary monitor and getting a version of GNOME installed I can relate to a little better. I should also be able to set it up for CLI mode only for the host terminal.

Final Question: Linux is apparently the hardest OS to get set up for remoting into. When was the last time you reached the finish line, only to find out you were doing it the hard way, even if the easy way wouldn’t have worked for you anyway?

Privacy Policy