📳🔥 PixelFlasher, a GUI tool for flashing / updating / rooting / managing Pixel phones.

[badabing2003]

PixelFlasher v5.x on Linux MINT 21.1 (based on ubuntu 22.04LTS)

As already reported, I could not start v5.x PF with the message "ImportError: libws_baseu_net-3.2.so.0: cannot open shared object file: No such file or directory".

Based on the conversation on Github, I tried to build it myself using the latest 5.1.0.2 sources.
The contents of the execution are as follows, the result was that the PixelFlasher binary was generated under the dist subdirectory and was successfully started. (I've only tried starting PF for now)

Thanks for the update, its interesting, as the steps are identical to how the Ubuntu version is being built on GitHub except perhaps the WxPython part.
Did you needed to do pip install on the wxPython after doing the requirements?
requirements already includes wxPython building.
If yes, I wonder why.
I'd be very curious to know if you can find the path and the version of libws_baseu_net-3.2.so on your Mint OS,

 

[klazyStrida]

Thanks for your reply badabing2003.
Firstly, I have to say I'm sorry that I'm Linux newbie,
so Please forgive me for not being able to specifically convey important information.

The reason that I pip installed wxPython after installing requirements.txt was that it was guided to do so on "Build it yourself" PixelFlasher README.md, and I didn't quite understand the need to do so.

The installation package and installation path of libwx_baseu_net-3.* are as follows.
(libws_base* in previous post was my typo, sorry)
So libwx_baseu_net-3.2 was not installed, libwsbase3.2 is not registered in ubuntu 22.04LTS repository. but I was able to build and launch the generated PF binaries.

$ sudo apt search libwxbase
i A libwxbase3.0-0v5 - wxBase library (runtime) - non-GUI support
p libwxbase3.0-0v5:i386 - wxBase library (runtime) - non-GUI support
i A libwxbase3.0-dev - wxBase library (development) - non-GUI sup
p libwxbase3.0-dev:i386 - wxBase library (development) - non-GUI sup

$ sudo dpkg -L libwxbase3.0-0v5
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.5.0
/usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.5.0
/usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.5.0
/usr/share
/usr/share/doc
/usr/share/doc/libwxbase3.0-0v5
/usr/share/doc/libwxbase3.0-0v5/README.Debian
/usr/share/doc/libwxbase3.0-0v5/changelog.Debian.gz
/usr/share/doc/libwxbase3.0-0v5/copyright
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/libwxbase3.0-0v5
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
/usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0
/usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0

 

[badabing2003]

Thanks for your reply badabing2003.
Firstly, I have to say I'm sorry that I'm Linux newbie,
so Please forgive me for not being able to specifically convey important information.

The reason that I pip installed wxPython after installing requirements.txt was that it was guided to do so on "Build it yourself" PixelFlasher README.md, and I didn't quite understand the need to do so.

The installation package and installation path of libwx_baseu_net-3.* are as follows.
(libws_base* in previous post was my typo, sorry)
So libwx_baseu_net-3.2 was not installed, libwsbase3.2 is not registered in ubuntu 22.04LTS repository. but I was able to build and launch the generated PF binaries.

You don't have to be sorry for being a newbie, and in fact you're doing quite well for a self proclaimed newbie
I've seen my share of self proclaimed knowledgeables that don't do as well.

I see where the confusion might arise from the notes.
I'll try to make it clearer when I move it to a wiki.

Basically if requirements step works, then the manual pip install step is unnecessary, as it is already satisfied by the requirements step, on the other hand if it fails, then you would need to do the pip step again and repeat the requirements step.

Thanks for the update.

Update:
Just for kicks, I added that step into the Ubuntu 22.04 build action.
You can see from the logs, that it said it's already satisfied.

I don't expect it to make a difference for you, but I'd be curious to know if by any chance this build would work for you.

 

[badabing2003]

@klazyStrida
I think / hope this will do it. Let me know

Build for Mint 21.1 · badabing2005/PixelFlasher@991c54d

Pixel™ phone flashing GUI utility with features. Contribute to badabing2005/PixelFlasher development by creating an account on GitHub.

github.com

 

[klazyStrida]

I'm glad to hear that the information I've provided has given you some points to improve build workflow.

However, I myself do not have a github account yet, so as an anonymous user, I can only use it to see and learn about information posted on github. (There are many difficult things for elderly users like me, so I can't jump right in...)
When I saw the contents of mint_21_1.yaml and ubuntu_22_04.yaml created/updated this time, I learned for the first time that "this kind of content is written to execute build automation".

It would be nice if someone could actually test it and report back the results...

 

[badabing2003]

@klazyStrida
if you go to the link I provided, at the bottom part you'd see the artifacts, ie the build

Click on it and download, and see if it runs for you.
You don't have to look at the build logs.

Edit: Updated link
This is a direct link to the program built for mint.

 

[klazyStrida]

thank you for reply. but

if you go to the link I provided, at the bottom part you'd see the artifacts, ie the build
:: (snip)
Click on it and download, and see if it runs for you.

I can't download "PixelFlasher_Mint_21_1". it's not a link.
Maybe, It is necessary to be logged into Github.
Maybe the same reason, the Direct Link shown in your reply becomes "Page Not Found".

It may be better to create my account on Github as soon as possible...

 

[badabing2003]

thank you for reply. but


I can't download "PixelFlasher_Mint_21_1". it's not a link.
Maybe, It is necessary to be logged into Github.
Maybe the same reason, the Direct Link shown in your reply becomes "Page Not Found".

It may be better to create my account on Github as soon as possible...

I updated the link, see if that works, maybe without account it does not let you get the artifacts directly.
I placed it under the release 5.1.0.2

 

[klazyStrida]

I updated the link, see if that works, maybe without account it does not let you get the artifacts directly.
I placed it under the release 5.1.0.2

Sorry for the inconvenience.
I was able to download both from Direct Link and from Release 5.1.0.2.

So, PixelFlasher_Mint_21_1, but the result did not change and the following error occurred and could not be started.

Traceback (most recent call last):
File "PixelFlasher.py", line 3, in <module>
File "PyInstaller/loader/pyimod02_importers.py", line 352, in exec_module
File "Main.py", line 17, in <module>
File "PyInstaller/loader/pyimod02_importers.py", line 352, in exec_module
File "wx/__init__.py", line 17, in <module>
File "PyInstaller/loader/pyimod02_importers.py", line 352, in exec_module
File "wx/core.py", line 12, in <module>
ImportError: libwx_baseu_net-3.2.so.0: cannot open shared object file: No such file or directory
[176442] Failed to execute script 'PixelFlasher' due to unhandled exception!

 

[klazyStrida]

Following the contents of ubuntu_22_04.yaml, I tried building with the following steps.
(I created a separate directory from the previous build and ran it there)

$ python3 -m venv venv
$ . venv/bin/activate
$ pip install https://extras.wxpython.org/wxPytho...4/wxPython-4.2.0-cp310-cp310-linux_x86_64.whl
$ pip3 install -r requirements.txt
$ pip install -U -f https://extras.wxpython.org/wxPython4/extras/linux/gtk3/ubuntu-22.04 wxPython
$ pip freeze
$ ./build.sh
$ ls dist

As a result, the PixelFlasher binary generated in dist/ was successfully launched as before.
I've attached the build log just in case.

As previously commented, "pip install -U -f https://extras.wxpython.org/wxPython4/extras/linux/gtk3/ubuntu-22.04 wxPython" shows message "Requirement already satisfied:", So it looks like this didn't need to be done.

 

[badabing2003]

Following the contents of ubuntu_22_04.yaml, I tried building with the following steps.
(I created a separate directory from the previous build and ran it there)

As a result, the PixelFlasher binary generated in dist/ was successfully launched as before.
I've attached the build log just in case.

As previously commented, "pip install -U -f https://extras.wxpython.org/wxPython4/extras/linux/gtk3/ubuntu-22.04 wxPython" shows message "Requirement already satisfied:", So it looks like this didn't need to be done.

Thank you,
I will try to scrutinize the logs and see if I can spot anything.
Stay tuned.

 

[badabing2003]

New Release:
June 01, 2023 v5.2.0.0 release

• Update build workflows
• Add payload_dumper functionality to PixelFlasher to handle OTA files, thanks to vm03 for sharing source code.
• Added rules engine code to better / easier management of the UI widgets enabling / disabling.
• Auto detect Pixel OTA image and extract boot / init_boot / vbmeta for patching and flashing.
• Add Full OTA mode, which flashes full OTA image, while optionally retaining root, and best of all, for A/B devices, both slots are bootable, you can even have one rooted and one not.

 

[Misuto]

@badabing2003 I wanna say thank you for making PixelFlasher for our devices, it's a great tool that makes flashing quick and easy. I just have a quick question. I've flashed other custom ROMs fine, but I heard awhile back that I can't flash Evolution X ROM with your tool because they do it differently than other ROMs for the Pixels? I'm thinking because it first requires that you flash their vendor_boot vendor_boot.img in recovery, but I'm not totally sure. I was wondering if it's possible now to flash Evolution X with your tool, or would it be possible in the future?

 

[V0latyle]

@badabing2003 I apologize if this was discussed previously...

How did you figure out how to make both slots bootable at the same time?

In my experience, manually switching slots would cause several boot loops followed by boot failue. How did you get around this?

 

[badabing2003]

@badabing2003 I apologize if this was discussed previously...

How did you figure out how to make both slots bootable at the same time?

In my experience, manually switching slots would cause several boot loops followed by boot failue. How did you get around this?

As you probably already know, the reason why Factory flashing breaks dual booting (I know it is not the right term, but it is easier said than each time saying, being able to boot from both slots) is two fold.

1. If you inspect the factory image, you'd see that there is system-other image , when you flash factory image, it flashes to current active slot, and doesn't care about the inactive slot, and in fact it flashes system-other.img to the inactive slot's system partition, effectively deeming that slot unbootable, because the contents of it is not system partition stuff, but rather odex files to be copied to /data on first boot, this is similar to how brand new phones are shipped, where only one slot is bootable.
2. A while back I did some tests with factory images by removing system-other from being flashed and hence keeping the inactive slot intact (hopefully bootable), This would slow down the app optimization as there is nothing to copy on first boot, and optimization will happen on demand as applications are accessed.
   This approach worked on older Pixels (Pixel XL) however it failed on newer ones (probably all Android 10+ shipped Pixels), and that was due to AVB.

That was left like that for a long time accepting the fact that we can't have dual boots until when a user ran into an issue and was asking about flashing OTA, it started here, you can see the progress of that discussion, then at this point I did some Full OTA based tests on Pixel 5.

We know that OTA does not touch the active slot (which is the main point of A/B), so I was expecting no corruption, but was also expecting AVB to fail, and to my surprise it didn't.
Then @Lughnasadh did more tests and confirmed my lucky findings.

So now PF supports processing OTA image, extracting boot / patching it and then doing sideload OTA flash to achieve the dual booting.

Over here I answered a user about the differences between factory and full OTA along with some pros / cons.

 

[badabing2003]

@badabing2003 I wanna say thank you for making PixelFlasher for our devices, it's a great tool that makes flashing quick and easy. I just have a quick question. I've flashed other custom ROMs fine, but I heard awhile back that I can't flash Evolution X ROM with your tool because they do it differently than other ROMs for the Pixels? I'm thinking because it first requires that you flash their vendor_boot vendor_boot.img in recovery, but I'm not totally sure. I was wondering if it's possible now to flash Evolution X with your tool, or would it be possible in the future?

You're welcome.

One of the key factors for PixelFlasher's success is the fact that across all Google based devices (Pixels and even older ones) the flashing steps are consistent.
You get a factory image, run it while the phone is in bootloader mode.
Yes PF manages to customize the flash_all script, to replace stock boot with patched boot add / remove flags ..., but all are predictable and consistent.

Unfortunately we can't say the same thing about ROMs.
Each ROM maker has their own flashing approach, and some even their own custom flashers / and different steps.
Some run in recovery, some run in bootloader, the file structures are not consistent.
To support a ROM, I would need to code for each ROM separately, which is a lot of effort for little gain, and even if I wanted to, some steps can't be automated, I can boot to recovery, but can't tell the phone to load and flash a file, it needs to be done on the phone, which also defeats the point of PF, (which is mainly an automation tool).

Even the archiving of the artifacts differs from ROM to ROM.
With Google, it's always a zip
with some ROMs, it could be zip, tgz, tar, md5 (I don't even know why it's named ,md5, it's a tar-ed file)
and to top it off, some have nested other archives, in one of the other various forms.

I slowly started added support for different archive formats and with OTA support I also added support to unpack payload.bin file, which many ROMs use some more building blocks exist now than it did a while back.

If all the steps can be automated, and the steps are consistent and don't change, then support can be added if there is enough interest, but please realize, I don't use any 3rd party ROMs, am not familiar with their subtleties , can't test and won't be able to provide help when things go wrong, do you still think I should support custom ROMs? I consider this an advanced modding, and hence expect advanced users to know how to do it.

Take a look at this feature request for example, it's really much simpler than what you're requesting, and see all the questions I needed answered to be able to code something that works.

 

[Misuto]

You're welcome.

One of the key factors for PixelFlasher's success is the fact that across all Google based devices (Pixels and even older ones) the flashing steps are consistent.
You get a factory image, run it while the phone is in bootloader mode.
Yes PF manages to customize the flash_all script, to replace stock boot with patched boot add / remove flags ..., but all are predictable and consistent.

Unfortunately we can't say the same thing about ROMs.
Each ROM maker has their own flashing approach, and some even their own custom flashers / and different steps.
Some run in recovery, some run in bootloader, the file structures are not consistent.
To support a ROM, I would need to code for each ROM separately, which is a lot of effort for little gain, and even if I wanted to, some steps can't be automated, I can boot to recovery, but can't tell the phone to load and flash a file, it needs to be done on the phone, which also defeats the point of PF, (which is mainly an automation tool).

Even the archiving of the artifacts differs from ROM to ROM.
With Google, it's always a zip
with some ROMs, it could be zip, tgz, tar, md5 (I don't even know why it's named ,md5, it's a tar-ed file)
and to top it off, some have nested other archives, in one of the other various forms.

I slowly started added support for different archive formats and with OTA support I also added support to unpack payload.bin file, which many ROMs use some more building blocks exist now than it did a while back.

If all the steps can be automated, and the steps are consistent and don't change, then support can be added if there is enough interest, but please realize, I don't use any 3rd party ROMs, am not familiar with their subtleties , can't test and won't be able to provide help when things go wrong, do you still think I should support custom ROMs? I consider this an advanced modding, and hence expect advanced users to know how to do it.

Take a look at this feature request for example, it's really much simpler than what you're requesting, and see all the questions I needed answered to be able to code something that works.

That makes sense, thanks for the detailed response.

 

[badabing2003]

Update:
June 03, 2003 v5.2.0.2 release

• #76 Get a better build with Github action to support more Linux based platforms (no functionality changes).

 

[shoey63]

Update:
June 03, 2003 v5.2.0.2 release

• #76 Get a better build with Github action to support more Linux based platforms (no functionality changes).

I'll test later on Ubuntu 22.04 but does this mean the problematic "libwx_baseu_net-3.2.so.0:" error has been resolved on Linux?
Also, is there a particular python version that should be used?

 

[badabing2003]

I'll test later on Ubuntu 22.04 but does this mean the problematic "libwx_baseu_net-3.2.so.0:" error has been resolved on Linux?
Also, is there a particular python version that should be used?

Yes, this build is confirmed to address that infamous libwx_baseu_net-3.2.so issue.
Let me know if you encounter any issues, hopefully we put it to bed once and for all.

You don't need to have Python at all, unless you're trying to build it yourself.
Executable bundles what it needs.