Stuck starting /dev/mapper/luks

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.

edited Feb 7 at 14:04

asked Feb 6 at 21:22

qrplr

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 at 21:41

add a comment |

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.

edited Feb 7 at 14:04

asked Feb 6 at 21:22

qrplr

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 at 21:41

add a comment |

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.

edited Feb 7 at 14:04

asked Feb 6 at 21:22

qrplr

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.

boot luks disk-encryption

edited Feb 7 at 14:04

asked Feb 6 at 21:22

qrplr

edited Feb 7 at 14:04

asked Feb 6 at 21:22

qrplr

edited Feb 7 at 14:04

asked Feb 6 at 21:22

qrplr

asked Feb 6 at 21:22

qrplr

asked Feb 6 at 21:22

qrplr

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 at 21:41

add a comment |

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 at 21:41

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 at 21:41

add a comment |

1 Answer
1

active

oldest

votes

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.

answered Feb 7 at 7:50

telcoM

18.5k12347

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 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 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 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 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 at 21:53

|
show 1 more comment

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);

);

draft saved

draft discarded

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f499166%2fstuck-starting-dev-mapper-luks%23new-answer', 'question_page');

);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

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.

answered Feb 7 at 7:50

telcoM

18.5k12347

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 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 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 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 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 at 21:53

|
show 1 more comment

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.

answered Feb 7 at 7:50

telcoM

18.5k12347

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 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 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 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 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 at 21:53

|
show 1 more comment

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.

answered Feb 7 at 7:50

telcoM

18.5k12347

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.

answered Feb 7 at 7:50

telcoM

18.5k12347

answered Feb 7 at 7:50

telcoM

18.5k12347

answered Feb 7 at 7:50

telcoM

18.5k12347

answered Feb 7 at 7:50

telcoM

18.5k12347

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 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 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 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 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 at 21:53

|
show 1 more comment

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 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 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 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 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 at 21:53

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 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 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 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 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 at 21:53

|
show 1 more comment

draft saved

draft discarded

Thanks for contributing an answer to Unix & Linux Stack Exchange!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

搜尋此網誌

mjhjmtu