An unofficial Debian Installer for Pinebook Pro

[xmixahlx]

build script for tsys/manjaro kernel:
https://forum.pine64.org/showthread.php?tid=8968

i plan to modify for future branches and provide a separate crosscompiling script.

[Jeremiah Cornelius]

've observed some issues with my FDE system when there are times that the boot hangs waiting for the device (see attached). To fix it I just cycle power it off and on a few times until it works. Am I the only one? It can be a hardware issue?

https://pasteboard.co/ISow5Qc.jpg

I've run these for my PBP off of USB, SD, emmC and now NVMe. I haven't had a timeout with encrypted LUKS at boot. Are you booting from SD? Just guessing, this may be a lower-rated or "worn" SD card.

[e-minguez]

've observed some issues with my FDE system when there are times that the boot hangs waiting for the device (see attached). To fix it I just cycle power it off and on a few times until it works. Am I the only one? It can be a hardware issue?

https://pasteboard.co/ISow5Qc.jpg

I've run these for my PBP off of USB, SD, emmC and now NVMe. I haven't had a timeout with encrypted LUKS at boot. Are you booting from SD? Just guessing, this may be a lower-rated or "worn" SD card.

I'm using the internal eMMC exclusively

Enviado desde mi ONEPLUS A5010 mediante Tapatalk

[Jeremiah Cornelius]

Memory filesystem


If I recall correctly, Manjaro sets up several memory filesystems. Any thoughts on introducing memory filesystems for /tmp and friends on our Debian builds?

The plus: Less flash wear.

The minus: on a memory constrained system such as the Pinebook Pro (and in particular in combination with 64bit binaries) this might result in more paging.


Note: When I was running Manjaro for some time, emacs's cscope mode was requesting more space in /tmp than what was configured. So, with a conservative /tmp size, we may run into problems from time to time.

I've been very successful with implementing zram-swap, as outlined here zram swap support for the PBP; aka: "how to download more RAM" by  @"Arglebargle"  

On the PBP, with Bullseye at least, this is not without minor problems. It causes lsblk to hang, which interrupts common operations, like updating initramfs from apt/dpkg/etc. I worked around this by manually turning off swaps and unloading the module for these tasks.

Otherwise, zram-swap should be almost considered for default, as it addresses your concerns about solid-state storage wear and swappiness - while increasing functional RAM availability. Android has this standard for years, and little wonder, considering the target devices and their use cases.

---

've observed some issues with my FDE system when there are times that the boot hangs waiting for the device (see attached). To fix it I just cycle power it off and on a few times until it works. Am I the only one? It can be a hardware issue?

https://pasteboard.co/ISow5Qc.jpg

I've run these for my PBP off of USB, SD, emmC and now NVMe. I haven't had a timeout with encrypted LUKS at boot. Are you booting from SD? Just guessing, this may be a lower-rated or "worn" SD card.

I'm using the internal eMMC exclusively

Enviado desde mi ONEPLUS A5010 mediante Tapatalk

Ah. It was worth a shot. My eMMC, on two different machines, haven't had this problem. I'd still bet it's the particular chip, or partitions and formats.
If your parts/formats are standard from the debian-installer script, I'd eliminate those, as I again have two working examples - 64 and 128 Gb.

[xmixahlx]

the v5.5 branch of the tsys/manjaro kernel has been tested and the kernel build script is updated:
https://forum.pine64.org/showthread.php?tid=8968

working well so far!

[danielt]

Memory filesystem


If I recall correctly, Manjaro sets up several memory filesystems. Any thoughts on introducing memory filesystems for /tmp and friends on our Debian builds?

The plus: Less flash wear.

The minus: on a memory constrained system such as the Pinebook Pro (and in particular in combination with 64bit binaries) this might result in more paging.


Note: When I was running Manjaro for some time, emacs's cscope mode was requesting more space in /tmp than what was configured. So, with a conservative /tmp size, we may run into problems from time to time.

I've been very successful with implementing zram-swap, as outlined here zram swap support for the PBP; aka: "how to download more RAM" by  @"Arglebargle"  

On the PBP, with Bullseye at least, this is not without minor problems. It causes lsblk to hang, which interrupts common operations, like updating initramfs from apt/dpkg/etc. I worked around this by manually turning off swaps and unloading the module for these tasks.

Otherwise, zram-swap should be almost considered for default, as it addresses your concerns about solid-state storage wear and swappiness - while increasing functional RAM availability. Android has this standard for years, and little wonder, considering the target devices and their use cases.

Just out of interest, did you have problems with the default zswap based approach?

Out-of-the-box the installer should already support compressed in-memory swap but it will use zswap rather than zram. In other words the compressed in-memory swap is preferred but when things get difficult it is reinforced by having a real swap partition as well. The idea is that some processes cause pages to be mapped but then never really use them. Thus a system under memory pressure benefits from getting this rarely or never used data out to disk... I suspect this is true even on systems based on eMMC which is why I adopted zswap by default. I hoped it would be in the "Goldilocks zone" between excessive flash wear and poor system behaviour under memory pressure (zram works well for Android because they can nuke background apps but there is not framework to make correct decisions about what to kill on a full Linux system so it is more important to avoid the OoM killer).

BTW I'm still trying to discover the most "Debian" way to enable ram based tmpfs but the follow looks like it will restore the systemd default behaviour and establish a ram based tmpfs (the Debian maintainers explicitly override this default to make sure it never turns on without the user requesting it):

Code:

sudo cp /usr/share/systemd/tmp.mount /etc/systemd/system/

---

Sorry... above please s/swap partition/swap file/ but otherwise its all good ;-)

[moonwalkers]

Memory filesystem


If I recall correctly, Manjaro sets up several memory filesystems. Any thoughts on introducing memory filesystems for /tmp and friends on our Debian builds?

The plus: Less flash wear.

The minus: on a memory constrained system such as the Pinebook Pro (and in particular in combination with 64bit binaries) this might result in more paging.


Note: When I was running Manjaro for some time, emacs's cscope mode was requesting more space in /tmp than what was configured. So, with a conservative /tmp size, we may run into problems from time to time.

I've been very successful with implementing zram-swap, as outlined here zram swap support for the PBP; aka: "how to download more RAM" by  @"Arglebargle"  

On the PBP, with Bullseye at least, this is not without minor problems. It causes lsblk to hang, which interrupts common operations, like updating initramfs from apt/dpkg/etc. I worked around this by manually turning off swaps and unloading the module for these tasks.

Otherwise, zram-swap should be almost considered for default, as it addresses your concerns about solid-state storage wear and swappiness - while increasing functional RAM availability. Android has this standard for years, and little wonder, considering the target devices and their use cases.

Just out of interest, did you have problems with the default zswap based approach?

Out-of-the-box the installer should already support compressed in-memory swap but it will use zswap rather than zram. In other words the compressed in-memory swap is preferred but when things get difficult it is reinforced by having a real swap partition as well. The idea is that some processes cause pages to be mapped but then never really use them. Thus a system under memory pressure benefits from getting this rarely or never used data out to disk... I suspect this is true even on systems based on eMMC which is why I adopted zswap by default. I hoped it would be in the "Goldilocks zone" between excessive flash wear and poor system behaviour under memory pressure (zram works well for Android because they can nuke background apps but there is not framework to make correct decisions about what to kill on a full Linux system so it is more important to avoid the OoM killer).

BTW I'm still trying to discover the most "Debian" way to enable ram based tmpfs but the follow looks like it will restore the systemd default behaviour and establish a ram based tmpfs (the Debian maintainers explicitly override this default to make sure it never turns on without the user requesting it):

Code:

sudo cp /usr/share/systemd/tmp.mount /etc/systemd/system/

---

Sorry... above please s/swap partition/swap file/ but otherwise its all good ;-)

I've used a rather resource constrained machine (Core 2 Duo with 4GiB RAM and SATA II SSD) as my daily driver for over a year. I don't have precise benchmarks, but in my experience no matter the tuning I've done zram was resulting in a more responsive system than zswap. My understanding of the reason for that is that zram has a fixed size of its virtual block device, but if the data in there is highly compressible it'll take very little ram (you can actually see those stats if you run zramctl, 'sudo zramctl' in Debian). So unless you need to swap you will use no additional CPU or RAM. Because of that I can typically create a virtual zram block device that's as big if not bigger than the amount of RAM I have. At work for our fleet we set 1.5*RAM, on my personal machines I set 2*RAM and the only time I've seen issues is with apps that seriously overcommit the memory or with things like downloading large incompressible file from mega.nz using Firefox instead of Chrome. zswap on the other hand uses a fixed amount of RAM, IIRC, and then if the memory pressure becomes high enough for it to dump pages to on-disk swap it will first decompress them (+CPU usage), and then dump them on disk uncompressed (+I/O). So in my experience zswap is only good if you have moderate to low memory pressure, but if you're in a medium-high memory pressure you're better off with zram, and if zram is inadequate (you need to cram way too much into RAM, more than 2-2.5xRAM) then you're better off giving up on any RAM compression techniques and just doing the old-school on-disk swap, where you can have some scripts that dynamically allocate extra swap space based on the need.

Currently I use zram with my PBP, though instead of complex script described in the neighboring topic I just have zram in /etc/modules-load.d/, zram line in /etc/fstab, and the following line in udev rules:

Code:

KERNEL=="zram0", SUBSYSTEM=="block", ACTION=="add", ATTR{initstate}=="0", PROGRAM="/bin/sh -c 'echo $(($(LANG=C free -k | grep -e \"^Mem:\" | sed -e \"s/^Mem: *//\" -e \"s/  *.*//\")*2))KiB'", ATTR{disksize}="$result", RUN+="/sbin/mkswap $env{DEVNAME}", TAG+="systemd"

The script could use some refinement, in fact IIRC I do have a more refined version we use in our fleet, but I was too lazy to copy it back to my machine.

[Solra Bizna]

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.

[jasrn]

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!

[moonwalkers]

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.