What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A Linux update that “breaks” a computer can mean several different failures: the machine may stop before the boot menu, a new kernel may fail while an older one still works, package configuration may have stopped halfway, or the bootloader may no longer find the operating system. The safest fix is to identify that failure class first and then use the narrowest procedure documented for your distribution and release.
Before running any command, record your distribution and release, the exact error text, whether the machine reaches firmware or GRUB, whether a text console or recovery shell opens, what update you ran, and whether important data is backed up. Package commands for Debian-based systems are not interchangeable with Fedora commands, and Fedora’s traditional DNF systems use a different recovery model from rpm-ostree editions such as Silverblue.
If valuable data is not backed up, prioritize copying it or obtaining expert help before invasive repairs. A command that removes packages, changes boot configuration, or writes to the wrong disk can make recovery harder.
Recommended Free Tools
Classify the failure before you try to fix it
Use the symptom that occurs earliest in the startup process. The table is a triage map, not a diagnosis; the same symptom can have more than one cause.
#1 Best Overall
| What you see | Likely failure class | Safest first path | Main risk |
|---|---|---|---|
| Firmware appears, but no usable boot entry or GRUB menu loads | Bootloader, EFI entry, disk, or firmware problem | Use the distribution’s rescue media and inspect the installed system | Writing GRUB to the wrong disk or changing EFI entries incorrectly |
| GRUB appears, but the newest kernel hangs, panics, or returns to the menu | Kernel or initramfs regression | Try a previously installed kernel or recovery entry if one is offered | Assuming an older-kernel boot proves the exact cause |
| The desktop or a text login works, but the update reported dependency or configuration errors | Interrupted package transaction or dependency inconsistency | Use the package manager for your distribution and inspect its proposed changes | Removing or downgrading packages without reviewing the transaction |
| Fedora starts after a partial upgrade but packages conflict | Traditional DNF package set no longer matches enabled repositories | Confirm the release and repositories, then consider dnf distro-sync |
Unexpected downgrades or package erasures |
| Fedora Silverblue or another rpm-ostree edition fails after deployment | Bad image deployment | Select the previous deployment with rpm-ostree rollback |
Applying DNF instructions to an image-based system |
Debian’s installation manual explicitly treats a bootloader configuration problem and a newly installed kernel that will not boot as separate recovery cases. Treat “Linux will not start” as a description of a symptom, not as a command to run.
Protect data and capture evidence
If the system still boots, copy irreplaceable files to another disk or a trusted network location before changing packages. If it does not boot, use rescue or live media to copy data before attempting repairs. Do not format a partition or accept a transaction that proposes broad removals until you understand what it will delete.
- Write down the distribution name, release, desktop edition, and whether the machine uses BIOS or UEFI.
- Photograph or transcribe the complete error, including the first line that appears before a later cascade of messages.
- Note the update command or graphical action you used and the time it failed.
- Record whether GRUB, a text console, recovery mode, or only firmware is reachable.
- Identify encryption, LVM, RAID, Btrfs subvolumes, separate
/bootpartitions, and separate EFI system partitions before mounting anything. - Keep a second computer available if you need to create recovery media or read current distribution instructions.
Debian Reference recommends a full backup before high-risk repair and says that a seriously broken installation may be better served by a backup followed by a clean installation. Fedora likewise recommends backing up before a system-wide upgrade. These are safety requirements, not signs that every failed update requires reinstallation.
Free tools Windows power users keep installed
One-click scans. No signup required.
If the boot menu appears
Use a distribution-provided recovery entry or an older installed kernel when the menu actually offers one. Do not assume every distribution keeps an older kernel or that every firmware setup uses the same keys.
Ubuntu’s GRUB recovery route
Ubuntu’s Recovery_mode guidance describes holding Shift during BIOS startup or pressing Escape with UEFI to display GRUB. Choose Advanced options, then select a recovery-mode entry for the relevant kernel. Firmware timing and menu entries vary, so these keystrokes are Ubuntu guidance rather than universal Linux instructions.
If an older kernel boots, leave that working entry available. Make a backup, collect the failing kernel’s messages, and follow the current Ubuntu instructions for diagnosing or removing the faulty update. A successful older-kernel boot narrows the investigation to the newer kernel or its early-boot files; it does not by itself prove which component is responsible.
When no recovery entry is available
If GRUB offers no usable kernel, drops to a prompt, or cannot find the installed system, stop guessing at package commands. Move to the rescue-media procedure for your distribution. A package manager cannot repair a system you cannot reliably access unless you first provide a separate environment.
If the desktop or a text console still starts
Repair only the package state that matches your distribution. First let the package manager show what it intends to install, remove, or downgrade. Read the proposed transaction; cancel it if it would remove essential desktop, boot, storage, or authentication packages unexpectedly.
Rank #2
Debian and other APT/dpkg systems
Debian Reference documents the following sequence for a failed installation caused by missing dependencies after a forced dpkg -i operation:
sudo apt --fix-broken installsudo dpkg --configure -a
apt --fix-broken install asks APT to resolve missing dependencies. dpkg --configure -a configures packages that were unpacked but never completed. They address different states; neither is a universal cure for a bootloader or kernel failure.
Run the commands from a functioning installed system, preferably after closing applications that may be using packages being changed. Read every proposed removal, replacement, or downgrade before confirming. Debian Reference discusses cached older package versions when a newer version is unusable, but lower-level dependency overrides are last-resort actions. Do not use --force-all, edit files under /var/lib/dpkg casually, or remove packages merely to make an error message disappear.
Traditional Fedora systems using DNF
For a conventional Fedora installation that still boots, Fedora’s upgrade documentation describes dnf distro-sync as a way to align installed packages with the versions available from enabled repositories. It can help after a partial upgrade or dependency mismatch and may downgrade packages when the repositories require it.
After confirming the release and repository configuration, inspect the proposed transaction:
sudo dnf distro-syncIf unsatisfied dependencies prevent synchronization, Fedora documents an optional form that can erase conflicting packages:
sudo dnf distro-sync --allowerasingUse --allowerasing only after reading the complete removal list. If it proposes removing the desktop, kernel, storage stack, networking, or authentication components you need, cancel and investigate the repository mismatch instead of approving it. The cited Fedora page covers Fedora 38, 39, and 40 and was last reviewed on 2024-04-25; verify the equivalent instructions for the release actually installed.
Do not mix package-manager procedures
APT/dpkg commands repair Debian-family package databases. DNF commands repair traditional RPM package sets. Neither procedure should be copied to an unrelated distribution, and neither is the right rollback mechanism for Fedora’s image-based editions.
Rank #3
Fedora Silverblue and other rpm-ostree editions
Fedora identifies Silverblue and other image-based systems as rpm-ostree based. Their operating system is deployed as an image rather than assembled by treating every system file as an independent DNF transaction. Fedora’s Silverblue cheat sheet documents:
rpm-ostree rollbackThe command makes the previous deployment the default boot entry. Reboot only after confirming which deployment will become active, and verify the exact behavior for your edition and current release in Fedora’s documentation. Do not run dnf distro-sync as a substitute for an rpm-ostree rollback.
If the previous deployment is not present, or the machine cannot reach a deployment menu, use the edition’s current rescue guidance and preserve data before rebuilding or reinstalling the operating system.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →If the installed system will not boot
Use official installer or live media to create a separate recovery environment. A generic USB flash drive can hold the distribution’s live image or installer; you need another working computer to download the image and create bootable media. The drive itself does not repair the installed system, and its capacity, firmware compatibility, and creation steps depend on the distribution.
Debian installer rescue mode
Debian’s stable installation guide includes a rescue mode. It asks you to select the installed root filesystem and, when possible, opens a shell in that filesystem. If it cannot do so directly, the selected root is exposed at /target in the installer environment. The manual says rescue mode uses hardware detection to make disks and network devices available and does not overwrite the installation merely because you entered rescue mode.
Follow the installer’s prompts to identify the correct root volume. If the system uses encryption, LVM, RAID, Btrfs subvolumes, or separate boot partitions, make sure the relevant volumes are unlocked and mounted as the distribution expects before changing files or reinstalling a bootloader.
Fedora installation media
Fedora installation media has offered Rescue a Fedora system under its Troubleshooting submenu, or the inst.rescue boot option. The documented default mount point for the installed system is /mnt/sysimage. The cited boot-options material is older installer documentation, so confirm the menu wording and mount behavior against the current Fedora release before proceeding.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchOnce the installed system is mounted, use the rescue environment’s documented method to inspect logs and repair packages. Do not assume that a path shown in one Fedora installer version is correct for another.
Ubuntu live-media and chroot recovery
Ubuntu’s community LiveCdRecovery guidance describes booting live media, mounting the installed root filesystem, and using chroot to run repairs in the installed environment. It is community guidance, so verify the exact mount and chroot procedure against current Ubuntu documentation for the release and storage layout.
There is no safe one-size-fits-all mount block. Root may be on a plain partition, LVM, RAID, an encrypted container, or a Btrfs subvolume; /boot and the EFI system partition may also need to be mounted at their correct paths. Using the wrong device can expose or alter another disk. If you are unsure which volume is root, stop before running mount, chroot, package commands, or bootloader commands.
What to do from a rescue environment
- Identify disks, partitions, encryption containers, volume groups, and filesystems using the tools documented for your distribution’s rescue environment.
- Unlock and activate storage only when you understand the layout and have confirmed the target filesystem.
- Mount the installed root and any required
/bootor EFI partitions at the paths specified by the distribution guide. - Copy important files to separate storage before making repairs.
- Use the distribution’s package or bootloader instructions for the mounted system, preserving the rescue environment’s paths and network setup.
- Unmount cleanly and reboot only after checking that the intended root, boot, and EFI volumes were changed.
Disk errors, unreadable filesystems, encryption problems, and valuable data without a backup justify professional assistance. A wrong repair command can overwrite evidence needed for data recovery.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Repairing a bootloader failure
A bootloader message such as “grub rescue” is not the same problem as an unresolved package dependency. Check whether the machine uses UEFI or legacy BIOS, which disk contains the installed system, where the EFI system partition is mounted, and how the distribution generates its GRUB configuration.
Debian’s installer rescue manual gives this as an example for reinstalling GRUB to the first disk’s master boot record:
grub-install '(hd0)'This is a manual example, not a universal command. On UEFI systems, the correct target is normally an EFI system partition rather than an MBR. Disk numbering, partition layout, firmware mode, and the distribution’s bootloader configuration all affect the correct procedure. Never substitute (hd0) or a guessed device name for the target identified by your own system and current distribution documentation.
If the bootloader was changed during an update, first determine whether the installed filesystem and kernel are intact. Reinstalling GRUB without mounting the correct root and boot partitions can produce a bootloader that still cannot find the operating system.
When the new kernel is the apparent problem
Use a previously installed kernel only if GRUB offers one and it boots reliably. Keep the working kernel until the distribution documents a safe fix or replacement. Collect the exact panic, initramfs, module, or filesystem message from the failed entry, because “kernel did not boot” can describe incompatible drivers, a damaged initramfs, a storage problem, or a separate bootloader issue.
Do not delete every older kernel to reclaim space while diagnosing the failure. Removing the only known-good boot path can turn a recoverable regression into a rescue-media case. Kernel package removal and regeneration steps differ by distribution and release; use the current official instructions after you have a backup.
When a clean installation is safer
Stop escalating repair commands when package metadata is severely damaged, essential partitions are unreadable, storage errors are appearing, or a proposed transaction would remove broad parts of the system. Preserve personal data and configuration first. Debian Reference specifically notes that a full backup followed by a clean installation can take less time and produce a better result for a seriously broken system.
A reinstall is not a shortcut if you have not identified the correct disks and copied data. Confirm the backup by opening representative files on another device, record any encryption recovery keys, and document the old partition layout before erasing anything.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsCommon mistakes that make recovery worse
- Running a package command before identifying the distribution. APT, DNF, and rpm-ostree have different transaction models.
- Using “force” options as a first response. Forced dependency overrides can leave a system in a less coherent state than the original failure.
- Deleting package-database files. Files under
/var/lib/dpkgor equivalent databases contain state needed to complete or reverse transactions. - Approving removals without reading them. A synchronization that removes a conflicting library may also remove the desktop or boot components that depend on it.
- Applying a copied chroot command blindly. Incorrect root, boot, or EFI mounts can repair the wrong filesystem.
- Assuming rollback is always available. An older kernel or rpm-ostree deployment may have been removed, pruned, or never created.
- Ignoring repository and release mismatches. DNF synchronization cannot safely reconcile repositories from the wrong Fedora release or an incomplete third-party setup.
- Continuing after disk errors. Repeated writes can reduce the chance of recovering data from a failing drive.
A practical recovery worksheet
Before asking for help, provide these facts in one message or support ticket:
- Distribution, edition, and release.
- BIOS or UEFI firmware mode.
- Whether firmware, GRUB, a recovery menu, a text console, or the desktop is reachable.
- The exact error text and the point at which startup stops.
- The update command or graphical action that preceded the failure.
- Whether the system uses encryption, LVM, RAID, Btrfs, separate
/boot, or a separate EFI partition. - Whether important data is backed up and whether you have a bootable recovery USB.
- Any package transaction proposal, especially packages marked for removal or downgrade.
This information lets a helper choose between a package repair, a kernel investigation, an image rollback, a rescue environment, or a bootloader procedure instead of guessing.
Documentation and version caveats
Use the Debian stable installation guide for rescue-mode behavior and Debian Reference for APT/dpkg recovery. Ubuntu’s Recovery_mode page documents the GRUB recovery-menu route, while its LiveCdRecovery page is community guidance that should be checked against current release documentation for mount and chroot details. Fedora’s DNF troubleshooting material cited here is scoped to Fedora 38–40 and was last reviewed on 2024-04-25; Fedora rescue-media instructions retrieved from older installer documentation may use different menu labels or mount points today. Fedora Silverblue’s cheat sheet supports the basic rpm-ostree rollback behavior, but edition-specific instructions should always be verified before use.
Sometimes, things go wrong, and the system you’ve carefully installed is no longer bootable.
Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
The correct response is not a universal command. Identify what still works, protect data, choose the procedure for the installed distribution and package model, and stop when the proposed repair becomes broader or riskier than the evidence justifies.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
