An unofficial Debian Installer for Pinebook Pro

[xmixahlx]

I just ran an apt upgrade on my Debian with armhf userspace, and it wants to update initramfs after updating cryptsetup-bin and cryptsetup-initramfs.
This hangs, without completing.
From /var/log/apt/history..log :

Setting up initramfs-tools (0.136) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.136) ...
update-initramfs: Generating /boot/initrd.img-5.4.2-2-pinebookpro-arm64

I have to kill this and clear the dpkg lockfiles, but a 'dpkg --configure -a' continues hanging at the same point. Yes, there's plenty of free space on /boot, and it's mounted rw.

Could this be because it's mixing armhf binaries with a arm64 kernel? Seems unlikely - but your own original is all arm64-native, so I wonder...

Are there suggested fixes, if I need a 64-bit cryptsetup-initramfs?

 I don't think so. I was using debian sid armhf for a while to test and didn't have this issue. I recall rebuilding initrd a few times.

I didn't encounter any considerable issue, I was just ready to test arm64 userspace and haven't had any issues there either to change back.

[bsammon]

you need to checkout with git due to submodules in the installer

I did figure out that using git made the problem going away.

My main point in posting this was -- maybe the documentation should mention this so that more people don't have to figure it out by trial and error the way I did.

[Jeremiah Cornelius]

I just ran an apt upgrade on my Debian with armhf userspace, and it wants to update initramfs after updating cryptsetup-bin and cryptsetup-initramfs.
This hangs, without completing.
From /var/log/apt/history..log :

Setting up initramfs-tools (0.136) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.136) ...
update-initramfs: Generating /boot/initrd.img-5.4.2-2-pinebookpro-arm64

I have to kill this and clear the dpkg lockfiles, but a 'dpkg --configure -a' continues hanging at the same point. Yes, there's plenty of free space on /boot, and it's mounted rw.

Could this be because it's mixing armhf binaries with a arm64 kernel? Seems unlikely - but your own original is all arm64-native, so I wonder...

Are there suggested fixes, if I need a 64-bit cryptsetup-initramfs?

 I don't think so. I was using debian sid armhf for a while to test and didn't have this issue. I recall rebuilding initrd a few times.

I didn't encounter any considerable issue, I was just ready to test arm64 userspace and haven't had any issues there either to change back.

Thanks! This helps.
I did do some deeper troubleshooting this morning. I added the option "set -x" at the top of my /usr/share/initrd-tools/hooks/cryptroot and manually ran update-initrd -u -v for verbose output.

This ensured that update-initrd would show me where it was hanging, and that the hook script would likewise throw status to the console.

So, as I guessed, I'm hanging up in the cryptroot hook. Good hunch.

The lines that lead to the script hanging are here:
+ crypttab_print_entry
+ local DEV MAJ MIN sourcename uuid keyfile
+ resolve_device PARTLABEL=mmcblk2-RootFS
+ local spec=PARTLABEL=mmcblk2-RootFS dev devno maj min
+ resolve_device_spec PARTLABEL=mmcblk2-RootFS
+ local spec=PARTLABEL=mmcblk2-RootFS
+ blkid -l -t PARTLABEL=mmcblk2-RootFS -o device

I assume the last blkid line is where failure is happening. At this point, console freezes, and is unresponsive to <ctl-c> for breaking, though I can still force the shell to bg the task with a <ctl-z>.

My latest hunch is that there are device name problems? I'm going to try and research - but any help from the forum is really appreciated.

LATE EDIT!
When I run 'sudo blkid' with no arguments, I get a hard hang on the console. I can't even push the task to bg!
Ideas? Suggestions?
THANKS!

---

I just ran an apt upgrade on my Debian with armhf userspace, and it wants to update initramfs after updating cryptsetup-bin and cryptsetup-initramfs.
This hangs, without completing.
From /var/log/apt/history..log :

Setting up initramfs-tools (0.136) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.136) ...
update-initramfs: Generating /boot/initrd.img-5.4.2-2-pinebookpro-arm64

I have to kill this and clear the dpkg lockfiles, but a 'dpkg --configure -a' continues hanging at the same point. Yes, there's plenty of free space on /boot, and it's mounted rw.

Could this be because it's mixing armhf binaries with a arm64 kernel? Seems unlikely - but your own original is all arm64-native, so I wonder...

Are there suggested fixes, if I need a 64-bit cryptsetup-initramfs?

 I don't think so. I was using debian sid armhf for a while to test and didn't have this issue. I recall rebuilding initrd a few times.

I didn't encounter any considerable issue, I was just ready to test arm64 userspace and haven't had any issues there either to change back.

Thanks! This helps.
I did do some deeper troubleshooting this morning. I added the option "set -x" at the top of my /usr/share/initrd-tools/hooks/cryptroot and manually ran update-initrd -u -v for verbose output.

This ensured that update-initrd would show me where it was hanging, and that the hook script would likewise throw status to the console.

So, as I guessed, I'm hanging up in the cryptroot hook. Good hunch.

The lines that lead to the script hanging are here:
+ crypttab_print_entry
+ local DEV MAJ MIN sourcename uuid keyfile
+ resolve_device PARTLABEL=mmcblk2-RootFS
+ local spec=PARTLABEL=mmcblk2-RootFS dev devno maj min
+ resolve_device_spec PARTLABEL=mmcblk2-RootFS
+ local spec=PARTLABEL=mmcblk2-RootFS
+ blkid -l -t PARTLABEL=mmcblk2-RootFS -o device

I assume the last blkid line is where failure is happening. At this point, console freezes, and is unresponsive to <ctl-c> for breaking, though I can still force the shell to bg the task with a <ctl-z>.

My latest hunch is that there are device name problems? I'm going to try and research - but any help from the forum is really appreciated.

LATE EDIT!
When I run 'sudo blkid' with no arguments, I get a hard hang on the console. I can't even push the task to bg!
Ideas? Suggestions?
THANKS!

More fun new info. Gparted completely hangs, without rendering. Just a frozen black rectangle, that ties up my display in Wayland.
Some reading online suggests that there's a device not correctly responding to the system function calls in both blkid and parted.

This is introduced behavior - I could formerly run Gparted. Still looking for replies, but I may backup home data, export package list with apt-clone, and re-install.

[xmixahlx]

did you update && upgrade recently?

what happens if you try to pull packages from unstable?

I am using mesa-git sway-git and xfce-git on debian so I can't be comparatively helpful

that and I am currently not using LUKS since testing arm64

[Jeremiah Cornelius]

did you update && upgrade recently?

what happens if you try to pull packages from unstable?

I am using mesa-git sway-git and xfce-git on debian so I can't be comparatively helpful

that and I am currently not using LUKS since testing arm64

I did update and upgrade a couple of times. The problem emerged at the end of last update, yesterday.
Right now, I have a broken apt/dpkg database, until initrd is rebuilt from dpkg --configure -a.
Hence, the catch-22. ;-)

God, I'd forgotten how much about Debian that I knew, until I had to dig into this one. Normally I'm closer to solution architecture and product management than systems engineering/admin.

So, a positive exercise!

[Der Geist der Maschine]

I fail booting a selfcompiled kernel:

I built and installed Manajaro's latest kernel from source

Code:

make -j2 bindeb-pkg && apt-get install ../linux-image-5.5.0-rc7-1-pinebookpro-arm64+_5.5.0-rc7-1-pinebookpro-arm64+-5_arm64.deb

For apt-install, a lot of messages passed by, initrd was receated and even extlinux.conf got automatically updated

Code:

$ cat /boot/extlinux/extlinux.conf
## /boot/extlinux/extlinux.conf
##
## IMPORTANT WARNING
##
## The configuration of this file is generated automatically.
## Do not edit this file manually, use: u-boot-update

default l0
menu title U-Boot menu
prompt 0
timeout 10


label l0
    menu label Debian GNU/Linux kernel 5.5.0-rc7-1-pinebookpro-arm64+
    linux /vmlinuz-5.5.0-rc7-1-pinebookpro-arm64+
    initrd /initrd.img-5.5.0-rc7-1-pinebookpro-arm64+
    fdt /rk3399-pinebook-pro.dtb
    append root=LABEL=mmcblk1-RootFS console=ttyS2,1500000n8 console=tty0 ro maxcpus=4 coherent_pool=1M

label l0r
    menu label Debian GNU/Linux kernel 5.5.0-rc7-1-pinebookpro-arm64+ (rescue target)
    linux /vmlinuz-5.5.0-rc7-1-pinebookpro-arm64+
    initrd /initrd.img-5.5.0-rc7-1-pinebookpro-arm64+
    fdt /rk3399-pinebook-pro.dtb
    append root=LABEL=mmcblk1-RootFS console=ttyS2,1500000n8 console=tty0 ro maxcpus=4 coherent_pool=1M single
    

label l1
    menu label Debian GNU/Linux kernel 5.4.2-2-pinebookpro-arm64
    linux /vmlinuz-5.4.2-2-pinebookpro-arm64
    initrd /initrd.img-5.4.2-2-pinebookpro-arm64
    fdt /rk3399-pinebook-pro.dtb
    append root=LABEL=mmcblk1-RootFS console=ttyS2,1500000n8 console=tty0 ro maxcpus=4 coherent_pool=1M

label l1r
    menu label Debian GNU/Linux kernel 5.4.2-2-pinebookpro-arm64 (rescue target)
    linux /vmlinuz-5.4.2-2-pinebookpro-arm64
    initrd /initrd.img-5.4.2-2-pinebookpro-arm64
    fdt /rk3399-pinebook-pro.dtb
    append root=LABEL=mmcblk1-RootFS console=ttyS2,1500000n8 console=tty0 ro maxcpus=4 coherent_pool=1M single

    

Code:

$ dir /boot/
total 50697
drwxr-xr-x  5 root root     1024 Jan 25 14:06 .
drwxr-xr-x 21 root root     4096 Jan 23 00:16 ..
-rw-r--r--  1 root root   204751 Dec 13 04:21 config-5.4.2-2-pinebookpro-arm64
-rw-r--r--  1 root root   204401 Jan 24 21:44 config-5.5.0-rc7-1-pinebookpro-arm64+
drwxr-xr-x  2 root root      512 Dec 31  1969 efi
drwxr-xr-x  2 root root     1024 Jan 25 14:06 extlinux
-rw-r--r--  1 root root  6295863 Jan 24 21:19 initrd.img-5.4.2-2-pinebookpro-arm64
-rw-r--r--  1 root root  6422051 Jan 25 14:06 initrd.img-5.5.0-rc7-1-pinebookpro-arm64+
drwx------  2 root root    12288 Jan 22 23:30 lost+found
-rw-r--r--  1 root root    62112 Jan 25 14:06 rk3399-pinebook-pro.dtb
-rw-r--r--  1 root root    60795 Jan 25 14:06 rk3399-pinebook-pro.dtb.bak
-rw-r--r--  1 root root  4416507 Dec 13 04:21 System.map-5.4.2-2-pinebookpro-arm64
-rw-r--r--  1 root root  4807055 Jan 24 21:44 System.map-5.5.0-rc7-1-pinebookpro-arm64+
-rwxr-xr-x  1 root root 20220416 Dec 13 04:21 vmlinuz-5.4.2-2-pinebookpro-arm64
-rw-r--r--  1 root root  9196524 Jan 24 21:44 vmlinuz-5.5.0-rc7-1-pinebookpro-arm64+

Code:

$ dir /lib/modules/
total 16
drwxr-xr-x  4 root root 4096 Jan 25 14:05 .
drwxr-xr-x 17 root root 4096 Jan 25 10:27 ..
drwxr-xr-x  3 root root 4096 Jan 23 00:23 5.4.2-2-pinebookpro-arm64
drwxr-xr-x  3 root root 4096 Jan 25 14:05 5.5.0-rc7-1-pinebookpro-arm64+

I had a quick look into the new initrd and it looks reasonable.

A reboot booted straight into the previous kernel

Code:

$ uname -a
Linux pinebook-pro 5.4.2-2-pinebookpro-arm64 #1 SMP PREEMPT Sun Jan 19 22:43:25 UTC 2020 aarch64 GNU/Linux

How is that possible?

[Jeremiah Cornelius]

I fail booting a selfcompiled kernel:

I built and installed Manajaro's latest kernel from source

Code:

make -j2 bindeb-pkg && apt-get install ../linux-image-5.5.0-rc7-1-pinebookpro-arm64+_5.5.0-rc7-1-pinebookpro-arm64+-5_arm64.deb

For apt-install, a lot of messages passed by, initrd was receated and even extlinux.conf got automatically updated

Code:

$ cat /boot/extlinux/extlinux.conf
## /boot/extlinux/extlinux.conf
##
## IMPORTANT WARNING
##
## The configuration of this file is generated automatically.
## Do not edit this file manually, use: u-boot-update

default l0
menu title U-Boot menu
prompt 0
timeout 10


label l0
    menu label Debian GNU/Linux kernel 5.5.0-rc7-1-pinebookpro-arm64+
    linux /vmlinuz-5.5.0-rc7-1-pinebookpro-arm64+
    initrd /initrd.img-5.5.0-rc7-1-pinebookpro-arm64+
    fdt /rk3399-pinebook-pro.dtb
    append root=LABEL=mmcblk1-RootFS console=ttyS2,1500000n8 console=tty0 ro maxcpus=4 coherent_pool=1M

label l0r
    menu label Debian GNU/Linux kernel 5.5.0-rc7-1-pinebookpro-arm64+ (rescue target)
    linux /vmlinuz-5.5.0-rc7-1-pinebookpro-arm64+
    initrd /initrd.img-5.5.0-rc7-1-pinebookpro-arm64+
    fdt /rk3399-pinebook-pro.dtb
    append root=LABEL=mmcblk1-RootFS console=ttyS2,1500000n8 console=tty0 ro maxcpus=4 coherent_pool=1M single
    

label l1
    menu label Debian GNU/Linux kernel 5.4.2-2-pinebookpro-arm64
    linux /vmlinuz-5.4.2-2-pinebookpro-arm64
    initrd /initrd.img-5.4.2-2-pinebookpro-arm64
    fdt /rk3399-pinebook-pro.dtb
    append root=LABEL=mmcblk1-RootFS console=ttyS2,1500000n8 console=tty0 ro maxcpus=4 coherent_pool=1M

label l1r
    menu label Debian GNU/Linux kernel 5.4.2-2-pinebookpro-arm64 (rescue target)
    linux /vmlinuz-5.4.2-2-pinebookpro-arm64
    initrd /initrd.img-5.4.2-2-pinebookpro-arm64
    fdt /rk3399-pinebook-pro.dtb
    append root=LABEL=mmcblk1-RootFS console=ttyS2,1500000n8 console=tty0 ro maxcpus=4 coherent_pool=1M single

    

Code:

$ dir /boot/
total 50697
drwxr-xr-x  5 root root     1024 Jan 25 14:06 .
drwxr-xr-x 21 root root     4096 Jan 23 00:16 ..
-rw-r--r--  1 root root   204751 Dec 13 04:21 config-5.4.2-2-pinebookpro-arm64
-rw-r--r--  1 root root   204401 Jan 24 21:44 config-5.5.0-rc7-1-pinebookpro-arm64+
drwxr-xr-x  2 root root      512 Dec 31  1969 efi
drwxr-xr-x  2 root root     1024 Jan 25 14:06 extlinux
-rw-r--r--  1 root root  6295863 Jan 24 21:19 initrd.img-5.4.2-2-pinebookpro-arm64
-rw-r--r--  1 root root  6422051 Jan 25 14:06 initrd.img-5.5.0-rc7-1-pinebookpro-arm64+
drwx------  2 root root    12288 Jan 22 23:30 lost+found
-rw-r--r--  1 root root    62112 Jan 25 14:06 rk3399-pinebook-pro.dtb
-rw-r--r--  1 root root    60795 Jan 25 14:06 rk3399-pinebook-pro.dtb.bak
-rw-r--r--  1 root root  4416507 Dec 13 04:21 System.map-5.4.2-2-pinebookpro-arm64
-rw-r--r--  1 root root  4807055 Jan 24 21:44 System.map-5.5.0-rc7-1-pinebookpro-arm64+
-rwxr-xr-x  1 root root 20220416 Dec 13 04:21 vmlinuz-5.4.2-2-pinebookpro-arm64
-rw-r--r--  1 root root  9196524 Jan 24 21:44 vmlinuz-5.5.0-rc7-1-pinebookpro-arm64+

Code:

$ dir /lib/modules/
total 16
drwxr-xr-x  4 root root 4096 Jan 25 14:05 .
drwxr-xr-x 17 root root 4096 Jan 25 10:27 ..
drwxr-xr-x  3 root root 4096 Jan 23 00:23 5.4.2-2-pinebookpro-arm64
drwxr-xr-x  3 root root 4096 Jan 25 14:05 5.5.0-rc7-1-pinebookpro-arm64+

I had a quick look into the new initrd and it looks reasonable.

A reboot booted straight into the previous kernel

Code:

$ uname -a
Linux pinebook-pro 5.4.2-2-pinebookpro-arm64 #1 SMP PREEMPT Sun Jan 19 22:43:25 UTC 2020 aarch64 GNU/Linux

How is that possible?

Off the top of my head? Are there symlinks that need updating to /linux and /initrd from /boot?

[Der Geist der Maschine]

Off the top of my head? Are there symlinks that need updating to /linux and /initrd from /boot?

extlinux.conf uses the actual filenames and no easy-to-read symlinks.

I don't think there were symlinks before my apt-get install.

[gillham]

Be careful upgrading to unstable packages as I installed firefox from unstable (which works) but later did a 'dist-upgrade' that installed a number of new packages from unstable.  Then gdm3 wouldn't come up due to a segv somewhere.  I tested a few times and figured out a number of packages that needed to be held back.  I don't have the list handy right now, but I can post it later.  Basically it seems to me there is a compiler problem affecting us.

EDIT: FWIW, here are the packages from unstable I had to hold to keep GDM3 from core dumping. There might be more, this is just what I ran into as mentioned above.

echo "libgjs0g hold" | dpkg --set-selections
echo "libgirepository-1.0-1 hold" | dpkg --set-selections

echo "libglib2.0-0 hold" | dpkg --set-selections
echo "libglib2.0-bin hold" | dpkg --set-selections

echo "libwayland-client0 hold" | dpkg --set-selections
echo "libwayland-server0 hold" | dpkg --set-selections

[Der Geist der Maschine]

My kernel was half the size of Daniel's kernel. That made me realize that mine was compressed while his was not.

I assume that's why uboot refused to boot it and moved on to the next kernel in the extlinux.conf list.

Now that I uncompressed my kernel, a boot ends up in a black screen. I assume Daniel put some magic into his kernel deb.