An unofficial Debian Installer for Pinebook Pro

[danielt]

I've recently spent a little while hacking together a quick 'n dirty Debian installer for the Pinebook Pro.

https://github.com/daniel-thompson/pineb...-installer


It is not a fully fledged installer... just some code that run on the Pinebook Pro itself using an existing Debian (or maybe Ubuntu) distro. It will install an operating system from scratch to an alternative media. Nevertheless it is a "real" installer in that sense that there is no downloadable image, no default password and you get to choose the keyboard layout, locale, timezone and desktop environment for yourself!

It uses upstream Debian packages for everything except the kernel and bootloaders. Actually... on that subject I deserve no credit for the kernel (which is the v5.4 close-to-mainline kernel that @tsys has has been hacking on) or the bootloaders (which are simply the binaries from @Mrfixit2001 's update repo).

So far I have only used it to author SD cards (from a distro running from eMMC) however it has been tested with the eMMC disabled so we can be confident the bootloaders work. That means that, in principle, it is also suitable for installing to eMMC when running from SD card. I've also only tested text mode and the Gnome desktop environment (wayland, panfrost, gnome 3.34).

One interesting feature of this installer is that it is trivial to switch from arm64 (default) and armhf (add ARCH=armhf to the make command line). This allows you to run identical distros with the two different instruction sets... which could make for some interesting benchmarks if someone wants to make them.

Check out the Pine64 wiki for feature status, known issues and workarounds.

---

2019-12-14: Partial LUKS rootfs support, automatic kernel updates, enable audio DAC by default, faster boot times.

---

2019-12-31: Rewrite as a shell script, automatic unmounting on error, better co-existance of installs to different media on the same machine (e.g. micro SD and eMMC installs).

---

2020-01-21: In response to user requests, @e-minguez created a wiki page (above) to share features status, known issues and workarounds. Please contribute and help keep it up to date! Note that if you have a forum login then you already have a wiki login.

---

2020-02-14: Wow! Over 250 posts about a relatively humble bit of code. To be clear this thread is still the best place to discuss and seek support. There's no need to read all the posts... after reading *this* post perhaps skip to the end and only read the last three pages or so to find out what issues people currently care about most!

---

2020-03-02: Kernel updated to v5.5 (which will also be delivered to existing installs via apt upgrade), direct installation of buster is supported  (and documented) RELEASE=buster is now an install option, installed some extra firmware to help with BT, update to latest u-boot and made it easier to disable panfrost if needed.

[Arwen]

@danielt, Perhaps you know.

Is there a way to create an ARM multi-arch / multi-lib version of any Linux distro?

Before AMD's 64 bit architecture became common, most Linux distro that support x86_64, were multi-library. After that transistion period was over, and x64 become dominant, some like me never bothered to disable x86 compatibility.

[danielt]

@danielt, Perhaps you know.

Is there a way to create an ARM multi-arch / multi-lib version of any Linux distro?

Before AMD's 64 bit architecture became common, most Linux distro that support x86_64, were multi-library. After that transistion period was over, and x64 become dominant, some like me never bothered to disable x86 compatibility.

I think it is different for different distros since when all the fluff is stripped away it basically means careful packaging (to allow parallel install of libraries by using different directories) and a package manager that can cope with multiple architectures. Thus the answer may change depending on your choice of distro.

Debian is pretty good in that regard. For example with the benefit of qemu-user I am currently running a arm64 base system but enriched with some amd64 libraries (just enough to run the x86-64 binaries found in rkbin/tools/ and permit me to build u-boot on Pinebook Pro). These days Debian is well separated so you can do all sorts of crazy things with qemu and binfmt to allow alien binaries to run. The only problem I've seen is that you can't run pair armhf and i386 as multi-arch because they both use the same filename for their dynamic linker.

More practically I also did a simple test on an SD card freshly installed with my installer to try running an armhf 32-bit browser within an OS that is mostly arm64 (epiphany is installed to stop the removal of firefox from dragging away too much with it):

Code:

sudo apt install epiphany-browser
sudo apt remove firefox-esr
sudo dpkg --add-architecture armhf
sudo apt update
sudo apt install firefox-esr:armhf

Finally be aware that even if you can't get multi-arch working as you would like it to then you can probably use containers to work around it. For example if you are running a 64-bit kernel then you can host a arm64 LXC containers in armhf distros and vice versa.

[Arwen]

Thank you, that was what I was looking for.

[Solra Bizna]

Tried using your installer from a booted mrfixit image to prepare a bootable SD card. And it...

...

...worked perfectly, with no problems at all. Not even a single piece of questionable stray terminal output.

Nice!

[xmixahlx]

thank you for sharing your project script. I await delivery of an ANSI PBP and was going to do basically exactly this! your work is appreciated very much.

I also see you have crypt/luks references. this will be my focus as well. I suspect that providing a new kernel build and crypt support in the installer, as well as swap, will check all boxes for me (and I assume many others...)

debian sid is my preference. What are you using?

looking forward to a minimalist debian netinst experience on PBP!

[danielt]

I also see you have crypt/luks references. this will be my focus as well. I suspect that providing a new kernel build and crypt support in the installer, as well as swap, will check all boxes for me (and I assume many others...)

debian sid is my preference. What are you using?

looking forward to a minimalist debian netinst experience on PBP!

LUKS is now working. I hacked together basic support for encrypted rootfs yesterday evening (although I didn't document it yet because the code that implements is isn't very nicely written):
https://github.com/daniel-thompson/pineb...r/issues/1

The big gotcha is that in order to install to a luks partition you need crypto support in the kernel you are running the installer from. The original stock kernel did not include support for this and I have not yet tested it on a system that has been upgraded to v1.6. Success reports welcome (and thanks to @Solra Bizna for the one already shared) since if I get enough of these I can delete the "not tested enough" from the list of limitations ;-) .

The installer will install Debian Bullseye  (testing) but other than the kernel and firmware everything is pure Debian so the classic upgrade path should "just work" (update sources.list, update, upgrade, dist-upgrade)... and if it doesn't you can rely on the usual Debian Unstable warranty: if it breaks: you get to keep both parts :-) . Alternatively you can hack the installer: make clean && sed -ie 's/bullseye/sid/' Makefile etc/apt/sources.list should get you most of the way there although I think you might also have to remove security and updates from sources.list .

[xmixahlx]

thanks for the reply. I impatiently await my PBP and will follow along with your progress. T.T

oh, and I hope to run on a solo nvme when that is fixed...

[Jeremiah Cornelius]

LUKS is now working. I hacked together basic support for encrypted rootfs yesterday evening (although I didn't document it yet because the code that implements is isn't very nicely written):
https://github.com/daniel-thompson/pineb...r/issues/1

The big gotcha is that in order to install to a luks partition you need crypto support in the kernel you are running the installer from. The original stock kernel did not include support for this and I have not yet tested it on a system that has been upgraded to v1.6. Success reports welcome (and thanks to @Solra Bizna for the one already shared) since if I get enough of these I can delete the "not tested enough" from the list of limitations ;-) .

The installer will install Debian Bullseye  (testing) but other than the kernel and firmware everything is pure Debian so the classic upgrade path should "just work" (update sources.list, update, upgrade, dist-upgrade)... and if it doesn't you can rely on the usual Debian Unstable warranty: if it breaks: you get to keep both parts :-) . Alternatively you can hack the installer: make clean && sed -ie 's/bullseye/sid/' Makefile etc/apt/sources.list should get you most of the way there although I think you might also have to remove security and updates from sources.list.

This is my dream list. Unfortunately I haven't my PBP delivery yet, and you've moved so quickly before I've had opportunity to contribute!

Is there a dummy kernel package for pinning, or is that not even really necessary?
Maybe a PPA for the Debian packaged kernel and headers/source packages would be worth starting? Some frown on PPA, I know. I build so much for Deb/Ubu/Pop on Intel, it might be worth me taking up these and kernels, once my feet are wet with the machine.

[danielt]

This is my dream list. Unfortunately I haven't my PBP delivery yet, and you've moved so quickly before I've had opportunity to contribute!

Is there a dummy kernel package for pinning, or is that not even really necessary?
Maybe a PPA for the Debian packaged kernel and headers/source packages would be worth starting? Some frown on PPA, I know. I build so much for Deb/Ubu/Pop on Intel, it might be worth me taking up these and kernels, once my feet are wet with the machine.

The kernel is handled by the package manager (it's just a ` make bindeb-pkg` from the kernel build system though) with a tiny hack thrown in to ensure the kernel is uncompressed when it is installed to /boot (the u-boot distro boot protocol doesn't work with compressed kernels).

However the kernel is just a download rather than a proper apt repo so there is no kernel upgrade path. A PPA is a good idea although hopefully it can be obsoleted even more quickly than my installer: providing the fuel guage driver and the panel-simple update get upstreamed this cycle PPA can be obsolete as soon as Debian adopts v5.6 kernel!