Sign in Subscribe

If Fedora is on your laptops, track the release number

Fedora 42 reached end of life on May 27. If Linux desktops are part of your fleet, the release number, firmware path, and upgrade plan need to be visible before a support ticket proves they were not.

If Fedora is on your laptops, track the release number

Fedora Linux 42 is now end of life. Fedora's own table lists May 27, 2026, and the docs are plain about what that means: EOL releases are no longer maintained and do not receive updates.

I read this as a reminder that Linux desktops are real endpoints. If they are in your environment, the release number belongs in inventory, not in somebody's memory.

Fedora is a good example because it moves quickly on purpose. The Fedora lifecycle docs say new releases arrive roughly every six months, with about 13 months of maintenance. Release N is supported until four weeks after Release N+2. It works for teams that want a current desktop stack, but it runs on a different schedule than an LTS fleet.

Admins need to watch this because a laptop can drop to an unsupported release before the team notices. A developer installs Fedora because the hardware support is good. A lab machine gets repurposed. A student device survives another semester. Nobody complains, so nobody checks. The first sign is usually a ticket, a failed package update, or a security exception.

What I would want visible

If I were responsible for Linux laptops, I would start with simple inventory fields before getting clever:

  • Distribution and release, such as Fedora 42, Fedora 43, Fedora 44, Ubuntu 24.04 LTS, or Ubuntu 26.04 LTS.
  • Support status for that release, preferably reduced to something an admin can filter: supported, approaching EOL, or unsupported.
  • Upgrade target and owner. A machine without an owner is not managed. It is just present.
  • Third-party package sources, because release upgrades get harder when random repos and vendor packages are part of the base system.
  • Firmware update path and firmware status, especially on laptops.

Firmware is easy to overlook if your Linux experience still comes from servers or hobby machines. The firmware support on Linux laptops has improved. The Linux Vendor Firmware Service acts as the portal where hardware vendors upload firmware updates. Major Linux distributions use its metadata for clients like fwupdmgr and GNOME Software. The LVFS documentation explains the relationship: fwupd queries supported hardware and deploys firmware when the vendor metadata is present.

Richard Hughes, who leads much of this work, announced in May that HP had become a premier LVFS sponsor, joining Dell and Lenovo on the LVFS sponsor list. Not every model is covered and staged testing is still required, but firmware updates need to be part of the Linux endpoint process.

What I would do with Fedora 42 machines now

First, find them. Do not start on an upgrade plan if you cannot answer how many Fedora 42 systems exist and who owns them.

Then separate the devices into groups:

  • Machines that can move directly to Fedora 44.
  • Machines that need a pilot because of hardware, VPN, EDR, developer tooling, or third-party repositories.
  • Machines that should move to a slower platform because Fedora's cadence is a bad fit for that role.
  • Machines nobody can explain. Those need an owner before they need an upgrade command.

For the actual upgrade path, use Fedora's docs instead of folklore. The DNF system-upgrade guide says to fully update the current system first, review the release notes, back up data, download the target release packages, and perform the offline upgrade. It also notes that Fedora supports upgrades across at most two releases. Fedora 42 to Fedora 44 fits that boundary. Older machines may need smaller steps.

After the upgrade, check what changed. Do the VPN and certificates still work? Did the EDR client survive the release jump? Are developer containers, Flatpaks, printers, and browser policies still behaving? Did fwupdmgr get-updates show firmware waiting for a reboot? The goal is to confirm the pilot group is current afterward. Finishing one machine is only the dry run.

The FileWave-shaped part

For FileWave admins, the habit is familiar: make the fleet report its status before you decide what to do next.

This is also where timing matters. FileWave Linux support is coming soon, and that should make this kind of release and firmware visibility more actionable, not less. I would not wait for launch day to decide which Linux laptops count, which releases they run, and who owns the exceptions.

If Linux is part of your endpoint roadmap and the timing matters for your environment, connect with FileWave sales for the current details.

The useful target is a report or group that shows which Linux laptops are on unsupported releases, which ones are close to EOL, which ones have pending firmware, and which exceptions have an owner. Once that is visible, remediation becomes standard policy work instead of tracking machines one by one.

Linux laptops can be normal endpoints. They need the same checks the others get: version, support status, firmware state, owner, and next action.

Sources