Can't flash userdata on motorola-harpia about lk2nd

[TravMurav]

At that point it just hangs for a very long time

can you try fastboot flash -S 64M userdata image.img?

I am planning to try just dd-ing the image directly to an SD card

If you're using a prebuilt img.xz then you need to unxz it and, importantly, simg2img it. Also OS won't resize the fs in that case afaik

[rogueeve575]

Thanks, I tried the simg2img utility and the -S switch. It made no difference but if I try MUCH smaller values, such as 32K, it does get several chunks through before it hangs again, up to a number of chunks that seems to scale pretty linearly with the chunk size, as if the hang is triggered after a certain amount of data has been transferred.

Is there a way to have fastboot pause between each chunk of userdata, like in case a buffer somewhere is being overrun or something - that's my first instinct anyway. Since I don't see a switch for that in fastboot --help I'm thinking maybe I'll try to compile fastboot from source and see if I can manually hack one in.

I forgot to mention in the OP that I have also tried running usbdump in another terminal while running fastboot, and I can see lots of data go by which stops dead at the point of hang and then just never recovers with no further traffic over the USB, I've even left it overnight.

At that point the lk2nd UI on the phone is still responsive, but no further fastboot commands work at all (instant hang after enter w/ no output), even commands which previously worked, until I power-cycle the phone or select "Restart Bootloader" from the lk2nd menu.

I also noticed the "fastboot -w" command this time, which does appear to work as expected as long as there hasn't been a hang that boot, as well as commands such as "fastboot reboot bootloader".

I'm happy to run whatever commands would help or troubleeshoot code (I'm a C/C++ programmer), I just don't know very much about Android or any of the associated tools to really know where to start.

See attached command log.
log03312024.txt

[rogueeve575]

Okay, I hacked fastboot to add a 2.5 second delay before sending each chunk, no change:

RetCode FastBootDriver::Download(const std::string& partition, struct sparse_file* s, uint32_t size,
                                 size_t current, size_t total, bool use_crc, std::string* response,
                                 std::vector<std::string>* info) {
+	const int DELAY = 2500;
+	printf("delay hack %dms...\n", DELAY);
+	usleep(DELAY * 1000);

    prolog_(StringPrintf("Sending sparse '%s' %zu/%zu (%u KB)", partition.c_str(), current, total,
                         size / 1024));
    auto result = Download(s, use_crc, response, info);
    epilog_(result);
    return result;
}

Then I started adding lots more debug prints, and was able to determine the following stack trace:

FastBootDriver::Download
sparse_file_callback
write_all_blocks
sparse_file_write_block
write_fd_chunk

It hangs somewhere beneath write_fd_chunk probably where fastboot is calling into a function pointer return out->sparse_ops->write_data_chunk(out, m->size(), m->data()); and I stopped tracing. (So far I haven't been able to break out of the hang when running fastboot under gdb, or attach to an existing fastboot process after the hang, it just hangs gdb as well).

Is there a method to get verbose output or debug mode etc to start something similar for lk2nd (of course I could follow the README.md to build from source but I'm not sure if there's an existing recommended method to output any debug to make that useful)?

[TravMurav]

First of all, could you try building lk2nd from rebase/uboot branch and check if it changes anything when ran as-is?

After that you can build the same branch with additional DEBUG=2 DEBUG_FBCON=1 to get logs on the device screen.

I suspected the fastboot thread hangs/dies for some reason on the device side somehow, which is why I suggested -S to make sure it's not incorrect ram setup (i.e. device tries to write a chunk more than has ram allocated for) but it seems like it's neither that nor any kind of a watchdog if you say it dies after specific size written to the devcie ignoring the delays...