A recent upgrade rendered my computer unbootable. The boot never completes. It is stuck at:

Start job is running for /dev/mapper/luks-4956cb53-c8e8-4525-b3e0-2f54bad2a801

Additionally, I am now unable to boot via a USB drive... So essentially, I have the Grub boot environment and am feeling that I've quite checkmated myself.

Normally I run Debian, but this machine, a cheap atom tablet is running Manjaro i3, because it had the best hardware compatibility at the time.

EDIT: I finally managed to find a USB drive that will boot (not sure why the others were failing) and can mount the LUKS partition. I'm still unsure how to confront the stalled process.

  • No, sorry, it's actually luks-4956cb53-c8e8-4525-b3e0-2f54bad2a801. I assumed that is the partition ID but haven't been able to check since I can't get to a normal terminal prompt.
    – qrplr
    Feb 6, 2019 at 21:41

2 Answers 2


It looks like you have access to GRUB and the system can successfully load the kernel and the initramfs file.

I don't know much about Manjaro, but a quick Google search tells me it apparently uses mkinitcpio as its initramfs generator.

The man page mkinitcpio(8) indicates there are several boot options you might wish to try:

  • adding rd.debug to your default boot options should produce a debug output, which might shed some more light on what is going on.

  • break=premount might give you shell access while the system is still running on initramfs. If that still gets stuck before the point where shell access would be activated, you might need disablehooks=<something> also. Unfortunately I have no clue what that <something> should be: perhaps someone with Manjaro installed with disk encryption could find out the name of the mkinitcpio hook that is responsible for unlocking the LUKS encrypted volumes. The hook script should be located in /etc/initcpio/hooks or (more likely) /usr/lib/initcpio/hooks.

  • Nothing in /etc/initcpio/hooks. ls /usr/lib/initcpio/hooks lists: btrfs, consolefont, dmraid, encrypt, keymap, lvm2, mdadm, memdisk, mhwd-fb, openswap, resume, shutdown, sleep, udev, usr, v86d.
    – qrplr
    Feb 7, 2019 at 14:11
  • encrypt sounds promising. So, adding the extra boot options break=premount disablehooks=encrypt should drop you into a shell before the initramfs attempts to unlock the encrypted disk and gets stuck, so you could investigate what is going on. A broken copy of cryptsetup? Missing /etc/crypttab? Missing libraries or kernel modules? You could try cryptsetup luksOpen /dev/<your encrypted partition> test - does it also get stuck? Any error messages?
    – telcoM
    Feb 7, 2019 at 14:34
  • Disabling the encrypt hook puts me at a rootfs prompt. The partition isn't listed in /dev/; however, it is in /dev/disk/by-uuid/. Running the cryptsetup test with either requests the passphrase, then returns me to the prompt with no message, error or otherwise.I know the relation between Grub and LUKS can vary. In my case, Grub requests Attempting to decrypt master key... Enter passphrase for hd1,gpt5 (4956cb53c8e84524b3e02f54bad2a801): Only upon entering the passphrase do I get to the traditional Grub menu, where I can boot or edit the boot command.
    – qrplr
    Feb 7, 2019 at 15:15
  • Hmm. That suggests the cryptsetup command is actually successful when it gets to prompt for the passphrase, so there is probably nothing wrong with the encryption layer at least. Is there a /etc/crypttab file in the rootfs environment? What does it say? Since your initramfs is on an encrypted volume, there might be a key file embedded in the initramfs that allows the encrypt hook to unlock the real root filesystem without prompting for the passphrase a second time. /etc/crypttab might tell where it's supposed to be.
    – telcoM
    Feb 7, 2019 at 19:26
  • Sorry, I'm not seeing /etc/crypttab. In /etc there is only fstab, initrd-release, ld.so.cache, ld.so.conf, modprob.d/, and mtab. All, save mtab, which links to /proc/self/mounts, and the ld.so.cache file, are empty. I'm not sure if it matters but there is an error at the rootfs prompt: sh: can't access tty; job control turned off.
    – qrplr
    Feb 8, 2019 at 21:53

If anybody finds this (like I did) from a web search: I had the same problem (encrypted Manjaro system hags at Start job is running for /dev/mapper/luks…) and could fix it by simply disconnecting all USB devices except the keyboard. I noticed that my PC sometimes hangs when I connect new devices prior to booting it up and disconnecting everything helps. The same this time.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .