Full root filesystem encryption on an Armbian system (NEW, replaces 2017 tutorial on this topic)


 Share

1 1

Recommended Posts

Full root filesystem encryption on an Armbian system

(new, fully rewritten, replaces my earlier tutorial on this topic)

 

MMGen (https://github.com/mmgen)

 

This tutorial provides detailed, step-by-step instructions for setting up full root filesystem encryption on an Armbian system.  The disk can be unlocked remotely via SSH or the serial console, permitting unattended bootup.

 

An automated script that performs the same steps, saving you much time and effort, can be found at https://github.com/mmgen/mmgen-geek-tools

 

Note that unlike my earlier tutorial all steps are performed within a running Armbian system.

 

The tutorial is known to work with the following board/image combinations:

 Orange Pi PC2  Debian Buster mainline / Ubuntu Bionic and Focal legacy
 RockPi 4  Debian Buster mainline / Ubuntu Bionic and Focal legacy
 RockPro 64  Ubuntu Focal mainline
 Odroid HC4  Debian Buster mainline / Ubuntu Focal mainline

 

 

 

 

 

You may have success with other boards/images too. If so, please post the details below (or open an issue in the mmgen-geek-tools Github repository), and I’ll add your board to the list.

 

Requirements:

  • A SoC with a running, upgradeable and Internet-connected Armbian system
  • A blank Micro-SD card and USB card reader, or, alternatively, a blank eMMC installed on the board
  • The ability to edit text files and do simple administrative tasks on the Linux command line

 

Step 1 - Preliminaries

 

All steps in this tutorial are performed as root user on a running Armbian system (the “host”).

 

The encrypted system (the “target”) will be created on a blank micro-SD card.  If your board has an eMMC not currently in use, the system can be created on it instead.

 

Architecture of host and target (e.g. 64-bit or 32-bit ARM) must be the same.

 

For best results, the host and target hardware should also be identical or similar.  Building on a host with more memory than the target, for example, may lead to disk unlocking failure on the target.

 

If you’re building the target system for the currently running board and with the currently running image, which is the recommended approach, the two preceding points will be a non-issue.

 

Packages will be installed using APT, so the host machine must be Internet-connected and its clock correctly set.

 

 

Step 2 - Upgrade your system and install the cryptsetup-bin package

 

# apt update && apt upgrade
# apt install cryptsetup-bin

 

 

Step 3 - Get and unpack the latest Armbian image for your board

 

Create your build directory:

# mkdir armbenc-build && cd armbenc-build

 

Download the Armbian image of your choice for your board, place it in this directory and unpack:

# xz -dv *.img.xz

 

 

Step 4 - Create mount directories and set up the loop mount

 

Create the mount directories:

# mkdir -p mnt boot root

 

Determine your first free loop device:

# losetup -f

 

Associate the image file with the loop device name displayed by the previous command.  This will be '/dev/loop0' in most cases, but if your output was different, substitute that for '/dev/loop0' in the following steps.

# losetup -P /dev/loop0 *.img

 

Examine the disk image using fdisk on the loop device:

# fdisk -l /dev/loop0

 

The output should look something like this:

Device       Boot Start     End Sectors  Size Id Type
/dev/loop0p1      32768 3489791 3457024  1.7G 83 Linux

 

Make a note of the start sector (32768 in this case).  You’ll need this value in the steps below.

 

Now mount the loop device:

# mount /dev/loop0p1 mnt

 

 

Step 5 - Copy the boot loader to the SD card

 

Insert the blank micro-SD card and card reader into a USB port.

 

Determine the SD card’s device name using 'dmesg' or 'lsblk'.  We’ll assume it to be '/dev/sda', since that’s the most likely case.  If your device name is different, substitute it for '/dev/sda' in the the following steps.  For an eMMC, the device name will probably be '/dev/mmcblk1'.

 

WARNING: if '/dev/sda' refers to some other storage device, running the following commands unchanged will destroy data on that device, so always remember to substitute the correct device name!!!  The best way to eliminate this danger is to disconnect all unused storage devices on the board before proceeding further.

 

Copy the image’s boot loader to the SD card, using the Start sector value from Step 4 as the argument for 'count':

# dd if=$(echo *.img) of=/dev/sda bs=512 count=32768

 

 

Step 6 - Partition the SD card

 

# fdisk /dev/sda

 

At the fdisk prompt, create a new DOS disk label with the 'o' command.  Use the 'n' command to create a primary partition of size +200M beginning at the same Start sector as the disk image.  Type 'p' to view the partition table, which should now look something like this:

Device      Boot  Start      End  Sectors  Size Id Type
/dev/sda1         32768   442367   409600  200M 83 Linux

 

Use 'n' again to create another primary partition beginning one sector after the first partition’s end sector and filling the remainder of the card.  Type 'p' once more to view the partition table:

Device      Boot  Start      End  Sectors  Size Id Type
/dev/sda1         32768   442367   409600  200M 83 Linux
/dev/sda2        442368 30636031 30193664 14.4G 83 Linux

 

Ensure that the first partition’s Start sector matches that of the disk image (32768 in this example) and that the second partition’s Start sector is one greater than the End sector of the first (442368 and 442367, respectively, in this example).  If you’ve made a mistake, use 'd' to delete a partition and start again.


Once everything looks correct, type 'w' to write the partition table to disk.

 

 

Step 7 - Copy the system to the SD card

 

The following commands will create a filesystem on the SD card’s boot partition and copy the boot partition data from the image file to it.  Don’t forget to substitute the correct device name if necessary.  If you’re building the system on an eMMC, the boot partition device is likely to be '/dev/mmcblk1p1' instead of '/dev/sda1'.

 # mkfs.ext4 /dev/sda1            # or '/dev/mmcblk1p1', for an eMMC target
 # e2label /dev/sda1 CRYPTO_BOOT
 # mount /dev/sda1 boot
 # cp -av mnt/boot/* boot
 # (cd boot; ln -s . boot)

 

Create the encrypted root partition.  When prompted for a passphrase, it’s advisable to choose an easy one like 'abc' for now.  The passphrase can be changed later with the 'cryptsetup luksChangeKey' command (type 'man cryptsetup' for details) once your encrypted system is up and running.

# cryptsetup luksFormat /dev/sda2 # or '/dev/mmcblk1p2', for an eMMC target

 

Activate the encrypted root partition and create a filesystem on it:

# cryptsetup luksOpen /dev/sda2 rootfs  # enter your passphrase from above
# mkfs.ext4 /dev/mapper/rootfs

 

Mount the encrypted root partition and copy the system to it:

# mount /dev/mapper/rootfs root
# (cd mnt && rsync -a --info=progress2 --exclude=boot * ../root)
# sync # be patient, this could take a while
# mkdir root/boot
# touch root/root/.no_rootfs_resize

 

Unmount the boot partition and image and free the loop device:

# umount mnt boot
# losetup -d /dev/loop0

 

 

Step 8 - Prepare the target system chroot

 

# BOOT_PART=($(lsblk -l -o NAME,LABEL | grep CRYPTO_BOOT))
# ROOT_PART=${BOOT_PART%1}2
# ROOT_UUID="$(lsblk --nodeps --noheadings --output=UUID /dev/$ROOT_PART)"
# BOOT_UUID="$(lsblk --noheadings --output=UUID /dev/$BOOT_PART)"

# cd root
# mount /dev/$BOOT_PART boot
# mount -o rbind /dev dev
# mount -t proc proc proc
# mount -t sysfs sys sys

 

Copy '/etc/resolv.conf' and '/etc/hosts' so you’ll have a working Internet connection within the chroot:

# cat /etc/resolv.conf > etc/resolv.conf
# cat /etc/hosts > etc/hosts

 

If you’re using non-default APT repositories, you may need to copy their configuration files as well so that 'apt update' and 'apt install' will use them inside the chroot.  Note that you can only do this if the host and target systems have the same distro/version.  If that’s not the case, you’ll have to edit the target files by hand.

# cat /etc/apt/sources.list > etc/apt/sources.list
# cat /etc/apt/sources.list.d/armbian.list > etc/apt/sources.list.d/armbian.list

 

If you’re using an apt proxy, then copy its configuration file too:

# cp /etc/apt/apt.conf.d/*proxy etc/apt/apt.conf.d/

 

 

Step 9 - Edit or create required configuration files in the target system

 

Perform the editing steps below using a text editor of your choice:

  1. Edit 'boot/armbianEnv.txt' so that the 'rootdev', 'console' and 'bootlogo' lines read as follows.  If you’ll be unlocking the disk via the serial console, then use 'console=serial' instead of 'console=display'. Note that enabling the serial console will make it impossible to unlock the disk from the keyboard and monitor, though unlocking via SSH will still work:

    rootdev=/dev/mapper/rootfs
    console=display
    bootlogo=false
    
  2. Edit 'etc/initramfs-tools/initramfs.conf'.  If your board will have a statically configured IP, add the following line to the end of the file, substituting the correct IP in place of 192.168.0.88:

    IP=192.168.0.88:::255.255.255.0::eth0:off
    

    If the board will be configured via DHCP, then edit the DEVICE line as follows:

    DEVICE=eth0
    
  3. If host and target systems are both Debian buster, you may wish add some key modules to the initramfs to avoid a blank display at bootup time.  The easiest way to do this is to add all currently loaded modules as follows:
    # lsmod | cut -d ' ' -f1 | tail -n+2 > etc/initramfs-tools/modules
    
  4. Retrieve the SSH public key from the remote unlocking host and copy it to the target:

    # mkdir -p etc/dropbear-initramfs
    # rsync yourusername@remote_machine:.ssh/id_*.pub etc/dropbear-initramfs/authorized_keys
    

    If you want to unlock the disk from more than one host, then edit the authorized_keys file by hand, adding the required additional keys.

  5. Create 'etc/crypttab':

    # echo "rootfs UUID=$ROOT_UUID none initramfs,luks" > etc/crypttab
    
  6. Create 'etc/fstab':

    # echo '/dev/mapper/rootfs / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1' > etc/fstab
    # echo "UUID=$BOOT_UUID /boot ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 2" >> etc/fstab
    # echo 'tmpfs /tmp tmpfs defaults,nosuid 0 0' >> etc/fstab
    
  7. Create the dropbear configuration file:

    # echo 'DROPBEAR_OPTIONS="-p 2222"' > etc/dropbear-initramfs/config
    # echo 'DROPBEAR=y' >> etc/dropbear-initramfs/config
    
  8. If the target is Ubuntu bionic, then a deprecated environment variable must be set as follows:

    # echo 'export CRYPTSETUP=y' > etc/initramfs-tools/conf.d/cryptsetup

     

  9. Set up automatic disk unlock prompt. Performing this optional step will cause the disk password prompt to appear automatically when you log in remotely via SSH to unlock the disk. Using your text editor, create the file 'etc/initramfs-tools/hooks/cryptroot-unlock.sh' with the following contents:
    #!/bin/sh
    
    if [ "$1" = 'prereqs' ]; then echo 'dropbear-initramfs'; exit 0; fi
    
    . /usr/share/initramfs-tools/hook-functions
    
    source='/tmp/cryptroot-unlock-profile'
    
    root_home=$(echo $DESTDIR/root-*)
    root_home=${root_home#$DESTDIR}
    
    echo 'if [ "$SSH_CLIENT" ]; then /usr/bin/cryptroot-unlock; fi' > $source
    
    copy_file ssh_login_profile $source $root_home/.profile
    
    exit 0
    

    Save the file and execute the command:

    chmod 755 'etc/initramfs-tools/hooks/cryptroot-unlock.sh'

     

 

Step 10 - Chroot into the target system, install packages and configure

 

Now chroot into the encrypted system.  All remaining steps will be performed inside the chroot:

# chroot .

 

Install the cryptsetup package and the dropbear SSH server:

# apt update
# echo 'force-confdef' > /root/.dpkg.cfg
# apt --yes install cryptsetup-initramfs dropbear-initramfs # for a buster or focal image
# apt --yes install cryptsetup dropbear-initramfs           # for a bionic image
# rm /root/.dpkg.cfg

 

Make sure everything was included in the initramfs (all three commands should produce output):

# lsinitramfs /boot/initrd.img* | grep 'usr.*cryptsetup'
# lsinitramfs /boot/initrd.img* | grep dropbear
# lsinitramfs /boot/initrd.img* | grep authorized_keys

 

Your work is finished! Exit the chroot and shut down the board:

# exit
# halt -p

 

Insert your freshly written SD card into the board’s main SD slot (or, if the target is an eMMC, just remove the SD card from that slot) and reboot.


Unlock the disk by executing the following command on your remote unlocking machine, substituting the correct IP address if necessary:

$ ssh -p 2222 root@192.168.0.88

 

If you performed step 9.10 above, the disk password prompt should appear automatically after login.  If not, you must enter the command 'cryptroot-unlock'.

 

You may also unlock the disk from the target board’s console if you wish.  Note, however, that certain disk images (RockPi 4 buster mainline, for example) might give you a blank display at startup, so you’ll have to enter your disk password “blindly”.  This bug will hopefully be fixed in the future.


If all went well, your root-filesystem encrypted Armbian system is now up and running!

Link to post
Share on other sites

Armbian is a community driven open source project. Do you like to contribute your code?

Thanks for pointing that out!

 

As far as overlap goes, I think this tutorial (and the automated script) has a clear use case, as it creates encrypted Armbian systems without building or compiling anything, which is much easier for most users (the automated script can create a fully configured system on your SD card or eMMC in a matter of minutes).

 

Secondly, the tutorial can be a valuable learning experience for those interested in better understanding disk partitioning, loop devices, LUKS encryption, uBoot, the Linux bootup process, basic administrative commands, etc.

Link to post
Share on other sites

Thanks for the post.
I test the script with Orange Pi zero with the latest Ubuntu Focal image.

Armbian 20.08.1 Focal with Linux 5.8.5-sunxi

After writing to the SD, at booting phase, following error occurs.

 

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Error: invalid dtb and unrecognized/unsupported machine ID
  r1=0x00001029, r2=0x40000100
  r2[]=05 00 00 00 01 00 41 54 00 00 00 00 00 00 00 00
Available machine support:

ID (hex)        NAME
ffffffff        Generic DT based system
ffffffff        Allwinner suniv Family
ffffffff        Allwinner sun9i Family
ffffffff        Allwinner A83t board
ffffffff        Allwinner sun8i Family
ffffffff        Allwinner sun7i (A20) Family
ffffffff        Allwinner sun6i (A31) Family
ffffffff        Allwinner sun4i/sun5i Families

Please check your kernel config and/or bootloader.

@MMGen anything I need to do additionally to support Orange Pi Zero?

 

Thanks.

Link to post
Share on other sites

9 hours ago, DevShanky said:

I am wondering if this script would break nand-sata-install since the base Armbian images are single partition while the new encrypted image on SD card is having a separate Boot and Root partition. 

 

If this is the case then how can we move the image to eMMC from SD?

 

-R

 

You don't need nand-sata-install, because the tutorial (and script) create the encrypted system directly on the eMMC. This has been tested successfully on the RockPi 4. Would like to hear from users how it works on other boards.

Link to post
Share on other sites

4 hours ago, sunzone said:

Thanks for the post.
I test the script with Orange Pi zero with the latest Ubuntu Focal image.

Armbian 20.08.1 Focal with Linux 5.8.5-sunxi

After writing to the SD, at booting phase, following error occurs.

...SNIP....

@MMGen anything I need to do additionally to support Orange Pi Zero?

 

Thanks.

This is not the kind of error I would expect to see. Are you sure you performed all the steps correctly, didn't omit anything? Is the SD card itself in working order? I'll take a look at the Focal Orange Pi Zero image to see if there's anything there that might be causing this error, but I don't have that board to test on, unfortunately.

 

UPDATE: I looked at your image. Some things you might want to check:

 

1) Make sure you're editing armbianEnv.txt correctly. After performing the edits, the file should look like this:

verbosity=1
bootlogo=false
console=display
disp_mode=1920x1080p60
overlay_prefix=sun8i-h3
overlays=usbhost2 usbhost3
rootdev=/dev/mapper/rootfs
rootfstype=ext4

2) In boot.cmd there are two lines beginning with 'setenv rootdev'. Make sure you're deleting the first one.

 

If that doesn't work, there are other things you might try and see whether you get the same or similar error at bootup:

 

1) Use the automated script instead of the tutorial.

2) Try the Buster image instead of Focal.

Link to post
Share on other sites

20 hours ago, MMGen said:

This is not the kind of error I would expect to see. Are you sure you performed all the steps correctly, didn't omit anything? Is the SD card itself in working order? I'll take a look at the Focal Orange Pi Zero image to see if there's anything there that might be causing this error, but I don't have that board to test on, unfortunately.

 

UPDATE: I looked at your image. Some things you might want to check:

 

1) Make sure you're editing armbianEnv.txt correctly. After performing the edits, the file should look like this:


verbosity=1
bootlogo=false
console=display
disp_mode=1920x1080p60
overlay_prefix=sun8i-h3
overlays=usbhost2 usbhost3
rootdev=/dev/mapper/rootfs
rootfstype=ext4

2) In boot.cmd there are two lines beginning with 'setenv rootdev'. Make sure you're deleting the first one.

 

If that doesn't work, there are other things you might try and see whether you get the same or similar error at bootup:

 

1) Use the automated script instead of the tutorial.

2) Try the Buster image instead of Focal.

 

1) Checked

2) Applied

Still the same error..

1) Used automated script

2) Used Buster image
Still the same error....

Link to post
Share on other sites

31 minutes ago, sunzone said:

Also tried with an Opi Zero Plus I had since it is 64bit, following the steps and also using the script.

Boot hangs after 




Starting kernel ...

 

Sorry to hear that. I'm afraid I've run out of options, since I don't have an Opi Zero for testing. If you really need root fs encryption, then you might try building Armbian with the CRYPTROOT_ENABLE option mentioned by @DevShankyin the post above.

 

Link to post
Share on other sites

On 10/21/2020 at 6:10 PM, MMGen said:

Sorry to hear that. I'm afraid I've run out of options, since I don't have an Opi Zero for testing. If you really need root fs encryption, then you might try building Armbian with the CRYPTROOT_ENABLE option mentioned by @DevShankyin the post above.

 

I will look into that.
Thanks.

Edit: building Armbian with the CRYPTROOT_ENABLE option works :)

Link to post
Share on other sites

Great step-by-step guide as an alternative to the build option, and also as a training/education for people less familiar with this in general :)

 

I guess it should be safe to assume that if `CRYPTROOT_UNLOCK` works, so should this guide?

 

`CRYPTROOT_ENABLE` confirmed working on:

 

* OdroidC4 (current buster and bullseye tested)

* OdroidHC4 (current buster tested; interactive prompt does not show at boot and seems to stop at "Starting Kernel..." but remote unlock over SSH still works. Additionally, eth0 will only come up again after boot if you issue `ip link set eth0 down; rmmod realtek; sleep 1; modprobe realtek; ip link set eth0 up` after boot)

 

 

Thanks to people in IRC for figuring out the points for the hc4.

 

Link to post
Share on other sites

12 hours ago, legogris said:

I guess it should be safe to assume that if `CRYPTROOT_UNLOCK` works, so should this guide?

 

No, I wouldn't assume that. See the comments by @sunzone above regarding the Orange Pi Zero.

 

In their case, the problem may be connected with the fact that the OPi Zero requires 'flash-kernel' to set up the boot loader.

 

I think that boards/images that don't depend on flash-kernel should generally work with this tutorial, but I need more test data to confirm that hypothesis.

Link to post
Share on other sites

Thank you for the comprehensive tutorial!

Instead of installing the encrypted system on an SD/eMMC I'd like to move the rootfs to my SSD and keep the boot partition on the SD-card (I'm using the Odroid HC4, unfortunately can't boot directly from SSD). Is it sufficient to edit the armbianEnv.txt-file in the SD-card's boot-partition? Do you have any suggestions on this?

Link to post
Share on other sites

On 6/7/2021 at 3:30 PM, Bagel said:

Thank you for the comprehensive tutorial!

Instead of installing the encrypted system on an SD/eMMC I'd like to move the rootfs to my SSD and keep the boot partition on the SD-card (I'm using the Odroid HC4, unfortunately can't boot directly from SSD). Is it sufficient to edit the armbianEnv.txt-file in the SD-card's boot-partition? Do you have any suggestions on this?

Yes, this should be doable. Create a LUKS partition and ext4 fs on the SSD, copy the root fs to it,  update /etc/crypttab with the new device UUID, mount, chroot and update the initramfs. I haven't tested this myself though, so other steps might be required. But first you should try the tutorial without modification to make sure it works for your board. If it does, please let me know and I'll add the HC4 to the "supported" list.

Link to post
Share on other sites

On 6/17/2021 at 12:42 PM, MMGen said:

Yes, this should be doable. Create a LUKS partition and ext4 fs on the SSD, copy the root fs to it,  update /etc/crypttab with the new device UUID, mount, chroot and update the initramfs. I haven't tested this myself though, so other steps might be required. But first you should try the tutorial without modification to make sure it works for your board. If it does, please let me know and I'll add the HC4 to the "supported" list.

Whoop, it works, thanks! I've followed the (non-boot) parts in your tutorial. thus I created a single partition on the SSD, formatted it with LUKS/ext4 and copied the rootfs over to my SSD. I've performed some steps on the original (source) OS as well, such as installing dropbear, copying the authorized keys and editing the crypttab and fstab (basically step 9) + update initramfs.

After rebooting and configuring the new rootfs such as providing new root password etc. I've added two lines to the fstab on the new or target-rootfs:

UUID=old-rootfs-uuid-here /oldfs ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 2
/oldfs/boot /boot none bind 0 0

Now the new system is aware of the boot folder. When I run update-initramfs on the new rootfs, the boot folder is updated accordingly. Not sure if this is the best way to do it, suggestions and improvements are welcome.

 

When starting the newly copied system for the first time, I noticed that I couldn't use ssh to login for the first time (with root + password "1234"). Is this expected behaviour?

 

 

Link to post
Share on other sites

On 7/4/2021 at 2:29 PM, Bagel said:

Whoop, it works, thanks! I've followed the (non-boot) parts in your tutorial. thus I created a single partition on the SSD, formatted it with LUKS/ext4 and copied the rootfs over to my SSD. I've performed some steps on the original (source) OS as well, such as installing dropbear, copying the authorized keys and editing the crypttab and fstab (basically step 9) + update initramfs.

After rebooting and configuring the new rootfs such as providing new root password etc. I've added two lines to the fstab on the new or target-rootfs:

UUID=old-rootfs-uuid-here /oldfs ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 2
/oldfs/boot /boot none bind 0 0

Now the new system is aware of the boot folder. When I run update-initramfs on the new rootfs, the boot folder is updated accordingly. Not sure if this is the best way to do it, suggestions and improvements are welcome.

 

When starting the newly copied system for the first time, I noticed that I couldn't use ssh to login for the first time (with root + password "1234"). Is this expected behaviour?

 

 

Glad everything worked! However, the bind mount wasn't necessary. Since you're still booting from the SD/eMMC, the old fstab would have worked unmodified. Can't say why you couldn't log in via SSH initially, but in any case this is a minor issue.

Link to post
Share on other sites

13 hours ago, Werner said:

Since we have this as open issue do you want to port your tutorial to the documentation and use this thread as support thread?

Thanks for the offer/request. I'll be busy for the next several days, but when I get some free time I'll look into doing this.

Link to post
Share on other sites

Hello and first things first MANY THANKS for this great tutorial!!!

 

And I think I have discovered a small typo which will cause the tutorial to fail at that particular step. See here


Step 8 - Prepare the target system chroot

 

# BOOT_PART=($(lsblk -l -o NAME,LABEL | grep CRYPTO_BOOT))

# ROOT_PART=${BOOT_PART%1}2

# ROOT_UUID="$(lsblk --nodeps --noheadings --output=UUID /dev/$ROOT_PART)"

# BOOT_UUID="$(lsblk --noheadings --output=UUID /dev/$BOOT_PART)"

 

this line here:


# BOOT_PART=($(lsblk -l -o NAME,LABEL | grep CRYPTO_BOOT))

should be correctly

# BOOT_PART=($(lsblk -l -o NAME,LABEL | grep CRYPTO_ROOT))

,,,BOOT should be ,,,ROOT (see commands above for clarification)

 

Unfortunately, I was not successful with the full encryption. I got an ODROID-HC2 as a gift and wanted to try a full encryption with the latest Armbian. I got stuck already at the beginning. In the requirements it says that you have to do it on an already running Armbian host and on the other hand you have to have a free card/reader on the respective host with which you can write to a free SD card.

[

Zitat

 

...all steps are performed within a running Armbian system.

 

The tutorial is known to work with the following board/image combinations:

 Orange Pi PC2 Debian Buster mainline / Ubuntu Bionic and Focal legacy

 RockPi 4 Debian Buster mainline / Ubuntu Bionic and Focal legacy

 RockPro 64 Ubuntu Focal mainline

 Odroid HC4 Debian Buster mainline / Ubuntu Focal mainline

 

Requirements:

A blank Micro-SD card and USB card reader, or, alternatively, a blank eMMC installed on the board

 

 

 

 

 

 

The ODROID-HC2 unfortunately has only one micro-SD slot, but it already has my micro-SD card 1 running on the Armbian Bullseye. I can badly pull out during operation this micro-SD card 1 and instead simply insert the empty micro-SD card 2 :-) I have no external SD-card reader which I could attach to the USB port of my ODROID-HC2. So I tried the following. I just used a USB stick (8GB) instead of the empty SD card 2 (32GB) and wrote all the procedure explained in the tutorial to the USB stick, so the target was the USB stick. After everything was successfully completed I removed the USB stick and the micro-SD2 from the ODROID-HC2 and plugged it into my Linux desktop PC. The USB stick was "sdb" and the microSD card was "sdc". I then cloned the contents of the USB stick I just created to the blank micro-SD card 2.

dd if=/dev/sdb of=/dev/sdc bs=1M && sync

 

but unfortunately it did not work. When I put the microSD card into the ODROID-HC2 and boot then I can neither ping nor connect via dropbear/ssh under the configured port. So it seems that the system is not reachable. I noticed that according to the tutorial you should enter DEVICE=eth0 in boot.ini. However, on my ODROID-HC2 with the Armbian bullseye image, the network interface is enx001e06xxxxxx where the numbers/letters after the prefix enx corresponds to the MAC address of the ODROID-HC2. I wonder if this is the error? Would I then have to enter the hardware MAC address in the boot.ini accordingly so device=enx001e06xxxxxx before I had generated the initram?

 

maybe there are ODROID-HC2 users among you who have already done it and can give help? am curious and looking forward to helpful contributions. Thanks in advance.

 

Edited by g00d
formatting error
Link to post
Share on other sites

Hi again. The error I complained about in the last post related to CRYPTO_BOOT CRYPTO_ROOT in Step8) s not an error, but had been seen/written incorrectly by me. Was my mistake, sorry.

 

However, I just can't get this to work with full encryption on the ODROID-HC2. Whenever I try to start the ODROID-HC2 with the new created full-encrypted microSD card I never see my ODROID-HC online, no IP in the network, no ping, not possible to ssh into the configured 2222 dropbear port.I have now made the following attempts in the meantime:

 

1) booted with the microSD card, quite normal into the Armbian operating system. Then inserted an empty USB stick and transferred with nand-sata-install the root filesystem to the USB stick. The microSD is now only used for booting the /boot partition, the filesystem was swapped to the USB stick. This allows me to easily "umount /boot" and then remove the microSD card while the Armbian OS is running. Then I inserted the second empty microSD into the slot of the ODROID-HC2 and went through the entire tutorial point by point exactly as indicated. For me, the startup sector is 8192, so I configured it accordingly.

 

2) In Step9.1) I have manually created the boot/armbianEnv.txt and fed it with the three lines. In step 9.2 I tried three things. First with device=eth0 to get the lease via DHCP, but it didn't work. Then I tried the manual IP assignment, also with eth0 specification. Did not work either. And last but not least I switched back to DEVICE=eth0 but replaced eth0 with enx001e06123456 because my running Armbian OS uses this interface name where 123456 is the real MAC address of the NIC. But this did not help either.

 

3) In step 9.8) I was unsure if I need the line. What is meant by "If the target system is an Ubuntu bionic?" that confuses me. Surely the target system is Armbian ??? Anyway, I have tried both possibilities. Once without this line and once with this line. However, neither of them worked.

 

In step 10.2) I installed "cryptsetup-initramfs" and "dropbear-initramfs". Did not work. Then I tried the variant by installing also the package "cryptsetup". But again without success.

 

EDIT: I see on the /boot partition unter /boot/boot.ini those lines:


# this is for mainline only
if test "${board_name}" = "xu4"; then setenv fdtfile "exynos5422-odroidxu4.dtb"; fi
if test "${board_name}" = "xu3"; then setenv fdtfile "exynos5422-odroidxu3.dtb"; fi
if test "${board_name}" = "xu3l"; then setenv fdtfile "exynos5422-odroidxu3-lite.dtb"; fi
if test "${board_name}" = "hc1"; then setenv fdtfile "exynos5422-odroidhc1.dtb"; fi

 

ODROID-HC2 seems missing here. Can that cause the trouble ?

 

I have now prepared dozens of times my microSD as described in the instructions but the ODROIC-HC board just does not come online. The LEDs all light up as usual, nothing inconspicuous here. But no ping, no IP in the subnet (I checked by nmap scans and insight in my network router) and so I can't ping the rebooted system at all first.

The ODROID-HC2 also has no video output, which means I have no way to see where the error is, or where it hangs. What else should I try, where could the worm be buried? Hope someone can help me.

 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

1 1