[sdm-cryptconfig] - sdmcryptfs does not ask for password on RaspberryPi 5 about sdm HOT 10 CLOSED

It appears that you posted another reply which you have since deleted that contained an sdm command with plugins cryptroot and installing some apps via apps plugins.

A couple of comments re that (missing) post:

• There is an example of the cryptroot plugin in the Plugins documentation:
• If you have multiple invocations of the apps plugin in a single command line, you need to give each one of them a name= argument or the sdm command WILL fail. This is documented here: https://github.com/gitbls/sdm/blob/master/Docs/Plugins.md#apps
• Your script invoked the user plugin twice, once to add the user, and another to set the password. You can do them both in a single invocation: `--plugin user:"adduser=foobar|password=foobarspassword"
• You mentioned that sdm didn't ask for a password. Not clear where in the whole process of customize/boot/encrypt you're referring to that no password was requested. The only place it would ask for a password with your example (if it worked, which it didn't due to the above apps plugin issue) is when you run sdmcryptfs. Can you please clarify if it's still an open question?
• You said that "Inserted the disk into the PI and booted it up, the system did not came up properly". I'm not at all surprised since the customize using your example will fail for the reason mentioned above (multiple apps invocations in a single command will cause the sdm command to fail unless you use the name= argument on each of them.

I strongly encourage you to review the contents of the files (in the IMG) after each customize until you're more famiiliar with sdm: /etc/sdm/history and /etc/sdm/apt.log. All errors are logged there as well as on the console.

Example of using the cryptroot plugin: https://github.com/gitbls/sdm/blob/master/Docs/Plugins.md#examples-4

Example of using the user plugin: https://github.com/gitbls/sdm/blob/master/Docs/Plugins.md#user (read the entire section up to the vnc plugin)

from sdm.

No hints offhand, but I'll have an in-depth look at it later today.

Looks like you were able to successfully connect to the initramfs over ssh, and you're running sdmcryptfs from the ssh session. Is the system you ssh-ed in from on wifi or hard-wired?

from sdm.

Thanks @gitbls . I can confirm that I was able to successfully connect over ssh and that I run sdmcryptfs from the ssh session.

The system is hard-wired.

from sdm.

That might be an edge case.

Using the same setup, I was able to complete the Full disk encryption process, when using an NVMe disk as source of the operation system, instead of an SD Card, while using an USB stick as scratch device in both scenarios.

from sdm.

Thank you for the tools!

I am running trying to use sdm to do the 'Standalone rootfs Encryption Configuration'

the following command to prepare full disk encryption on a Raspberry Pi 5 with latest RaspiOS:

sudo sdm-cryptconfig --authorized-keys ./authorized_keys --ssh --reboot

Afterwards in initramfs the sdmcryptfs /dev/mmcblk0 /dev/sda does not ask for the 'YES' confirmation or an encryption password. The system just reboots.

bash-5.2# sdmcryptfs /dev/mmcblk0 /dev/sda
2024-06-21 07:52:49 Shrink partition '/dev/mmcblk0p2' and get its size
2024-06-21 07:53:08 Device '/dev/mmcblk0' rootfs size: 734449 4K blocks (3.0GB, 2.8GiB)
2024-06-21 07:53:08 Save rootfs '/dev/mmcblk0p2' to '/dev/sda'
2024-06-21 07:53:08 rootfs save should take less than 3 minutes
Connection to 192.168.1.198 closed by remote host.
Connection to 192.168.1.198 closed.
`

Any hints?

Unfortunately, I'm unable to repro this. Here's what I did:

• Burned a lightly-customized Bookworm to an SD Card and booted it
• Ran the exact same sdm-cryptconfig command as you
• System rebooted, I ssh'd in, and voila (this is from my 2nd repro attempt; I ran the first one to completion)

bash-5.2# sdmcryptfs /dev/mmcblk0 /dev/nvme0n1 
> 1970-01-01 00:00:36 Shrink partition '/dev/mmcblk0p2' and get its size
> 1970-01-01 00:00:41 Device '/dev/mmcblk0' rootfs size: 756832 4K blocks (3.1GB, 2.9GiB)
> 1970-01-01 00:00:41 Save rootfs '/dev/mmcblk0p2' to '/dev/nvme0n1'
> 1970-01-01 00:00:41 rootfs save should take less than 3 minutes
756832+0 records in
756832+0 records out
> 1970-01-01 00:01:28 rootfs Save elapsed time: 00:00:47
> 1970-01-01 00:01:28 Enable LUKS2 encryption on '/dev/mmcblk0p2' with cipher 'aes-xts-plain64'
> 1970-01-01 00:01:28 Enabling encryption could take a while
> 1970-01-01 00:01:28 OK to ignore superblock signature warning
WARNING: Device /dev/mmcblk0p2 already contains a 'ext4' superblock signature.

WARNING!
========
This will overwrite data on /dev/mmcblk0p2 irrevocably.

Are you sure? (Type 'yes' in capital letters): 

Does the system you're encrypting have a monitor on it? If so, what happens on the monitor when the SSH session closes?

Per your 3rd comment, there should be no difference in the behavior based on the source (boot) disk. I typically use an SD Card for testing, and have never seen this.

Unfortunately, the initramfs environment is fairly primitive and sdmcryptfs doesn't have any logging built in.

Since you were able to complete the encryption using an NVME boot disk, what should we do with this issue?

Thx

from sdm.

Oh, wait a sec...in your first attempt were you using a "vanilla" IMG that was not sdm-customized? I'm going to try that scenario for a repro.

Nope, just tested with an rpi imager-written SD card, and it worked correctly (no premature ssh disconnect).

from sdm.

If you have multiple invocations of the apps plugin in a single command line, you need to give each one of them a name= argument or the sdm command WILL fail. This is documented here: https://github.com/gitbls/sdm/blob/master/Docs/Plugins.md#apps

That is true, I noticed that it more less finally or at least it was not visible to me that the image preparation was not successful. I then removed apps plugin and sdm created my customized image properly. A red failure noticed would made it more visible to me (the unexperienced user).

I read the examples from the docs you mention, but for me a full sdm call, with user and apps installation and cryptroot plugin usage would have been very helpful!

from sdm.

I was now able to create an encrypted NVMe device once and everything worked like a charm. I think it is not an sdm issue, that I ran into.

I am running the Raspberry Pi 5 8GB in an Argon One V3 / M.2 NVMe PCIe case. I have the feeling that this case is causing the glitch, which forces me to reconnect and not being able to finish the encryption process in the first place.

I will try it again, without this case and an SD and report back to you.

from sdm.

Without the case it is unfortunately the same behavior. The only thing that I can imagine now, that the USB device is faulty. I will get another one and try again. Though it does not explain, why SSH is dropping ...

[13:24:52] foobar@foobar:~ $ ssh [email protected]
The authenticity of host '192.168.1.111 (192.168.1.111)' can't be established.
ED25519 key fingerprint is SHA256:ZSVz10iMs9MsAshhkXr8tmpSiMydUlCrCf48mCkmBKE.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.111' (ED25519) to the list of known hosts.
bash-5.2# sdmcryptfs /dev/mmcblk0 /dev/sda
> 2024-06-22 11:26:15 Shrink partition '/dev/mmcblk0p2' and get its size
> 2024-06-22 11:26:22 Device '/dev/mmcblk0' rootfs size: 744546 4K blocks (3.0GB, 2.8GiB)
> 2024-06-22 11:26:22 Save rootfs '/dev/mmcblk0p2' to '/dev/sda'
> 2024-06-22 11:26:22 rootfs save should take less than 3 minutes
Connection to 192.168.1.111 closed by remote host.
Connection to 192.168.1.111 closed.
``

from sdm.

If you have multiple invocations of the apps plugin in a single command line, you need to give each one of them a name= argument or the sdm command WILL fail. This is documented here: https://github.com/gitbls/sdm/blob/master/Docs/Plugins.md#apps

That is true, I noticed that it more less finally or at least it was not visible to me that the image preparation was not successful. I then removed apps plugin and sdm created my customized image properly. A red failure noticed would made it more visible to me (the unexperienced user).

Don't hold your breath for red failure notices. I have no plans to add such. If you'd like a bigger notice, you can call sdm in a script, check the exit status, and do your own red thing.

I read the examples from the docs you mention, but for me a full sdm call, with user and apps installation and cryptroot plugin usage would have been very helpful!

The beauty of sdm's plugins is that they are very modular and there is no impact from one to another except for the few ordering issues clearly mentioned in https://github.com/gitbls/sdm/blob/master/Docs/Plugins.md. Read that document several times.

As you encounter need for using additional plugins, you can simply add the --plugin switches to the command line for each plugin, or (better yet) add them to a plugin list file (explained at the top of the Plugins document and called a pluglist.

Unfortunately, there is no way to provide examples for everyone's specific uses. It requires a bit of understanding, experimentation, and build-your-own.

from sdm.