Search the Community

Hello. I just tried the latest Armbian jammy for PineBook Pro and the kernel refuses to boot. I tried to replace the 6.6.31 kernel with 6.1.63 from older image and it works without problems.

You are looking at the master branch. We need an orange-pi-6.9 branch. See: https://megous.com/git/linux/tree/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts?h=orange-pi-6.9#n729 But simply adding this node will not bring results. A set of patches from this rk3399-typec-6.9 branch is needed and there may be something else. Use the instructions to get the necessary README Look at the contents\history (git log -p megi/rk3399-typec-6.9) of the received branches. Special attention is paid to: megi/tcpm-6.9 megi/typec-extcon-6.9 megi/rk3399-typec-6.9 megi/fusb302-6.9

I got in contact with the kernels author and got told, that DP-Alt is not yet implemented for the rockpro64. Looking at the schematics, the usb-c controller seems identically to the pinebook pro. I am ready to start digging in the device-tree file for the rkp64 by comparing the pbp to the rkp64. But I don't know how to create and test the Kernel from these files.

Generating images, once device is in the system, does not burn our expensive time. It costs a lot less then answering this support question. Updates are generated for all devices (of one family) at once. Adding and removing is expensive and perhaps someone fixed this problem? Then we need to put it back. Those are already maintaining activities, which we don't have resources for ... keeping devices in auto-build costs us close to nothing (until compilation succeeded) and this is the same way all others distros do, while they are marking those random auto-build as "supported by Linux X" ... We at least tell you "we don't know if it works", as checking is expensive. Or even impossible as nobody from the team has this device. It was added by someone like you, user, that wanted to keep this device in the Armbian system, which system provides a lot of common fixes and generally helps maintaining those devices. Our interest is that Armbian runs well on as many devices as possible, but the costs of that is super extreme - as you know, we can't sell you our work, you don't want to pay our bills .... Once we bring support on some device, we have copycats that does absolutely nothing but also "supports" this device. It is really difficult as costs dealing with those devices is close to impossible to cover. If you want that device function perfectly and when there is close to nobody helping, one needs to spent serious time / money to support HW dealers business, copycats and you. Its not sustainable. The same applies to other devices that were thrown to the market ... We are maintaining this system, some devices, while the rest are on you - community. Providing images, keeping this device in the system that is getting common updates all the time, is already great added value. Bugs are shared among similar devices, which means when this bug will be fixed for Pinebook PRO, this device will also have working images ... Its pure economy. They can't afford that. Device is here - and if you want to keep it operational, its your problem. Well, our common problem. We add our share and we can't add more. We don't have this device, we don't have anyone maintaining it. Not anymore. Now, a lot of those devices will still work even nobody maintain them. This indicates it stops before loading user space, probably kernel is crashing. Sometimes you need to solder those pins. HW designers aim is to make a device that they can sell well ... Does this device matches that? Yes, its a nice toy. There is no GRUB on those devices, but yes, problems with boot loader are possible. Every major kernel bump renders some devices into not usable state. That is why we have so much work that nobody notice and very little help. If we could allocate needed resources, all of those "Community (not) supported" will be working. This is certainly not in HW designers interests (as they want to sell you new device), while end users can't understand that buying hardware is just a fists step and means nothing. You need to add a lot more to have this device functional. This is not RPi, who has masses of people that will maintain it for free.

Hi, I read everything I could possibly find on the DP-Alt mode for the RockPro64 and came to the conclusion that no Distro is offering that right now. However, the Pinebook Pro seems to have support via a Kernel Patch. Can the Pinebook Pro Kernel be installed on the RockPro64? Is there a repository for Armbian Kernels? Thanks very much.

Like on the OrangePi's which have problems with the latest Community Edition (kernel 6.6.x and their armbian-firmware) I went back to the most actual stable image before kernel 6.6.x (non-Community Edition?) for the Pinebook A64 which can be found at https://armbian.hosthatch.com/archive/pinebook-a64/archive/Armbian_23.11.1_Pinebook-a64_bookworm_current_6.1.63.img.xz You do get a non-Desktop system with Armbian 23.11.1 Pinebook-a64 bookworm current kernel 6.1.63 then do a Kernel-Freeze in armbian-config -> system apt update/upgrade and you will end with a stable Armbian 24.5.1 Bookworm with Linux 6.1.63-current-sunxi64 This will recognize my 14" Screen, WiFi and Ethernet (USB)

@Gunjan Gupta Today I did try the following images Armbian_community_24.8.0-trunk.205_Pinebook-a64_noble_current_6.6.31_gnome_desktop.img and Armbian_community_24.8.0-trunk.205_Pinebook-a64_bookworm_current_6.6.31_minimal.img on my 14" (1080p?) Pinebook non-Pro A64, but I do get only a black screen It didnt help to use echo 8 > /sys/devices/platform/backlight/backlight/backlight/actual_brightness or the pkexec-command The screen lights up, but to information on the screen. I had only (sometimes) access via a USB-Ethernet-Adapter. But at some boots the ethernet wasnt recognized and the onboard-Wifi doesnt sho up The last version I could get my screen to work - with a CLI-version of bookworm - is 24.2.0 of armbian (after update?) I dont know how to switch via 720p/1080p for the different screensizes of the Pinebook A64 non-Pro (I have 14" and not 11.6") BTW: after updateing the 24.2.0 of armbian via apt update/upgrade the system is also non-working (Black screen and no ethernet and no Wifi) Its has updated to kernel 6.6.31 and this was also the "death" to some of my OrangePi installations The "Community Editions" are at this time unuseable (because non-tested) - this could end in a bad reputation also for the supported devices - as I think. For me its software-obsoleszenz - rendering working hardware into a paperweight

Late reply here, but it seems all the Armbian images are broken. While I understand your frustration with Pine64, I think you should remove the Pinebook Pro from your list of images. Being up front and saying that you don't support the hardware is better / less frustrating than claiming to support the hardware but providing broken images. Anyway, I'm selling my Pinebook Pro and reverting it to the factory Manjaro build. It's too annoying to keep fighting with it.

Hi Referring to https://forum.armbian.com/topic/32667-usb-c-port-doesnt-work-on-pinebook-pro-after-the-latest-update-on-kernel-662/ USB -C is not working. I also tried 6.7.4-edge with no success. Looking for a solution G??gle found this: https://www.linuxquestions.org/questions/slackware-arm-108/pinebook-pro-usb-c-port-not-working-after-kernel-upgrade-4175732886/#google_vignette referring to Megi`s 6.7 kernel. The link was outdated, but the base worked and had versions 6.8 and 6.9. Tried both with a lot of success: USB-C working and the HDMI monitor output as well as Gigabit Ethernet work like a charm again. 😄 The only small issue remaining: Sound is not working (no analog or digital.) armbianmonitor: https://paste.armbian.com/mamocolodo (I had a small issue following Megi`s Readme: The board.dtb should replace rk3399-pinebook-pro.dtb in one of the existing dtb trees. I used dtb-6.7.4-edge-rockchip64.) any ideas about the sound issue are greatly appreciated. Sepp

@snakekick Thanks, that seems to confirm my findings back a few months ago. Adding a 5ms delay in the test case did not prevent the crash. Though it could be the system load is at play. Maybe adding a delay at the kernel level would do. pcie is tagged on the big CPUs so the SATA disks seem to matter (as the ethernet port). One could try in emergency mode (passing emergency to the kernel (I do it by "setenv extraboardargs emergency" after halting u-boot with a key press then enter "boot"). You will have just the root partition mounted read-only (so no network connection, a serial console is required). Then run the test. Also note that the design of the GPU regulator has the same issue as the CPU b one ... (for my tests I blacklisted panfrost, ie the GPU driver). After looking at the rockchip64 board schematics the design around the CPU b regulator is not similar but exactly the same as the helios64 one (rockchip64 uses a tcs4545 regulator for cpu b and tcs4546 for GPU). I wonder if the easiest fix would not be to pay someone to desolder the syr837 regulator and solder a tcs4545 instead - same for the GPU regulator a tcs4546 instead of the syr838... except that these chips from Torch Chip seem nowhere to be found. Maybe rip them from a rockpro64 board. @aprayoga can you confirm the Helios64 design for the rk3399 big cpu and gpu regulators are the same as the RockPro64 ones? Would it make sense (and would it fix the unstable cpu_b) to desolder the syr837/syr838 to replace them with tcs4545/tcs4546? Ie the tcs4535 datasheet (I am still unable to find the tcs4545 datasheet) I found tells tcs425 has internal pulldown for VSEL and EN which syr837 does not, the syr837 datasheet requires a 22uF capacitor for VIN but the helios64 has a 10uF one like the rockpro64 for the tcs4545. The SW pin of the helios64 has 470uH inductor with 4 x 22uF capacitors like the rockpro64 for the tcs4545 (like the typical application in the tcs4535 datasheet with 470uH inductor with two 22uF capacitors)? Do you know a replacement for the TCS4545/TCS4546 that has closer specs than the syr837/syr838? I cannot seem to find TCS4545/TCS4546 for sale (maybe I could buy a rockproc64 to desolder them at least for a test... or could you check on your side with a helios64 board that the cpufreq-switching-2-b test above crash with syr837 but not with tcs4545 with vanilla rk3399 opp definitions in dts? Sadly the Helios64 filled a market that is left unfilled. People who do not have the know-how to go full low-wattage DIY NAS and who also cannot afford to pay 1K€ for a NAS (and who might need two NASs to make things worse). In the meantime, I spend a lot of time learning about DIY NAS, but it is still hard to get wattage at full load (they tend to give all idle power usage). I probably will end up gambling and buying one build and pray... but with Helios64 I had the metrics before buying. I found that the Rock960 has the same design for the cpu_b and gpu regulators except for the inductor which is 0.240uH on the rock960 and 0.470uH on the Helios64. But hard to tell if the Rock960 is stable with my cpufreq switching test for the big cpus of the rk3399, might be the use of the board does not stress it as much as a raid10 on the helios64 pcie sata which is tagged to the cpu_b ... (initially it was 4 3TB WD Red - the old CMR model WD30EFRX-68EUZN0), from Helios4 setup as advertised by Kobol wiki for the Helios4... the board crashes on first boot after assembly with this raid setup. Mind I found that the Pinebook Pro also has the same design as the Helios64 this time around the syr837/syr838 ... I begin to wonder if either they are all broken (could be the amount of stress of a NAS ethernet or raid10 pcie is not that common) or if this is not the issue at stake.

Moved post to unsupported/community maintained. This is not a supported board. My mistake, misread the post. This is pine64 not pinebook a64. That board should be supported but the forum structure isn't up to date. I have added the correct tag for the post, but left it in the original locatation.

Also on 1st class hardware it does not go without issues: https://www.google.com/search?q=why+kernel+upgrades+breaks+features On trash ultra cheap and forgotten hardware, where Armbian is trying to make a difference, breakage % is significantly bigger. Every kernel, that is work of thousands of people (some forget to test changes), breaks features even we invest tens of thousands of hours into stabilizing it. There is virtually no support from industry and no support from end users, but we still managed to build automated monitor for upgrades on many boards in automated way: https://github.com/armbian/os?tab=readme-ov-file#latest-smoke-tests-results Sadly, we don't test Pinebook, not complex functions as this and not all possible upgrades. Expanding testing to that and patching would cost additional few millions which is simply not possible to secure from this. In past year, nobody applied to serve as test engineer to develop this further. Other Linux distributions are far far away even from this. Install Armbian on a desktop PC.

!!! Warning !!!: Think twice before you upgrade kernel on your PineBook Pro. After years unfortunately I decided to unlock upgrades Armbian Kernels and upgraded kernel to the newest one (current) - 5.15.93. After reboot Armbian couldn't find my encrypted root disk and booting ended every time in (initramfs). I installed again kernel 5.10.60 #21.08.1 and Armbian finds my encrypted disk again. Of course still there is no information that I have to enter the password to unlock disk but only black screen. Happily I know that I have to enter the password when the screen is black. Every upgrade of Armbian is connected with a dose of stress that I'll have to fix my computer. I thought that every following kernel should fix errors not create them.

Description Other devices could be added if whatever the regulator needed for UHS is enabled. Read perf def improved on the gnome disk benchmarks. Jira reference number [AR-9999] let's enable salva's UHS overlay for RK3399 tested on PBP with 2ghz with 64 gig samsung evo select i like using the yabs.sh fio benchmark for mixed r/w tests curl -sL yabs.sh | bash -s -- -i -g -n also did gnome disk utility read benchmark before kernel 6.6.10 yabs # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## # # Yet-Another-Bench-Script # # v2024-01-01 # # https://github.com/masonr/yet-another-bench-script # # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## # Sat Jan 6 05:59:38 PM EST 2024 ARM compatibility is considered *experimental* Basic System Information: --------------------------------- Uptime : 0 days, 0 hours, 2 minutes Processor : Cortex-A53 Cortex-A72 CPU cores : 6 @ 1512.0000 2016.0000 MHz AES-NI : ✔ Enabled VM-x/AMD-V : ❌ Disabled RAM : 3.7 GiB Swap : 1.9 GiB Disk : 57.5 GiB Distro : Armbian 23.08.0-trunk sid Armbian 23.08.0-trunk sid Kernel : 6.6.10-edge-rockchip64 VM Type : NONE IPv4/IPv6 : ✔ Online / ❌ Offline fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/mmcblk1p1): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 1.82 MB/s (457) | 8.12 MB/s (126) Write | 1.85 MB/s (463) | 8.51 MB/s (133) Total | 3.68 MB/s (920) | 16.63 MB/s (259) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 12.39 MB/s (24) | 12.48 MB/s (12) Write | 13.51 MB/s (26) | 13.74 MB/s (13) Total | 25.90 MB/s (50) | 26.23 MB/s (25) gnome disk utility read benchmark (just defaults) Cool got some tiny gains on everything but 4k block after UHS enabled 6.6.10 yabs # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## # # Yet-Another-Bench-Script # # v2024-01-01 # # https://github.com/masonr/yet-another-bench-script # # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## # Sat Jan 6 06:05:48 PM EST 2024 ARM compatibility is considered *experimental* Basic System Information: --------------------------------- Uptime : 0 days, 0 hours, 0 minutes Processor : Cortex-A53 Cortex-A72 CPU cores : 6 @ 1512.0000 2016.0000 MHz AES-NI : ✔ Enabled VM-x/AMD-V : ❌ Disabled RAM : 3.7 GiB Swap : 1.9 GiB Disk : 57.5 GiB Distro : Armbian 23.08.0-trunk sid Armbian 23.08.0-trunk sid Kernel : 6.6.10-edge-rockchip64 VM Type : NONE IPv4/IPv6 : ✔ Online / ❌ Offline fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/mmcblk1p1): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 1.85 MB/s (464) | 8.81 MB/s (137) Write | 1.88 MB/s (471) | 9.32 MB/s (145) Total | 3.74 MB/s (935) | 18.14 MB/s (282) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 13.06 MB/s (25) | 13.64 MB/s (13) Write | 14.38 MB/s (28) | 15.23 MB/s (14) Total | 27.44 MB/s (53) | 28.87 MB/s (27) gnome disk utility read benchmark (just defaults) View the full article

Description Debian sid desktops have been failing to build for a while due to a dependency issue with ghostscript-x this package has been abandoned... or mostly abandoned.. see Debian Bug #1022718 Removed package from base desktop package lists... Resolves error message below The following packages have unmet dependencies: ghostscript-x : Depends: ghostscript (= 10.01.2~dfsg-1) but 10.02.1~dfsg-1 is to be installed E: Unable to correct problems, you have held broken packages. tested with ./compile.sh build BOARD=pinebook-pro BRANCH=edge BUILD_DESKTOP=yes \ DESKTOP_APPGROUPS_SELECTED='3dsupport browsers internet multimedia' DESKTOP_ENVIRONMENT=cinnamon \ DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base RELEASE=sid View the full article

Normally when you have installed a XFCE-Desktop image for the Pinebook A64 you could set the display brigthness with the following pkexec command to a readable higher level - like I did in the past (possible brightness values are 1-10 - on startup this is only set to 2): pkexec /usr/sbin/xfpm-power-backlight-helper --set-brightness 8 read-out command for the current value: pkexec /usr/sbin/xfpm-power-backlight-helper --get-brightness but on standard CLI-install pkexec and xfpm-power-backlight-helper are missing, so to use this command-line (in /etc/rc.local) you have to install these 2 packages: sudo apt install xfce4-power-manager pkexec

Hello, as already mentioned in topic USB C port doesn't work after upgrading to the latest kernel 6.6.2 . The previous problem with not working left usb 3 port persist no more. Everything is fine. As I remember , before update the usb c port has worked with the adapter and the devices like mouse, usb flash etc. Now it doesn't work any more, furthermore it gives no signal of life. There is 0 amps current measured, also dmesg -W gives no output at all after plugging in the device. PS: I was unable to upload the report file, also the service paste.armbian.com doesn't work at the moment.

hi, make sure you have all the kernel modules in your initramfs as listed here: https://github.com/NixOS/nixos-hardware/blob/master/pine64/pinebook-pro/default.nix i had the same issue with my archilnux installation until i included all of them

I bought a Pinebook Pro two weeks ago. It came with Manjaro KDE preinstalled on EMMC. I wanted to try out Armbian, so I downloaded the Bookworm XFCE image from May 27th. In order to get the SD booted, I first flashed Tow-Boot for Pinebook Pro (pine64-pinebookPro-2021.10-005.tar.xz) from github Tow-Boot to the SPI. Then during boot after pressing ESC the menu lets you select the SD card for boot. The first boot to Armbian worked well. I could set up user, timezone and everything. The XFCE desktop looks very clean with a reasonable selection of software. Well done, team! But after I upgrade the system with apt update & upgrade, the next time the machine is booted and SD card is selected, armbian won't boot anymore 😞 The upgrade seem to have broken something. I tried it twice, the second time freezed the kernel-upgrades in the armbian-config tool prior to upgrading it. Didn't help. Manjaro from EMMC still boots ok. Attached is a screenshot of the failed boot process, after I selected SD card to boot on the Tow Boot menu.

I slowly convinced myself that I wanted a PineBook Pro, some time after the first production run. But then COVID, parts shortages, etc. happened and they were not available again until about mid-2022. But when they were, I decided to snap one up. And since then I have not been able to get it to boot Armbian. It came from the factory with Manjaro, which for me being a Debian guy, might as well be useless. So the PBP sat around collecting dust. Since then I have tried a few times to get it to work. I read many forum posts, tried some things. I won't document all that in detail. In this post, I will continue from where I left off here. However to summarize, that was about comparing DTB/DTS files to Kali, which supposedly works. That may become useful later, but I don't think that's the main problem. I think that the main problem is that this new batch came from the factory with no bootloader flashed to the included SPI flash chip. This is a problem on PineBook Pro because the RK3399 has a kind of weird boot order: SPI, eMMC, SD card. Therefore, if you just put in some SD card you flashed, it still boots from the factory Manjaro from the eMMC. Whatever bootloader they are using also apparently will not recognize an otherwise working Armbian image on an SD card. Now, because of the weird boot situation, there is supposed to be a switch to turn off eMMC. However this did not work for me. Which means one of 2 things: The switch does not work. I read at least one other person saying this. Also on the new revision, it's in a slightly different place than the old revision (may be a clue, maybe not). I simply had a bad Armbian image (which I had burned to sd card) that would not boot for whatever reason.[0] But let's put that aside for a moment. As I still think the main problem is the (empty) SPI. And that will be the easiest/best path forward. I confirmed the 'blank SPI' theory 2 different ways. First, as mentioned in a follow-up to the linked post (4 paragraphs above): As Martijn Braam states here: Of course, I like to beat a horse until it's really dead be thorough in my investigations, so today I wasted a lot of time[1] verifying that this indeed was the case. I did so by dd'ing the /dev/mtd0 block device into a file[2]. When I examined the file, it contained all FF, and also it is about 16 MiB in size. To me this confirms that indeed, the SPI on the new batch comes from the factory empty. So what is next? I keep reading that the only people who had success first had to install something like tow-boot to the SPI. That will be my next step. But before I flashed anything to SPI, I wanted to see what really came from the factory (which I did above). I will continue to document my progress whenever time allows for me to work on this. [0] Once I got the bootloader situation sorted, I later used this same image (on the SD card) to boot and install Armbian, so I do not think this was the case. [1] In the end the solution was simple. But first I wasted a lot of time trying to get rkdeveloptool working in Manjaro on the PBP. Only to realize it's intended to be used from a second machine to read the SPI flash via USB in maskrom mode. Anyway, lesson learned. [2] I tried to attach it but maybe it's too big.

Hi, I put the image on an SD card, but the machine fails to boot. Looking at the serial console, it just sits in a loop with the CPU constantly resetting after an exception. Serial console log is attached. Regards, Dianne. bootloop.txt

Hi all, I have a working Pinebook Pro Focal build with LUKS encryption enabled. The only issue I have is that when booting no progress or password prompt is displayed. As soon as I enter the password and hit enter I see the boot logo or console output depending on what is set in armbianEnv.txt. I will be continuing my research and learning about the boot process in general but wanted to check in here to see if people had any obvious pointers to share or whether maybe this is a known limitation that is going to be hard to resolve. Thanks, Matt

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 (plus possibly others—follow the comments in this thread for additional info): Orange Pi PC2 Debian Buster mainline / Ubuntu Focal legacy RockPi 4 Debian Trixie mainline / Ubuntu Focal legacy RockPro 64 Ubuntu Focal mainline Odroid HC4 Debian Buster mainline / Ubuntu Focal mainline Pinebook Pro Debian Bookworm current minimal Rock Pi 4A+ Unknown Pine A64 Unknown Orange Pi 5 Debian Bookworm mainline / Ubuntu Noble mainline minimal Rock 5B Debian Trixie mainline Nano Pi M6 Noble mainline minimal / Noble Gnome desktop vendor Raspberry Pi 5** Debian Trixie minimal (see note) Banana Pi F3 Debian Trixie mainline minimal / Ubuntu Noble vendor minimal * Boards/images in bold blue type are personally tested by the author. Others may have issues or require additional steps provided by users below. ** For instructions on how to adapt this tutorial for the Raspberry Pi, see here (instructions are provided by a third party and are untested by the author). 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, an 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 (the “target device”). If the board has an eMMC, it may be used as the target device instead of an SD card. Depending on your platform, you may need to run “armbian-install” and select “Install/Update the bootloader on MTD Flash” (preferable) or “Install/Update the bootloader on eMMC” to enable booting from the eMMC. 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 package # apt update && apt upgrade # apt install cryptsetup 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 Start End Sectors Size Type /dev/loop0p1 32768 61931519 61898752 29.5G Linux filesystem 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 target device If applicable, insert a blank micro-SD card and card reader into a USB port. Determine the target 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 be something like '/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. Determine whether your image has a GPT partition table or a legacy MBR (i.e. DOS) one. This can be done by running fdisk -l on the image file and examining the “Disklabel type” entry. For GPT images, also make note of the value in the “Type” column. On ARM devices, it’s likely to be “Linux root (ARM-64)”, for example. You’ll need this information soon when partitioning the target device: # fdisk -l *.img Copy the image’s boot loader to the target device. With MBR-partitioned images, we use the Start sector value from Step 4 as the argument for 'count', while with GPT ones we skip the first 64 sectors and correspondingly subtract 64 from 'count', reducing the number of copied sectors by 64: ### MBR (DOS) images: # dd if=$(echo *.img) of=/dev/sda bs=512 count=32768 ### GPT images: # dd if=$(echo *.img) of=/dev/sda bs=512 skip=64 seek=64 count=32704 Step 6 - Partition the target device # fdisk /dev/sda At the fdisk prompt, create a new disk label with the 'o' command (for MBR images) or 'g' (for GPT images). Use the 'n' command to create a partition of size +400M beginning at the same Start sector as the disk image (for MBR images, select the “primary” partition type). Type 'p' to view the partition table, which should now look something like this: Device Start End Sectors Size Type /dev/sda1 32768 851967 819200 400M Linux root (ARM-64) Use 'n' again to create another partition beginning one sector after the first partition’s end sector and filling the remainder of the device (for MBR, select “primary” again). Type 'p' once more to view the partition table: Device Start End Sectors Size Type /dev/sda1 32768 851967 819200 400M Linux root (ARM-64) /dev/sda2 851968 120829951 119977984 57.2G Linux root (ARM-64) 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 (851967 and 851968, respectively, in this example). If you’ve made a mistake, use 'd' to delete a partition and start again. With GPT images, you’ll need to change the partition type of your two partitions to match that of the image. Type 'l' to list the known partition types and find the entry matching the value of the “Type” column you made note of above. Note the entry’s integer code and exit the pager with 'q'. Using the 't' command, change the type of your two partitions using this code. Type 'p' once again to view the partition table, which should now look something like this (depending on your platform): Device Boot Start End Sectors Size Id Type /dev/sda1 32768 442367 409600 200M 83 Linux root (ARM-64) /dev/sda2 442368 30636031 30193664 14.4G 83 Linux root (ARM-64) Once everything looks correct, type 'w' to write the partition table to disk. Step 7 - Copy the system to the target device The following commands will create a filesystem on the target device’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 will be something like '/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: If the file 'boot/armbianEnv.txt' exists, edit it 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 If your image lacks an 'armbianEnv.txt' file, you’ll need to edit the file 'boot/extlinux/extlinux.conf' instead. All changes will be made to the line beginning with “append”. Alter the argument beginning with “root=” so that it reads “root=/dev/mapper/rootfs”. If you’ll be unlocking the disk via the serial console, remove the “console=tty1” argument. If not, remove the argument beginning with “console=ttyS...”. Replace the “splash plymouth...” argument with “splash=verbose”. Make sure to read the note about unlocking via serial console in the previous step. 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::end0:off If the board will be configured via DHCP, then edit the DEVICE line as follows: DEVICE=end0 If your default network device has a different name, say eth0, then use that instead of end0. The device name can be discovered by issuing the command ip link and looking for the device labelled link/ether. 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 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. Create 'etc/crypttab': # echo "rootfs UUID=$ROOT_UUID none initramfs,luks" > etc/crypttab 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 Create the dropbear configuration file: # echo 'DROPBEAR_OPTIONS="-p 2222"' > etc/dropbear/initramfs/dropbear.conf # echo 'DROPBEAR=y' >> etc/dropbear/initramfs/dropbear.conf 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 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 Now regenerate your SSH host keys: # ssh-keygen -A 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!

recent days I find Chromebook may be better Arm devices with laptop form factor. compare with Pinebook pro, Chromebooks are cheaper, and mass product, and better tested. why no much people discuss how to install 3rd OS to its internal emmc, or reflash its uboot? I have searched on ArchArm forum, only 1 topic. but there actually a way to reflash uboot, and mainline uboot already has support for arm based chromebooks. It should be easy, but why no discussion?