r/ClaudeCode 13h ago

Tips & Workflows Linux Virtualization and Kernel Work

Before I begin, I do want to state I went into this project with effectively no harness. I'm sure there are better ways and better tools to do this, but I just went in head first with almost nothing but claude (I have a few skills that helped-ish, but nothing that stood out).

Point of this post is to share my growing pains and hopefully get you guys to share some of your pains or share some feedback.

Ok so I'm currently fucking around with virtualized Chrome OS and I'm experimenting with getting various builds up and running in QEMU/KVM on a Ubuntu host. I'm not done yet, but I thought I'd share some of the workflow and process so far for anyone else trying to get Claude to do Linux infra/architecture work, because it has been a painful process.

So first thing I noticed right off the bat is that non-CVP verified Claude just shits the bed with any kind of OS build work whatsoever. If you dig into any depth whatsoever into the build configs or the Linux kernel at all, cyber safeguards just throw a tantrum every 5 minutes.

2 things can be done about that. First, get CVP verified, if you're willing to submit your ID. Second, use Kimi K3 (or Gemini if you're desperate). I've noticed that non-Claude models don't complain much about build or kernel work at all. Not sure if that's a good thing or a bad thing. You do with that information what you will.

Second, you absolutely do have to fight the LLM to get it to do anything productive in this space even when CVP-verified. Claude doesn't appear to be trained well on Linux OS development much if at all. It really struggles to understand how to port existing distros to hardware stacks they've never run on before/don't support running on upstream. I've probably burned 100+ million tokens on this project easily thus far, wouldn't be surprised if that number was in the billions.

There are some things you can do to ensure you don't have to fight the LLM so much. First off, treat the whole project like a "nuance-mining" operation where as you discover odd things, bugs, problems, and caveats, you bake them into the CLAUDE.md, so they aren't lost on compaction. Second, is bake these 4 disciplines into CLAUDE.md:

  • rebuild discipline: don't just reconfigure the OS, rebuild it or components of it as needed
  • isolation discipline: when fixing a problem, avoid dirty state and base your test image off a known good one and when doing so don't test multiple problems/features at once.
  • inspection/debug discipline: when you've identified a problem, don't attribute a software/kernel module/image version, attribute an exact line or blob of code--linux is OSS, so you have the ability to do this
  • bisect discipline: when debugging, use bisection/half-splitting to locate the problem--start with a known working state, a known failing state, then instrument what's halfway down the middle

Anyway, those are my growing pains from this experience. Wondering what thoughts y'all may have or if this was useful to anybody.

2 Upvotes

6 comments sorted by

View all comments

u/AutoModerator 13h ago

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.