Fresh build, LUKS password doesn't work; "Cannot initialize device-mapper" about cryptmypi

[unixabg]

Greetings,
Not sure if you did build attempt on master branch or next-4.x. I believe what is in next-4.x works. If not report back.

[sininspira2]

Hello,
Sorry for the delay in response. Yes, I made sure I was pulling next-4.x. The LUKS volume is also able to be unlocked if I plug the SD card into another machine.

[unixabg]

Greetings,
Which raspberry pi are you using? I just spun up a fresh test sd card of pios-encrypted-basic from next-4.x, tested with hardware Pi 3B. All just worked for me.

[sininspira2]

I tried on a 4 but will try a 3B next

[unixabg]

Greetings,
What branch are you using? And please know I updated the master branch with a merge from next-4.x on 12/24/2022. I tested most of the images in the next-4.x branch before the merge.

[sininspira2]

Just pulled the latest from Master and seem to be having the same issue on boot; using pios-encrypted-basic this seems to be the only thing of note in the script output:

• Calling 7000-stage2-initramfs.hook ...
  Attempting to build new initramfs ... (CHROOT is /mnt/cryptmypi)
  Creating symbolic links from current physical device to crypttab device (if not using sd card mmcblk0p)
  Using kernel ''
  Building new initramfs ...
  W: missing /lib/modules/5.15.0-57-generic
  W: Ensure all necessary drivers are built into the linux image!
  depmod: ERROR: could not open directory /lib/modules/5.15.0-57-generic: No such file or directory
  depmod: FATAL: could not search modules: No such file or directory
  cat: /var/tmp/mkinitramfs_FshBnZ/lib/modules/5.15.0-57-generic/modules.builtin: No such file or directory
  find: ‘/var/tmp/mkinitramfs_FshBnZ/lib/modules/5.15.0-57-generic/kernel’: No such file or directory
  W: Can't find modules.builtin.modinfo (for locating built-in drivers' firmware, supported in Linux >=5.2)
  Adding binary-link /usr/sbin/modprobe
  Adding binary /usr/bin/kmod

[sininspira2]

Going through some other images and it seems ubuntu-encrypted-basic sort of worked? I got "cryptsetup: crypt: set up successfully" and the spinning circle for a while but then it dumped me into initramfs

[alphafox02]

Attempting roughly the same setup, except chose kali-encrypted w/ dropbear. The image was built on 22.04.

End result is kali/Pi4 boots, it can get dhcp and drop bear starts, but presented with the same thing as the initial posts indicates over and over when presenting the password. I can see the same notification on the hdmi port within the boot sequence right prior to it looking for dhcp.

Is it somehow an issue with the image being built on 22.04 as opposed to building it on Kali? Suppose I should see. I do notice this on the machine that built the image, with the concerning part being the seg fault.

`Adding script /usr/share/cryptsetup/initramfs/bin/cryptroot-unlock
Calling hook zz-cryptsetup
Adding config /etc/initramfs-tools/unlock.sh
/usr/share/initramfs-tools/scripts/local-block/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/panic/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/local-top/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/init-top/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/local-premount/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/init-bottom/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/init-premount/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/local-bottom/ORDER ignored: not executable
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
Building cpio /boot/initramfs.gz initramfs
Cleaning up symbolic links
... 7000-stage2-initramfs.hook completed!

• Calling 7400-stage2-otherscript.hook ...
  Other script _STAGE2_OTHERSCRIPT is not set on config: Setting default value stage2-otherscript.sh
  Checking if stage2 other script /home/dragon/Github/cryptmypi/examples/kali-encrypted-basic-dropbear//stage2-otherscript.sh exists ...
  /home/dragon/Github/cryptmypi/examples/kali-encrypted-basic-dropbear//stage2-otherscript.sh found!

Script execution

Disable autoresize
Removed "/etc/systemd/system/basic.target.wants/rpi-resizerootfs.service".
Failed to disable unit, unit rpiwiggle.service does not exist.
Adjusting root= in /boot/cmdline.txt
Old crypt ROOT is root=PARTUUID=59536845-02
New crypt ROOT is root=/dev/mapper/crypt
Replacing UUID to encrypted path in /etc/fstab
Old fstab UUID is UUID=1566e8b7-578d-4af4-b0f7-666f88e40735
New crypt path in fstab is /dev/mapper/crypt
Set a label for system check on /dev/sda1

End of Script execution

... 7400-stage2-otherscript.hook completed!

• Calling 7500-stage2-chroot-final.hook ...
  Attempting to remove /etc/initramfs-tools/hooks/zz-cryptsetup hook ...
  ... attempted hook removal complete!
  ... 7500-stage2-chroot-final.hook completed!

• Calling 7600-stage2-teardown-chroot.hook ...
  Tearing down RPi chroot mount structure at '/mnt/cryptmypi'.
  Unmounting binds
  ... 7600-stage2-teardown-chroot.hook completed!

• Calling 7700-stage2-teardown-mounts.hook ...
  Attempting to unmount /dev/sda1 ...

• Unmounted /dev/sda1

Attempting to unmount /mnt/cryptmypi ...

• Unmounted /mnt/cryptmypi

  ... 7700-stage2-teardown-mounts.hook completed!

• Calling 7800-stage2-teardown-luks-close.hook ...
  Attempting to close open LUKS /dev/sda2 ...
  Command successful.

• LUKS closed.

  ... 7800-stage2-teardown-luks-close.hook completed!

• Calling 7900-stage2-teardown-cleanup.hook ...
  ... 7900-stage2-teardown-cleanup.hook completed!

Goodbye from cryptmypi (4.11-beta).
`

[unixabg]

Greetings,
So as of recently, I have had only time to test builds from Kali host vm. So it could be something with ubuntu, not sure. I can get dev environment setup soonish to test again that builds are working from Kali host. Can you share a diff of your kali-encrypted-basic-dropbear/cryptmypi.conf against the one in the master ver 4.11-beta? Please drop any passwords or sensitive info.

[alphafox02]

I’ll try the diff tonight. I started with next-4 branch before moving to master. Same result in each case, plan to try with kali in a VM tonight. I recall the only change I made to the conf file was to change the luks password and uncomment the line to make the image lighter. I just blew away the conf when doing the git checkout of master and redid the same changes.

[unixabg]

Greetings,
It is a good test to try building on a Kali VM. Also if using Rpi4 target please read https://github.com/unixabg/cryptmypi/blob/master/examples/kali-encrypted-basic-dropbear/cryptmypi.conf#L16-L23 and adjust accordingly. I have seen where Rpi3 image will not work on Rpi4 and vice versa for some of the examples. Thank you for being willing to help in testing this issue.

[alphafox02]

Good catch so maybe for the kernel filter I need to just change it to l+ instead of v8+? If so I’ll make the change and rebuild the image one more time with 22.04

[alphafox02]

Good catch so maybe for the kernel filter I need to just change it to l+ instead of v8+? If so I’ll make the change and rebuild the image one more time with 22.04

[alphafox02]

Following up, making that one change to the conf file for the pi4 results in everything working perfectly even if the image is built by 22.04. Problem, a least for me, is resolved. Thank you!

[unixabg]

Greetings,
Thank you for testing and reporting back. I think for now I am going to close this since I can not reproduce the error with a correctly configured conf file to the corresponding hardware platform.