[HowTo] armbian jessie server enrypted rootfs using whole sd

[Arben]

The aim, when I started to work on this issue, was to have a headless server with an encrypted rootfs, which uses the whole sdcard, despite the boot partition, and that could be unlocked remotely, meaning entering the encryption password at the booting process from another machine via a ssh connection. Even there are many HowTos in the web, I found no one describing all the needed steps for this combination. For me it was pretty hard to gather all needed information. Therefore I want to share my findings.

I reached this as described in this HowTo. I used armbian jessie server, which is working out of the box without obvious errors or bugs up to now.

Trying this HowTo is on your own risk!

Assumptions:
- you are working on a linux system
- you know how to work with dd
- you know how to edit files in a console with e.g. nano
Needed:
- Odroid C2
- SD-Card
- USB-Stick with at least 2GB

Preparations on a linux machine - not on the odroid yet

First of all download the armbian image and unpack it. I tried this with the server image, but it should also work with the desktop image (untested).

Then write the image with dd to your sdcard and to an usb stick. It's the same command with different devices at the "of=" parameter:

Code: Select all

sudo dd if=/path/where/your/armbianimage/is/Armbian_5.06_Odroidc2_Debian_jessie_X.XX.XX.raw of=/dev/sdX

After you have done that, plug the sdcard and the usb-stick to the odroid and boot it up.

From now on we are working on the odroid!

If you want to do this already headless on the ODROID-C2, look up the ip-address and connect to it.
At the first startup you will be asked for the initial configuration like username and so on. This is not that important, because we won't use this fs later. But don't forget the pw you have entered!

On the odroid now your usb-device should be listed as sda. If not be careful using the instructions from now on!

Code: Select all

lsblk

Code: Select all

NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda           8:0    1 29.9G  0 disk 
├─sda1        8:1    1   64M  0 part 
└─sda2        8:2    1  1.4G  0 part 
mmcblk0     179:0    0 57.7G  0 disk 
├─mmcblk0p1 179:1    0   64M  0 part /boot
└─mmcblk0p2 179:2    0 57.6G  0 part /

Mount the rootfs partition of the usb drive to /mnt:

Code: Select all

mount /dev/sda2 /mnt

If you access your odroid via ssh, sometimes it's easier to know the ip-address. You can change the configuration for the future operating system, which is located on the usb-drive at the moment to this for a static IP. If you don't want a static IP, but you want to be able to decrypt the system remotely later, you have to add at last the line containing the pe-up command. This command is needed to flush the ip configured for the dropbear server, which is needed for the remote decryption.

Code: Select all

nano /mnt/etc/network/interfaces.default

Adjust to your needs:

Code: Select all

# Wired adapter #1
allow-hotplug eth0
        iface eth0 inet static
            address 192.168.1.200
            netmask 255.255.255.0
            gateway 192.168.1.2
            pre-up ip addr flush dev eth0
#       iface eth0 inet dhcp
#       hwaddress ether # if you want to set MAC manually
#       pre-up /sbin/ifconfig eth0 mtu 3838 # setting MTU for DHCP, static just: mtu 3838
#
# Wired adapter #2
#auto eth1
#       iface eth1 inet dhcp
#       hwaddress ether # if you want to set MAC manually
#       pre-up /sbin/ifconfig eth0 mtu 3838 # setting MTU for DHCP, static just: mtu 3838
#
# Wireless adapter #1
#auto wlan0
#       iface wlan0 inet dhcp
#       wpa-ssid SSID
#       wpa-psk xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
# to generate proper encrypted key: wpa_passphrase yourSSID yourpassword
#
# Local loopback
auto lo
        iface lo inet loopback

Now we have to change /mnt/etc/fstab (on the usb drive) to point to our usb drive:

Code: Select all

nano /mnt/etc/fstab

Code: Select all

/dev/sda2 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1
/dev/mmcblk0p1 /boot vfat defaults 0 2
tmpfs /tmp tmpfs defaults,rw,nosuid 0 0

Change the entry of the boot args in /boot/boot.ini defining the rootfs to also point to our usb drive.
The line containing the boot args should look like this:

Code: Select all

nano /boot/boot.ini

Code: Select all

# ...
# Boot Arguments
setenv bootargs "root=/dev/sda2 rootwait rootflags=data=writeback rw ${condev} no_console_suspend hdmimode=${m} m_bpp=${m_bpp} vout=${vout} fsck.repair=yes loglevel=${verbosity} net.ifnames=0"
# ...

After that we have to update boot.cmr and also the initrd together with the image files and copy the needed files to the boot partition:

Code: Select all

mkimage -C none -A arm -T script -d /boot//boot.ini /boot/boot.scr
update-initramfs -c -k all
mkimage -A arm64 -O linux -T ramdisk -C none -a 0 -e 0 -n "uInitrd $(uname -r)" -d /boot/initrd.img-$(uname -r) /tmp/uInitrd-$(uname -r)
cp /tmp/uInitrd-$(uname -r) /boot
cp /tmp/uInitrd-$(uname -r) /media/uInitrd

Now you can reboot.

After the reboot you can connect again to the odroid-c2 and you will encounter, that you have to do again the initial configuration process. That's because we are now running from the usb drive. At this point enter your desired values, because this will be later our operating system.
To verify this correct drive once more check the current mounts after doing the configuration:

Code: Select all

mount | grep /dev/sda2

If this is listed, everything went fine:

Code: Select all

/dev/sda2 on / type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600,data=writeback)

You should now create a backup of your current boot files for being later able to boot again with the usb drive, if something goes wrong, without having to repeat all the steps until now.

Code: Select all

mkdir boot/backup_boot_from_usb
cp boot/* boot/backup_boot_from_usb/

Install the needed packages:

Code: Select all

apt-get -y install lvm2 cryptsetup parted nano rsync dropbear

The next steps are to delete the current rootfs partition on the sdcard, to create a new enrypted partition and to set up the lvm.
List the current partitions with parted:

Code: Select all

parted -l

Code: Select all

Model: Corsair Voyager 3.0 (scsi)
Disk /dev/sda: 32.1GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  68.2MB  67.1MB  primary  fat16        lba
 2      68.2MB  1540MB  1472MB  primary  ext4


Model: SD SA64G (sd/mmc)
Disk /dev/mmcblk0: 61.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  68.2MB  67.1MB  primary  fat16        lba
 2      68.2MB  61.9GB  61.9GB  primary  ext4

We use again parted for the deletion and creation of the partitions. Do not forget to select the sdcard in parted!Enter parted:

Code: Select all

parted

Here you can see, what I've entered. You can see, that I took the former start value of partition 2 as the new starting value. 100% tells parted to use all the rest of the sdcard.

Code: Select all

GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) select /dev/mmcblk0                                              
Using /dev/mmcblk0
(parted) rm 2
(parted) mkpart primary ext4
Start? 68.2MB
End? 100%                                                                 
(parted) q                                                                
Information: You may need to update /etc/fstab.

Now we have to set the correct label of the partition with fdisk:

Code: Select all

fdisk /dev/mmcblk0

Code: Select all

Welcome to fdisk (util-linux 2.25.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): t
Partition number (1,2, default 2): 2
Hex code (type L to list all codes): 8e

Changed type of partition 'Linux' to 'Linux LVM'.

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Device or resource busy

The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).

As fdisk tells us we execute partprobe:

Code: Select all

partprobe

Now our new partition is ready for the encryption. After entering this command you will be asked for a password. Select a strong one and do not forget it! Adjust the parameters, if needed:

Code: Select all

cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/mmcblk0p2

Open (decrypt) the encrypted partition:

Code: Select all

cryptsetup luksOpen /dev/mmcblk0p2 lvm

Create the logical groups, volumes, ...:

Code: Select all

pvcreate /dev/mapper/lvm
vgcreate vg /dev/mapper/lvm
lvcreate -l 100%FREE -n root vg

Create the filesystem:

Code: Select all

mkfs.ext4 /dev/mapper/vg-root

Mount the logical volume:

Code: Select all

mount /dev/mapper/vg-root /mnt

OK, now we move our current fs to the sdcard:

Code: Select all

rsync -av --exclude=/media --exclude=/mnt --exclude=/proc --exclude=/dev --exclude=/sys / /mnt

Create and mount some folders for being able to chroot to the new fs:

Code: Select all

mkdir -p /mnt/dev
mkdir -p /mnt/mnt
mkdir -p /mnt/proc
mkdir -p /mnt/sys
mkdir -p /mnt/media
mount -o rbind /dev /mnt/dev
mount -t proc proc /mnt/proc
mount -t sysfs sys /mnt/sys
mount -t vfat /dev/mmcblk0p1 /mnt/media

Now chroot to the new fs:

Code: Select all

chroot /mnt

From now on everything is executed in the new fs
If you want to come back to your regular root fs, type exit.
Write the UUID of the encrypted partition to /etc/crypttab[/ii]:

Code: Select all

echo lvm UUID=$(cryptsetup luksUUID /dev/mmcblk0p2) none luks|tee /etc/crypttab

Edit /etc/fstab to usethe logical volume mounting root "/":

Code: Select all

nano /etc/fstab 

Your /etc/fstab should look like this:

Code: Select all

/dev/mapper/vg-root / ext4 errors=remount-ro 0 1
/dev/mmcblk0p1 /boot vfat defaults 0 2
tmpfs /tmp tmpfs defaults,rw,nosuid 0 0
/var/swap none swap sw 0 0

Populate the changes to the initram:

Code: Select all

update-initramfs -t -u -k $(uname -r)

Update the image and initrd:

Code: Select all

mkimage -A arm64 -O linux -T ramdisk -C none -a 0 -e 0 -n "uInitrd $(uname -r)" -d /boot/initrd.img-$(uname -r) /tmp/uInitrd-$(uname -r)

Copy it to the boot folder:

Code: Select all

cp /tmp/uInitrd-$(uname -r) /boot
cp /tmp/uInitrd-$(uname -r) /media/uInitrd

Now we change quickly back to the usb fs to finish this part of the configuration
Now exit chroot:

Code: Select all

exit

From here we change again the boot args:

Code: Select all

nano /boot/boot.ini

Code: Select all

# ...
# Boot Arguments
setenv bootargs "root=/dev/mapper/vg-root cryptdevice=/dev/mmcblk0p2:lvm rootwait rootflags=data=writeback rw ${condev} no_console_suspend hdmimode=${m} m_bpp=${m_bpp} vout=${vout} fsck.repair=yes loglevel=${verbosity} net.ifnames=0"
# ...

After that we have to update the boot.cmr:

Code: Select all

mkimage -C none -A arm -T script -d /boot//boot.ini /boot/boot.scr

Now we prepare our system for remote login in the boot process.
Therefore we come back to our chroot fs:

Code: Select all

chroot /mnt

Here we configure the initram to start a small dropbear server:

Code: Select all

echo DROPBEAR=y >> /etc/initramfs-tools/initramfs.conf 

For finding your odroid in the boot process, set a static ip in the device part in the initramfs.conf.

Code: Select all

nano /etc/initramfs-tools/initramfs.conf

Adjust to your needs:

Code: Select all

# ...
DEVICE=eth0 >> /etc/initramfs-tools/initramfs.conf
IP=192.168.1.222:::255.255.255.0::eth0:off
#...

Again we have to update initram, images, ...:

Code: Select all

update-initramfs -t -u -k $(uname -r)
mkimage -A arm64 -O linux -T ramdisk -C none -a 0 -e 0 -n "uInitrd $(uname -r)" -d /boot/initrd.img-$(uname -r) /tmp/uInitrd-$(uname -r)
cp /tmp/uInitrd-$(uname -r) /boot
cp /tmp/uInitrd-$(uname -r) /media/uInitrd

Here you can also backup your boot files if something goes wrong, you don't have to create them again for booting the encrypted fs:

Code: Select all

mkdir boot/backup_encrypted_rootfs
cp boot/* boot/backup_encrypted_rootfs/

Now the rsa key has to be copied to your host from which you want to connect to the odroid. Adjust to your host:

Code: Select all

scp etc/initramfs-tools/root/.ssh/id_rsa user@192.168.1.333:/desired/path/

Now we are done. We exit chroot:

Code: Select all

exit

After a reboot connect via ssh with:

Code: Select all

ssh -i /desired/path/id_rsa root@192.168.1.222 # remember the ip configured in the initram.conf 

After you are connected, you can enter the password this way:

Code: Select all

echo -n "Passphrase" > /lib/cryptsetup/passfifo; exit

Done

[mad_ady]

Great tutorial! I think it's worthy to become an article in the magazine. I like how you're using ssh to input the passphrase. Tell me, does dropbear stop and openssh start once you unlock the disk? Also, what happens in case of unclean shutdown? Should we expect just abdirty filesystem or does the encryption layer have special requirements. Also it would be nice to know some performance stats - encrypted vs unencrypted. Did you enable hardware encryption support anywhere? And lastly, can you provide real-world use cases where an encrypted rootfs would be desired?

[Arben]

Great tutorial! I think it's worthy to become an article in the magazine. I like how you're using ssh to input the passphrase. Tell me, does dropbear stop and openssh start once you unlock the disk? Also, what happens in case of unclean shutdown? Should we expect just abdirty filesystem or does the encryption layer have special requirements. Also it would be nice to know some performance stats - encrypted vs unencrypted. Did you enable hardware encryption support anywhere? And lastly, can you provide real-world use cases where an encrypted rootfs would be desired?

Hi mad_ady,

thanks for your feedback. Yes dropbear is stopped at startup and openssh starts running instead. See this traceline (it's from my C1 with the same configuration, because of my current UART wiring):

Code: Select all

Begin: Running /scripts/init-bottom ... Begin: Stopping dropbear ... done.

I never had a corrupted fs and I'm using disk encryption on all my systems. Even not on hard power offs. But there is a fsck at system startup (also from my C1):

Code: Select all

Begin: Will now check root file system ... fsck from util-linux 2.25.2
[/sbin/fsck.ext4 (1) -- /dev/mapper/vg-root] fsck.ext4 -a -C0 /dev/mapper/vg-root 
/dev/mapper/vg-root: recovering journal
/dev/mapper/vg-root: clean, 55091/3252224 files, 507979/12986368 blocks
done.

Crypto HW support is working out of the box as far as I can see. Using an encrypted USB-HDD shows, that the bottleneck is the USB port. I have transfer rates from ~20MB/s up to ~30MB/s depending on filesize and r or w. Therefore I also assume, that at r/w operations on the local fs also the SD-card will be the bottleneck. If you want special tests, please tell me which performance tests you need exactly and I will do them.

Regarding your question of the real-world usecase: Everybody has to decide for himself, if he needs an encryption on this level or not. In my case it is more preventive for the worst-case scenario. I have sensible data, which are not in the homefolder, like /usr/bin, a mysql db and some more. They are also not "really secret". It's just more for the case, if these data get into hands they shouldn't. Do I really want, that this person sees all my passwords or my income stats in dhe db ...? Therefore I decided to use this solution. It's easy to setup (once you know how to do this) and I don't have to carry anymore about it.

I hope I could answer your questions and I'm sorry for my late reply (was a little bit busy in my job).

BR, Arben

[mad_ady]

Thanks for the details. Do you have the same hostkey shared by dropbear and openssh? Otherwise I suspect you'd get the nagging prompt that identity check failed.
Also, do you notice higher CPU usage when doing intensive IO compared to non-encrypted disks? E.g. try to check CPU usage when doing:

Code: Select all

dd if=/dev/zero of=/dummy-encrypted-file bs=1M count=500
dd if=/dev/zero of=/media/non-ecrypted-disk/dummy-file bs=1M count=500

[Arben]

Do you have the same hostkey shared by dropbear and openssh?

I use different ip-addresses for dropbear and openssh and therefore I bypass this problem. I use this also as indicator if my server is up and running, e.g. after a power loss.

I have executed your tests, but I don't know if these are reliable, because my toshiba sd slows extremly down on larger files (no matter if encrypted or not).
The test on the encrypted sd card:

Code: Select all

date; dd if=/dev/zero of=/root/dummy-encrypted-file bs=1M count=500; sync; date
Mon May 16 17:37:59 CEST 2016
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 173.315 s, 3.0 MB/s
Mon May 16 17:41:18 CEST 2016

Shows the following CPU load with the command found here:

Code: Select all

echo $(date) > load.log; while true; do top -bn 2 -d 0.01 | grep '^%Cpu' | tail -n 1 | gawk '{print $2+$4+$6}' >> load.log; sleep 1; done

Code: Select all

cat load.log 
Mon May 16 17:37:57 CEST 2016
23.6
26.3
54.6
72.7
10
17.7
18.7
50
18.7
38.9
21.1
15.8
18.7
22.2
20
21
23.5
22.2
21.1
17.6
17.7
18.7
20
16.7
22.2
25
20
21.1
23.5
17.7
20
17.7
21.1
23.6
18.7
17.7
20
37.5
20
23.5
21
22.3
22.3
23.6
17.6
20
23.5
17.7
21.1
36.9
17.7
22.2
26.4
17.7
21
18.7
21
20
17.7
23.5
21.1
18.8
20
15.8
17.7
22.3
22.3
20
17.7
17.7
17.7
17.7
18.7
20
26.4
22.3
20
21
25
17.7
21
23.5
21.1
15.8
22.2
20
27.8
20
22.3
18.7
16.7
21
22.3
16.7
18.7
23.5
16.7
21.1
53
21.1
22.2
18.7
18.7
22.2
22.2
16.7
22.3
15.8
16.7
23.6
45
21
18.7
16.7
22.2
20
17.7
21
21
17.7
18.7
27.8
22.2
23.5
41.7
27.3
16.7
68.7
61.1
27.3
33.3
41.6
33.4
20
38.5
33.3
30.8
18.7
21.1
23.6
17.7

Test on the not encrypted usb drive:

Code: Select all

date; dd if=/dev/zero of=/media/not_encrypted/dummy-file bs=1M count=500; sync; date
Mon May 16 17:45:43 CEST 2016
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 15.7563 s, 33.3 MB/s
Mon May 16 17:46:01 CEST 2016

Shows the following CPU load (same command):

Code: Select all

cat load.log 
Mon May 16 17:45:40 CEST 2016
18.7
16.7
23.5
37.5
50
20
16.6
25
20
15
20
21.1
20
19.1
31.6
28.6
21
18.7
17.7

I don' know if this helps you?!

[mad_ady]

I see a 10 times speed increase when you're writing to a non-encrypted disc. Also, your load seems pretty high in both tests. I'll think of other tests and let you know.

[Arben]

I see a 10 times speed increase when you're writing to a non-encrypted disc.

That's why I mentioned, that the SD card slows down extremely

[mad_ady]

I admit, I'm interested mostly in encryption speed (to compute hashes). One way you could test to see if sdcard is the bottleneck or not would be to:
1. Create a ramdrive of, let's say 200MB
2. On the ramdrive create an encrypted lvm inside a 100MB file
3. time dd if=/dev/zero of=/path/to/encrypted/lvm/file bs=1M count=100 conv=fsync. You could create a filesystem, but I don't think it would make much difference
4 time dd if=/dev/zero of=/path/to/unencrypted/ramdisk/file bs=1M count=100 conv=fsync

The times shoul only depend on encryption settings. I think there are some settings that might need to be enabled to benefit from hardware (or gpu?) accelerated encryption. I still need to learn about this topic.

[cake]

Thanks Arben,
I followed your instructions, and got it working. I used Ubuntu minimal on a C2.
Your instructions got me most of the way.

[cake]

Something related...
If the purpose of this is to host the device in a data center and not worry data theft, I was wondering how easy it would be for someone to capture the LuKS pass- example: someone with skills pulls out the emmc card, and clones, then modifies the boot partition so when you remote into it to unlock it, it copies the password somewhere. Any thoughts? My skills are poor, just wondering.

I was thinking a user could just superglue the emmc card in. right?

[mad_ady]

the password should not be stored on the device in clear. You should have to input it on every boot

[g000444555]

Thanks Arben,
I followed your instructions, and got it working. I used Ubuntu minimal on a C2.
Your instructions got me most of the way.

I tried to do the same without success. Could you please share the adjustments you made for the Ubuntu minimal on a C2? That would save tons of time and effort for me and many other people.

[cake]

Sorry I sent mine out to a data center for collocation.
I did make adjustments, but I am truly a amateur, all the changes I made where mostly common sense, I fixed a couple typos from the example above, and I believe I had /dev/mmcblk0 (emmc) and /dev/mmcblk1 (sdcard) also I think the usb thumb drive came up as /dev/sda so I made some changes when following along. To be honest I went really slow and thought about every command for a while, I did deviate from Arben's instructions a little. Hope the next successful guy can share more.

I spent some time on my desktop setting up a isc-dhcp-server and iptable rules, packet forwarding so I could test remote booting with a public IP inside a LAN before mailing. I still have those settings if anybody needs help and needs Internet for installing stuff and want to configure initramfs dropbear with static public IP and not a local IP. (192.168.X.X). My setup looked like this Internet--> wifi / router --> Linux Desktop (Debian-Ubuntu) -->ethernet cable---> odroid
I could run apt-get and everything just fine inside a LAN on the odroid and test remote booting.
Cheers

[g000444555]

Hi cake,

Thanks for letting me know. Interesting stuff, as I might also place one of my docker clusters into a data center in the future.

Sounds like you might have been lucky with your Ubuntu minimal C2, because with the latest updates it isn't even able to boot from the USB drive: viewtopic.php?f=136&t=27696

That was the reason I switched to ArchLinux, even though I haven't managed to setup LUKS yet, at least it did not seem to have such trivial issues.

Debian on the other hand seems to be the best image available for C2 so far but the distro itself has almost "ancient" packages especially for the stuff I need it for.

Kind regards

[cake]

Hi cake,

Thanks for letting me know. Interesting stuff, as I might also place one of my docker clusters into a data center in the future.

Sounds like you might have been lucky with your Ubuntu minimal C2, because with the latest updates it isn't even able to boot from the USB drive: viewtopic.php?f=136&t=27696

That was the reason I switched to ArchLinux, even though I haven't managed to setup LUKS yet, at least it did not seem to have such trivial issues.

Debian on the other hand seems to be the best image available for C2 so far but the distro itself has almost "ancient" packages especially for the stuff I need it for.

Kind regards

I had similar trouble, I would write the image to a sdcard (emmc adapter), or usb, and the Odroid would stop somewhere in the boot process. Someone told me to use a program called etcher. Etcher wrote the image to the sdcard and emmc correctly. I was using dd before giving etcher a try.

[g000444555]

I had similar trouble, I would write the image to a sdcard (emmc adapter), or usb, and the Odroid would stop somewhere in the boot process. Someone told me to use a program called etcher. Etcher wrote the image to the sdcard and emmc correctly. I was using dd before giving etcher a try.

I might give it a try then. As indicated in viewtopic.php?f=136&t=27696 I went through a process of trying few things, including altering the UUID of the two drives. Eventually, I was recommended to use rsync in order to copy the root filesystem into the USB drive. The odd thing is that dd copied the data correctly to the SD card and the boot was successfull. Also, other distros (Debian and ArchLinux) did not have this problem. The problem with dd appears to be only when using the Ubuntu minimal C2 and the USB disk (fine with the SD card).

My initial intention was indeed to use the Ubuntu image because it is the officially supported image. However, the above issue along with some concernes raised the red flag for me. In particular:

* The Ubuntu minimal C2 image is almost a year old. Other distros are only couple of months old.
* The fstab has a duplicate entry for the root (/) which was causing a warning (viewtopic.php?f=136&t=27701&p=196935&hi ... ab#p196935). Crapware alert
* The updated wiki has broken links for the official distributions (it has been at least 2-3 days like that): https://wiki.odroid.com/odroid-c2/odroid-c2

Even though I switched to ArchLinux, there are issues there too (https://archlinuxarm.org/forum/viewtopi ... 15&t=11907).

My final test will be to try gentoo. If that is problematic as well then I will have to resort back to Ubuntu or Debian.

Cheers

[cake]

I see a 10 times speed increase when you're writing to a non-encrypted disc.

That's why I mentioned, that the SD card slows down extremely

This is with following your setup instructions, but using a emmc instead. (ran it twice)

Code: Select all

date; dd if=/dev/zero of=/root/dummy-encrypted-file bs=1M count=500; sync; date
Thu Sep 14 14:14:07 UTC 2017                                                                                                                                                                                                                   
500+0 records in                                                                                                                                                                                                                               
500+0 records out                                                                                                                                                                                                                              
524288000 bytes (524 MB, 500 MiB) copied, 4.3854 s, 120 MB/s                                                                                                                                                                                   
Thu Sep 14 14:14:13 UTC 2017

date; dd if=/dev/zero of=/root/dummy-encrypted-file bs=1M count=500; sync; date
Thu Sep 14 14:15:30 UTC 2017
500+0 records in
500+0 records out
524288000 bytes (524 MB, 500 MiB) copied, 4.9845 s, 105 MB/s
Thu Sep 14 14:15:37 UTC 2017

[Colin]

Instead of dropbear I want to use a key file on the sd card or usb stick (like a key). How can I do this. Because now when I don’t do the last part (Now we prepare our system for remote login in the boot process.) It doesn’t startup anymore. And I don’t get an option to fill in the password when booting on the console.

[poincare]

Could this work on Armbian for the N2?