Purpose
It is not intended as a one-stop-solution guide.
The intention is To Provide A Basic Understanding of the steps required to succesfully recover when an incident has prevented the operating system from loading.
Requirements
- Basic understanding of using a console or virtual terminal to execute commands.
- Ability to edit configuration files using terminal a console editor like nano, micro or vi(m).
- You are willing to learn
The knowledge gained and skills acquired will be applicable - not only for Manjaro Linux - but for almost any GNU/Linux system.
Adapt and adjust
- If your system does not boot using EFI …
- If you are not using installer default …
- If you are using a custom partition layout …
- If you are using another filesystem …
adapt the guide accordingly
Assumptions
Always use same boot as when operating normally
Never fix BIOS system when booted in EFI mode
Never fix EFI system when booted in BIOS mode
No customized core packages
kernel, glibc, nvidia, python et.al. must be from core repo
Default Manjaro Linux
- using grub and EFI boot
- one disk and no dual boot (Win or Linux)
- default installer partition layout
- filesystem
- luks (ext or btrfs)
- vfat (EFI)
- ext4 (root)
- btrfs subvolume layout on root partition
@@cache@home@log
Preparation
Any ability to recover requires You to be prepared for the situation.
Tools to acquire an ISO
Tools for downloading and verifying a Manjaro ISO is available from extra repo
- manjaro-iso-downloader (GUI)
- manjaro-get-iso (CLI)
Bootable USB
A basic recovery scenario requires a recent ISO
- Official Installer ISO
- A dedicated Rescue ISO [1 by @linux-aarhus] [2 by @cscs]
- [SystemRescue] - Arch based using Xfce
Boot ISO from GRUB
→ [HowTo] Boot Manjaro ISO directly with GRUB
Create Bootable USB
Beside the dd tool there is a couple good utilities with a GUI (be sure the device is not mounted)
- ventoy
- isoimagewriter
Boot the system
Boot the system using the live ISO
Mount Filesystem
With the system booted to the ISO at hand we need to decide how to proceed.
If the system is encrypted, you will need to unlock the partition. If you also remember what filesystem was used when you installed the system - it makes the decision easier.
Because - at time of writing 2025-03-07T23:00:00Z - manjaro-chroot and the --automount option does not support btrfs.
Terms and definitions
We will use variables which you must substitute for the actual system
| Term | Variable | Example |
|---|---|---|
| disk device | $disk |
/dev/sda or /dev/nvme0n1 |
| efi system partition | $esp |
/dev/sda1 or /dev/nvme0n1p1 |
| linux root partition | $root |
/dev/sda2 or /dev/nvme0n1p2 |
Identify your primary disk
To identify the primary disk for your Manjaro installation
lsblk -f
reading the lsblk -f output
If you have more than one Linux system or you are dual-boot Manjaro / Windows - be sure to identify correctly.
- ignore
loopdevices - disk with a small partition formatted using vfat and a large partition using ext4 or btrfs
- the NAME column could be
sda,sdbetc. ornvme0n1,nvme0n2etc. - the column indentation will list the partitions e.g.
sda1,sda2etc. - assign the NAME to the variable
$diske.g./dev/sda - assign the partition using ext4 or btrfs to the variable
$roote.g./dev/sda2
If your system is booted using EFI, identify the EFI partition
- assign the partition using vfat to the variable
$espe.g./dev/sda1
Assign the variables in the terminal like this - be sure to use your device and partition layout - the example uses /dev/sdy
The commands will reference the variables - making it easer to execute the correct command
disk=/dev/sdy
esp=/dev/sdy1
root=/dev/sdy2
If your system is not encrypted move along to ext4 or btrfs fileystem mount
LUKS encrypted filesystem
First thing is to unlock the LUKS container.
cryptsetup luksOpen $root cryptroot
Verify the container has opened correct by listing the block devices - expect a new cryptroot device below your root partition
lsblk -f
Verify the filesystem for cryptroot using the FSTYPE column in above output.
ext4 filesystem
Mount your root partition
If your root is encrypted - mount the cryptroot container
mount /dev/mapper/cryptroot /mnt
Otherwise mount the partition
mount $root /mnt
btrfs filesystem
Mounting the btrfs subvolumes requires more work
mount -t btrfs -o subvol=@ $root /mnt
mount -t btrfs -o subvol=@cache $root /mnt/var/cache
mount -t btrfs -o subvol=@log $root/mnt/var/log
mount -t btrfs -o subvol=@home $root /mnt/home
using EFI boot
Then mount the efi partition
mount -t vfat $esp /mnt/boot/efi
Optional hardware mount
Some operations in chroot may require access to the hardware, thus require additional hardware related systems mounted.
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /run /mnt/run
mount --bind /run /mnt/run
Enter chroot
Enter a chroot enviroment using manjaro-chroot command and bash as the shell - if you prefer zsh - substitute bash with zsh
manjaro-chroot /mnt /bin/bash
Inside chroot
To restore bootloader, see → GRUB/Restore the GRUB Bootloader - Manjaro
Next to a power-out - alien packages are the most common cause leading to a recovery attempt.
To be able to ask the community for assistance it is required that you remove all alien packages (created using a custom PKGBUILD e.g. AUR)
-
Create a list of alien packages
The list is timestampedpacman -Qm > alien-pkgs-$(date '+%s').txt -
Remove all aliens
Verify you did not replace core system with a custom package
Verify you are not using a custom driver for e.g. wifi cardsudo pacman -Rns $(pacman -Qqm) -
Optionally rebuild the mirrorlist
pacman-mirrors --continent -
Then run a full system sync
pacman -Syu
Exit chroot
exit
Restart the system
reboot
System Restored
Evaluate the content of the alien-pkgs-<timestamp>.txt and rebuild only those required for your day-to-day operation.