I just got a PinePhone pro! Let me preface what follows by saying that I believe in owning my computers, and to me, this means being able to open a local shell and run mainline drivers. I am a somewhat normal user in the sense that I’m not super concerned about privacy and such. This is my first impression after ~2 hours of use of a PINE64 PinePhone Pro.
So far, I’ve found several usability issues after taking the phone out of the box and setting it up. Most of these affect a broad audience (e.g., anyone who wants to install packages, anyone who wants an escalated shell):
The user password KDE asks for does not work for the login shell. AFAICT, the pin is used for this purpose. I kept trying to elevate my shell with my password instead of my pin and for awhile thought I’d have to boot another image, chroot, and reset my password that way. I only thought to try my pin as a last resort. This could be simplified by using the KDE password, instead of the pin, as the login password.
This also creates a minor security issue, since PINs use only a subset of the characters available for a free-text password.
By default, pacman is missing the “archlinuxarm” and “manjaro-arm” keyrings, which cause confusing errors when trying to install packages for the first time. This could be simplified by shipping an image that includes these keyrings, and including them in the default Manjaro-Plasma ARM images.
Existing packages don’t work out of the box, including some basic ones. For example, vim won’t start after I install it from pacman because it’s missing the libperl dynamic library.
This was a design choice by the KDE developers, to use a separate PIN for the login screen.
By default, the user you set up on first boot has the same PIN and password.
These keyrings are shipped with the image. Else you wouldn’t be able to update or install anything.
The keyrings get populated on first boot.
vim has a runtime dependency on perl. It’s exactly the same as it is on x86_64.
This was a design choice by the KDE developers, to use a separate PIN for the login screen.
By default, the user you set up on first boot has the same PIN and password.
[Questionable design choice: prompting for PIN and password, then only using PIN] The setup process asked me for both a PIN and a password. I’m now pretty curious as to what the password is for. I think we can agree that if this had not asked for a password, the logical assumption would be password == PIN. Perhaps setup ought not to ask for a password then?
These keyrings are shipped with the image. Else you wouldn’t be able to update or install anything.
The keyrings get populated on first boot.
[Possible bug] I was not able to update or install anything until I set up these keyrings manually. It seems like they were not populated correctly in my case. This was a pain, and probably would have taken me a lot longer to figure out than it did if I were new to Linux.
vim has a runtime dependency on perl. It’s exactly the same as it is on x86_64.
[User error] Perhaps this has more to do with the AUR than Manjaro ARM then. I installed Perl manually, and then vim worked.
First off, @Strit and others, thank you so much for the engagement here, and double kudos for doing this without pay. This already puts you above 90% of the user-facing product teams I’ve worked with in situations like this. More follow-up follows
The user setup has 4 fields.
Full name
Username
PIN/password
Confirm PIN/Password
In addition to those, the PinePhone out-of-box setup asked for a free-text password. This increasingly seems like a bug or partially stubbed-out (or partially removed) feature (see more speculation at bottom of post). If I get to it, I might try to run this down but for me it’s a low priority.
Did you install vim from the AUR for some reason?
Nope! I used pacman -S vim, which apparently installed an official package (see below). I assumed, incorrectly, it came from the AUR since it didn’t work out of the box (missing Perl runtime library). Manually reinstalling Perl, which was already present, fixed the issue. However, popping up a level, it seems counterintuitive that I should need to explicitly mess with perl to use vim, especially since perl is listed in the “Depends On” section for vim (see below).
Here’s the full package listing if you’re interested:
$ pacman -Ss vim
...
extra/vim 9.0.0135-1 [installed]
Vi Improved, a highly configurable, improved version of the vi text editor
...
$ pacman -Qi vim
Name : vim
Version : 9.0.0135-1
Description : Vi Improved, a highly configurable, improved version of the vi text editor
Architecture : aarch64
URL : https://www.vim.org
Licenses : custom:vim
Groups : None
Provides : xxd vim-minimal vim-plugin-runtime
Depends On : vim-runtime=9.0.0135-1 gpm acl glibc libgcrypt pcre zlib perl
Optional Deps : python: Python language support [installed]
ruby: Ruby language support
lua: Lua language support
tcl: Tcl language support
Required By : None
Optional For : pacman
Conflicts With : gvim vim-minimal
Replaces : vim-minimal
Installed Size : 4.58 MiB
Packager : Arch Linux ARM Build System <builder+seattle@archlinuxarm.org>
Build Date : Wed 03 Aug 2022 01:50:18 PM CDT
Install Date : Mon 05 Sep 2022 02:45:56 PM CDT
Install Reason : Explicitly installed
Install Script : No
Validated By : Signature
Some speculation:
I wonder if PINE64 uses the standard images or perhaps something else given the inconsistencies here.
Any chance the PINE64 factory might be pulling from intermediate/non-validated builds? I see a bunch of “Factory Image xxx” builds in Plasma Mobile Releases, which looks suspicious to me
Perhaps there are inconsistencies between the (UAT?) test environment and images being flashed by PINE64, especially around first-time out-of-box experience and keyring initialization.
The phone rebooted after gathering initial info like password, pin, username, name, etc. Could this be a different piece of software from what we test?
As far as I know, and I don’t know exactly how the factory does things, they get an image made from those factory images. The image they get contains the factory image from github and is wrapped by a script that installs Tow-boot on SPI and then flashes the factory image to the eMMC.
So those images are the official factory images that’s on the eMMC.
Again, as far as I know, PINE64 does not change anything on the images, so they should have the same user setup as the main images. And regarding keyrings, maybe the initialization did not manage to complete it time before the device rebooted.
For reference, here’s how the User Configuration page looks on the latest factory image:
