2025-09-02
Right now I'm entering a new era in my college career as a Masters student. With this opened up many opportunities, one of those was to teach a course. One of my long term goals is to become a professor to guide undergraduate students in their computer science journey. This opportunity is really cool, exciting, and gets me nervous all at the same time.
Now what class am I teaching? How does it work? Am I really the one teaching even though my title is a graduate teaching assistant (grad TA)? To answer these, I'm teaching an intro course (CSCI 1101) with another grad TA co-teach. While I am technically a TA, we are trusted to run this course as we'd like, as long as we cover the expected accreditation topics.
The course is going to go through the history of computing, what it is, a bit of programming, and how to succeed in both this program and industry. My hope is to introduce typical tools like git version controlling, VS Code, and anything else we encounter, but also encourage students to reach out with LinkedIn, through professors, and student organizations.
While this is an experimental time for me, there's a lot to learn about what it means to teach others. Along with this, balancing my curiosity with research and coursework. I'm happy to get to learn more while sharing this with underclassmen, lets see how this goes. I'll likely update my journey here or continue to log this in my new git repo here.
Cheers!
2025-06-25
Hello, World!
Well this is new to me. I've never really written down my thoughts like this for people to see. My goal with this is to I guess expose how I think to possible recruiters and anyone else interested in getting to know me and what I like to do. So far I've found joy in self hosting applications on hardware I have at home (2 Raspberry Pi 5 boards) and building software in general. This brings us to today's topic of how I had my first emergency mode boot up with a new Pi board I got.
I've only ever heard of possibilities and other horror stories of screwing over a Linux system, but for the first time have I encountered anything close to that. How it started was me getting the new Pi 5 16gb RAM board (lets not judge just yet) and paired it with Argon's Neo 5 NVMe case using a Lexar SSD. The point of the build was to build up my Pi board and reduce any latency for my web apps. Now I know there's better hardware and ways to do so, but I wanted the challenge and learning experience.
Anyway, while setting it up it started on a cheap SD card while I waited for the SSD to arrive. Once it did and everything was installed, I used the SD Card Copier program that's built into Pi OS to copy the whole OS from the SD card to the SSD. One of the options given was whether to give new UUIDs (or not) to the drives. After some recommendations with a Google search, I was led to just letting them keep their UUIDs, which this becomes important later and is the initial mistake.
The board was behaving great until I had the bright idea to turn the SD card storage into a backup drive. With very little experience in erasing, repartitioning and remounting drives, I worked my way around to setting it up to which the boot issues began. During that whole process I erased the boot firmware the Pi needed to startup properly. After tons of research, none of which helped, I followed my instincts with a couple clues left to me of what happened. Emergency boot investigation starts.
The first hint came from listing the available partitions and storage devices on the Pi, to which I saw the /boot/firmware
was unmounted. Nothing in my research pointed to this issue, but I happened to notice it go away when I initially was prepping the SD card. The first attempt at remounting the boot firmware, the Pi started up again! SUCCESS! ...or so I thought. Even with a couple reboots, it wasn't showing that it wasn't working until I moved the setup back by my router and couldn't SSH into it. After some more investigating and failing, my Hail Mary was remembering that decision about the UUIDs. So I decided to change the UUID of the newly partitioned drive and leave the appropriate drive with the boot firmware to keep the original ID. This was more to prevent any future headaches for anything that needed to refer back to this partition outside of the /etc/fstab
file references.
End of the day, if you decide to expand your OS into a new device, make sure it's in the proper storage device you actually want it to run in. If you decided to do things the hard way like myself, give your partitions unique UUIDs (ironic given that's their point) and point to the appropriate partition in your fstab file.
Cheers!