Hello, I’m running into trouble after I followed the guide to create LUKS encrypted drive. It seems like SD card is encrypted now, but the zymkey doesn’t pair during start up.
I don’t have a battery in it, because my local store didn’t have it in stock and I don’t plan to use the physical security or RTC. But can missing battery impact the pairing when in development mode?
Hi, May I know which board are you using?
RPI3B+ or RPI0W?
It is RPI3B+, I’m using 2.5A adapter and I have tried unplugging everything.
@Ganjys some answers/suggestions
- No battery required for the encrypt/decrypt function to work - but obviously you need 5V applied to you Pi.
- Can you confirm that the Pi + SD card + Zymkey have not been interchanged with other Pi/SD card
- Can you confirm that during your LUKS encryption set up, the system when through two reboot cycles.
- What code is the Zymkey 4i flashing, that make you thinks its not pairing (send a video to support@zymbit.com, if easier).
That’s what I thought, but just wanted to make sure.
Yes, it’s the same PI +SD card+ zymkey.
I’m not sure about the second reboot. It restarted after phase 1, the raspberry pi booted up, but nothing was happening( I read that phase 2 can take some time to start). I stepped away from the screen for 15 minutes and when I came back it seemed like it had rebooted again, but now it showed on screen that no Zymkey installed and the LED is flashing rapidly unlike when it paired with the pi, before encryption.
I experienced a similar problem and have opened a message on the board. Unfortunately, I am unable to update the ticket. I have been following this message and thought I would interject.
I successful installed the zymbit hardware and got the correct flash sequence. The details are in a post under my name. I got the zymkey error of a missing python module.
I found later if I ran the zymbit install a second time, the zymkey error was corrected. I have done about five zymbit software installs and three have resulted in the zymkey error. Running the install routine a second time, cleared the problem. I can’t find anything in the output of the command the second time that suggest what was missed the first time.
Hopefully this helps. It has allowed me to proceed.
Sean
I have just been granted reply status (insert drum roll here) that enabled me to respond to your post. I experienced a similar problem and found a resolution by just running the zymbit install a second time.
More details are available if you read my post ImportError: No module named zymkey.
Sean
We have not observed any of these problems in our testing but what might be happening is that the installation doesn’t really complete. At the end of the installation, the unit should always reboot. Is this the case with your installations? If not, perhaps the connection to our apt repository is dropping.
I am now having this issue. The device affected has been using the LUKS w/ Zymkey disk for 6 months+ without any issues. After performing standard system maintenance the device no longer boots and claims “no zymkey installed”. Steps followed:
- apt-get update
- apt-get upgrade -y
- reboot
Hardware: Raspberry Pi 3 B+ (Stretch) w/ Zymkey 4i
I perform the same routine against all my raspberry pi’s weekly or bi-weekly to keep them updated. These steps have been performed many times on this device specifically, with LUKS installed, and never been an issue until today. I will post photos of the console showing the errors. Basic trouble shooting questionnaire filled out below. I am able to access the BusyBox built-in shell if that will help me get it to boot in any way. Please advice on how to recover device.
-
No battery required for the encrypt/decrypt function to work - but obviously you need 5V applied to you Pi.
Using a 5V/2.5AMP power supply, has worked for this raspberry pi (Raspberry Pi 3 B+) for many months. -
Can you confirm that the Pi + SD card + Zymkey have not been interchanged with other Pi/SD card
Can confirm no interchanging has occurred, stopped working directly after reboot. -
Can you confirm that during your LUKS encryption set up, the system when through two reboot cycles.
Can confirm install performed two reboots, first two attempts at install I did not have success because of this issue. After realizing the problem, allowed second reboot and install completed successfully. Have been using LUKS encrypted Pi for many months. After performing standard system maintenance (apt-get update, apt-get upgrade -y, reboot) this error is now occurring. -
What code is the Zymkey 4i flashing, that make you thinks its not pairing (send a video to support@zymbit.com, if easier).
Strobe flashing repeatidly
I have a RPi 3B+ “Stretch” development unit that serves as a master template for deployment to Zymbit units. I normally update both this unit and another test unit that has a Zymbit key on it. To date the updates have had no affect on the Zymbit unit. After reading this thread……I decided to update my RPi 3B+ development unit to see what the latest patches would be before updating my Zymbit test unit. Here’s what’s new/updated with in the last 2 weeks:
The following packages will be upgraded:
libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc libraspberrypi0 raspberrypi-bootloader raspberrypi-kernel
raspberrypi-kernel-headers
I have managed to reproduce this issue over here. The framework for the LUKS encryption relies on initramfs. Every time there is a kernel update, we have hooks in place that insure that the initramfs is rebuilt. The main reason for this is because the kernel modules must follow the version of the kernel itself. I myself have upgraded countless numbers of times but, for some reason, in this latest kernel upgrade, the modules that are stuffed into the initrd.img are determined by the initramfs shell kernel module utilities (modprobe, based on busybox) to be icompatible with this kernel version. Since Raspbian puts the i2c bus drivers (i2c-bcm2835, i2c-bcm2708 and i2c-dev) into individual kernel modules instead of putting them into the monolithic kernel, the reason you are seeing “ERROR: no zymkeys found” is because the i2c bus is inactive because the drivers could not be loaded via initramfs.
Not sure yet, but this looks like a Raspbian issue or a significant refactoring that screws up the rebuilding of the initramfs.
I will look into this further. In the meantime, one hack to get your encrypted root fs back online might consist of rebuilding the initrd.img with fresh/correct kernel modules. Conceivably, you could take your SD card and mount it on an unencrypted and working raspberry pi, unpack the initrd.img from the /boot partition of the encrypted SD card, replace the modules with the working unit, then rebuild the initrd.img and move it back to the encrypted SD card /boot partition.
1 Like
So, it turns out that there was a bug in our encryption scripts which was introduced recently. The encryption scripts (mk_encr_sd_rfs.sh and mk_encr_ext_rfs.sh) have been updated and should work with no further problems on systems that are performing SD card encryption for the first time.
Hello Scott,
I’m glad to hear the bug has been fixed. I’m finally finding time to attack this side project issue now that school is back in session and am going to attempt to recover my EFS from its un-usable state currently. I was hoping you could elaborate more on your suggested strategy as some of it makes sense, and some of it is beyond my computing skills/understanding or I have never attempted before.
- Mount EFS to Non-EFS Raspberry Pi with latest kernal updates
I think i’m good here. Plan is to mount EFS SD on Non-EFS RPi via USB SD Reader. - Unpack initrd.img from /boot of EFS
Also think I’m good here, should be standard img unpack (not familiar with commands unfortunatly) - Replace modules with working unit
Got lost here, pre-set command, or list of modules? how do I know which modules to include, and from where? - Rebuild the initrd.img
Rebuild makes sense in context with unpack (not familiar with commands unfortunatly) - Move back to EFS /boot partition
cp initrd.img /mnt/{}/boot - Hope
The above steps are an interpretation of your initial attack strategy, if you have any suggestions to improve my chances of success, or I misunderstood something please let me know. Any help, steps, or guides will be greatly appreciated.
Hi
We still see similar problem in zymbit. We had installed 15 devices to customers and some are failed after usage of months. Since devices are in production mode and perimeter detection wired we cant open that and replace sd card. It will blow zymkey.
Only thing we changed is we are using Overlay FS partition as readonly as given in raspi-config due to RPI sd card sometime get corrupted due to power failure.
Any idea what to do ?
P.S Also strange thing happens in one of our test device in development mode , After power on/off RPI 4-5 times attempts it recognize the zymkey boot perfect but on upon next power off , it shows same error.
Hello Naresh,
Which OS are you using? Please capture the error messages in each case and post here.
Bob
Hi
Here is OS details :
uname -r
5.10.17-v7+
lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Release: 10
Codename: buster
Also find screenshot of error.
Replacing power usb cable now solves the random connection issue.
Can you clarify why this ignoring unknow option ‘timeout’ occurs in cryptofs ?