So it looks like the binding process did NOT correctly complete in the first Getting Started phase. (The rapid flashing indicates a communication error). When correctly bound it will flash every three seconds, continuously, no intermittent rapid flashing.
To move forward, lets take a few steps back and collect some information about your app:
Was there supposed to be a URL here? What specific things is the fingerprint composed of?
I am using Raspbian Jessie 4.9
I’m not using any API at the moment., I’m simply trying to 1)Bind the Zymkey and 2) encrypt the root fs.
Sandisk 32GB SD card
Hello there,
I am running Stretch on a RPi 3 Model B with a Scandisk 16 GB SD. I recently purchased a Zymkey 4i. I’ve successful gone through the getting start steps and have confirmed that the Zymkey 4i is bound to the RPi (via the slow blinks).
My goal was to then encrypt the Root partition via Option 1. I first confirmed that 7 is the root partition and dev/sda is the FAT32 formatted USB key (32 GB). While running the Script for Option 1, it takes some time to complete (as the walkthrough suggests), but partway through, the Zymkey begins blinking rapidly (so it appears unbound). Also, once the script completes and the reboots have occurred, the Zymkey continues to blink rapidly. Additionally, I verified the device was no longer bound by shutting down the RPi, removing the Zymkey, and then booting up the device. I assumed if the encryption and binding was successful, the boot would fail without the zymkey, but everything booted fine. Again, the Zymkey WAS successfully bound prior to starting the encryption process, but seems to have become unbounded somewhere during the process.
Can someone provide some guidance on this?
Thanks,
Geoff
@Gtewksbury were you able to run your application in the “encrypted volume”, after boot ?
Also, in the scenario you describe, is the zymkey lock tab cut ? (placing it into production mode).
@cudacuda Can you post a short video of the blink pattern - either in this community, or email to support@zymbit.com. Thx
I will have to try to rebind the Zymkey to the Pi. I’ll start with a fresh image and go from there.
@Gtewksbury Are you using Noobs or are you using one of the other images (Stretch Desktop or Lite)? If you are using Noobs, the root file system is usually located at partition 7. If so, then you will need to invoke the conversion script with the option -m 7 as per our post on encpryption. In this case, it would look like this:
curl -G https://s3.amazonaws.com/zk-sw-repo/mk_encr_sd_rfs.sh | sudo bash -s -- -m 7
The default for the script is to use a Raspbian Desktop or Lite image where the root file system is located at partition 2. In this case, the encryption process would have failed. You could try one of two things:
-m 7 option.@jason Apparently this was a leftover comment in a previous version of the document 
The fingerprint is primarily composed of the CPU serial number, the SD card CID and the Zymkey serial numbers.
@Phil_of_Zymbit, thanks for the quick response. The root partition booted up without any problem (even after removing the zymbit). It’s strange. Like I was saying, the zymbit was definitely bound to the RPi prior to running the encryption script. However, I tried this 2 times, and both times, the RPi was still operational afterward, but it seems to have unbound somewhere during the encryption script.
I’m unable to boot from the encrypted filesystem. I’ll get the error:
Begin: Mounting root file system … Running /scripts/local-top …
Segmentation fault
cryptsetup (cryptrfs): cryptsetup failed, bad password or options?
Segmentation fault
cryptsetup (cryptrfs): cryptsetup failed, bad password or options?
Segmentation fault
cryptsetup (cryptrfs): cryptsetup failed, bad password or options?
cryptsetup (cryptrfs): maximum number of tries exceeded
cryptsetup: going to sleep for 60 seconds…
Begin: Running /scripts/local-premount …
Waiting for root file system … Begin: Running /scripts/local-block …
Segmentation fault
cryptsetup (cryptrfs): cryptsetup failed, bad password or options?
Segmentation fault
cryptsetup (cryptrfs): cryptsetup failed, bad password or options?
Segmentation fault
cryptsetup (cryptrfs): cryptsetup failed, bad password or options?
cryptsetup (cryptrfs): maximum number of tries exceeded
cryptsetup: going to sleep for 60 seconds…
Begin: Running /scripts/local-block …
Segmentation fault
cryptsetup (cryptrfs): cryptsetup failed, bad password or options?
Segmentation fault
cryptsetup (cryptrfs): cryptsetup failed, bad password or options?
Segmentation fault
cryptsetup (cryptrfs): cryptsetup failed, bad password or options?
cryptsetup (cryptrfs): maximum number of tries exceeded
cryptsetup: going to sleep for 60 seconds…
Gave up waiting for root file system device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/mapper/cryptrfs does not exist. Dropping to a shell!BusyBox…
(initramfs)
The output from the above commands see 
My hardware and software setup is:
Raspberry Pi Compute Module 3+ CM3+
on
MyPi Industrial IoT Integrator Board
with
Raspbian Stretch Lite
Version: November 2018
Release date: 2018-11-13
Can someone provide some guidance on this?
Best regards
Matthias
Matthias,
Can you please confirm that you have completed the Getting Started Guide, and that you have succesfully bound your zymkey 4i to the host Pi (indicated by a slow flashing LED - one flash every three seconds, continously).
Which partition number are you using for your encrypted volume ?
How did you set up your encrypted volume ?
a) From SDcard to SDcard,
or
b) from USB to SDcard.
Thx
Hi,
thank you for your quick reply. You can find my answers below:
1: I’ve successfully performed the Guide and bound the zymkey to the pi. The blue light was slowly blinking as described in the Guide.
2: I use the standard parameters. So the partition 2 was used for encryption and /dev/sda was used as temp space.
3: The cm3+ module has itself 32GB disk space embedded with the “/boot”(partition 1) and “/” partition 2 on it. Additionally there is an sd-card slot with a 256GB card /dev/sda1 which is used for the tarball and for the temp system to boot.
Can i supply any further useful information?
Best regards
Matthias
What is the LED on the Zymkey doing ?
Can you describe, or (preferably) send a short video to support@zymbit.com.
Hi Phil,
now the zymkey led is blinking more frequently as it wasn’t bount to the pi. Is it possible that it lost his binding? The zymkey 4i is working in developer mode without a battery.
BR
Matthias
A rapid blinking indicates that Zymkey is not (or no longer) bound to the Pi. To eliminate some possible causes, could you please repeat from beginning the Getting Started process - be sure to start with a fresh -not-encrypted- image. Let us know if you can restore binding.
Hi Phil,
ok, I’ll try to create an image with a bound zymkey. Then start the encryption process to get were we are now and then restore the image of the first step to see if the zymkey will be bound again. I’ll try it at thuesday.
br
Matthias
Hey Phil, I just wanted to see if you had any ideas. I also realized I forgot to provide some information. The zymbit lock key is NOT cut. I am running in Developer mode.
Just to restate my issue, I’ve gone through the Getting Started steps to bind my Zymkey 4i to my RPi 3 running Stretch. It binds successfully. However, once I run the root partition encryption script, somewhere during the process, the Zymkey becomes unbound (blinking quickly) and never rebinds after the encryption script completes. Additionally, although the script takes about an hour to complete, it doesn’t look like the root partition is encrypted, as I was able to boot to it after removing the Zymkey. Is there any additional information I could provide?
Scenario:
-Raspberry Pi w/Zymkey 4i is in production mode and key destruction setting is enabled
-Device is powered on and running
-Case w/perimeter circuit is opened (keys are deleted)
-RS232 cable is connected and serial connection is opened up
-Files are retrieved via serial connection prior to rebooting the system
Question:
Is the above scenario possible? Does the Zymkey or any service trigger an automatic reboot if the perimeter detect is triggered. If not could this somehow be configured to do so?
There are 2 ways of dealing with the scenario you describe: