Subscribe to GEN
Login to GEN
Fedora is where new Linux technology lands first. New kernels, compilers, desktop and graphics stacks arrive here long before they reach an enterprise distribution, which makes it an excellent choice for developer workstations, for new laptops and GPUs, and for teams who need current toolchains. For a distribution that moves this quickly, it is remarkably well put together, and we support it properly wherever it is the right tool.
Service levels run from a next business day response to 30 minutes, 24 hours a day, every day of the year, from in-house UK engineers. There is no contract, no minimum term and no notice period: you buy hours at our published rates and draw against them.
Fedora sits at the top of the Red Hat family tree. It is upstream of CentOS Stream, which is upstream of Red Hat Enterprise Linux, so much of what appears in RHEL, and later in AlmaLinux and Rocky Linux, appears in Fedora first. A developer on Fedora today is working with the kernel, compilers, SELinux policy and system tooling that the enterprise distributions will adopt in the years ahead.
That is the reason to choose it. New hardware tends to work on Fedora first because the kernel and graphics drivers are current. Developers get recent language runtimes and toolchains without fighting the base system for them. And because Fedora shares rpm, dnf, systemd, SELinux, firewalld and NetworkManager with the enterprise distributions, the skills and scripts built on a Fedora workstation carry straight across to the servers the software is deployed on.
Fedora is not one product. Fedora Workstation is the desktop most people know; Fedora Server is the conventional server edition; Fedora CoreOS is an automatically updating, container-focused operating system for hosts; the atomic desktops such as Silverblue and Kinoite deliver the whole system as a single image with rollback; and Fedora IoT applies the same approach to devices. We support all of them.
Fedora is open source. Whether you support the project is entirely your decision, and not one we will make for you. If you do choose to, do it directly with the project, so the money reaches it rather than a reseller.
Fedora faults follow its release cadence. Most of the calls we take arrive in the weeks either side of a new release, or the day a new machine arrives with hardware the previous kernel had never seen.
A dnf system-upgrade that will not resolve its dependencies, an offline upgrade that stopped part way through, or a machine left so many releases behind that it has fallen out of support. We finish or unpick the transaction, then bring the system level with a supported release.
A system that will not boot after an upgrade or a new kernel, missing boot loader entries, an out of tree driver that has not rebuilt for the new kernel, or a Btrfs root that has run out of space. Fedora keeps previous kernels installed, so there is usually a way in to start from.
Wi-Fi without firmware, external displays and docks that stay dark, suspend that never resumes, audio devices PipeWire cannot see, and GPUs that need a driver from outside Fedora. We find out which layer is missing, rather than trying kernel parameters until something changes.
RPM Fusion, COPR and vendor repositories that have not yet published packages for the new release, conflicts between them and Fedora's own packages, and the one repository that blocks an entire system upgrade.
A CoreOS host or Silverblue desktop that came up broken after an update, layered packages blocking an upgrade, rebasing to a new release, and pinning a known good deployment. The previous deployment is kept, so rolling back is usually a reboot rather than a rebuild.
Denials that appear after a release upgrade brings new policy, contexts lost when files were moved into place, and containers that cannot reach their volumes. We fix the policy, labels or booleans rather than switching SELinux off.
The applications on top, from web servers and databases to containers, are covered on our Linux support page. If a system is down now, raise it on the HelpDesk.
Once a year, at least. With a new release roughly every six months and each supported for roughly thirteen, every Fedora machine has to move forward about once a year to keep receiving security updates. That is manageable on a schedule, and painful when it is left until a machine has already fallen out of support.
Workstation and Server. dnf system-upgrade downloads the whole of the new release first, then installs it in a dedicated boot with nothing else running. Most failures happen before that point, on a third party repository or a driver, which is why we resolve them first.
CoreOS, Silverblue, Kinoite and IoT. The atomic variants move to a new release by rebasing with rpm-ostree. The new deployment is staged beside the old one, and if it does not come up properly, the previous deployment is still there to boot.
Moving on from Fedora. Where a Fedora server has become something the business needs to leave alone for years, we move it to AlmaLinux or Rocky Linux. Because Fedora is ahead of them rather than alongside, that is a planned rebuild, not an in-place conversion. Fedora releases long past support are covered on our legacy system support page.
Fedora's natural home is the developer's desk. One Fedora laptop is easy; forty of them, on three different releases, with a mixture of GPUs and docking stations, is where it needs managing. This is the work that keeps a Fedora fleet current and productive.
A fleet moved through each release on a timetable: a pilot group first, then everyone else, well inside the support window. Tracked against our asset register as part of a maintenance plan.
Development environments in Toolbx containers, so each project gets its own toolchain without touching the host, and rootless Podman for building and running the same images that go to production.
New models brought into service, firmware updates, and GPU drivers for development and compute work, including drivers from outside Fedora that have to keep rebuilding for every new kernel.
Screen sharing and remote desktop under Wayland, multiple displays and docks, conferencing audio and Bluetooth headsets through PipeWire, and the older applications that still expect X11.
Encrypted disks on laptops, SELinux kept enforcing, firewalld zones that suit a machine moving between office and home, and SSH and sudo policy that is specific rather than blanket.
Silverblue and Kinoite for teams who want a workstation that cannot drift: the base system delivered as one image, applications alongside it, and every update reversible.
It is a question we are asked often, and the honest answer depends on how long the machine needs to stay put. The difference between the two is not quality: it is release cadence.
Fedora moves forward every six months or so and supports each release for about thirteen. That is exactly what a developer workstation, a laptop with brand new hardware or a CI runner needs, and it means everything on it is current. It also means every Fedora machine has an upgrade to plan, every year, for as long as it is in service.
AlmaLinux and Rocky Linux follow Red Hat Enterprise Linux, with lifecycles measured in years. For a long-lived production server, one installed to run an application for most of a decade, that is what we would usually recommend, and AlmaLinux is what we run on our own servers.
The two fit together well. Because Fedora is upstream of the enterprise distributions, a team can develop on Fedora and deploy to AlmaLinux or Rocky Linux with the same package tooling, the same SELinux model and the same service management, and we support both ends of that pipeline.
Yes. GEN support Fedora Workstation, Fedora Server, Fedora CoreOS, the atomic desktops such as Silverblue and Kinoite, and Fedora IoT, across the UK. Service levels run from a next business day response to 30 minutes, 24 hours a day, every day of the year, delivered by in-house UK engineers with no contract.
Fedora is well engineered and can run production workloads, but each release is supported for roughly thirteen months, so every Fedora server has to be upgraded to a new release about once a year. For a server meant to be installed once and left running for years, GEN would usually recommend AlmaLinux or Rocky Linux instead. Fedora is the right choice where current kernels and toolchains matter more than a long lifecycle, and on developer workstations.
A new Fedora release arrives roughly every six months, and each release is supported for roughly thirteen months. In practice every Fedora machine needs moving to a newer release about once a year to keep receiving security updates.
Fedora sits upstream of CentOS Stream, which in turn sits upstream of Red Hat Enterprise Linux. Much of what later appears in RHEL, and so in AlmaLinux and Rocky Linux, appears in Fedora first. The tooling is shared across the family: rpm and dnf, systemd, SELinux, firewalld and NetworkManager, so skills and scripts carry across.
Yes. Fedora is upgraded in place with dnf system-upgrade, which downloads the new release and installs it during a reboot, and the atomic variants are moved to a new release with rpm-ostree, keeping the previous deployment available as a rollback. GEN check third party repositories and drivers before the upgrade, because they are the most common reason one fails, and take a snapshot or image first so there is always a way back.
Yes. GEN support the atomic desktops, including Silverblue and Kinoite, and Fedora CoreOS for container hosts, including rpm-ostree layering, rebasing to a new release, and rolling back a deployment that has gone wrong.
No. Fedora is free and open source, and GEN's support does not depend on any subscription. Whether to support the project is the customer's own decision; anyone who chooses to should do so directly with the project, so the money reaches it rather than a reseller.
No. There is no support contract, no minimum term and no notice period. Customers buy hours at published rates and use them as they need them, or take a fixed price annual maintenance plan if they prefer a predictable cost.
Our engineers are UK based and in-house, with no offshore outsourcing: the specialist who takes your case is the specialist who works it, and they hold the production experience to match the equipment in front of them. Risk is assessed before anything is changed, the SAPR method is applied to every fault, and five shifts a day mean an overnight handover is a conversation between two engineers rather than a note left in a ticket. Our AI runs on our own hardware in our own data centres, and it never writes a word you read.
There is no support contract, no minimum term and no notice period. You buy hours at our published rates, use them when you need them, and what you do not use carries over. How GEN support works sets all of it out in full.
