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?