That’s correct. The module got renamed to
bcm2835_wdt. See this. Haven’t tried myself yet, my first goal is a reliable Zymkey setup
That’s correct. The module got renamed to
sudo sh -c 'echo c > /proc/sysrq-trigger'
Don’t want to test myself right now, I’m not physically near the RPi.
It’s a power issue after all. Today during phase 2 the red LED started flashing wildly. The header extender (to get longer pins) looks flimsy (pins too flat/thin). Will apply proper power and retry. Thx all and sorry for the confusion.
EDIT: all working well now. The only remaining issue seems to be: if I don’t do an
apt-get update and
apt-get upgrade (before zk sw installation) phase 2 autostarts. If I do an
apt-get update and
apt-get upgrade phase 2 does not autostart.
Pass 2 still sometimes fails. I now have the new official RPi USB power brick (5.1V, 2.5A) connected, an ethernet cable, a USB stick and nothing else. More info:
pi@raspberrypi:~ $ sudo journalctl -u cfg_SD_crfs.service -- Logs begin at Thu 2016-11-03 18:16:42 CET, end at Thu 2018-07-26 11:52:40 CEST. -- Jul 26 11:18:06 raspberrypi systemd: Started First time boot encrypted filesystem cfg service. Jul 26 11:18:12 raspberrypi cfg_SD_crfs.sh: Creating LUKS key...Session ACK not received Jul 26 11:18:12 raspberrypi cfg_SD_crfs.sh: led_msg failed Jul 26 11:18:12 raspberrypi cfg_SD_crfs.sh: Unexpected response received. sessionMsgID = 0100, rx msgid = 39e2, expected_msg_id = 0007 Jul 26 11:18:12 raspberrypi cfg_SD_crfs.sh: led_msg failed Jul 26 11:18:20 raspberrypi cfg_SD_crfs.sh: Session ACK not received Jul 26 11:18:20 raspberrypi cfg_SD_crfs.sh: led_msg failed Jul 26 11:18:20 raspberrypi cfg_SD_crfs.sh: Unexpected response received. sessionMsgID = 0100, rx msgid = 8d9d, expected_msg_id = 0007 Jul 26 11:18:20 raspberrypi cfg_SD_crfs.sh: led_msg failed Jul 26 11:18:20 raspberrypi cfg_SD_crfs.sh: done. Jul 26 11:18:20 raspberrypi cfg_SD_crfs.sh: Formatting crypto file system on /dev/mmcblk0p2...Command failed with code 32. Jul 26 11:18:20 raspberrypi cfg_SD_crfs.sh: Device /dev/mmcblk0p2 is not a valid LUKS device. Jul 26 11:18:20 raspberrypi cfg_SD_crfs.sh: done. Jul 26 11:18:20 raspberrypi cfg_SD_crfs.sh: Creating ext4 partition on /dev/mmcblk0p2...mke2fs 1.43.4 (31-Jan-2017) Jul 26 11:18:20 raspberrypi cfg_SD_crfs.sh: The file /dev/mapper/cryptrfs does not exist and no size was specified. Jul 26 11:18:20 raspberrypi systemd: cfg_SD_crfs.service: Main process exited, code=exited, status=1/FAILURE Jul 26 11:18:20 raspberrypi systemd: cfg_SD_crfs.service: Unit entered failed state. Jul 26 11:18:20 raspberrypi systemd: cfg_SD_crfs.service: Failed with result 'exit-code'.
Update: I got it working with a base image of stretch. The zymkey locks, encrypts the root file system, and flashes every 3 seconds verifying it’s locked to the pi again.
Trying with the custom image (~9GB), it took ~5 hours to finish phase 1. I did get a couple tar errors of “a file changed while looking at it” and “ignoring socket”.
Phase 2 started, and I didn’t have keyboard or HDMI attached as recommended by another user. I waited the weekend, and it didn’t lock.
Restarting it with a monitor and keyboard, it ran for a bit and restarted on its own. I could log in, but everything was slow due to bzip2 taking up 10-100% of the CPU. The Zymbit also isn’t locked (flashing every 3 seconds), but the SD card is encrypted when I slap it in my laptop.
Does this mean phase 2 didn’t start until I restarted it, and now it’s going through it? I didn’t run sudo apt-get update like scriptmelvin mentioned, but the custom image I flashed most certainly has run that command in the past.
I’m not able to get the custom pi image to lock during Phase 2.
During phase 1 on ssh-ed terminal:
Partition #1 contains a vfat signature.
mke2fs 1.43.4 (31-Jan-2017)
Making a tarball of original root file system image…tar: Removing leading `/’ from member names
tar: /mnt/tmproot: file changed as we read it
tar: Removing leading `/’ from hard link targets
tar: /tmp/mongodb-27017.sock: socket ignored
Created symlink /etc/systemd/system/multi-user.target.wants/cfg_SD_crfs.service → /etc/systemd/system/cfg_SD_crfs.service.
On Pi’s side during Phase 1:
[12864.803985] EXT4-fs error (device sda1): ext4_validate_block_bitmap:385: comm rsync: bg 96: bad block bitmap checksum
[13651.681592] EXT4-fs error (device sda1): ext4_validate_block_bitmap:385: comm kworker/u8:4: bg 50: bad block bitmap checksum
[13656.704721] EXT4-fs (sda1): Delayed block allocation failed for inode 1054501 at logical offset 0 with max blocks 1 with error 74
[13656.709004] EXT4-fs (sda1): This should not happen !! Data will be lost
During Phase 2 on Pi’s side:
[ TIME ] Timed out waiting for device dev-disk-by\x2dpartuuid-7358e674\x2d01.device.
[DEPEND] Dependency failed for /boot.
[DEPEND] Dependency failed for Local File System.
[DEPEND] Dependency failed for File System Check on /dev/disk/by-partuuid/7358e674-01.
[264.624420] EXT4-fs error (device sda1): ext4_mb_generate_buddy:756: group 144, block bitmap [maybe another word here] clusters
Note: Any additional restart boots me in emergency mode or “Kernel panic -not syncing”.
Probably not the problem:
- Power: “under voltage detected” errors have occurred before, but a new power supply has eliminated the error in the past 6 hours it’s been running.
- USB un-formatted: “Could not mount” and other related errors occurred when using a USB from a failed zymbit attempt, and suggestions to use wipefs when the usb had been previously used as a Linux boot-from-usb. Both errors have been eliminated by cleaning & reformatting with Windows terminal.
Additional Hardware Information:
- Raspberry P* i 3 B+ w/ Stretch
- Running scripts through ssh-terminal from Ubuntu 18,04
- Pi Powered by a 6 cell LiPo battery through a pdb
- Wifi dongle attached to pi advertising wifi
- Pi connected to monitor using PIP with an HDMI cable
- Zymbit 4i (not lite)
- I’ve successfully implemented this twice on a base Stretch image
- I’ve tried a full run through 4 times with the custom Stretch image. Power and mounting issues have occurred on the first two, but I don’t know how to continue from here.
I am testing now with a USB-bootable rPi3B+ followiyng these instructions (working): https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md
Wonder if there is a script tested from Zymkey for this case.
/dev/sda1 mounts boot and /dev/sda2 mounts /.
Maybe I could use SD-encryption method and then moving to USB as I have done with a non-encrypted SD-card.
Reason is I expect to have a much more robust device if using USB as storage than SDcards. Is this non-sense?
Why doesn’t phase2 start?
It does automatically?
i want to destroy everything
We have a script which can migrate your root file system to an external USB device instead of converting the SD card. See “Option 2 - Migrate existing SD card to external LUKS storage device”.
This is a good strategy for robustness if you intend to use a hard drive or SSD.
Stage 2 starts automatically. It may take a long time depending on:
- The size of your existing root file system.
- The speed of your external device. We recommend using an SSD connected via SATA-USB converter.
- The speed of your SD card. Some SD cards are extremely slow on write even though they are rated as class 10.
With this option can I completelly remove SDcard? I thought it was still necessary to for the /boot partition
How can i recognized that The phace 2 is running?
@Iker That’s correct, you still need the SD card for the /boot partition.
@pico2183 The console that you started the script from will show 2 lines when phase 1 has completed:
root file sys conversion phase 1 complete.
Rebooting to installer partition to start phase 2...
So, there is any chance I can remove completelly SDcard now that Rasperry Pi 3B+ is booted from USB?
Moving /boot from SDcard to a second USB might work?
I’m sorry, but After reboot, how do i know that it started?
Reboot it’s very quickly
Hello! We have 5 Raspberry 3B +, with their corresponding Zymkey 4i modules installed correctly, using the encryption of the operational SD and the blue LED flashing in a stable way in linked format. The first of these devices has turned off and removed electric power, removed the Zymkey 4i from the pi and has proceeded to cut the tabs from development mode to production mode.
After restarting the computer, does not longer start, getting a message from “cryptsetup (cryptrfs) failed, bad password or option?”
ALERT! / dev / mapper / cryptrfs does not exit "
The blue led flashes quickly, but when the start is started, the light is paid off.
Add that our base istalation was done in the following way, the SD of 32 has the following original partitions:
/ dev / mmcblk0p1 / boot
/ dev / mmcblk0p2 (encrypted) (6GB)
Later we used the free space of the 32GB card (27 GB) in a new partition / dev / mmcblk0p3 / data ext4
Our intention is to leave encrypted the partition where our developments are and that the partition where the data of the patient is housed can be recovered in case of failure of the raspberry pi.
In none of the teams have we had problems starting with this configuration
We have yet to send our other remaining equipment to our customers and I have no faith that this problem will not happen again.
Can you please send us a picture image of the zymkey with cut tab.
If you prefer to have a private support channel, please email it to firstname.lastname@example.org, and we will pick it up from there.