This is kind of silly, but I wanted to report I got a virtual machine running with QEMU/KVM on my UBPorts CE Pinephone. I'm using Mobian with phosh and Mate installed. Virt-manager did most of the lifting.
With a gig of memory for each OS it isn't speedy, but it does work. My goal was to get the abandoned media player Banshee running on my phone. My vm is Ubuntu 17.04 arm64, installed as Ubuntu Server and then with xorg, xdm, fvwm, pulseaudio, and Banshee.

Has anyone tried using petitboot on this particular SBC; if so, were you able to get it working successfully?  Is anyone aware of a compiled list of instructions for getting that boot loader up and running?  

On a somewhat related note, I haven't been able to get my board to boot from the SD card slot; I've read that I'll need to jumper some cables to bypass eMMC booting, but have no idea what jumping means.  Are there any pictures of what I'd need to do to the board in that situation?  

Thanks

Mine:  Pine64 mobian/debian CE, full first update successful...

I've seen green and blue indicator lights, but don't understand what they're signaling. Are these hardware-specific, operating-system (mobian/debian), or application specific?

Thanks

Just received my Pine64 mobian Community Edition, and with Pine64.org forum help, completed the massive first update.
Lovin' it.
   But is there any sort of online User Manual for the mobian edition?  Or do we just rely on Q&A in the Forum?
   And, for "Search" purposes in this forum, I'd ask everyone to BE SPECIFIC in the Thread Subject  - Thanks.

Thanks!

Would the raspberry pi be able to sync the time and date on my time? I’d yes would anybody be able to recommend any apps that would be able to do it? I have heard of gadgetbrodge but I don’t think that is on the pi or I haven’t seen any videos or info on it

Hello,

got a PP KDE CE and started using p-boot[url=https://xnux.eu/p-boot-demo/][/url] bootloader to compare OOSS.

Using my SIM, I'm experiencing trouble with data downloading

Of course, searched for the right APN on the (Italian) carrier website and write it in the Manjaro / Phosh beta2-20201119 OS, Manjaro / Plasma201122 and Ubuntu Touch settings page.

The message is always the same (Manjaro / Plasma201122 and Ubuntu Touch):

"ERR_NAME_RESOLUTION_FAILED",

and (Manjaro / Phosh beta2-20201119 OS):

"...
If the address is correct, here are three other things you can try:
Try again later.
Check your network connection;
If you are connected but behind a firewall, check that Firefox has permission to access the Web".

On the other side, WI-FI, calls and SMS never gave me problem with the OOSS above.

No treads on this issue, I guess.

Any help?

Many thanks.

How can i get updates on when some products will be on stock again in the store without manually checking every day? Do the Pine64 newsletter cover this? Or is there any RSS i can follow?
Thank you in advance!

Hello All,

Received my KDE Plasma Community Edition two days ago.  Pretty exciting...however I realize it is is over my head and requires more tinkering time than I can currently afford.

I was able to perform the updates and was successful in sending and receiving calls with an AT&T sim.   So far only receive texts but not send.  In general I have had success with the the port / all usb, Ethernet and HDMI.   I know there have been issues in that dept.  Otherwise the phone is still pretty much as received.

At any rate...I would just like to recoup cost not looking to make a profit.  It should of course just be in more capable and deserving hands.  I am in New Mexico, USA so would prefer making arrangements with someone here in the U.S.

Hi Pine64'ers

Update: There is now a wiki where ideas from this thread are consolidated: https://wiki.pine64.org/wiki/PineFlash

I had a crazy random idea, but I think it is worth exploring. Open to some feedback.

I propose Pine64 looks into creating custom open-source flash drives. I think these are devices we all use regularly and I think there is some great opportunity to improve on them!

# Why?

Currently, flash drives are almost exclusively closed-source. This poses a few major problems:

1. Security: You have zero idea what is running on the drive. It would be exceptionally easy for example to change a file at will. Imagine this happening to an SSH key for example, which is quite easily recognizable.

2. Corruption: We've all been in this scenario where a flash drive suddenly fails without warning.

3. Encryption: Some drives offer "encryption", but this rarely includes the memory itself and if it does, it's all done client side. And then you have to trust this is actually robust and trust the implementation.

4. Planned Obsolescence: In theory a drive could purposely give out after so many writes or reads, forcing you to go out and buy another.

# Opportunities

I think there are tonnes of opportunities to improve on existing designs:

1. RAID: If you were to use several lower-capacity flash chips (which could also end up cheaper), the community could explore RAID to increase either speed, redundancy or both! This would need a minimum of two chips, ideally four.

2. Cache: It could be possible to do some intelligent caching - for example if you know a particular format is being used, you could cache the file table.

3. Encryption: Of course the big one could be some form of encryption. This could make this an attractive option for people who travel or want some protection! You may even want the drive to display something entirely different until some password is provided to reveal the real contents.

One way this could be done is to have it first present a small blank file system, where either the user or some script copies a key (possibly in response to some content already there) to the drive. The drive could then unmount and remount as the full drive and use this to decrypt the rest of the contents.

4. Wear Leveling: Just because companies claim to have really good wear-leveling, doesn't mean they actually do.

5. Compression: It might be possible to compress certain types of data. There are a few algorithms, such as LZ4 that don't really add too much overhead if they are unable to compress some data, but could yield large returns on compress-able data.

6. SMART: The drive could provide a SMART table to provide information about disk wear (the same thing SSDs do). This could even be calibrated to temperature and time for example.

7. Type A & Type C USB: Type C is likely the future, but there is also tonnes of devices still using type A. It would be cool to have a device that is robust for both.

8. Casing: A nice little piece of positive PR with the Pine64 logo

# Expectations

I imagine the first version will realistically only support USB 2 speeds at most, possibly USB 1, but I expect this community to be capable of getting up to USB 3 speeds after a few iterations.

There are some flash chips and USB controllers that already do most of the work, so this could greatly reduce the risk of v1 not working at all and to work on one problem at a time.

# Long-term

I suggest this could lay some ground-work for a custom M.2. drive, something some current Pine64 devices support and something I think future Pine64 devices will make more use of.

Open to ideas!

For those who have isses with the Firefox adress bare as described here:

https://wiki.postmarketos.org/wiki/Phosh...ooks_weird

make shure the mobile-config-firefox package is installed (is in by default)
create a directory ~manjaro/.mozilla/firefox/<profile>/chrome/
copy /etc/mobile-config-firefox/userChrome.css to ~manjaro/.mozilla/firefox/<profile>/chrome/