PPP may be a long wait for viability.

[Chief]

After doing plenty of reading and research into my PPP and several operating systems installed I have realized that the PPP has got quite a ways to go before it can be used reliably. At present my device will once again not boot but I have been through this before and successfully recovered it -- but for what? The device is unreliable and I decided to box (just like the cylons in Battle Star Galactica). I already have two PP Convergence and they run nicely but I have also noticed that the rolling release concept of updates can also hurt your reliability. After a problem in the last update on my PPC concerning Uboot and Settings updates it caused my device to sleep and then require a hard boot to recover. This is a first problem with PPC in my opinion and experience. I have now realized that updating is not a great idea so I suggest once a standard of good has been achieved, your happy with device operation - don't update. Freeze it right there in that sweet spot. I had to flash my PPC with Arch Linux 2022-05 version which by the way included those updates and the device is fine - perfect. So I think I might wait with my PPP until the end of the year and then look at the latest versions after reading about any issues concerning the version history. I will then select that good version and flash that, then do initial update and then stop. This might be the best scenario overall in my humble opinion.

-I would love to see the equivalent of a Lubuntu  LXQT LTS type image for Pine phones of all sorts. This could be a direct competitor to Arch Linux and because of the LTS concept of Debian/Ubuntu may be quite reliable.

[wibble]

The distros are still in the 'move fast and break things' phase trying to fill in the gaps in expected functionality for a pure linux smartphone. Until those gaps close we're unlikely to see a distro we'd think of as stable, but there are workarounds.
* backups before upgrade - so you can revert to the previous working state if an upgrade doesn't go well
* parallel 'stable' and 'testing' installs, either to separate partitions selected with p-boot, or on eMMC and uSD. Upgrade the 'stable' one when the 'testing' one is sufficiently reliable, or swap which one you consider which.
For some distros you could probably do an install to a btrfs rootfs and use snapshots before updates too.

[Chief]

The distros are still in the 'move fast and break things' phase trying to fill in the gaps in expected functionality for a pure linux smartphone. Until those gaps close we're unlikely to see a distro we'd think of as stable, but there are workarounds.
* backups before upgrade - so you can revert to the previous working state if an upgrade doesn't go well
* parallel 'stable' and 'testing' installs, either to separate partitions selected with p-boot, or on eMMC and uSD. Upgrade the 'stable' one when the 'testing' one is sufficiently reliable, or swap which one you consider which.
For some distros you could probably do an install to a btrfs rootfs and use snapshots before updates too.

Hi Wibble ... I agree with the move fast or bust concept and yes this will be the case in a betabetabeta type situation
Yes back everything up first and then take the chance on update. What I was suggesting is similar in that instead of zillions of updates and precautions why not wait until a period of time and then flash the most up to date system as a one timer. It's another option to deal with the ever changing scenario. When you mention "backup" are you suggesting using Gnome-Disks to capture a present .img? If so that might be a good idea as well. All the programs that a person installs could also be captured on the .img

[wibble]

If I was trying to sue it as a daily driver I'd probably use tow-boot's USB mass storage boot option and take a whole device image to my desktop machine so I could put it back exactly as I left it before the upgrade. Whether that's a raw device image with dd, or a partition-aware and filesystem-aware imaging tool that can save and restore only the used bits is a personal choice. They each have pros and cons - the dd image is bigger and takes longer, but can be loop mounted to get stuff out of it more easily. Whether you're using encrypted filesystems might force your hand - I don't know if the filesystem-aware ones handle that.

On the openmoko I had multiple partitions to pick from at boot, but its u-boot could use the screen as well as buttons so it was more like the p-boot experience on the PP and I don't think it's a viable option on the Pro. The Qi bootloader that appeared later was closer to the tow-boot experience from what I remember, and limited the options somewhat for the benefit of being faster.

[Chief]

I will have to look at the towboot mass USB image. never noticed that before.
Thanks friend.

[wibble]

https://tow-boot.org/devices/pine64-pinephonePro.html

At the bottom under Additional Features:
"The phone can be started in USB Mass Storage mode by holding the volume up button at startup before and during the second vibration. The LED will turn blue if done successfully. In this mode, the phone will work like a USB drive when connected to a host computer."