UPDATED (June 2021): 17-distro multi-boot image for Pinephone (incl. 3GiB variant)

[laaglu]

Hi megous,

Many thanks for your work, it is great and truly appreciated. The time from press-power-on to pboot-main-screen is so incredibly fast.

Currently my most wanted feature would be as bujiraso suggested 'Boot to eMMC' (either as an option in the menu or as a key combination or both). I have tried power+volume-up but that did not seem to work. So currently I do a lot of micro-sd shuffling to switch between eMMC and pboot (too bad the micro-sd is not accessible without opening the phone on the current model, I hope Pine will consider an external slot in a future design). Is there a way to get boot to eMMc to work with present version, maybe by patching a file or something other tweak?

Lukas

[megous]

Hi megous,

Many thanks for your work, it is great and truly appreciated. The time from press-power-on to pboot-main-screen is so incredibly fast.

Currently my most wanted feature would be as bujiraso suggested 'Boot to eMMC' (either as an option in the menu or as a key combination or both). I have tried power+volume-up but that did not seem to work. So currently I do a lot of micro-sd shuffling to switch between eMMC and pboot (too bad the micro-sd is not accessible without opening the phone on the current model, I hope Pine will consider an external slot in a future design). Is there a way to get boot to eMMc to work with present version, maybe by patching a file or something other tweak?

Lukas

Oh, right. It works if you also use p-boot for eMMC. It doesn't work as bypass to run U-Boot from eMMC. That would be quite a different matter.

p-boot would have to load U-Boot's SPL over itself and execute it. It would have to get out of the way too, first. Kinda complicated.

---

For package managers that use signatures, you typically need to have time set up correctly on your phone, because certificates are issued for a certain time window.

Also apparently package managers don't like to hit files that I marked as unchangeable, and instead of ignoring them, they fail the whole update. Workaround is to remove immutable flag on those files, back them up before update, and copy my versions back after update. It's usually various modem scripts.

Better fix may be to use NoUpgrade NoExtract options of pacman and equivalent options for other package managers, next time.

---

Looks like pacman and dpkg have ways to ignore select files by specifying the ignored files in the configuration files. Alpine package manager doesn't even have a config file that I can find, and it doesn't look like it has this functionality, so not sure how to work around this issue on distros that use it. Maybe someone else has some suggestions?

PMOS-Plasma is hopeless, you can't set the timezone, changes just don't stick.  But the clock is right, correctly displayed in GMT.  PMOS-Phosh has the right time and timezone so that is where I started digging first.  Tracked it down.  /etc/apk/keys is empty.  You are defaulting to having device mapper claim /dev/mmcblk2, but I didn't bother encrypting my preload, so had to figure out a way around that.   Then it was easy enough to copy the keys from the preload install over and the error about untrusted repos went away. Now it has a dependency issue.

# apk upgrade
ERROR: unsatisfied constraints:
  cmd:kpartx (virtual)
  provided by: multipath-tools
  required by: postmarketos-mkinitfs-0.14.1-r1[cmd:kpartx]

Made any changes in any of that or is that just life on the edge and it will get fixed upstream in a few hours?

All changes that I made have original files backed up in /.xnux dir. I didn't make any changes related to package management. If keys file is empty it was empty in the original image too.

I also don't use device mapper, so not sure what that comment is about.

[jmorris]

All changes that I made have original files backed up in /.xnux dir. I didn't make any changes related to package management. If keys file is empty it was empty in the original image too.

I also don't use device mapper, so not sure what that comment is about.

Haven't used pmbootstrap yet, just been using the preload so far.  So can't say if it installs keys, but one would think so or it wouldn't work?  alpine-keys looks like where some of them should be installed from, not clear where the postmarketos key comes from.  Haven't found the apk equiv for rpm -qf <filename> to track down what package owns a file.

When pmos was running I couldn't mount /dev/mmcblk2p2, looking in /proc/partitions revealed dm-0 and dm-1, clearing those out allowed mounting the preload to get to the keys.  Something cranked up device mapper, so many layers to crawl through to figure out what and why. 

Also see another issue.  When running pmos from your kernel the only governors are menu and ladder, while preload pmos is running the options are "ondemand userspace conservative performance schedutil" and conservative is picked.  Difference is when connected to a USB 2.0 port the battery stays in Discharging state on your kernel because drain is always over 600mA.  On the preload it will charge to the high 90s and then begin flopping between discharging and charging.  And of course on all OS options tried to date there is nothing visible when plugged into a USB 3.0 port.  Fun.

And gotta ask a silly question.  What is the point of Arch on the image?  It boots to a text mode login and there isn't an onscreen keyboard.  Tapping the power button will do a clean shutdown to get out but can't see what else to do with it.  WiFi has to be configured first and it doesn't show a USB network device so can't ssh in.  Try a USB hub and keyboard?

EDIT: Nope, confused on idle governors and cpufreq governors. So back to looking for a difference between the kernels to explain the different battery behaviour.

[Braveheart]

Hi @megous. Thank you very much for your enormous work.

Will this be the last image of the multi-distro? In case it is not the last one, when will you update it?

I ask if I should download the image now or wait a bit for it to update.

Will you add more operating systems?

[quixote]

Thanks so much for this! Really cool for trying out OSes. Mobian is much further along than I realized. Sailfish looks like it could be fun, but the "skip" link on their page to "set up a Jolla account" doesn't work. So I skipped Sailfish instead LuneOS has nice design work. I'll definitely be checking them out when they're further along. This is great!

[LinAdmin2]

Hi @megous. Thank you very much for your enormous work.

Will this be the last image of the multi-distro? In case it is not the last one, when will you update it?

I ask if I should download the image now or wait a bit for it to update.

Will you add more operating systems?

Since you did not yet get an answer I assume that this multi boot has rather been an intersting one time gimmick.

[wibble]

Hi @megous. Thank you very much for your enormous work.

Will this be the last image of the multi-distro? In case it is not the last one, when will you update it?

I ask if I should download the image now or wait a bit for it to update.

Will you add more operating systems?

Since you did not yet get an answer I assume that this multi boot has rather been an intersting one time gimmick.

Or that megous only looks at the forum from time to time, in between doing other good things that benefit the rest of us. If you're interested in doing some of the work for an updated version yourself the toolchain is published, and not hard to understand:
https://megous.com/git/pinephone-multi-boot/tree/

[megous]

Hi megous,

Many thanks for your work, it is great and truly appreciated. The time from press-power-on to pboot-main-screen is so incredibly fast.

Currently my most wanted feature would be as bujiraso suggested 'Boot to eMMC' (either as an option in the menu or as a key combination or both). I have tried power+volume-up but that did not seem to work. So currently I do a lot of micro-sd shuffling to switch between eMMC and pboot (too bad the micro-sd is not accessible without opening the phone on the current model, I hope Pine will consider an external slot in a future design). Is there a way to get boot to eMMc to work with present version, maybe by patching a file or something other tweak?

Lukas

Hi,

I released a new version of p-boot today (https://xnux.eu/p-boot/p-boot2.jpg). You can try updating the multi-boot image with it. It has reboot to eMMC feature, among many other changes. I can not update kernel yet, because my latest kernels include the mainlined audio patches, which have different alsa control names from those distros expect, and that's currently blocking the release of updated multi-boot image (for the last month or so).

But updating p-boot alone should work. Not sure how p-boot's 60 FPS LCD support will interact with unpatched kernel, but hopefully it will work just fine.

p-boot.bin is available here https://megous.com/git/p-boot/plain/dist/p-boot.bin (md5sum 91394ee1ec405295d255396c1a6b9a66)

You can update it by dding it to a right location in the image.

So for example:

dd if=p-boot.bin of=/dev/mmcblk0 bs=1024 seek=8

or on PC:

dd if=p-boot.bin of=/dev/sdX bs=1024 seek=8

where /dev/sdX is the whole SD card block device, not partition.

You can also backup the previous p-boot first

dd of=p-boot-bak.bin if=/dev/sdX bs=1024 skip=8 count=32

---

Hi @megous. Thank you very much for your enormous work.

Will this be the last image of the multi-distro? In case it is not the last one, when will you update it?

I ask if I should download the image now or wait a bit for it to update.

Will you add more operating systems?

Since you did not yet get an answer I assume that this multi boot has rather been an intersting one time gimmick.

Or that megous only looks at the forum from time to time, in between doing other good things that benefit the rest of us. If you're interested in doing some of the work for an updated version yourself the toolchain is published, and not hard to understand:
https://megous.com/git/pinephone-multi-boot/tree/

This ^^^ + there are some things making the new release hard currently, mostly around mainlined kernel codec driver changes being incompatible with what distros expect. Some distros are moving forward with supporting the new kernel, but it's not currently possible to run a single kernel that will work with all distros. The new release is in my plans, though.

---

Hi @megous. Thank you very much for your enormous work.

Will this be the last image of the multi-distro? In case it is not the last one, when will you update it?

I ask if I should download the image now or wait a bit for it to update.

Will you add more operating systems?

I'll probably do a new release around 5.10-rc3 (say, mid november). I plan to add jumpdrive. What OS do you have on mind?

---

All changes that I made have original files backed up in /.xnux dir. I didn't make any changes related to package management. If keys file is empty it was empty in the original image too.

I also don't use device mapper, so not sure what that comment is about.

Haven't used pmbootstrap yet, just been using the preload so far.  So can't say if it installs keys, but one would think so or it wouldn't work?  alpine-keys looks like where some of them should be installed from, not clear where the postmarketos key comes from.  Haven't found the apk equiv for rpm -qf <filename> to track down what package owns a file.

When pmos was running I couldn't mount /dev/mmcblk2p2, looking in /proc/partitions revealed dm-0 and dm-1, clearing those out allowed mounting the preload to get to the keys.  Something cranked up device mapper, so many layers to crawl through to figure out what and why. 

Also see another issue.  When running pmos from your kernel the only governors are menu and ladder, while preload pmos is running the options are "ondemand userspace conservative performance schedutil" and conservative is picked.  Difference is when connected to a USB 2.0 port the battery stays in Discharging state on your kernel because drain is always over 600mA.  On the preload it will charge to the high 90s and then begin flopping between discharging and charging.  And of course on all OS options tried to date there is nothing visible when plugged into a USB 3.0 port.  Fun.

And gotta ask a silly question.  What is the point of Arch on the image?  It boots to a text mode login and there isn't an onscreen keyboard.  Tapping the power button will do a clean shutdown to get out but can't see what else to do with it.  WiFi has to be configured first and it doesn't show a USB network device so can't ssh in.  Try a USB hub and keyboard?

EDIT:  Nope, confused on idle governors and cpufreq governors.  So back to looking for a difference between the kernels to explain the different battery behaviour.

To charge from PC port you either need to suspend the phone, or power it off, or use some DCP/CDP charger. Pinephone is USB2.0 device, so it can't detect USB3.0 port easily and up the current limit to 900mA.

Point of arch is to run whatever you want. You can install anything you like inside, like i3wm, or some other desktop environment. You can control it over USB keyboard, or via serial port. I may add an option to use emulated USB serial port too, if I figure out what to put to kernel command line. That is the Arch Way TM.

[Avisando]

Hi megous. Thank you very much for making this valuable project available to us. I look forward to the next version of your work.

Would it be possible to include an option that allows to reinitialize the "multi-boot image" eliminating all the changes introduced by the user ?.

PS: I hope you consider including Glodroid in your OS list.

[utopiah]

Thanks for the great work. It's one of the most convenient way to showcase how much freedom we get from having a device we truly own.

I discovered just earlier today via Pinephone first steps https://scattered-thoughts.net/writing/p...rst-steps/ that there is also Mobile NixOS dedicated for the pinephone https://mobile.nixos.org/devices/pine64-pinephone.html with builds couple of weeks old https://hydra.nixos.org/job/mobile-nixos...6_64-linux

It could be interesting to make it available too.