BTRFS saved my broken root folder [devlog 3]

Well I tried installing google-cloud-sdk and for some reason it didn’t seem to be working, but I couldn’t uninstall it completely with pacman -Rns google-cloud-cli. Initially I thought the problem was still in the root folder, so I decided to rollback my system using btrfs. Now, I’ve never done this before but I remember configuring my system somewhat to do it with snapper-rollback. Unfortunately, it didn’t work. But I had it configured enough to just do:

sudo snapper rollback -a classic {snapshot no of boot}

It created a pre snapshot which I guess was the broken root, and a new snapshot which is the one I want to boot into (before installing google-cloud-sdk) and makes that writeable (all other snapshots are read only). This was quite the ordeal and it still isn’t fixed coz @home isn’t changed.

I found the changes it did to my ~/.config folder, and after wiping that it was purged.

---

That was the only important information I felt I might need when looking back. Documenting it this way might be super useful in the future once I train IIYS on my system’s state so that it can help me with related problems months down the line.

I tried documenting my day using obsidian this time, instead of directly using the devlog. It did help my productivity because

• I can keep track of tangents in thought better, and also the results they lead to (the last part is super useful)
• Even though I feel like I haven’t done a lot I can look back and see that I did infact do a decent amount of work

That’s the good part, the bad part as you might have guessed by the way I started the devlog, is that I can’t use my obsidian note paraphrased by an LLM to write my devlog. I tried and it was… alright. But hopefully with more data of the obsidian notes and the corresponding devlog I’ll be able to make the LLM a better writer. Without further ado, here’s today’s output:

Today was another adventure in my quest to create the perfect AI assistant for my IIYS project. I decided to dive into using gcloud APIs to build a LangChain bot that can chat, remember conversations, and reference long-term memory. Setting up the budget for gcloud was straightforward, but choosing the right tools took some consideration. I opted for langchain-google-vertexai instead of langchain-google-genai since it has access to code-bison and is generally more cloud-native.

The real fun began with the installation of gcloud. I messed up initially, and undoing that wasn’t easy. Thankfully, I had my system configured with btrfs snapshots, so I used snapper to roll back:

sudo snapper rollback -a classic {snapshot no of boot} This created a pre-snapshot (the broken boot) and a new snapshot, which I booted into, making it writeable. The process was quite the ordeal and didn’t fully fix the issue since @home wasn’t changed.

The breakthrough came when I purged the gcloud config folder in ~/.config. This reset my terminal back to normal after it had mistakenly been behaving as if it were in the cloud.

Integrating gcloud with the Fish shell posed another challenge. By using bass, I managed to run the necessary bash fixes within Fish—quite the elegant solution, if I do say so myself.

My next task was figuring out how to run Gemini Flash via LangChain, though I hit some authorization snags. Solving this will be crucial for advancing the IIYS project, as it’s a key component of the assistant’s functionality.

Every step, even the setbacks, is progress. Onward to tomorrow!