24/7 Linux Support

Nobody rings a Linux specialist to be told how popular Linux is. They ring because a server has dropped to an emergency console and will not come back, because an mdraid array has failed to assemble, because a volume group is missing a physical volume, or because something on the box looks wrong and nobody in the building can say whether it has been broken into. That is the work, and it is what our engineers do.

"It has dropped to an emergency console"
"The mdraid array will not assemble"
"LVM says a physical volume is missing"
"I think this has been hacked"

Service levels run from a 4 hour response Monday to Friday through to 30 minutes, 24 hours a day, every day of the year including bank holidays. There is no support contract, no minimum term and no notice period: you buy hours at our published rates and you draw against them. Every tier reaches an engineer, because we do not employ anybody to read a script at you first.

What the Call Is Usually About

Linux faults are not vague. By the time somebody picks up the phone the system has usually told them exactly what is wrong, in a form nobody on site can act on. These are the cases that arrive most often.

Emergency console and boot failure: a dracut or initramfs shell, an unbootable root filesystem, a bad entry in fstab or crypttab, a GRUB configuration that no longer points at a kernel that exists, a full /boot after an upgrade, or a systemd unit failing early enough to stop the boot. We work from the console, serial or IPMI, get the system up, and then find out what put it there.
mdraid recovery: degraded and failed arrays, superblocks that no longer agree, arrays that will not assemble after a controller change or a disk reorder, and the far more dangerous case of a rebuild started onto the wrong member. We read the metadata before touching anything, assemble read-only where we can, and image the members first when the data matters more than the clock.
LVM2 recovery: volume groups reporting a missing physical volume, metadata restored from archive, thin pools that have run out of metadata space, snapshots that have filled and been dropped, and logical volumes recovered after a partition table was rewritten underneath them. Most LVM problems are recoverable, and most become unrecoverable at the hands of somebody guessing.
Suspected compromise: unexplained outbound traffic, a load average with nothing to account for it, cron and systemd timers nobody wrote, altered SSH configuration and authorised keys, or a hosting provider notice. The first advice is usually to stop: do not reboot, do not reinstall, and do not delete anything, because all three destroy the evidence that tells you how they got in and whether they are still there.
Filesystem and data recovery: ext4 and XFS repair, journals that will not replay, corruption after a power event, and ZFS and Btrfs pools that will not import or mount. We work on images rather than originals wherever the equipment allows it.
The system nobody owns: a server the last administrator built, undocumented, still running something the business depends on. We audit it, document it, and take it on from there.

If a system is down now, raise it on the HelpDesk or see emergency support. If you believe the system has been compromised, say so when you raise it, and leave it running.

The Stack Running On It

Very few Linux tickets are about Linux itself. They are about the thing running on it: a web server returning 502, a database that will not start after a power cut, a mail server that has stopped being accepted anywhere, a container host that has filled its disk. We support the operating system and the stack sitting on top of it as one system, because that is how the fault behaves, and because the answer is very often in a layer nobody had thought to look at.

Web servers and proxies: Apache and nginx configuration, virtual hosts, rewrites, reverse proxying, HAProxy and Caddy, TLS certificates with Let's Encrypt and certbot including the renewals that quietly stopped, and the 502, 504 and connection reset faults that come from the layer behind rather than the web server itself.
PHP and application runtimes: PHP-FPM pool sizing and process management, opcache, memory and execution limits, major PHP version upgrades on live sites, plus Python WSGI and ASGI, Node.js and Java workloads run under systemd.
Databases: MariaDB, MySQL and PostgreSQL installation, tuning, replication and failover, InnoDB crash recovery, corrupt tables, runaway queries, upgrades between major versions, and backups that are verified by restoring them rather than by the job reporting success.
Containers: Docker and Podman, Compose stacks, image builds and registries, storage drivers and volumes, networking and published ports, resource limits, and Kubernetes where the estate genuinely warrants it. Also the routine causes of a container host falling over: unpruned images, logs with no rotation, and a full /var/lib/docker.
Mail: Postfix, Dovecot and Exim, SPF, DKIM and DMARC, TLS, queue and deliverability problems, and the blacklist removals that follow a compromised account or an open relay.
File and directory services: Samba including domain membership and file server roles, NFS, rsync, OpenLDAP, FreeIPA and Kerberos.
Network services: BIND, Unbound and dnsmasq, DHCP, NTP and chrony, WireGuard, OpenVPN and StrongSwan, and the firewall rules in nftables, iptables or firewalld that sit around all of it.
Caching, queues and monitoring: Redis, Memcached, RabbitMQ, Prometheus, Grafana, Zabbix and centralised logging, configured to alert on things that matter rather than everything.

Where the stack is on our own infrastructure, see GEN Cloud. Where it is on yours, on your premises or at another provider, it makes no difference to how we support it.

Any Flavour, Fully Supported

Linux is not a single product, and a support offer that stops at Red Hat and Debian is not a Linux support offer. We fully support Alpine, Arch, Rocky, Alma, Red Hat, Fedora, Kali, Mint, Debian, NixOS, SuSE and Ubuntu, we take on CentOS and other distributions that have reached end of life, and we can support most of the rest. Our own routing, switching, firewalls, servers, telephony and virtualisation run on Linux internally, across the same distributions our customers use, so the differences between them are something we live with daily rather than look up.

Alpine

Alma

Arch

Fedora

Kali

Mint

Debian

NixOS

RedHat

SuSE

Rocky

Ubuntu

Embedded Linux

A growing part of our Linux work is not on servers at all. It is on devices: industrial controllers, gateways, kiosks, instrumentation, single board computers and custom hardware, where Linux is the firmware rather than the operating system and the vendor who built it has moved on, been acquired, or simply stopped answering. Most of this work has reached us by referral from customers and from other engineers, which tells you how few people take it on.

Build systems: Yocto and OpenEmbedded layers and recipes, Buildroot, OpenWrt, and plain cross-toolchains, including taking on an existing build tree nobody in the business now understands.
Boot and low level: U-Boot, device tree, kernel configuration and patching, board support packages, serial console and JTAG access to boards with no documentation left.
Drivers and interfaces: kernel and userspace drivers for I2C, SPI, CAN, GPIO, UART, RS485 and USB peripherals, and getting a working driver out of a vendor blob that only ever built on one old kernel.
Field reliability: read-only root filesystems, overlay and tmpfs layouts, flash wear and filesystem choice, watchdogs, and A/B update schemes that survive a power cut halfway through.
Device security: secure boot and signed images, disabling the debug paths that shipped by accident, credential handling on devices sitting on customer networks, and the long tail of CVEs in a kernel and BusyBox that were frozen years ago.
Recovery and continuity: reproducing a build for hardware whose original supplier has gone, extracting and rebuilding firmware, and keeping a fleet in service when replacement is not commercially realistic.

Small platforms are supported as seriously as large ones: Alpine, Raspberry Pi OS, OpenWrt and BusyBox based systems included.

Hardening

Hardening is the other half of the compromise conversation. Most of the Linux systems we are called to after a break-in were not attacked cleverly: they were reachable, out of date, and running more than they needed to. Hardening is unglamorous work that removes those three conditions, and it is done properly against a benchmark and a written record, not by pasting a list of settings from the internet into sshd_config.

Benchmark hardening: CIS benchmark and STIG alignment, applied and evidenced per system, with the deviations your applications genuinely require documented rather than quietly skipped.
Attack surface reduction: exposed services and listening sockets, packages and daemons nobody uses, firewall design with nftables or firewalld, and network segmentation between the systems that do not need to reach one another.
Access and privilege: SSH configuration and key management, sudo policy that is specific rather than blanket, service accounts that cannot log in, and removal of the accumulated accounts belonging to people who left.
Mandatory access control: SELinux and AppArmor policy written and enforced, rather than the permissive mode most estates quietly settled for years ago.
Kernel and runtime: sysctl and kernel parameter hardening, module blacklisting, systemd unit sandboxing, secure boot, and LUKS encryption at rest.
Audit and integrity: auditd rules that produce something usable, file integrity monitoring, log shipping off the host so the logs survive the incident, and detection of permission and configuration drift.
Patch discipline: vulnerability scanning and CVE tracking against what you actually run, with remediation scheduled rather than deferred. See preventative maintenance for how that is delivered as an ongoing service.

Performance Optimisation

"The server is slow" is a symptom, not a diagnosis, and it is very rarely solved by adding more hardware to it. We measure first, with perf, ftrace, bpftrace and the rest, find the actual constraint, and fix that. A system that has been properly profiled usually turns out to be waiting on one thing.

Storage and I/O: I/O scheduler selection, queue depth and readahead, filesystem choice and mount options, RAID chunk and stripe alignment, LVM layout, and where an SSD cache tier genuinely pays.
CPU and memory: NUMA topology and process placement, CPU pinning and isolation, governor and C-state configuration, swappiness, transparent huge pages, and dirty page writeback behaviour.
Networking: TCP stack tuning, offload settings, interrupt affinity and ring buffers, bonding and MTU, and the packet loss that gets blamed on the application for months.
Applications and databases: MariaDB, PostgreSQL, nginx, Apache, PHP-FPM and Java workloads tuned against the operating system underneath them rather than in isolation.
Virtualisation and containers: guest and host tuning for KVM and Proxmox, virtio configuration, storage path selection, and container resource limits that reflect the real workload.
Latency sensitive work: real time kernels, tickless configuration and jitter reduction for telephony, trading, instrumentation and control systems.

Consultancy and Projects

Beyond fault work, GEN provides Linux consultancy to organisations getting more from what they already run, or making a planned move away from a proprietary platform or an unsupported distribution.

Migration planning: moving off Windows, legacy Unix, or a distribution that has reached end of life, with a realistic path and minimal disruption.
Architecture and design: Linux server environments, high availability clusters, storage and network configurations built to last.
Automation and scripting: Bash, Ansible and Python automation to remove manual process and the errors that come with it.
Centralised management: OpenLDAP, FreeIPA and Kerberos for single sign-on and policy across a large Linux estate.
Containerisation: Docker, Podman and Kubernetes design, deployment and operational support.

Training

GEN delivers structured Linux training for system administrators, engineers and developers, covering foundations through to advanced operations. Courses are available on site, remotely, or as bespoke programmes built around your own environment. Use the More Linux Training button above to see current course availability and pricing.

Linux Support UK, Emergency Console, mdraid and LVM Recovery

Server, Desktop and Embedded. Supplying and Supporting Linux since 1991