search

unixabg / cryptmypi

Project to assist users in building an encrypted raspberry pi
GNU General Public License v3.0
63 stars 20 forks source link

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

Closed sininspira2 closed 1 year ago

sininspira2 commented 1 year ago

As the title states, first boot after flashing an SD card gets to the "Please unlock disk crypt" prompt, at which point the LUKS password doesn't work and is met with

Cannot initialize device mapper. Is dm_mod kernel module loaded? Cannot use device crypt, name is invalid or still in use

Used pios-encrypted-basic example, didn't change anything in the config file except for the device to flash to. Built on Ubuntu 22.04 LTS.

unixabg commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

unixabg commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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!

Attempting to unmount /mnt/cryptmypi ...

Goodbye from cryptmypi (4.11-beta). `

unixabg commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.