I have a fifty gigabyte partition on a spare laptop that exists for one reason: to let me break Ubuntu on purpose. Every six months, when the next release enters its snapshot cycle, I wipe that partition, install whatever the latest snapshot is, and run through the same four-step checklist I have used since 2022. Most cycles, nothing breaks. A few cycles, I find a real bug and file it. One cycle, I lost a Saturday to a kernel regression that nobody else saw yet. That is the cost and the value of running pre-release Ubuntu as a hobby, not as a duty.
The Ubuntu 26.10 snapshot cycle is in its final stretch. Snapshot 4 dropped earlier this month, the beta lands at the end of September, and the final release is October 15. None of those dates matter to anyone who is not actively testing. They matter to me because the partition on my spare laptop is about to be wiped again.
Why I keep a partition around for this
Pre-release Ubuntu is not the kind of software you install on the laptop you need to work on tomorrow. It is the kind of software you install somewhere you are willing to lose a day if the kernel turns out to be broken on your hardware. The partition on my spare laptop fits that brief exactly. It is large enough to install Ubuntu with a separate home directory, small enough that I do not feel bad about formatting it every cycle, and isolated enough that a bad snapshot cannot take my actual work laptop with it.
The cost of running pre-release on the wrong machine is well known. I wiped a work laptop in 2023 chasing a preview kernel that turned out to have a regression in the network driver. I learned the lesson the expensive way and now I only ever run snapshot cycles on the spare. The lesson generalizes: if you cannot afford to lose the machine tomorrow, you cannot afford to run the snapshot on it.
The cycle has been running long enough that the rhythm is predictable. About three weeks before the final release, Canonical cuts a series of snapshots that are supposed to be representative of what October will ship. About two weeks before, the beta lands. Between the beta and the final there are release candidates, which are mostly useful for confirming that a bug you reported in the beta actually got fixed. After the final, the cycle resets for the next release.
The four-step checklist I use every cycle
I run the same short checklist every time, and it has not changed since I started doing this in 2022. The point is to spend twenty minutes verifying the basics, not to use Ubuntu as a daily driver for a week. Here is the order:
- Wi-Fi. Open the system settings and confirm the Wi-Fi driver loaded without manual intervention. If it did not, file a bug. The number of times this has actually been broken is small. The number of times I have been glad I checked is also small. The cost of running the check is one minute.
- File system. Open the file manager and copy a folder between two internal drives. If the file system is healthy and the copy completes, the disk layer is fine. If the copy hangs, the kernel has a regression and I am filing a bug with a screenshot.
- Rendering. Open Firefox and load three heavy pages, including my own webmail, which has historically been a good canary for graphics driver regressions. If the pages render cleanly, the GPU stack is fine. If anything flashes, flickers, or fails to load, I am filing a bug.
- Kernel confirmation. Open a terminal and run
uname -rto confirm the kernel is the one the snapshot is supposed to ship. If it is, the install actually used the right ISO and I am not testing the wrong build. If it is not, something went wrong upstream and I want to know about it.
The whole checklist takes about twenty minutes on a clean install. That is enough to find the obvious regressions without making the cycle into a job. If I find a bug, I file it with the steps to reproduce and move on. If everything passes, I file a confirmation comment on the existing launchpad entry for the snapshot, which gives the developers a data point that the build worked on at least one real machine.
What the current snapshot actually contains
The current snapshot is the last one before the beta, which is why people who are not testing the cycle are paying attention to it. The kernel is Linux 7.2 across every flavor in the Ubuntu family, which is the version server folks and anyone running newer hardware will care about. For most desktop users, the difference between 7.2 and the 7.3 that ships in the final in October is invisible in daily use.
Two features are landing in the final release even though they are not in this snapshot yet. The first is a new onboarding flow that walks first-time users through more of the setup steps the desktop used to skip. The second is on-device speech-to-text (voice recognition that runs on your laptop rather than sending audio to a remote server for processing). Both are the kind of feature that you only notice when they go missing, which is the highest compliment a desktop feature can earn.
The package manager story is also shifting. Canonical has been talking about a unified App Center that treats the snap format and traditional Debian packages as equal citizens. The implementation is still rolling out and the experience is mixed, but it is the direction the project is moving in. Anyone who runs Ubuntu as a daily driver today will see this app surface within a few months.
When the snapshot is worth your time and when it is not
The snapshot is worth twenty minutes of your time if you have a stake in Ubuntu shipping working software. That means you develop for it, you ship a package that runs on it, or you run an environment that depends on a specific kernel or library version. If any of those are true, the snapshot is the cheapest way to find out whether your stack still works.
The snapshot is not worth your time if you are a curious user who wants to see the new desktop early. The beta in two weeks will give you the same preview without the installer bugs, and the final in five weeks will give you the real thing. There is no version of being curious early where the snapshot is better than waiting, except for the people who are actively filing bugs.
If you do decide to run it, run it on a partition that does not matter. The cycle is real, and the bugs are real, and the cost of testing on the wrong machine is your weekend. Production machines should stay on the current LTS (Long Term Support) release until October 16, when the new version ships and the upgrade math starts to make sense.
Trade-offs
Running the snapshot costs time even when nothing breaks. Twenty minutes for the checklist is the floor, and you will probably want to come back the next day and re-verify that the things you thought were fixed are still fixed after a reboot. Add another ten minutes for the second pass and you are at half an hour of your evening for a snapshot that you might not have any reason to use.
Judgment is the second cost. You have to decide whether a bug you see is something you should report, something you should ignore, or something you should fix yourself by holding off on an update. Most people do not want to develop that judgment, and the cost-benefit math is straightforward: if you are not writing software for Ubuntu users, the time is better spent on your actual work.
Risk is the third cost. A bad kernel update on a test partition is annoying. The same kernel update on a production machine is a weekend you do not get back. The cycle is real, but it is not the place to learn Linux the hard way.
If you are going to run it, run it on a partition that does not matter. If you cannot get a partition that does not matter, wait for the final.
What I would tell past me
Three things, if I could send a message back to the version of me that was reinstalling a work laptop at 11 PM on a Sunday in 2023.
- Run pre-release Ubuntu on a partition that does not matter, never on the machine you need to work on tomorrow.
- Keep the test checklist small enough to repeat every cycle. Twenty minutes, four checks, one bug report.
- Skip the daily builds unless you are actively filing bugs. The snapshots are where the cycle becomes useful for someone who is not a developer.
For anyone with a stake in Ubuntu shipping working software, this snapshot is the right week to spend twenty minutes on a test install. For everyone else, the final on October 15 will land without you and that is fine.