If you used edl rl --genxml then you just need to use edl qfil rawprogram0.xml patch0.xml . from the dump directory (BTW: make sure you have that dump also backed up somewhere else as a zip archive or something).
Note that patch0.xml is not generated by edl rl --genxml. But you can use the patch0.xml from one of the images posted on XDA.
I’m wondering if that tool would be able to restore the partitions that are unique for each device if those get lost.
Wow, wow, wow! Thanks a lot! 
This should be added to the first post. 
Device is up an running the original Teams-Android-OS again!
You’re message saved me a lot of time, finding out that I would have to add patch0.xml to the dump folder.
Now back to flashing the newest PMOS version using the standard edl commands.
So flashing the backup back was successful, reinstalling PMOS, too, so please find below the output of sudo gdisk -l /dev/mmcblk0.
Also to you: thanks a lot for explaining what’s currently up and for having a look into the partitioning.
Are the errors to worry about? 
Ok, got it corrected by using
sudo gdisk /dev/mmcblk0
and followed the advises (entering expert mode with x and then using options j, k and especially e (save with w afterwards)).
Now let’s see how to use the free space. 
Update: Don’t do what I’ve written above - I’m only able to enter fastboot - not booting anymore. So resetting once again. 
Update: Up and running again. Installed chromium and referring to
Great, I’ve tested those settings and it’s really fast. I adjusted the last parameter to hide the notification/top bar and the address bar:
From
Exec=env MESA_GLES_VERSION_OVERRIDE=2.0 /usr/bin/chromium-browser %U --enable-features=UseOzonePlatform --ozone-platform=wayland --start-maximized
to
Exec=env MESA_GLES_VERSION_OVERRIDE=2.0 /usr/bin/chromium-browser %U --enable-features=UseOzonePlatform --ozone-platform=wayland --start-fullscreen
If you are building this for somebody who shall only use chromium and not be able to exit it, you can even use:
Exec=env MESA_GLES_VERSION_OVERRIDE=2.0 /usr/bin/chromium-browser %U --enable-features=UseOzonePlatform --ozone-platform=wayland --start-fullscreen --kiosk
And @pgale is right, the virtual keyboard is not showing up for me either while using chromium.
That’s interesting. Will try it later thanks.
For kiosk mode - is there a way to remotely enable/disable I wonder?
Then already a feedback. Fullscreen makes it really difficult to leave the window. Kiosk should prevent this completely.
I would assume that you can write s script which changes the line in the config and kills and restarts chromium afterwards.
Another update:
chromium seems faster.
You can do the same edits for firefox (same folder, firefox-esr.desktop)
If you want the fullscreen mode and onscreen keyboard, firefox currently seems better (but is slower).
If you don’t mind the missing onscreen keyboard and you don’t leave the browser, chromium in fullscreen seems to be the best solution
If you don’t need the onscreen keyboard and you want to easily leave the browser, from my testing, chromium maximized is the best solution.
It’s sad, that chromium in fullscreen does not play as nicely with the system as firefox does (as the performance is better).
did you install chromium or chromium browser? From sudo apk add chromium?
As mrhand recommended, chromium.
Yeah I did that but I’m getting errors starting from CLI and the desktop icon doesn’t launch chromium
Hey thanks for going through that, do your partitions still look similar? Mine with stock had 50 (!) so I suspect you’re in a bit of a hybrid state where you have system & vendor again but not all the small android specific ones at the end.
On the note of patch0.xml - did you include mine with the qfil flash for the updated partition scheme? That’s a key piece that resizes the userdata partition and updates the CRC values. Without it that could explain the errors you saw from gdisk.
Btw, I’ve been generating these from a modified version of the qualcomm partitioning tool
No prob! I think we’re getting closer 
Here’s the canonical upstream for that tool, btw: ptool.py · master · Linaro / qcomlt / db-boot-tools · GitLab
They re-licensed it as BSD 3-Clause and ported it to Python 3, which is very nice of them.
Played around with the Lenovo Rescue and Smart Assistant tonight.
Mainly to find out whether it would be able to recover a device that lost all of its flash memory.
Functionally, for my devices, it’s the same as downloading the [email protected] from @deadman96385’s XDA Thread and running that through edl qfil. It will not restore a corrupted devinfo or any other device-unique partitions, such as DDR, oem, persist, resource, ssd. Only devinfo seems to contain device specific information that is used by the bootloader to set a few things up (such as serial number and product number).
But a corrupted devinfo doesn’t prevent the device from booting (coincidentally the device @mattmon sent me had a corrupted devinfo, probably from some in-depth experimenting ). The bootloader will gladly put any garbled bytes for the serial number and product number into the kernel commandline. Fun fact: You can even inject actual kernel command line arguments by replacing one of the values with a space + your injected argument. Unfortunately it can’t be longer than the serial number or product number minus 1 character (the space).
A corrupt devinfo partition does seem to prevent the Rescue and Smart Assistant from doing its job. I was never able to successfully flash a device that had a broken devinfo partition with it, it would give an error message right after finishing the flashing and drop me into 900e mode. EDL still got those devices booting fine.
It’s possible to replace the devinfo partition with one from another ThinkSmart and just edit the serial number in a hex editor to restore world order.
Thankfully, postmarketOS doesn’t really care about any of this.
Overall, a full dump using edl rl is still a highly recommended first course of action before you even boot up the device for the first time (I did this for 2 devices I freshly unboxed).
But I am starting to feel it’s very likely impossible to irreversibly brick the device by messing with the eMMC storage. But I have yet to test messing with some of the other unique partitions. Who knows? Maybe you can write some whacky DDR memory timings to the DDR partition and smoke the memory? I’m not too eager to find out 
That’s sounds promising, it should help with attempts to resize the partitions on the smart display 8 if it has a similar level of resilience to bricking!
Interested to see if the tools in the past few posts can also be used on that device too.
Are we confident that a full dump taken using “edl rl --genxml dump” covers everything that will be altered by changing partitions or are there any further steps to take before tinkering with them?
So far from my testing, I’m confident that edl rl --genxml covers everything.
But I will only know for certain once I attempt my eMMC swap and have to write back the full dump onto an empty eMMC. But that’ll have to wait until I got all the tools I need and also some more time on my hands.
Hehe, busted 
Was in a hurry to get it out, and was the only unit I knew for sure had the touch screen in question.
I suspect something about flashing the GSI may have done that. @pgale is having issues over in the other thread, with symptoms (after reading @FelixKa’s last post) seeming very similar to the unit I sent.
1st person to release the magic smoke from thier thinksmart wins… another thinksmart!
(Post pics of the carnage, then send me a dm to claim your prize.)
So I have just fired up the device and SSH again (maybe tomorrow or on the weekend I’ll be able to start installing wyoming/the satellite) but it still looks the same. Currently I have just used the backup from my dumps, only using patch0.xml from the stock teams android.
So should I try reflasing with my dumps and your patch0.xml? I would expect if I’m using all files provided by you it will not boot again. Willing to test again but I need some guidance what a next step would be that has a chance to go in the right direction.
I’m sorry to hear that and yeah, you are right - using SSH i was not able to start a browser on the device - maybe a different addition to the command is needed that states to open the browser on the display of the device instead as part of the ssh session. Or to see the process ID and restart it? Sorry that this is more guessing than knowing. But opening it using the icon was always working for me for all the browsers where I did the changes.
Btw. I’ve additionally tried epiphany (web) (installed via sudo apk add epiphany). Also runs great but does not play my videos from the homeassistant-jellyfin-server (chrome and firefox do!).
Depends on what the prize is - could be worth applying a paperclip strategically 
I just need to try a few more things. I’m alternating between PMOS and other versions as far as I can get (A11)
It’s odd, or at least odd to me as I can install and run PMOS and 8.1 but A11 just refuses to boot.
