An unofficial Debian Installer for Pinebook Pro

[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.