General feedback

I just opened my account on your forum.
Owner of Pinebook 11" and I could not stand the sluggish KDE they installed so I eventually downloaded many distro they proposed on their wiki until yours showed up in the list and I remembered using it on a raspberry long ago.

It rocks on the pinebook! So, thanks to the whole team responsible for this release.

Hopefully I’ll understand how to install it on the embedded storage in place of the SD card one day.

Oh wow! Didn’t know pinebook was so neat inside!

I would SO hack this sucker…probably even pull the USB case off…then open it up…solder down wires to the USB (on the expansion board on the left) and make it an “internal” USB so not to have a huge block hanging out of it…and use it like that.
I would wrap the USB pendrive w/o case in kapton or 18650 heatshrink tubing to prevent shorts)

Looks like there is PLENTY of room to do that

There should be a way to mount thru dietpi-drive_manager and install it to emmc (find the docs before you try)

A 16 GB eMMC module is visible, up and right from the CPU. You can pick up replacements for the module—ranging in size from 8 GB to 64 GB—on the Pine store. The module is user-replaceable. Reportedly read speeds up to 80 MB/s and write speeds up to 40 MB/s are being seen with the module. The Pinebook is able to boot from both the internal eMMC or an external micro SD Card.

The thing I am wondering is where is the heatsink? Does the bottomside of the keyboard act as the heatsink?

Thank you very much for the positive feedback.

About how to boot from eMMC:

Is it possible to plug off the eMMC? In this case you could plug into you PC/notebook either via USB-eMMC or (micro)SD-eMMC adapter. The latter at least is usually available for around 1-2 euro/dollar/pounds.
E.g. What Hardkernel offers:

If a fresh image is okay, you can also download the DietPi image to the Pinebook running system and flash it from there to the eMMC drive.

If you don’t want to start from fresh flash, you can clone the SDcard content to eMMC from an external system by plugging both, the SDcard and the eMMC module and use the dd command from a linux system. Not sure how to achieve from Windows, but there will be some tools available as well.

Then you need to tell the system to boot from eMMC, from the Pine64 Wiki e.g.:

  • Set or add to /boot/uEnv.txt: rootdev=/dev/mmcblk1p1
  • In /etc/fstab, change mmcblk0p1 to mmcblk1p1.

This assumes the eMMC module is available as /dev/mmcblk1 with root partition /dev/mmcblk1p1. Actually it’s better to use the drives UUID or PARTUUID instead of using the /dev paths, but either should work.

Finally plug off the SDcard and boot the Pinebook.


  • The fourth bullet point there: “To run the OS on eMMC”

They have a guide to remove the EMMC.

I guess I’d need some sort of adapter like the one you listed from Hardkernel.

I was wondering if I could boot from dietpi, download its image (my µSD being 32GB big) then dd’ing it to the EEMC.

Ah jep great.

But as said, if you are okay to start with a fresh image (or simply test this, performance differences and such), you can flash the new image from the running (SDcard) system to the eMMC drive. Perhaps this is the better start, also to verify, it’s working well, before buying the adapters, opening the Pinebook case and all that. You can always clone/flash your current system from SDcard to eMMC on the external system at a later time.

Then I’ll go that route.
Dietpi is way better than what they provide by default and I haven’t personnalized my µSD that much yet, only installed Windowmaker and configured the WIFI connectivity. Not such big of a deal to start again.
Especially if the eMMC allows me better performances.

DD to the eemc worked well and it is very fast compared to the µSD.
But then there is an issue with Kernel 4.20 of the last upgrade corrupting the OS, preventing it to boot.

Ui, you mean a simple APT upgrade installs Linux kernel v4.20? Unusual since this is not yet marked as very stable, most boards are on v4.14, the lastest LTS version.

In attempt to debug the issue: Do you have some copy&paste or screens from the error messages/boot log where it hangs?

You can prevent APT packages from upgrading by setting them on hold:

apt-mark hold <package>

But I am not sure about the kernel package for the Pinebook.

Check to identify:

dpkg -l | grep '^linux'

I overwrote the install with the current dietpe release so I do nto have any log, I can replicate the update that will force me to reinstall anew. After the reboot though I won’t be able to copy paste as the system won’t simply finish its boot process.

I’ll do just that… Back in a couple of minutes…

If you have a chance, could you take a picture (from mobile phone e.g.) from the screen when boot stuck?

Jep and errors from the update would be good.

I did some research and it seems that initramfs-tools are not required for uboot-based Pine64 devices, same on RPi.

You could try:

apt purge initramfs-tools

Carefully watch which other packages it wants to remove. If there is a linux kernel package removed, cancel, otherwise it should be save.
But this would only help if your error is indeed related to this package and not some other bootloader related trigger created the initramfs.

indeed it fails on initramfs:

Setting up systemd-sysv (232-25+deb9u8) …
Setting up libtiff5:arm64 (4.0.8-2+deb9u4) …
Setting up linux-dtb-dev-sunxi64 (5.70) …
Setting up libssl1.0.2:arm64 (1.0.2q-1~deb9u1) …
Processing triggers for libc-bin (2.24-11+deb9u3) …
Setting up udev (232-25+deb9u8) …
addgroup: The group `input’ already exists as a system group. Exiting.
update-initramfs: deferring update (trigger activated)
Setting up firefox-esr (60.4.0esr-1~deb9u1) …
Setting up libssl1.1:arm64 (1.1.0j-1~deb9u1) …
Setting up openssl (1.1.0j-1~deb9u1) …
Processing triggers for dbus (1.10.26-0+deb9u1) …
Processing triggers for hicolor-icon-theme (0.15-1) …
Setting up libpolkit-gobject-1-0:arm64 (0.105-18+deb9u1) …
Setting up libpam-systemd:arm64 (232-25+deb9u8) …
Setting up libpolkit-agent-1-0:arm64 (0.105-18+deb9u1) …
Setting up libpolkit-backend-1-0:arm64 (0.105-18+deb9u1) …
Setting up policykit-1 (0.105-18+deb9u1) …
Removed /run/systemd/system/polkit.service.
Processing triggers for initramfs-tools (0.130) …
update-initramfs: Generating /boot/initrd.img-4.20.0-sunxi64
/etc/initramfs/post-update.d//99-uboot: 3: .: Can’t open /etc/armbian-release
run-parts: /etc/initramfs/post-update.d//99-uboot exited with return code 2
dpkg: error processing package initramfs-tools (–configure):
subprocess installed post-installation script returned error exit status 1
Processing triggers for libc-bin (2.24-11+deb9u3) …
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)

root@DietPi:~# dpkg -l | grep linux
ii console-setup-linux 1.164 all Linux specific part of console-setup
ii libselinux1:arm64 2.6-3+b3 arm64 SELinux runtime shared libraries
ii linux-base 4.5 all Linux image base package
ii linux-dtb-dev-sunxi64 5.70 arm64 Linux DTB, version 4.20.0-sunxi64
ii linux-image-dev-sunxi64 5.70 arm64 Linux kernel, version 4.20.0-sunxi64
ii linux-stretch-root-dev-pinebook-a64 5.67 arm64 Armbian tweaks for stretch on pinebook-a64 (dev branch)
ii linux-u-boot-pinebook-a64-dev 5.67 arm64 Uboot loader 2018.11-rc3
ii util-linux 2.29.2-1+deb9u1 arm64 miscellaneous system utilities

I’ll reboot and post a photographic of the result.

Thanks for this. I think I found the issue:

Currently not sure, but it seems to our image is build on top of an ARMbian base image.

update-initramfs: Generating /boot/initrd.img-4.20.0-sunxi64
/etc/initramfs/post-update.d//99-uboot: 3: .: Can't open /etc/armbian-release
run-parts: /etc/initramfs/post-update.d//99-uboot exited with return code 2

ARMbian seems to have placed a custom post-update trigger that searches for /etc/armbian-release, which is not present on the DietPi image. Failing that, the created initramfs seems to be not placed into /boot, while the old was already removed.

Please check ls -Al /etc/initramfs/post-update.d/ and sub directory content. Not sure if some part of the path is hidden in the log, otherwise:

cat /etc/initramfs/post-update.d/99-uboot

Please paste the content of this.

I will raise an issue on GitHub about this:

Do I remember right, that the Pinebook image was the first after long time based on ARMbian again? We really have to take care their custom system adjustments. Sadly they do not add any hint via file name. For this reason the aim to name all our config files dietpi-* to make it easy to identify what’s from the base image, what from APT packages and what from us :slight_smile:.

Ah lol Fourdee already implemented a fix for this issue some days ago:

cat << _EOF_ > /etc/armbian-release
BOARD_NAME="Pinebook A64"

But I still believe there is a more native/elegant version by removing the APT trigger from ARMbian. However the above at least is proven to solve the APT upgrade issue.

Daggum, I want to get me one of those now to mess around with…too bad there isn’t a way to expand the RAM…