Topics created by Dave

@Dave said in UBports firmware for device "Volla Phone 22 with new display (mimameid_h12)" does not boot when using the "stable" or "rc" channels.:

So is it a good idea to run 20.04/devel on Volla 22 phone for daily productive use?

Since the devel channel is the only one that boots for you (not sure what is going on there, but since you are experiencing it, you are the expert) then I don't think you have much choice in the matter for now.

Overall the devs try to keep the devel channel as functional as possible, but eventually an update will be available that will break your OS in some way.
One measure you can take to keep this to a minimum is not to update your OS every time there is an update. If you have a configuration that mostly works, stick to that and resist the urge to update every time you notice there is a new update available.

Another way to go is to keep an eye on the forum. There usually is a post warning about an update that breaks devel. But since devel is updated daily, you might see the post too late.

The Phone Service Berlin shop today replaced the display of my Volla22 phone. The display appears to work, as far as can be judged by looking at the fastboot screen or recovery image screen, or the installation screen ("installing system image").

However, the installed Volla Phone 22 with new display (mimameid_h12) firmware does not boot. After installation, and whenever I switch on the phone, the phone is stuck in the bootup greeting screen showing volla~~~ in white letters on black screen.

In that stuck state, a short press on the power button just switches off the phone. Is this the Volla phone's boot loader?

Note that this problem cannot be explained by phone damage. Before the screen was replaced, the phone did boot and work "normally" with the standard Volla firmware image. And the same "stuck at boot" problem already happened when installing the "Volla Phone 22 with new display" firmware on the not yet repaired phone. Just at that time I attributed the failing boot to the firmware not being compatible with the old display (see post above).

edit: the phone now booted, after installing the "devel" channel of the Volla Phone 22 with new display (mimameid_h12) firmware.

I also created a dedicated topic for the problems concerning the Volla Phone 22 with new display (mimameid_h12) firmware image:

https://forums.ubports.com/topic/10395/ubports-firmware-for-device-volla-phone-22-with-new-display-mimameid_h12-does-not-boot

@Dave a quick check shows that the current server certificate for that site was issued on October 11th and is valid until Jan 2024.

Could you check if the date and time is set correctly on your family member's device?

@kugiigi no it's not urgent, but I would be glad if ubports did not lose support for japanese in the long run. I also know some people who will not be able to upgrade to focal, unless japanese input is restored, but they may not mind to wait a little longer.

@Dave I just had the same problem. When I tried to open https://ubports.open-cuts.org/ in Firefox, it gives a certificate error as well.

THANK YOU! I have spent months wondering why I could suddenly no longer read the forums on my browser of choice, and had to fall back on my secondary. You gave me the pointer I needed.

This seems to be a general problem with IPv6 access to cloudflare CDN from my location.

Same things happens e.g. for linux.die.net, too

$ wget -6 https://linux.die.net -O/dev/null --2023-07-12 11:16:32-- https://linux.die.net/ Resolving linux.die.net (linux.die.net)... 2606:4700:20::ac43:45bb, 2606:4700:20::681a:5e, 2606:4700:20::681a:15e Connecting to linux.die.net (linux.die.net)|2606:4700:20::ac43:45bb|:443... connected. GnuTLS: Error in the pull function. Unable to establish SSL connection.

both system-image.ubports.com and linux.die.net appear to be hosted via cloudflare CDN.

@Lakotaubp thanks for the clarification.

Replying to myself, I started reading in the original Volla phone kernel sources. Looking at dm-crypt.c it seems that it has patches that add some very specific (and broken) hacks to accommodate Mediatek hardware encryption (everything that depends on CONFIG_MTK_HW_FD which is set on the Volla's phone kernel).

This function seems to be the culprit. It escapes me how anybody could throw this kind of hack into a production kernel:

/* * MTK PATCH: * * Get storage device type (for hw fde on/off decision) * or id (for crypt_config). * * Returns: * 0: Embedded storage, for example: eMMC or UFS. * 1: External storage, for example: SD card. * -1: Unrecognizable storage. */ static int crypt_dev_id(const char *path) { int type = -1; if (strstr(path, "bootdevice")) { /* example: /dev/block/platform/bootdevice/by-name/userdata */ type = 0; } else if (strstr(path, "externdevice") || strstr(path, "vold")) { /* example: /dev/block/vold/private:179,2 */ type = 1; } pr_info("[dm-crypt] dev path: %s, type: %d\n", path, type); return type; }

So whenever you are trying to device-map some block device that does not have any of the substrings "bootdevice" or "vold" or "externdevice" in them, this returns -1, which in turn will break any attempts to use such a device in the device-mapper, thanks to the over-strict check added in crypt_ctr():

cc->id = ret = crypt_dev_id(argv[3]); if (ret < 0) goto bad;

Note how e.g. any loop device /dev/loop* will thus fail. However, this also allows a workaround. We just use a different name (with the same major/minor device numbers) that matches 'externdevice'. This way dmsetup will magically start working:

cp -a "${LODEV}" /dev/externdevice1 echo "0 128 crypt aes-ecb 0123456789abcdef0123456789abcdef 0 /dev/externdevice1 0" | dmsetup create crypt2

However, I am not sure whether this kind of workaround could be applied to 'cryptsetup'.

This really destroys any illusion WRT to code-quality of the kernels that is running the Volla phone.

@flohack yes I had similar reservations which kept me from trying this. However, looking at the recipes documented here (i.e. mostly the shell script fragments by @chrisc and @c4pp4), this looks quite doable.

They're just encrypting /home/phablet. After reboot /home/phablet is non-encrypted. You run a shell-script to replace it with a dm-crypt encrypted loopback block device and restart the lightdm session. Still quite cumbersome, but still better than no encryption at all.

Maybe adding a launcher as described here for running the crypto-mount script in the terminal will make this more practical.

I'm not yet done setting this up, as I was set back by that Mediatek related dm-crypt bug in the kernel that ships on the Volla Phone. But no real show-stoppers so far.

@dobey said in Security of data and passwords when phone is lost/stolen:

This is only true if the bootloader is already unlocked, or the device has a bug where unlocking the bootloader does not perform a system reset and destroy all data. Newer devices do not necessarily require "authorization" either, but just have a more complex process where you have to also set an option from within the booted Android system.

You're right. Completely forgot that unlocking forced a wipe. Thanks for the correction.

Newer devices do not necessarily require "authorization" either, but just have a more complex process where you have to also set an option from within the booted Android system.

Yes, that process is what I'm referring to when I say unlocking must be authorized from within the stock OS before it can be done to newer devices. (i.e., "must be flagged as unlockable from within developer settings" in the earlier post. I probably should have added the word "manually" before "flagged" to make that clear.)

Hi @advocatux ,

I ran into the same "signature error", attempting to update my Aquaris 10 FHD tablet. As I don't mind breaking the tablet (as opposed to my phone), I just attempted to upgrade using the development channel, which worked (i.e. no signature error), then once that was running switched back to the stable image, and this time no signature error as well.

Working nicely now, no problems, some bugs I encountered with 15.04 seem to be fixed with that release. Very happy. Will attempt the same procedure on my phone.

Dave

@Dave I think most of those issues will have been covered already as the update to 16.04 is nearly a year old now. I would get upto date with everything and check all is ok and go from there. If you are still having issues please come back here for help.

@advocatux said in Community infrastructure: Forum and Telegram:

@guru said in Community infrastructure: Forum and Telegram:

+1 for using the (existing) mailing-list as primary channel for technical discussions and support.

Are you talking about the UBports's ones or the old Canonical's Ubuntu-Phone list?

Both would do the job. The old one even better because a lot of UT users are still subscribed there and would may be encouraged to move to the UBports devices.

I'm pretty sure that the installer does not touch the partition layout.

Remember

Android is weird. I wouldn't be surprised if some devices/bootloaders have specific expectations about the partition layout these are embedded devices. If the bootprocess is severly messed up, you can't exactly put the hard disk into that other device and fix the partitions

So, while I guess it is possible to make cache smaller, I am not gonna try on my device and I'd caution you to do so!

Now to the aspect of "I'm running out of space" due to tinkering with libertine, ... well you still have some 6GB to through around, not huge, but not nothing either. If you run out of space, rather than doing acrobatics with partition sizes you want to look into acrobatics with bind mounting 😉

You could try and if it works document it here

https://docs.ubports.com/en/latest/userguide/dailyuse/libertine.html

I'd also try first with a symlink, but if that gives any problems, I would assume a bind mount should work. but then you have the additional challenge of having to reestablish the mount after every reboot. maybe it can be automated with upstart.