An unofficial Debian Installer for Pinebook Pro

[bsammon]

Is there any (reasonable) way to enable using this installer to install into a pre-made partition on the internal eMMC?

[Jeremiah Cornelius]

Is there any (reasonable) way to enable using this installer to install into a pre-made partition on the internal eMMC?

Not quite sure what you're asking. The installer can install to eMMC if run from a system booted on SD.
It does destructively re-partition the target block device, so any earlier partitioning is not going to survive.
If you had other requirements, it would be possible to manipulate the target, post installation with tools like gparted, e2resize, etc., run from your SD install. The caution here is that new or altered device names and fstab entries, etc, need to be carefully thought out - so as to not prevent the eMMC from booting!

[xmixahlx]

definitely. i edited the installer to add a home partition for testing to not obliterate my home directory every time.

edit the sfdisk.template to add your partition, then DONT mkfs the partition, and DO create the directory "mount point" and DO mount the partition.

[Jeremiah Cornelius]

definitely. i edited the installer to add a home partition for testing to not obliterate my home directory every time.

edit the sfdisk.template to add your partition, then DONT mkfs the partition, and DO create the directory "mount point" and DO mount the partition.

Ah. Good info. I have home on a separate device with ecryptfs, and adjust /home symlink and fstab.

[bsammon]

To elaborate on my question:
I already have two partitions on my eMMC with working (i.e. I can log in and run "ls") installs. I've created another empty 10 gig partition. With the boot-from-CD x86 debian installers I've used in the past, I could do an install that does not modify the partition table, and use the partition-tool to simply select a preexisting partition to install onto. I'd like to be able to do that on my PBP.
Also, I'd like to be able to run the installer while running from one of the other installs on the eMMC. If I'm not modifying the partition table, it shouldn't matter, I think.

There's two questions wrapped in one:
Can I do this with the current version of the installer?
If not, could this functionality be added (easily?) to a future version of the installer?

It sounds like xmixahlx knows of a way of modifying the installer that would enable that; having never looked at the guts of the installer, I find it hard to understand what he's talking about.

[Jeremiah Cornelius]

To elaborate on my question:
I already have two partitions on my eMMC with working (i.e. I can log in and run "ls") installs.  I've created another empty 10 gig partition.  With the boot-from-CD x86 debian installers I've used in the past, I could do an install that does not modify the partition table, and use the partition-tool to simply select a preexisting partition to install onto.  I'd like to be able to do that on my PBP.
Also, I'd like to be able to run the installer while running from one of the other installs on the eMMC.  If I'm not modifying the partition table, it shouldn't matter, I think.

There's two questions wrapped in one:
Can I do this with the current version of the installer?
If not, could this functionality be added (easily?) to a future version of the installer?

It sounds like xmixahlx knows of a way of modifying the installer that would enable that; having never looked at the guts of the installer, I find it hard to understand what he's talking about.

You want more than one bootable installation on the same block device? I think that's what you're asking.
You COULD work with the files in the installer to accomplish this, as xmixahlx describes. However, my assumption is that you can't have more than one /boot partition per block device, as the existing uboot isn't made for this, and there's no ability to select between /boot/initrd options - as there's no uboot console on the LCD and KB. 

Eventually, we will have a working GRUB or equivalent on the PBP, but until then, alternative installations need to be located on separate block devices, like microSD, for booting "blind".

[xmixahlx]

< SNIP >

oh the current kernel supports this already. do:

sudo dpkg --add-architecture armhf
sudo apt-get update
sudo apt-get install $package:armhf

I would avoid using tasksel in the installer, then install your minimal desktop environment, then install firefox:armhf or whatever.

Excellent. Thanks. I'm going to work on this.

So far, this has worked best of all. It's kind of bleeding edge, but between selective use of armhf packages, and from sid/unstable, I'm very close to having a system that I'd commit to NVMe.
Next stop will have to be Mesa from Git.

---

I had the same issues initially, but I am using Mesa from git now for updated panfrost.

Are there special flags or build instructions for panfrost and arm64? debuild and pbuilder?

Thanks!

i know jeremiah already knows this... but for anyone else, i've created a separate mesa-git how-to thread here as to not distract from danielt's thread:
https://forum.pine64.org/showthread.php?tid=8953

also, here is an openarena build script if you care about that:
https://forum.pine64.org/showthread.php?tid=8954

---

To elaborate on my question:
I already have two partitions on my eMMC with working (i.e. I can log in and run "ls") installs.  I've created another empty 10 gig partition.  With the boot-from-CD x86 debian installers I've used in the past, I could do an install that does not modify the partition table, and use the partition-tool to simply select a preexisting partition to install onto.  I'd like to be able to do that on my PBP.
Also, I'd like to be able to run the installer while running from one of the other installs on the eMMC.  If I'm not modifying the partition table, it shouldn't matter, I think.

There's two questions wrapped in one:
Can I do this with the current version of the installer?
If not, could this functionality be added (easily?) to a future version of the installer?

It sounds like xmixahlx knows of a way of modifying the installer that would enable that; having never looked at the guts of the installer, I find it hard to understand what he's talking about.

so technically i think you >could< do this, but there are some maintenance caveats that will probably mean that you won't want to.

if it did work... you could have a separate install on the emmc on a separate partition and possibly a separately partitioned /boot. 

however, since the sdcard is bootable... i would highly recommend just using that.

this isn't a partition table issue, this is a "we aren't using grub" issue. i would have to learn more about selectability before commenting. perhaps others already have the answer.

you should absolutely review danielt's installer before going any further. he's done a great job with this and reading the process is quite straight forward if you are familiar with debian installer and debootstrap, etc. (kudos)

i modified the installer to install debian sid arm64 directly and with a home partition (etc.) for testing, although i dropped the additional home partition for emmc install to simplify cryptfs.

[bsammon]

Well, I found a workaround, so I'm less concerned about an answer to my question.
I had a SD card that I had used the installer on, so I just copied the files from the SD card into the new partition on the eMMC, and that worked fine.

I now have three (somewhat) different linux installs on my eMMC. Only one boot partition though.
Since I haven't got anything that does a boot menu on the builtin screen and I haven't bought a serial-port adapter, I have to edit the extlinux.conf whenever I wish to switch to a different install.

This is exactly the place I expected to get to if the installer had the feature I was asking about.

[xmixahlx]

alrighty

[moonwalkers]

Just noticed that on my system (initially installed as a minimal Debian, with no tasks selected) CPUs 4 and 5 are pegged at 2GHz all the time, it's like cpufreq is not aware of them. Haven't yet looked into how to address that (besides removing maxcpus=4 from kernel cmdline), just wanted to bring it up to the community's attention. This fixed frequency would explain why my PBP has been burning through the battery charge compared to the stock OS.

---

Just noticed that on my system (initially installed as a minimal Debian, with no tasks selected) CPUs 4 and 5 are pegged at 2GHz all the time, it's like cpufreq is not aware of them. Haven't yet looked into how to address that (besides removing maxcpus=4 from kernel cmdline), just wanted to bring it up to the community's attention. This fixed frequency would explain why my PBP has been burning through the battery charge compared to the stock OS.

On a bit deeper investigation I stand corrected - CPUs 4 and 5 are controlled by cpufreq, and their frequency does scale down, but despite "ondemand" governor they do seem to be spending most of their time in 2GHz, even when the load is (or at least appears to be) nearly non-existent.

---

On an unrelated note, it seems that combinations Meta+<cursor key> don't work, I can't even see anything xev. Cursor keys by themselves work, Meta+Fn+<cursor key> (which effectively results in Meta+Home/End/PgUp/PgDn) work, but simple Meta+<cursor key> don't work. I assume that would be an issue with keyboard firmware?