(01-24-2020, 04:45 PM)Jeremiah Cornelius Wrote: 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?

(01-23-2020, 12:00 AM)xmixahlx Wrote: you need to checkout with git due to submodules in the installer

(01-25-2020, 11:40 AM)xmixahlx Wrote:

(01-24-2020, 04:45 PM)Jeremiah Cornelius Wrote: 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.

(01-25-2020, 03:08 PM)Jeremiah Cornelius Wrote:

(01-25-2020, 11:40 AM)xmixahlx Wrote:

(01-24-2020, 04:45 PM)Jeremiah Cornelius Wrote: 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!

(01-25-2020, 04:18 PM)xmixahlx Wrote: 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

(01-25-2020, 04:47 PM)Der Geist der Maschine Wrote: 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?

(01-25-2020, 05:02 PM)Jeremiah Cornelius Wrote: Off the top of my head? Are there symlinks that need updating to /linux and /initrd from /boot?