An unofficial Debian Installer for Pinebook Pro

[Solra Bizna]

Would you mind sharing the specifics of how you tuned zswap? As well as your typical/max VM usage. Maybe you just figured out the right combination of tunables I couldn't, or maybe my SSD was no longer as fast as it used to be. But I was frequently cramming 5GiB of data in RAM on my TP T60p with zram, where zswap wasn't perceptibly much better than just plain swap.

Somehow I knew you would turn out to be a fellow T60p user...

I don't remember tuning it at all. I just set zswap.enabled=1, disabled my zram init script, and away I went. My [current] usage totals about 3.8 4.1GiB, including about 0.6GiB of buffer cache. Maybe your extra gibibyte makes all the difference. My T60p runs a very minimal Sawfish setup instead of a full DE, which helps a lot.

[moonwalkers]

Would you mind sharing the specifics of how you tuned zswap? As well as your typical/max VM usage. Maybe you just figured out the right combination of tunables I couldn't, or maybe my SSD was no longer as fast as it used to be. But I was frequently cramming 5GiB of data in RAM on my TP T60p with zram, where zswap wasn't perceptibly much better than just plain swap.

Somehow I knew you would turn out to be a fellow T60p user...

I don't remember tuning it at all. I just set zswap.enabled=1, disabled my zram init script, and away I went. My [current] usage totals about 3.8 4.1GiB, including about 0.6GiB of buffer cache. Maybe your extra gibibyte makes all the difference. My T60p runs a very minimal Sawfish setup instead of a full DE, which helps a lot.

Very possible - my total RAM usage ((zram content + used RAM - zram compressed size)/total RAM) was usually sitting in 160%-180% range, that is around 5GiB +/- (accounting for only a little over 3GiB accessible out of 4GiB). With that usage on zswap data was getting dumped onto disk and I wasn't getting much I/O savings, but I was still taking the CPU hit from constant compressing/decompressing I would be doing with zram anyway. To be fair though, there was some I/O hit with zram too - after all if RAM pressure gets too high the VFS cache would be dropped as well as other non-anonymous pages... I still have my trusty T60p around, maybe I'll try one of these weekends setting it up with default zswap parameters vs my zram setup and put it through its paces once more.

[moonwalkers]

I see in unstable repos u-boot-rockchip package version 2020.01+dfsg-1 with the claim of supporting two RK3399-based platforms, Puma and Firefly. I assume that since PBP support is not claimed in there directly, unlike Rock64, it would be unsafe to install that package for now instead of the current blob?

[stefan.schumacher]

Hi,

Would it be much work to adapt the installer to Debian Buster? Bullseye is still a bit early in its development cycle for me to consider it as as my primary operating system for the laptop. Besides I will be able to install packages which I really need up-to-date from the backports or compile it from source.

Yours sincerely
Stefan

[xmixahlx]

it isn't difficult, no. i already referenced how to adapt the installer for buster: change "bullseye" to "buster" in the install-debian file, and change references to bullseye to buster in the apt/sources.list file.

great timing, tho... i was going to share with danielt a patch to do some modifications to the installer:
https://pastebin.com/raw/aFwcNwp7

adds a /home partition (also edits sfdisk template using 25G /root )
sets root password
grabs bluetooth firmware and alsa state from manjaro (ap6256-firmware & pinebookpro-post-install git repos)
fixes crypt for home usage (used /dev/mapper/$ in fstab)
seeds more useful sources.list per release
seeds an apt preferences file per release
changes swap to 4G

known issue: problem with the crypt option with buster as is. testing is needed for that combination. (cryptsetup-initramfs etc)

there are probably better ways to do these things. @danielt please take liberties in adaptation if desired.

issues to improve upon:
i lazily copied the manjaro PKGBUILD from the bluetooth folder rather than use !(PKGBUILD)

recommendations:
one directory in the installer to dump each of the git submodule repos into rather than using separate "firmware" and "bootloader" top folders
selectable /home partition
use sudo install (-Dm655, etc.) rather than sudo cp for chown/mod permissions

also, i just noticed that the keyboard fix isn't in the patch:

sudo mkdir -p ${SYSIMAGE}/etc/udev/hwdb.d
sudo cp -a firmware/pinebookpro-post-install/10-usb-kbd.hwdb ${SYSIMAGE}/lib/udev/hwdb.d/

[phs]

I've had a Core 2 Duo with 3GiB of RAM as my daily driver for years. I originally used zram, and saw some benefits from it, but when I switched to zswap the benefit can only be described as magical.

My understanding is that the rule of thumb is "zswap if you can have a swap partition, zram if you can't". Slow writes like you'd have on eMMC/SD might tip the balance in zram's favor, though; every machine I've used zswap on (including my PBP) has had a fast SSD to back it.

Would you mind sharing the specifics of how you tuned zswap? As well as your typical/max VM usage. Maybe you just figured out the right combination of tunables I couldn't, or maybe my SSD was no longer as fast as it used to be. But I was frequently cramming 5GiB of data in RAM on my TP T60p with zram, where zswap wasn't perceptibly much better than just plain swap.

---

I'm not sure if anyone else is running into it but I'm having trouble getting Gnome to start up after installing onto the eMMC using the installer.  Right now I've got an SD card with the main Mate image on it, and am booting from that, installing the install script and trying to install a Gnome environment onto the internal MMC.  I simply clone the repo, run `install_debian` with the DEVBLK set to mmcblk1 (the internal SD card) and run through the setup wizard (selecting "Debian Desktop, Gnome and Laptop" from the tasks list, and a 105 intl key keyboard from the keyboard prompt).  Everything seems fine until I reboot - I see the Debian splash screen, followed by a blinking cursor then eventually a grey screen containing "Oh no, something has gone wrong".

If I press Ctrl + Alt + F2 I'm dropped into a terminal session where I can log in, and confirm the base system seems fine.  dmesg doesn't give me any interesting output beyond thew already reported missing firmware issue.

Has anyone else seen this?  I'm somewhat at a loss!

In my installation I was using KDE and sddm kept crashing until I: a) added QT_XCB_FORCE_SOFTWARE_OPENGL=1 in /etc/environment, b) built mesa-git and made sure /usr/local/lib is given priority, c) installed mesa from experimental. Same was for some GTK stuff. Try forcing software rendering with the like of LIBGL_ALWAYS_SOFTWARE=1 perhaps? If that works you may need newer mesa. Otherwise I have no advise other then digging into logs.

I am experiencing something similar.  While experimenting with video acceleration my PBP freezed up, and subsequently would not boot into the bootstrapped debian image.  Instead I saw a graphical crash loop similar to my first experience with the cheap 8 GB U1 microSD: a blank screen, a brief appearance of a mouse cursor, then a blinking cursor in the upper left before repeating.  I never got the "Oh no" screen, but then I also did not install gnome.  Thinking I had fried the microSD somehow, I just today got my hands on a 32 GB A1.

It exhibits the same behavior.  I was able to get into another getty and in my dmesg I see one occurrence of this line for each crash loop (I can see new ones appear if I let the loop continue):

broken atomic modeset userspace detected, disabling atomic

..which seems to be this patch, somehow related to issues starting the graphical environment with the GPU [0].  I have no reason to think I would not have seen this message the first time I hit this failure mode, if I was able to get into a terminal.

Adding the mentioned environment variables to /etc/environment (and rebooting, confirming they appear in e.g. env in a getty session) has no effect.

[0]: https://patchwork.kernel.org/patch/11133803/

[Solra Bizna]

broken atomic modeset userspace detected, disabling atomic

That message is unfortunately routine. That message will always appear in the kernel log if you use current Xorg with any modern Linux video driver.

[jasrn]

I've had a Core 2 Duo with 3GiB of RAM as my daily driver for years. I originally used zram, and saw some benefits from it, but when I switched to zswap the benefit can only be described as magical.

My understanding is that the rule of thumb is "zswap if you can have a swap partition, zram if you can't". Slow writes like you'd have on eMMC/SD might tip the balance in zram's favor, though; every machine I've used zswap on (including my PBP) has had a fast SSD to back it.

Would you mind sharing the specifics of how you tuned zswap? As well as your typical/max VM usage. Maybe you just figured out the right combination of tunables I couldn't, or maybe my SSD was no longer as fast as it used to be. But I was frequently cramming 5GiB of data in RAM on my TP T60p with zram, where zswap wasn't perceptibly much better than just plain swap.

---

I'm not sure if anyone else is running into it but I'm having trouble getting Gnome to start up after installing onto the eMMC using the installer.  Right now I've got an SD card with the main Mate image on it, and am booting from that, installing the install script and trying to install a Gnome environment onto the internal MMC.  I simply clone the repo, run `install_debian` with the DEVBLK set to mmcblk1 (the internal SD card) and run through the setup wizard (selecting "Debian Desktop, Gnome and Laptop" from the tasks list, and a 105 intl key keyboard from the keyboard prompt).  Everything seems fine until I reboot - I see the Debian splash screen, followed by a blinking cursor then eventually a grey screen containing "Oh no, something has gone wrong".

If I press Ctrl + Alt + F2 I'm dropped into a terminal session where I can log in, and confirm the base system seems fine.  dmesg doesn't give me any interesting output beyond thew already reported missing firmware issue.

Has anyone else seen this?  I'm somewhat at a loss!

In my installation I was using KDE and sddm kept crashing until I: a) added QT_XCB_FORCE_SOFTWARE_OPENGL=1 in /etc/environment, b) built mesa-git and made sure /usr/local/lib is given priority, c) installed mesa from experimental. Same was for some GTK stuff. Try forcing software rendering with the like of LIBGL_ALWAYS_SOFTWARE=1 perhaps? If that works you may need newer mesa. Otherwise I have no advise other then digging into logs.

I am experiencing something similar.  While experimenting with video acceleration my PBP freezed up, and subsequently would not boot into the bootstrapped debian image.  Instead I saw a graphical crash loop similar to my first experience with the cheap 8 GB U1 microSD: a blank screen, a brief appearance of a mouse cursor, then a blinking cursor in the upper left before repeating.  I never got the "Oh no" screen, but then I also did not install gnome.  Thinking I had fried the microSD somehow, I just today got my hands on a 32 GB A1.

It exhibits the same behavior.  I was able to get into another getty and in my dmesg I see one occurrence of this line for each crash loop (I can see new ones appear if I let the loop continue):

broken atomic modeset userspace detected, disabling atomic

..which seems to be this patch, somehow related to issues starting the graphical environment with the GPU [0].  I have no reason to think I would not have seen this message the first time I hit this failure mode, if I was able to get into a terminal.

Adding the mentioned environment variables to /etc/environment (and rebooting, confirming they appear in e.g. env in a getty session) has no effect.

[0]: https://patchwork.kernel.org/patch/11133803/

This sounds identical to my behavior!  I can also SSH in and checking the system logs and I see Xorg or Wayland (depending on which I have selected in gdm.conf) segfault.  The funny thing is I had debian working a week ago but since this I can't get it work regardless of how I flash it or which SD card I write it to (or eMMC).  It's almost as if some HW flag is set that isn't compatible with the way this image is working now that I don't know how to unflag it (And not sure why it'd persist across reboot as that seems odd)

[jpakkane]

I have the same thing. Probably caused by a bug in the kernel and/or Mesa. I also got a message saying something like "unable to load firmware for rocksomething" in my old install using Gnome. I reinstalled xfce and that message is gone but starting X still does not work.

[Jeremiah Cornelius]

I have the same thing. Probably caused by a bug in the kernel and/or Mesa. I also got a message saying something like "unable to load firmware for rocksomething" in my old install using Gnome. I reinstalled xfce and that message is gone but starting X still does not work.

It's not just X11. This is true of my two installs of Debian with Wayland. One was working great for a couple of weeks, and a recent update blew this. No GDM3. I have a working SD on Buster, but there's no Plymouth and I get the firmware failure messages.