Initial state before installing iodé and fastboot issues

Hi,

I’ve been working with LineageOS for several years, but I am quite new to iodé and have issues getting my first device (a OnePlus 9 Pro) converted. From the available documentation it is unclear to me what state the documented installation procedures expect the device to be in before starting the installation of iodé.

Should it stay with Android 11 as shipped, should it be upgraded to Android 13 as requested for LineageOS, or should it be upgraded to the latest Android 14 release that is available from the vendor?

I tried the Android 13 way, but it broke both the autoinstaller and the manual installation, both being unable to locate/flash the “boot” partition.

My friend @ChHe recommended to try installing LineageOS first and then sideloading to iodé. I did that about four weeks ago using then current LineageOS and files from lemonadep · master · ota / release · GitLab and got a booting iodé 5.3 that meanwhile received an OTA upgrade to 5.4.

But at least when using it with a secondary user it runs quite unstable. Some apps keep crashing and it sporadically reboots several times a day.

So my questions are:

  1. What would have been the recommended way to install this device? (I have some more devices of the same model to do.)
  2. What would be the best way to get the messed-up device back to a consistent state, or are secondary users generally problematic with iodé?

Thanks in advance.

the fastboot method should work for all, but i would recommend to install the lastest vendor version.

As I said, I had tried the fastboot method, but starting at the latest Android 13 state from the vendor rather than 14, because I didn’t want to lose the ability to install LineageOS in case I don’t get around with iodé, and it was unclear what base installation iodé was expecting.

Here is what I got when running flashall.sh:

ANDROID_PRODUCT_OUT=.
fastboot=linux/fastboot
linux/fastboot getvar all
grep partition-type:cache
linux/fastboot getvar all
grep partition-type:metadata
linux/fastboot getvar all
grep partition-type:md_udc
linux/fastboot format:f2fs userdata
FAILED (remote: 'GetVar Variable Not found')
fastboot: error: Command failed
linux/fastboot erase userdata
Erasing 'userdata'
FAILED (remote: 'Check device console.')
fastboot: error: Command failed
linux/fastboot flash modem modem.img
Warning: skip copying modem image avb footer (modem partition size: 0, modem image size: 217411584).
Sending 'modem' (212316 KB)

At this point it hangs indefinitely (I left it for several hours), and after interrupting it, it leaves the device in an unusable USB state that stays until the next replug and/or power/boot cycle, I don’t remember exactly.

OK, I tried it once more with another 9 Pro and this time upgraded it to Android 14 before starting to install iodé. But it looks like the connection between the fastboot boot loader on the device and the fastboot binary on the PC is unstable and frequently causes the bootloader to behave unexpectedly or crash.

Just by running
linux/fastboot getvar all
repeatedly I get three different behaviours. Most of the time it works as expected and lists all the boot environment variables, but once in a while it prints out

getvar:all FAILED (remote: 'unknown command')
Finished. Total time: 0.000s

In some cases the command even causes the phone to show the fastboot splash screen again and reboot. I’ve tried it with different cables and by enforcing USB2 and USB3, but the behavior does not change.

With one of the basic tools malfunctioning like this there is no wonder that I can’t get the script to finish successfully that makes heavy use of that tool. This issue might also have lead to the error messages I posted above from the script running against my first 9 Pro.

Has anybody ever seen this before on devices of this model or any other models?
Is there any chance to switch this tool into a maybe slower, but more stable mode?

I can reproduce this with android-tools-35.0.1 and 35.0.2 from openSUSE as well as with the copy of 35.0.1 that comes bundled in the fastboot zip file of iodé 5.4.

Here is another test to reproduce the issue. When running
fastboot getvar is-userspace
I randomly get one of the following three results:

  1. getvar:is-userspace FAILED (remote: 'unknown command')
  2. getvar:is-userspace FAILED (remote: 'GetVar Variable Not found')
  3. is-userspace: no

Plus the occasional crash and restarting of the bootloader.

I now tried to execute the commands in flash-all.sh by hand, so that I can repeat steps that fail until they succeed. With this I got through to the update command, but this now always gets stuck like this until I interrupt the process or restart the bootloader on the device:

$ fastboot --skip-reboot update iode-5.4-20240831-lemonadep-img.zip
--------------------------------------------
Bootloader Version...: 
getvar:version-baseband                            FAILED (remote: 'unknown command')
getvar:serialno                                    FAILED (remote: 'GetVar Variable Not found')
--------------------------------------------
extracting android-info.txt (0 MB) to RAM...
getvar:product FAILED (remote: 'GetVar Variable Not found')
Checking 'product'                                 OKAY [  0.003s]
Warning: Could not determine slot for secondary images. Ignoring.
extracting fastboot-info.txt (0 MB) to RAM...
extracting super_empty.img (0 MB) to RAM...
extracting super_empty.img (0 MB) to RAM...
extracting super_empty.img (0 MB) to RAM...
extracting super_empty.img (0 MB) to RAM...
extracting super_empty.img (0 MB) to RAM...
extracting super_empty.img (0 MB) to RAM...
extracting super_empty.img (0 MB) to RAM...
extracting super_empty.img (0 MB) to RAM...
extracting super_empty.img (0 MB) to RAM...
extracting super_empty.img (0 MB) to RAM...
extracting super_empty.img (0 MB) to RAM...
extracting super_empty.img (0 MB) to RAM...
extracting super_empty.img (0 MB) to RAM...
extracting super_empty.img (0 MB) to RAM...
extracting super_empty.img (0 MB) to RAM...
extracting boot.img (192 MB) to disk... took 0.367s
archive does not contain 'boot.sig'
extracting super_empty.img (0 MB) to RAM...
Warning: skip copying boot image avb footer (boot partition size: 0, boot image size: 201326592).
Sending 'boot' (196608 KB)

You may have a problem with your USB cable / port.

I thought about cable or USB port issues as well, but I could reproduce the errors with several different cables, two laptops from different manufacturers, three samples of OnePlus 9 Pro and a OnePlus 6T.

The only things all tests had in common was that the phones were all manufactured by OnePlus and the laptops were running openSUSE Leap 15.5 and 15.6. But apart from these fastboot errors I don’t normally have issues with USB on these machines, even wen it comes to high-speed applications such as external SSDs via USB 3.x.