[FS#70408] "root account is locked", emergency mode + LUKS root

quequotion · 2021-08-15 05:29:31

I want to ask, specifically, about how and why the root account is locked in this scenario.

The last thread does not mention it, but I've had this problem (and am having it again; edit: already worked around the booting issue) when the root partition is a LUKS encrypted one.

I used the instructions on the Archwiki to encrypt my drive during the install process, by the way.

I have no memory of completing any step that would have locked the root account, and yet it is locked. I don't think the previous poster, who never replied to Videl's question, did either.

How could the root account locked when booting into emergency mode?

Edit: This will probably be resolved when this task is resolved.

Last edited by quequotion (2021-08-16 23:07:36)

quequotion · 2021-08-15 06:31:55

My take on this, at least with a LUKS partition triggering emergency mode, is that the root account doesn't exist without mounting the encrypted root partition.

In my case, there is an EFI partition that things can be stored on for booting, but how could one enable--at least--(root) access to fsck?

busybox?

Last edited by quequotion (2021-08-15 06:32:29)

frostschutz · 2021-08-15 07:32:01

did you set a root password when installing?

loqs · 2021-08-15 07:38:46

Are you using mkinitcpio with the systemd and sd-encrypt hooks? https://bugs.archlinux.org/task/70408

Last edited by loqs (2021-08-15 07:50:57)

quequotion · 2021-08-16 13:12:45

loqs wrote:

Are you using mkinitcpio with the systemd and sd-encrypt hooks? https://bugs.archlinux.org/task/70408

Why, yes. I am doing that.

HOOKS=(base systemd autodetect sd-vconsole modconf keyboard block mdadm_udev sd-encrypt)

a patch that adds a `shadow` hook that overwrites the `/etc/shadow` file in the initramfs with the one from the actual main OS

I wonder how that would work in the case of an encrypted LUKS drive which has failed its fsck: the disk fails to mount; no /etc, no /etc/shadow.. unless I can store *just* /etc/shadow in unencrypted storage (sort of defeats the purpose of encrypting the drive though, eh?), like on an EFI partition.

frostschutz wrote:

did you set a root password when installing?

Yes, and reset it from the Install Media while working this out to no effect. I think that is because the root filesystem on the encrypted drive fails to mount. edit: That is because the root account is explicitly locked.

BTW, in case anyone was curious: If the reason you are getting dumped to emergency mode is a failed fsck, all you need to do is complete that fsck, which you can do from the Install Media (even for LUKS encrypted drives).

Last edited by quequotion (2021-08-16 23:03:42)

progandy · 2021-08-16 13:53:30

The hook replaces the fiile during the initramfs generation, not during boot. If you want to minimize the possible leak, then modify the hook to use a custom shadow file that only includes a good password for root and nothing else.

Arch Linux

#1 2021-08-15 05:29:31

[FS#70408] "root account is locked", emergency mode + LUKS root

#2 2021-08-15 06:31:55

Re: [FS#70408] "root account is locked", emergency mode + LUKS root

#3 2021-08-15 07:32:01

Re: [FS#70408] "root account is locked", emergency mode + LUKS root

#4 2021-08-15 07:38:46

Re: [FS#70408] "root account is locked", emergency mode + LUKS root

#5 2021-08-16 13:12:45

Re: [FS#70408] "root account is locked", emergency mode + LUKS root

#6 2021-08-16 13:53:30

Re: [FS#70408] "root account is locked", emergency mode + LUKS root

Board footer