Heimdall: Flash operation ERROR: Failed to confirm end of file transfer sequence!
heimdall version v1.4.0, both 32-bit and 64-bit, Ubuntu 13.10
Attempting to flash recovery to Sprint Galaxy S3. Recovery uploads to 100% and then hangs for ten minutes, finally reporting “ERROR: Failed to confirm end of file transfer sequence!” This is not a device error as flashing recovery succeeds in Odin. I’ve experienced the same behavior with other devices. Occurs with or without the --no -reboot option.
This has been reported before and was corrected in v1.3.1. I don’t know if this is a regression or has a new cause. I do not have the older version to test. Verbose mode indicates the problem may be libusb (verbose output pasted below standard output)
Another behavior, possibly related, is that I must restart download mode after any heimdall operation besides ‘detect’. This is not difficult to manage, I report only as a possible symptom.
Any suggestions or comments appreciated.
Terminal output below:
$ sudo heimdall flash --RECOVERY recovery.tar.md5 --no-reboot Heimdall v1.4.0
Copyright © 2010-2013, Benjamin Dobell, Glass Echidna http://www.glassechidna.com.au/
This software is provided free of charge. Copying and redistribution is encouraged.
If you appreciate this software and you would like to support future development please consider donating: http://www.glassechidna.com.au/donate/
Initialising connection… Detecting device… Claiming interface… Attempt failed. Detaching driver… Claiming interface again… Setting up interface…
Initialising protocol… Protocol initialisation successful.
Beginning session…
Some devices may take up to 2 minutes to respond. Please be patient!
Session begun.
Downloading device’s PIT file… PIT file download successful.
Uploading RECOVERY 100% ERROR: Failed to confirm end of file transfer sequence! ERROR: RECOVERY upload failed!
Ending session… ERROR: Failed to send end session packet! Releasing device interface… Re-attaching kernel driver…
$ sudo heimdall flash --verbose --RECOVERY recovery.tar.md5 --no-reboot [sudo] password for jlehr: Heimdall v1.4.0
Copyright © 2010-2013, Benjamin Dobell, Glass Echidna http://www.glassechidna.com.au/
This software is provided free of charge. Copying and redistribution is encouraged.
If you appreciate this software and you would like to support future development please consider donating: http://www.glassechidna.com.au/donate/
Initialising connection… Detecting device… Manufacturer: “Sasmsung” Product: “MSM8960”
length: 18
device class: 2
S/N: 0
VID:PID: 04E8:685D
bcdDevice: 0100
iMan:iProd:iSer: 1:2:0 nb confs: 1
interface[0].altsetting[0]: num endpoints = 1 Class.SubClass.Protocol: 02.02.01 endpoint[0].address: 82 max packet size: 0010 polling interval: 09
interface[1].altsetting[0]: num endpoints = 2 Class.SubClass.Protocol: 0A.00.00 endpoint[0].address: 81 max packet size: 0200 polling interval: 00 endpoint[1].address: 01 max packet size: 0200 polling interval: 00 Claiming interface… Attempt failed. Detaching driver… Claiming interface again… Setting up interface…
Initialising protocol… WARNING: Control transfer #1 failed. Result: -9 WARNING: Control transfer #2 failed. Result: -9 WARNING: Control transfer #3 failed. Result: -9 WARNING: Control transfer #4 failed. Result: -9 WARNING: Control transfer #5 failed. Result: -9 WARNING: Control transfer #6 failed. Result: -9 Protocol initialisation successful.
Beginning session…
Some devices may take up to 2 minutes to respond. Please be patient!
Session begun.
Downloading device’s PIT file… PIT file download successful.
Uploading RECOVERY 0% 13%
26%
39%
52%
66%
79%
92%
100% ERROR: libusb error -7 whilst receiving packet. Retrying… ERROR: libusb error -7 whilst receiving packet. Retrying… ERROR: libusb error -7 whilst receiving packet. Retrying… ERROR: libusb error -7 whilst receiving packet. Retrying… ERROR: libusb error -7 whilst receiving packet.
ERROR: Failed to confirm end of file transfer sequence! ERROR: RECOVERY upload failed!
Ending session… ERROR: libusb error -7 whilst sending packet. Retrying… ERROR: libusb error -7 whilst sending packet. Retrying… ERROR: libusb error -7 whilst sending packet. Retrying… ERROR: libusb error -7 whilst sending packet. Retrying… ERROR: libusb error -7 whilst sending packet. Retrying… ERROR: libusb error -7 whilst sending packet. ERROR: Failed to send end session packet! Releasing device interface… Re-attaching kernel driver…
About this issue
- Original URL
- State: open
- Created 10 years ago
- Comments: 34 (1 by maintainers)
Don’t bother with this procedure. Use Odin, works flawlessly. For example, for the Galaxy S4 Mini, follow the steps in the two attached links, in that order https://forum.xda-developers.com/showthread.php?t=2364980 http://www.cyanogenmods.org/forums/topic/galaxy-s4-mini-lineage-14-1-nougat-7-1-rom/
My solution was to install twrp old version https://eu.dl.twrp.me/zeroflte/twrp-3.3.1-0-zeroflte.img.html
This is actually a heap of different bugs and bad error handling piled into a single issue. As far as I understand, current Heimdall version uses “can’t confirm the end of file” for most device-reported errors. Mine case was wrong kernel format in the recovery image. I have seen different reports about image size problems and such while googling this “error”. The software itself working fine, the image you trying to flash is rejected by a device for one reason or another.
Hi there, mine (using latest sources from github) failes after 100% – not with libusb error, but:
Can anybody help?
@motis10 I tried with different versions of Heimdall, on different computers, with different options, but nothing worked. Then I followed your trick and tried to flash
twrp-3.6.2_9-0-herolte.img.tar
instead oftwrp-3.7.0_9-0-herolte.img.tar
, and it worked! Fantastic! Thanks a lot for the idea!I no longer have the device from my initial post, but have worked with similar devices since then. I discovered that I failed to extract the recovery image from the tar file, which you can see in my command in the OP above. It does not appear that zadenikt used a tar archive from his command, but one cannot be sure of such things from pasted output. I cannot tell what Evpok did because his command is not included.
My recommendation is that you check the image with the ‘file’ command and if you have an archive, extract the image and try again.