Linux Deep Dive Part 2: End of Week 3

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am continuing my coverage of my deep dive into Linux. Let’s get started!

Last time, I installed Debian Linux on a USB external solid state drive using skills I learned from previous projects.

I am very much still in my trial period for Debian. Most of my time working with it has gone into exploring and diagnosing the system.

A lot of my MATE explorations into panels happened on at least day two. While I was able to assemble a semi-convincing Start bar look-alike, it still has a way to go.

I discovered the first of two big hitches when I took it in to Third Workshop and booted to Windows to demonstrate Minecraft in its unplayably slow state. I hit restart, booted into Debian, and it was still unplayably slow. I even rebooted several times, only for it to refuse the decent performance I knew I had seen already. We even put a simple clone of Minecraft by the name of Mine Test on there to test the FPS. I got it home, booted straight to Debian and Minecraft unexpectedly worked correctly.

It took me a while, but I finally narrowed the pattern down. The performance drop only happened if and only if I first boot to Windows and restart into Linux without shutting down completely.

Even though I didn’t master the problem by solving it completely, it hasn’t come back, so long as I don’t reproduce it on purpose. I’m fine leaving it alone.

And now for my other problem: Debian only successfully boots about half the time. I still don’t know this one. All I can do is lay out everything I know about it and hope someone knows what the deal is because I’ve yet to find a help topic that matches my problem exactly.

It used to be that Debian would boot every other time, but it did have a spell where it booted and failed about six consecutive times each. A few days ago, it’s gone to not booting at all. Whenever it fails, it drops into BusyBox, displaying an ash shell with the prompt (initramfs). It has some basic commands, and I think the general idea is that when the Linux kernel can’t find the files it needs, a knowledgeable operator can manually mount a drive and boot from there.

Now, I’ve mounted drives by hand before. I met someone going by hyperreal who generously spent over an hour and a half of his time on me. We seemingly tried everything to try and get BusyBox to boot. Nothing. We even peeked at the hard drives’ contents from a GRUB boot menu console (Don’t cite me on terminology here!). Everything looked good until BusyBox showed up again.

A lot of it was repetitive. In short, it looked like /root had the contents of my Windows… I may have it. What if GRUB is looking for sda or sdb specifically and they respond in the wrong order? I’ll check into it.

As I was saying before a flicker of hope interrupted me, The Windows drive was mounted to /root and I was able to umount it, but neither drive would mount there. I kept getting an “Invalid argument” error. Maybe the BusyBox mount command is a little different, but it should have worked each time. We tried mounting it from /dev, where devices are listed by an internal shorthand per system, and from a more out of the way place that listed them by UUID. There were four entries, and I suspect the two that didn’t look like hard drives were my mouse and keyboard.

Moving along, I also tried burning a Super GRUB Disk a total of three times. The first two were on my laptop, but they both flopped. I detoured for a while, doing other stuff mentioned above before making a good disk from my desktop.

I still need to mess around with the disk to know exactly what is going on. The working theory has been an unreliable install of GRUB. I have a new idea since writing this, but for now, I have a way to use my computer when I want.

Final Question: Any ideas on this one? I could really use the input, though I should probably get the comments section working some time.

Leave a Reply