Linux, Hibernation, and SSD: Four Years of an Accidental Migration

Four years of GNU/Linux: from dual boot to the SSD limit

Can you hibernate Windows and Linux simultaneously on the same computer? In theory, yes. On a 2015 Shuttle Slim mini PC—dual-core 1.5 GHz Celeron, 16 GB RAM, and SSD drive—the answer was a resounding no for months. This is the first stop on a four-year GNU/Linux experience that included impossible hibernation, SSD wear, and even a video cable change.

The starting point: installing Ubuntu 22.04.1 while keeping Windows 10 22H2 in dual boot with GRUB. Ubuntu hibernates without issue, once the offset is calculated in the GRUB file. Windows does not. Running shutdown -h results in the terse message: «The system cannot find the specified file (2)».

Why doesn't Windows hibernate with Linux installed?

The hiberfil.sys file exists in the Windows partition. Resizing it to match the RAM size—initially 40% of that figure—does nothing. The prevailing explanation is that the partition marked as active hosts GRUB, which Windows cannot digest. Changing the active partition might allow Windows to hibernate, but it would leave Ubuntu without a boot option. A perfect circle.

Usual methods were tried without success: disabling and reactivating the hibernation service via console with powercfg.exe /hibernate off and on. The flute didn't play either. The 90 GB free in the partition and 16 GB of memory rule out space issues. Someone half-jokingly suggested wiping Windows and virtualizing it within Linux.

The SSD that consumes 50 GB of daily writes

The warning came later: 40,600 GiB written and rising at a rate of 50 gigabytes daily, because the machine stays on for many hours. The manufacturer rates the disk limit at 160,000 GiB. There is margin, but the concern is real.

Part of the solution lies in TRIM. Distributions with systemd run it automatically—once a week or continuously with the discard option—so scheduling it manually with cron is a relic of another era. The other, more domestic approach is not having just one disk: SSDs die without warning, and mechanics at least show symptoms.

Swappiness, swap, and 25 GB to hibernate

Here comes the dance of figures. With vm.swappiness at 60 (default value), swap starts being used when 40% of RAM is full. Set to 0, it's as if it doesn't exist: the system ignores it, and some applications eventually die. With the value at 5, swap moves again, and nothing perishes.

The free -h output doesn't help calm nerves: 15 GiB total, 5.8 GiB used, 410 MiB free, and 9.3 GiB cached. The system monitor says something else—13.5 GB, 81.4%—and seems more credible for someone running three browsers, messaging apps, players, and a distributed computing client simultaneously. To hibernate, 25 GB of swap was created.

Wayland moves windows and exhausts RAM

The modern display protocol brings two gifts. The first: some maximized windows shift downward after the screen turns off and resumes. The second, worse: memory is gradually consumed until, exceeding 80%, some application dies. With pipas, the result is returning to Xorg.

And there is no comfortable Plan B. Xorg is heavily patched, and few people are willing to understand it. Proprietary drivers for graphics cards don't make it easier either.

From two Windows to two Linux: Ubuntu, Artix, and Linux Mint

The dual boot ended in divorce: Windows out, and in its place, a second Linux. First Artix, Arch's sister without systemd, with dinit boot and KDE Plasma. The installation was reasonable, except for PipeWire starting twice and killing the sound. Then came Linux Mint, and there the matter settled: it runs like a dream.

The balance between distros is not surprising. Memory consumption ends up being similar if you equalize what runs underneath: an bicho like ClamAV consumes a gigabyte on its own. Real differences appear in the community, not the desktop.

Flatpak, AUR, and the filling disk

To install Microsoft Teams or Mp3Gain, the short path is Flatpak. The problem is that packages occupy a pavor of disk space. The alternative in Artix is the AUR, where both are available as binaries without compilation. The 100% CPU consumption by browser renderer processes is a different matter: a symptom of software rendering.

The cable that ruined HD DTT

Accumulated anecdote: the pixelated image of HD DTT channels, present in Windows and almost all distributions. The cause was not software. It was an analog VGA cable. Changed for a DVI-D one, the problem disappeared.

---

Four years, several distributions, a motherboard repaired for 70 euros, and an SSD that still breathes. The conclusion is as modest as it is revealing: almost none of the problems were Linux's fault. Almost.