An unofficial Debian Installer for Pinebook Pro

[moonwalkers]

Thanks for your work on this, danielt! I'm happily running Debian Buster now off a microSD card.

Question regarding the `bootloader` Git submodule: It is now pointing to mrfixit2001's branch v1.5, which is not the latest available. Did you choose that branch for any particular reason? I created my microSD card using branch v1.9 (by manually checking it out, and commenting out the `git submodule update --init` command in the install script) and everything seems to be working just fine.

Hmm, I've tried installing v2.0 and can report happy results - while booting with all six cores enabled still takes some extra time, it is now almost an order of magnitude faster than before with v1.5.

[rlc]

Hi there,
I've got up-to-date installation on my eMMC:

root@joyce> uname -a
Linux joyce.n1.pinyon.org 5.5.0-1-pinebookpro-arm64 #1 SMP PREEMPT Sat Feb 22 17:10:06 UTC 2020 aarch64 GNU/Linux

I few weeks ago I futzed around with a variety of window managers because my 25 year partner, FVWM, is just too slow.  I settled on MATE.  Looks pretty good, but somehow X stopped working.  The current error in /var/log/Xorg.1.log is:

[  1513.672] (II) event1  - gpio-keys: device is a switch device
[  1515.715] (EE)
[  1515.715] (EE) Backtrace:
[  1515.715] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x188) [0xaaaacc1288a0]
[  1515.716] (EE) unw_get_proc_info failed: no unwind info found [-10]
[  1515.716] (EE)
[  1515.716] (EE) Segmentation fault at address 0xaadad44f3ba8
[  1515.716] (EE)
Fatal server error:
[  1515.716] (EE) Caught signal 11 (Segmentation fault). Server aborting
[  1515.716] (EE)
[  1515.716] (EE)
Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
[  1515.716] (EE) Please also check the log file at "/var/log/Xorg.1.log" for ad
ditional information.
[  1515.716] (EE)
[  1515.716] (II) AIGLX: Suspending AIGLX clients for VT switch
[  1515.742] (EE) Server terminated with error (1). Closing log file.

This is root running 'startx'.

As you can see from the timestamp it actually gets really far.  The full MATE desktop
is visible for about 1s before crashing.  When I was exploring window managers
I did quite a bit of inadvertant uninstalls of lower level X/gl/mesa sorts of packages,
but I have been extremely diligant about searching for  something missing, or a conflict, and I can't find it.

So I am hoping someone has an idea.

Thanks!

---

So after post I discovered the topic "mesa-git build script for latest panfrost", ran the script, and ran startx and up came the desktop.

https://forum.pine64.org/showthread.php?tid=8953

Hooray!

[xmixahlx]

glad mesa-git works for you.

regarding WM/DM, give xfce4, ice wm and sway a try. i primarily use sway and it is imho the best experience on pbp.

[danielt]

Thanks for your work on this, danielt! I'm happily running Debian Buster now off a microSD card.

Question regarding the `bootloader` Git submodule: It is now pointing to mrfixit2001's branch v1.5, which is not the latest available. Did you choose that branch for any particular reason? I created my microSD card using branch v1.9 (by manually checking it out, and commenting out the `git submodule update --init` command in the install script) and everything seems to be working just fine.

Hmm, I've tried installing v2.0 and can report happy results - while booting with all six cores enabled still takes some extra time, it is now almost an order of magnitude faster than before with v1.5.

Thanks for the feedback.

I haven't experimented with removing the maxcpus= workaround yet but I have updated to v2.0 in the latest (2020-03-02) release. See first post for other changes.

[Jeremiah Cornelius]

After the initial set up I wanted to create a root account so it is like my factory Debian. In a terminal I created it by using ($ passwd root) gave it a password and confirmed that it worked by switching accounts in terminal with ($ su root). When I log out of the DE then relogin and this time select different user it won't accept my password for root but it works while in terminal. Did I set this up incorrectly? Also I noticed that when in terminal as normal user I have to click the x in the top right corner to close terminal but while using root in terminal as soon as my mouse hovers over the x to close, it automatically logs out of DE causing me to sign back in. I'm still noobish but that doesn't seem right. Does this happen to anyone else?

If your graphical login is via GDM, then there are GDM policies with PAM restrictions that deliberately block a root login to full X/Wayland sessions. This is normal, and good - it discourages the *nix "worst practice" of general user operations by root.

If you must have a root desktop - and they do sometimes have utility - there are 2 things to do on Debian 10:
1 — Edit (as root/sudo) /etc/gdm3/daemon.conf. In the section for security add the stanza:

Code:

[security]
AllowRoot=true

2 — Edit (as root/sudo) /etc/pam.d/gdm-password”. Comment out the line containing “auth required pam_succeed_if.so user != root quiet_success”:

Code:

# auth required pam_succeed_if.so user != root quiet_successSave the file and exit.

This is more or less the same for Ubuntu and other Debian derivatives. Probably also Manjaro, etc. as I can't see that their different packagers would much deviate for PAM policies, etc.

[FeMike]

After the initial set up I wanted to create a root account so it is like my factory Debian. In a terminal I created it by using ($ passwd root) gave it a password and confirmed that it worked by switching accounts in terminal with ($ su root). When I log out of the DE then relogin and this time select different user it won't accept my password for root but it works while in terminal. Did I set this up incorrectly? Also I noticed that when in terminal as normal user I have to click the x in the top right corner to close terminal but while using root in terminal as soon as my mouse hovers over the x to close, it automatically logs out of DE causing me to sign back in. I'm still noobish but that doesn't seem right. Does this happen to anyone else?

If your graphical login is via GDM, then there are GDM policies with PAM restrictions that deliberately block a root login to full X/Wayland sessions. This is normal, and good - it discourages the *nix "worst practice" of general user operations by root.

If you must have a root desktop - and they do sometimes have utility - there are 2 things to do on Debian 10:
1 — Edit (as root/sudo) /etc/gdm3/daemon.conf. In the section for security add the stanza:

Code:

[security]
AllowRoot=true

2 — Edit (as root/sudo) /etc/pam.d/gdm-password”. Comment out the line containing “auth required pam_succeed_if.so user != root quiet_success”:

Code:

# auth required pam_succeed_if.so user != root quiet_successSave the file and exit.

This is more or less the same for Ubuntu and other Debian derivatives. Probably also Manjaro, etc. as I can't see that their different packagers would much deviate for PAM policies, etc.

Thank you you've been most helpful.

[Jeremiah Cornelius]

Thank you you've been most helpful.

Gladly!

[moonwalkers]

Thanks for the feedback.

I haven't experimented with removing the maxcpus= workaround yet but I have updated to v2.0 in the latest (2020-03-02) release. See first post for other changes.

Speaking of the hedgehogs - the new 5.5 kernel build is the first one I've seen to panic on PBP. I haven't yet been able to figure out what triggers the panic, but it seems to be more likely to happen when I just leave the laptop alone to eventually fall asleep. Can't provide much details about the panic itself either - I got the USB-to-UART cable only yesterday and haven't had time to play around with it yet.

[moonwalkers]

I haven't experimented with removing the maxcpus= workaround yet but I have updated to v2.0 in the latest (2020-03-02) release. See first post for other changes.

After running v2.0 with your 5.5-1 build for a while I can say that without maxcpus= workaround it takes between 10 and 15 seconds for me to see screen come to life after pressing power button. If the price of not having workarounds with nasty security implications is a mere 10 seconds of extra boot time I'm perfectly fine with paying it.

[danielt]

I haven't experimented with removing the maxcpus= workaround yet but I have updated to v2.0 in the latest (2020-03-02) release. See first post for other changes.

After running v2.0 with your 5.5-1 build for a while I can say that without maxcpus= workaround it takes between 10 and 15 seconds for me to see screen come to life after pressing power button. If the price of not having workarounds with nasty security implications is a mere 10 seconds of extra boot time I'm perfectly fine with paying it.

The option turned off in the v5.4 was pretty theoretic; it is designed to prevent a hostile virtualized kernel from learning at what address the host kernel had been mapped (and there would have to be another security hole in the hypervisor for that info to be useful). The security implications certainly weren't all nasty or I wouldn't have turned them off! IMHO browsing the web is a *much* more signficant security risk.

Anyhow when looking at v5.5 I realized there was another errata that I wasn't happy to disable so I force both workaround to deploy even when maxcpus=4. In other words the HARDEN_EL2_VECTORS is reenabled in v5.5 and will deploy in both cases. around the problem in a different way and all the security features are enabled again in v5.5.