An unofficial Debian Installer for Pinebook Pro
exactly!
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)
(02-07-2020, 04:55 PM)Solra Bizna Wrote: 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!
— Jeremiah Cornelius
"Be the first person not to do some­thing, that no one has thought of not doing before’’
— Brian Eno, "Oblique Strategies"
(02-07-2020, 07:47 PM)Jeremiah Cornelius Wrote:
(02-07-2020, 04:55 PM)Solra Bizna Wrote: 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.
(02-08-2020, 10:09 AM)moonwalkers Wrote: 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!
— Jeremiah Cornelius
"Be the first person not to do some­thing, that no one has thought of not doing before’’
— Brian Eno, "Oblique Strategies"
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?
from what I understand, the issues are gtk related, so starts with default kde wm could bypass until you launch a gtk app.
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?
Quote: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.
— Jeremiah Cornelius
"Be the first person not to do some­thing, that no one has thought of not doing before’’
— Brian Eno, "Oblique Strategies"
(02-09-2020, 01:25 PM)Jeremiah Cornelius Wrote: 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.


Possibly Related Threads…
Thread Author Replies Views Last Post
  Upgrading Armbian from v24.2.1 gnome, breaks pinebook pro Sb2024 0 172 11-10-2024, 02:50 PM
Last Post: Sb2024
  Pinebook pro won't boot after bootloader installation jwensouls 4 1,064 08-21-2024, 04:17 AM
Last Post: KC9UDX
  Official Debian support moonwalkers 64 65,622 07-08-2024, 01:40 PM
Last Post: Humid Stylus
  [Pinebook Pro/Mobian/XFCE4] can fix touch or screen in greeter not both SynthGal 0 434 05-31-2024, 09:42 AM
Last Post: SynthGal
  Debian on Pinebook Pro u974615 7 3,025 03-31-2024, 10:11 AM
Last Post: u974615
  Pinebook Pro upgrading from the factory image yamsoup 12 4,468 02-22-2024, 04:02 PM
Last Post: tllim
  Help installing Manjaro on eMMC of Pinebook Pro pine4546464 4 3,342 12-13-2023, 07:22 PM
Last Post: trillobite
  Need Help Recovering Manjaro /boot Contents on Pinebook Pro calinb 6 3,620 12-11-2023, 03:47 AM
Last Post: calinb
  Gentoo on Pinebook Pro RELEASE jannik2099 54 105,032 12-08-2023, 11:25 PM
Last Post: tllim
  Boot Order in Pinebook Pro food 8 2,864 11-23-2023, 07:37 AM
Last Post: KC9UDX

Forum Jump:


Users browsing this thread: 13 Guest(s)