When I first joined my school, students were given the option to either buy their school-issued Chromebook or take one on loan. I chose to buy mine. That meant I fully owned the hardware, although it was still enrolled on the school’s managed device system, which is normal for school environments.
At the time, this didn’t feel restrictive. It was just part of how the device worked in school. The Chromebook handled everything I needed, and most of my focus was on building simple websites and experimenting with ideas I was learning at the time. Nothing about the setup felt limiting yet.
When the Device Started Feeling More Restricted
Over time, the school restrictions became more strict and sometimes inconsistent, shifting from practical controls into something that felt more limiting in day-to-day use.
As my own technical understanding grew, I started noticing those restrictions more clearly. It wasn’t that the device suddenly stopped working for me, but rather that I began understanding more about how it was being managed and what was happening behind the scenes on a system level.
That curiosity naturally led me to explore how ChromeOS devices work, how enterprise enrolment functions, and how people in the wider Chromebook community approach modifications and Linux-based setups.
Exploring the Chromebook Modding Space
At first, I explored the ecosystem casually. I came across tools like sh1mmer, along with other community methods and discussions around Chromebook modification and recovery environments.
At that stage, I wasn’t committed to any single approach. I tested and researched different tools, mainly to understand what was possible and what level of flexibility I actually needed.
Eventually, I settled on Shimboot, mainly because it offered a more flexible and practical way to run Linux environments on my specific device.
This wasn’t about removing ChromeOS entirely. My goal was flexibility: being able to experiment with Linux while still keeping the device usable in a school environment.
Security Research and System Curiosity
As I spent more time around the system, I also became curious about how school-managed environments and network systems were structured.
During this process, I occasionally came across inconsistencies or behaviours that didn’t fully make sense. I attempted to report what I found through normal channels, but I never received meaningful responses. In most cases, it felt like the reports were either lost in the system or not prioritised.
While this wasn’t the main focus of what I was doing, it shaped how I started thinking about real-world systems, especially how large managed environments behave in practice.
Moving Toward Linux and Dual Use
Eventually, my focus shifted away from exploration and more toward building a usable system.
Instead of removing ChromeOS, I aimed to introduce Linux in a way that allowed both environments to be used, depending on what I needed.
At this stage, I was still only using the device in school, so maintaining usability was important. The goal was to keep a working setup while expanding what the device could do technically.
The “Hacked Chromebook” Setup
As the system evolved, I started referring to it as my “Hacked Chromebook.” The name was informal and simply reflected how heavily modified the device had become compared to its original state.
At first, everything was private. I experimented with different boot environments and configurations until I had something stable enough for regular use.
Eventually, I began using it daily in school as a dual-environment setup. It became something I relied on, switching between ChromeOS and Linux depending on what I needed at the time.
Because of how different it looked and behaved, it naturally stood out compared to standard school Chromebooks, especially when booting into Linux environments.
Fully Moving to Linux
Over time, I eventually transitioned fully into Linux as my main environment and removed ChromeOS entirely through my own soft-mod setup.
At that point, Linux became the only operating system I used on the device. This marked a shift from experimentation to full daily usage of a Linux-based system.
Daily Driving Linux and Hardware Improvements
As my interest in Linux grew, I began customising the system heavily for performance and usability.
I forked and modified an existing Chromebook Linux boot project (Shimboot) to better suit my hardware and use case. I did not contribute these changes upstream, as the project was something I adapted purely for personal use and experimentation.
One of the biggest improvements I made was GPU support and performance tuning on Debian 13. This made a noticeable difference in usability and allowed significantly better performance in graphical applications.
With these improvements, I was able to run Minecraft at 100fps+ on Debian 13, which was a major milestone for how far the setup had come compared to its original state.
Building My Own Tools and Infrastructure
As the system became more stable, I started building around it.
I created my own package repository at deb.ahmedallion.dev
This allowed me to manage custom packages and configurations specific to my setup.
Alongside this, I built a system status page that tracked when the device was active. This was purely for my own security and tracking purposes, so I could verify device usage and ensure I had accurate system activity logs for myself.
At this stage, the Chromebook had effectively evolved into a fully customised Linux machine with its own ecosystem.
How It Was Used in Practice
During this period, I used the device heavily in everyday school life.
Linux became the primary environment, while ChromeOS was eventually removed entirely. The system was used for development, experimentation, and general day-to-day computing.
It also became something people around me recognised because it behaved very differently from a standard school Chromebook.
Despite that, I kept most of the technical details to myself and only shared parts of the setup with a small number of people who understood the technical side.
Gradual Wind Down
As I reached my GCSE period, my focus naturally shifted away from experimentation and toward exams and school priorities.
Around the same time, the hardware itself began to fail. After being left in a bag during a particularly hot period in the UK, the battery degraded significantly and eventually reached a point where the device could only reliably run when plugged in.
After leaving school, the Chromebook was officially unenrolled from the managed system. At that point, I decided to fully wipe my Linux setup, remove all custom packages, and restore ChromeOS.
I also closed my custom repository and removed the tooling around it, as I no longer intended to maintain or use it. It was something I had moved on from rather quickly once I stopped actively working on the system.
The device was then repurposed for general family use rather than development.
Final Thoughts
Looking back, I don’t really see it as just a “hacked Chromebook” anymore.
It became a long-term project in understanding and modifying the hardware I owned. Along the way, I learned a huge amount about Linux systems, boot processes, hardware constraints, and how open-source tools can be adapted in practice.
It also gave me exposure to how real-world systems operate at scale, including managed device environments and network administration.
In the end, the most important part wasn’t any single setup or configuration. It was the process of continuously modifying, rebuilding, and understanding the system over time.
Now, it remains one of the earliest and most defining projects in my development journey, and fittingly, the machine I’m writing this blog on today.