An unofficial Debian Installer for Pinebook Pro

[xmixahlx]

exactly!

[Solra Bizna]

The setup I've used for my encrypted disks on all my recent systems, including my PBP, is to create a single LUKS partition and both root and swap on LVM inside that. Setup is annoying (LVM's documentation is slightly worse than nonexistent in some places) but then it all works with no extra pain, including restoring a hibernate* image from the encryped swap. This would also seamlessly work with separate /home as well. I'm not sure why this isn't the norm in the various "encrypted everything" guides.

*(not that I've successfully hibernated my PBP yet)

[Jeremiah Cornelius]

The setup I've used for my encrypted disks on all my recent systems, including my PBP, is to create a single LUKS partition and both root and swap on LVM inside that. Setup is annoying (LVM's documentation is slightly worse than nonexistent in some places) but then it all works with no extra pain, including restoring a hibernate* image from the encryped swap. This would also seamlessly work with separate /home as well. I'm not sure why this isn't the norm in the various "encrypted everything" guides.

*(not that I've successfully hibernated my PBP yet)

This was, if not any longer, the default partitioning done by Ubuntu, when selecting "Whole Disk" in the installer.
LVM plus encryption simplified my movement of an installation to a larger block device, but made the expansion of the LUKS, the LVM and then the Ext4 FS an unwieldy, complicated sequence.

Those are the kinds of things that were solved by Sun and Veritas with high-level abstraction in management utilities, 20 years ago! Well, we do have... gparted!

[moonwalkers]

The setup I've used for my encrypted disks on all my recent systems, including my PBP, is to create a single LUKS partition and both root and swap on LVM inside that. Setup is annoying (LVM's documentation is slightly worse than nonexistent in some places) but then it all works with no extra pain, including restoring a hibernate* image from the encryped swap. This would also seamlessly work with separate /home as well. I'm not sure why this isn't the norm in the various "encrypted everything" guides.

*(not that I've successfully hibernated my PBP yet)

This was, if not any longer, the default partitioning done by Ubuntu, when selecting "Whole Disk" in the installer.
LVM plus encryption simplified my movement of an installation to a larger block device, but made the expansion of the LUKS, the LVM and then the Ext4 FS an unwieldy, complicated sequence.

Those are the kinds of things that were solved by Sun and Veritas with high-level abstraction in management utilities, 20 years ago! Well, we do have... gparted!

To be fair, without LVM you can't do things like shutdown your laptop, replace your HDD/SSD, connect the old one with USB adapter, start your laptop from the old drive over USB, start migration, keep working as usual while migration is going on, then once it is finished just unplug the old drive in the middle of some build job or whatnot and shortly afterwards just suspend your laptop, throw it into backpack and get on your way. Without LVM even if the sequence is much simpler you're kinda stuck with either a lengthy downtime while the old drive is being cloned to a new one or with multiple rounds of rsync runs and shorter but still an extra downtime.

[Jeremiah Cornelius]

To be fair, without LVM you can't do things like shutdown your laptop, replace your HDD/SSD, connect the old one with USB adapter, start your laptop from the old drive over USB, start migration, keep working as usual while migration is going on, then once it is finished just unplug the old drive in the middle of some build job or whatnot and shortly afterwards just suspend your laptop, throw it into backpack and get on your way. Without LVM even if the sequence is much simpler you're kinda stuck with either a lengthy downtime while the old drive is being cloned to a new one or with multiple rounds of rsync runs and shorter but still an extra downtime.

I completely endorse and agree. I wish there were high-level workflows canned, to do exactly what you describe!

[jpakkane]

I reinstalled Debian from scratch with KDE. The login manager still does not work, but if you log in via the console and start the gui with "startx" it works (though after a while you'll probably get a Panfrost crash). Maybe the issue is related to Wayland usage?

[xmixahlx]

from what I understand, the issues are gtk related, so starts with default kde wm could bypass until you launch a gtk app.

[ThatGeoGuy]

I had been using this installer with Debian Sid for some time (with encrypted disks). It was working fine, but I booted into it yesterday and got the following error:

> libgcc_s.so.1 must be installed for pthread_cancel to work
> Aborted

this happens whenever I try to decrypt my disk, so even if I put the right password in, it fails every time. Has anyone using LUKS seen something like this at all? Is there a quick fix or is re-installing the solution?

[Jeremiah Cornelius]

ThatGeoGuy
I had been using this installer with Debian Sid for some time (with encrypted disks). It was working fine, but I booted into it yesterday and got the following error:

> libgcc_s.so.1 must be installed for pthread_cancel to work
> Aborted

this happens whenever I try to decrypt my disk, so even if I put the right password in, it fails every time. Has anyone using LUKS seen something like this at all? Is there a quick fix or is re-installing the solution?

You may be in a tough bind for a quick fix.
Assuming that the libraries to repair this in Sid are since updated and installable, the best bet is to boot an SD with a stable version of the Debian install, and mount a chroot of your encrypted system, from which you can apt update/apt upgrade - ultimately rebuilding your initrd and returning to a bootable state.

When the fix is for an issue that rebuilds initrd, it's also very important that your rescue SD have the same kernel version as your rescue target. With this debian installer, that should be no problem, if you didn't roll-your-own, and stuck with @danielt supplied kernel image.

The trick with this is manually unlocking the luks encrypted volume that your target system is on.
$ sudo cryptsetup luksOpen /dev/<blkdev+partnum>
This will do, if your device has been ID'd when udev started, and there's a corresponding link in /dev/mapper.

Otherwise, if your SD has Gnome Disks or gParted, you can open the encrypted volume with the GUI.

The rest will be regular chroot after mounting /dev/mapper/<cryptvolume> to /mnt, and 'mount -o bind' for /dev /dev/pts /sys and /proc to the corresponding chroot target filesysystem mount-points:

$ sudo mount /dev/mapper/<cryptvolume> /mnt/
$ sudo mount /dev/<CORRECT /BOOT VOLUME!!!!> /mnt/boot  <--This is important. If any fix involves an updated initrd, then it must go to right FS!
$ sudo mount -o bind /dev /mnt/dev
$ sudo mount -o bind /dev/pts /mnt/dev/pts
$ sudo mount -t proc none /mnt/proc
$ sudo mount -t sysfs sys /mnt/sys
$ sudo chroot /mnt/ /bin/bash
# apt update && apt upgrade

If you're lucky, this will get fixed updates and set everything again right. Exit the chroot and unmount in reverse order.

[ThatGeoGuy]

You may be in a tough bind for a quick fix.
Assuming that the libraries to repair this in Sid are since updated and installable, the best bet is to boot an SD with a stable version of the Debian install, and mount a chroot of your encrypted system, from which you can apt update/apt upgrade - ultimately rebuilding your initrd and returning to a bootable state.

When the fix is for an issue that rebuilds initrd, it's also very important that your rescue SD have the same kernel version as your rescue target. With this debian installer, that should be no problem, if you didn't roll-your-own, and stuck with @danielt supplied kernel image.

The trick with this is manually unlocking the luks encrypted volume that your target system is on.
$ sudo cryptsetup luksOpen /dev/<blkdev+partnum>
This will do, if your device has been ID'd when udev started, and there's a corresponding link in /dev/mapper.

Otherwise, if your SD has Gnome Disks or gParted, you can open the encrypted volume with the GUI.

The rest will be regular chroot after mounting /dev/mapper/<cryptvolume> to /mnt, and 'mount -o bind' for /dev /dev/pts /sys and /proc to the corresponding chroot target filesysystem mount-points:

$ sudo mount /dev/mapper/<cryptvolume> /mnt/
$ sudo mount /dev/<CORRECT /BOOT VOLUME!!!!> /mnt/boot  <--This is important. If any fix involves an updated initrd, then it must go to right FS!
$ sudo mount -o bind /dev /mnt/dev
$ sudo mount -o bind /dev/pts /mnt/dev/pts
$ sudo mount -t proc none /mnt/proc
$ sudo mount -t sysfs sys /mnt/sys
$ sudo chroot /mnt/ /bin/bash
# apt update && apt upgrade

If you're lucky, this will get fixed updates and set everything again right. Exit the chroot and unmount in reverse order.

Oh man, this seems gnarly. Given that I had barely any mods on the install itself (mesa-git, bluetooth from manjaro, and from testing->sid), I think I might be better off just re-installing, which seems like far less effort, given how simple the installer is. There was a time where I would actually do something like this, but I get the sense that this would be a mistake here, in terms of time tradeoff. Most of the relevant data for my home dir / configuration files were on an external SD anyways. That said, I would really like to get to the bottom of why this happened. I fear others' systems on sid may meet similar fates, given that I did not do much with the system and this happened.