Arch Linux

If you need emergency shell in initramfs then it's usually too late to add a hook and rebuild initramfs so having such option may no be much useful. There is "init=/bin/sh" cmdline parameter which allows you to have working root terminal inside initramfs even when your boot process is broken.

Yes, this is more a precautionary hook that I enabled when playing around with other hooks.

I a few kernel parameters, like `systemd.debug_shell` and `emergency`, and none of them worked, but I didn't try `init=/bin/sh`. If it really works even before the root FS has been mounted, then this hook is indeed useless.

"If it really works even before the root FS has been mounted"

It doesn't.
Edit:rdinit= would, but that also bypasses everything init in the initrd does, so it's not as useful.

This is related to [1][2]?

[1] https://github.com/archlinux/svntogit-packages/commit/7952a4228333c57926884fbd49526a8cfe2eaea1
[2] https://github.com/archlinux/svntogit-packages/commit/776743d220cbb56e9abca2cc8bcef3a0ab7c8d0a

@Scimmia I'm pretty sure it worked in the past when I used it to fix my broken boot process. Even Arch wiki documents it[1]. Has it changed recently? Or do you mean it doesn't work when systemd hook is used (I don't know about that one).

[1] https://wiki.archlinux.org/index.php/General_troubleshooting#Recovery_shells

Side note: I don't really get what locking root account in initramfs achieves in terms of system security.

mkinitcpio already has break=premount and break=postmount. I'm not sure what unlocking the root account achieves.

@grazzolini Does that work in a systemd based initramfs?

That aside, one can write a simple sd-shadow hook that reintroduces the shadow.initramfs behavior with ease, this would be useful to debug a systemd initramfs by reading the journals and such that would otherwise be lost after reboot, but that is all there is to it.

For the standard busybox it's just useless tho, since it doesn't care what shadow has to say.

MichelKoss1, all of that is done post-initramfs

I had the samme issue yesterday trying to figure out why Switch root wasn't happening in the systemd initrd. I like the `sd-shadow` and the `shadow` hooks.

The main issue with "break=premount' and "break=postmount" is that the when you do non-trivial boot setups, like with UEFI stubs, you can't edit the kernel cmdline if there is a regression in anything initrd related. This leaves you in a pickle if you could solve it with a shell but have that refused. Rebuilding the UEFI executable for the "break=" parameters is a bit annoying compared to having the root account unlockable if needed.

@Foxboron are you suggesting the none systemd initrd switch to using sulogin instead of exec sh to start a rescue shell which would then have the same behavior as the systemd initrd.
If so the code systemd uses to create minimal passwd, shadow and group files could be made common and reused?
Then there is the question of does whatever unlocks the root account need to copy the system's shadow to the initrd or is it sufficient to unlock the root account with an empty password or roots current password?

EDIT: this was quite verbose and useless, fixed it now with something more proper.

@loqs that is the best approach, to make busybox based use sulogin and reuse code for passwd group and shadow.
Next a shadow hook that will do the [1]old behavior of /etc/shadow.initramfs or locked.
Finishing with an announcement so everyone catches up the news, and add the shadow hook if wanted.

This makes both initramfs implementations equal in that sense, and the shadow hook will work on both.

...

Now, to the reason for the [2]revert, how frequent can the initramfs spontaneously fail that an unlocked root is a bad idea?
I really can't replicate that danger under normal circumstances, typically it will succeed always or fail always when something is wrong...
If something bad in the system can cause systemd based to spontaneously fail, I wouldn't be surprised that it would also cause the busybox based one to fail as well.

[1] https://github.com/archlinux/svntogit-packages/commit/7952a4228333c57926884fbd49526a8cfe2eaea1
[2] https://github.com/archlinux/svntogit-packages/commit/776743d220cbb56e9abca2cc8bcef3a0ab7c8d0a

As I understand this bugreport is about inability to get shell access in systemd hook while initramfs is broken therefore making busybox which doesn't have such issue working the same is off the rail.

I dislike the idea of having root password hash leaked in initramfs same as I dislike the idea of having to boot from livecd when initramfs breaks because it was decided debugging it from the inside impossible. I think asking people to rebuild their initramfs when they can't boot isn't helpful but I don't mind if systemd hook users are satisfied with it as long as busybox is untouched.

The solution in practice is to just have `FILES=(/etc/shadow.initramfs)`. But it would be better to have something standardized. I don't see *why* you'd be disclosing any root password checksum if the files are separate.

@loqs I think it's weird they use two different systems, yes. But I'd rather just want `shadow` to include `/etc/shadow.initramfs` and leave the other details for the busybox implementation.

Add eworm to the FS to elaborate on the shortcomings that required [1]?
If this hook is currently going to only apply to systemd should it not be provided by the systemd package instead of mkinitcpio?

[1] https://github.com/archlinux/svntogit-packages/commit/776743d220cbb56e9abca2cc8bcef3a0ab7c8d0a

@Foxboron the idea of using real root shadow contents is circulating in comments as potential solution and it's what hook attached to this FS does. Separate shadow file doesn't have such issue but apparently it has other shortcomings (arguably not the most informative commit description).

It's been some time. It would be really good to find a solution to this, as in the UKI scenario the status quo is maximum pain.

This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.

@bugbot still relevant