Hi eselarm Thank you for your post. I can't still find a button to answer directly to your post in this forum. If I replace the HW - and I could afford it - then the question of migration to the new platform arises. Nextcloudpi worked fine on armbian releases, there is no point in changing the OS. Obviously it is close enough to debian so the "port" from debian to armbian is not very difficult. As long as the same base version (bookworm, trixie) is used. Even debian 12 did not support the required PHP version 8.1 at the time, nextcloud required it. But nextcloudpi still did the update to that nextcloud version with the result of nextcloud not running. I host nextcloud at home and I don't want a fan running at full speed in my living room. The "generic x86-64" (or amd64) is really no choice. Once I bought a WLAN router with built-in room for a disk but even with no disk installed the fan did run and couldn't be stopped. Returned it. I heared about proxmox, docker. LXC and LXD. For the latter there are images for x86-64 HW with nextcloudpi provided. But choosing the right HW and do the migration to it seems difficult to me. Regards Norbert

Yes the WTL-40110175 3.8v 10.000mAh battery has 3x red (PB+) and 3x black (PB- GND) and 1x yellow (Overvoltage?) or Temperature) Here in Turkey I do only find a 3.7v 10.000mAh Cell, but without the yellow cable (only red and black): https://www.n11.com/urun/1260110-37v-10000mah-li-polymer-pil-devreli15a-87767963 The battery PDF gives me very less clues Pinebook-WTL40110175-3_8V-10000mAh-14inch.pdf

Hi geoW Couldn't find any button to reply to your answer to my question in this forum 😐 . But here it goes: I know well how to do updates of armbian, nextcloud and nextcloudpi and how to use ncp-config. I configured it even to do the updates automatically but was burned twice - once with Armbian OS (didn't boot because of compressed kernel modules) and once with nextcloudpi updates to nextcloud without prior checking the required PHP version (8.1). So, no automatic updates any more, but manual checks, of course. I have configured an RSS feed to the nextcloudpi github page. That didn't include the never officially released version 1.55.4 of nextcloudpi, of course. In the release notes for nextcloudpi (v1.55.3) it mentions support for nextcloud 30. See the github page: Nextcloud 30.0.1 (can be automatically updated to latest minor version) PHP 8.3 Debian bookworm Armbian v24.08 Fine. There are no release notes for version v1.55.4 nor where this one officially released, at all, just tagged. So, where do you get the information that an update to nextcloud version 31 is supported by this version of nextcloudpi (v.1.55.4) ? Did you successfully update nextcloud to version 31.x with this version v1.55.4 of nextcloudpi ? Where do you get the information about someone working to allow updates to nextcloud version 32 via nextcloudpi ? Unless there is an official report about this, I won't simply update my installation. So, my original question is: what to do after the end of support for version 30.0.x ? Added: OK, I see: you are running one of the provided images for your Raspi5. I don't have a Raspi 4 or 5, That's why I posted my problem in this forum. So the story is: There is no support for any HW except for the images provided. I agree, that Nextcloud GmbH is overflowed with european requests for offers and work due to the politics of the orange head in the US. This is favourable in my opinion. So, my impression is that, obviously, nobody cares about the few nextcloudpi users not running nextcloud on HW other than on the images provided. Regards Norbert

In the end, I couldn’t recover the device and ended up purchasing a new one. It was also a V5.1 board, but fortunately, it booted from the SD card without any extra steps and installed successfully. It seems we should keep in mind that even boards with the same version may not always work the same way.

There are schematics available for this device, so one could get a hint from those, but depends if you have electronics background or not. To me it seems that higher level software in Debian/Linux enables power management handling all the way using info it gets from the power management chip/circuitry. You can guess that for this device, same as smartphone, battery operation is considered primary/essential, so decision is 'low-batt' and shutdown. I have a BananaPi M1 that also has LiPo charging, but that is DIY soldereing, so no OS component bothers with not-connected cell, but if a cell is connected/soldered which I did, is charges and runs on that cell if microUSB PSU (they call it 'AC' in the chip signal names) is disconnected, although its SATA port is unpowered then. Runs Armbian Trixie CLI only (eth + serial console). An old business HP 2-core laptop that I got without battery and HDD runs fine on just the original HP power adaptor (has 3rd wire for some genuine HP charger purposes). For USB-C powered devices, there might be many things to deal with, e.g. my ROCK5B after un-boxing goes in a bootloop with a RPI5 PSU, was/is know, so I feed it with own 12V USB-C pig-tail. For the Pinebook, it might be that the 5V is perfectly 5.000V but drops to 4.900V or so in spikes under load, so the typical 5V SBC powering issue well-known from RPi and other cheap SBCs that cannot handle >5V USB PD voltages. The Pinebook might do well if you fake the battery, so look at colored wire/connector. I have used that several times in the past decades. The yellow wire might be for temperature so besides a proper voltage on black and red, you also need to do something with the yellow wire I guess. It also might be that is you skip/disable the parts of software that do power management handling, that it runs fine. So I would boot/run the 'image' of the pinebook in a systemd-nspawn container or libvirt VM (at least the user space) and see what is what. Maybe it is something like purge 'laptop-tools' package or so, or blacklist the kernel module for power management.