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)

Most upvoted comments

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:

s4mini> sudo ../Heimdall/build/bin/heimdall flash --verbose --RECOVERY recovery.img --no-reboot 

Heimdall v1.4.1

Copyright (c) 2010-2014 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...
Protocol initialisation successful.

Beginning session...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...

Some devices may take up to 2 minutes to respond.
Please be patient!

WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
Session begun.

WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
Downloading device's PIT file...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after receiving packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
PIT file download successful.

Uploading RECOVERY
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
0%WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...

7%

14%

22%

29%

37%

44%

52%

59%

66%

74%

81%

89%

96%

100%
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
ERROR: Failed to unpack received packet.

ERROR: Failed to confirm end of file transfer sequence!
ERROR: RECOVERY upload failed!

Ending session...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
Releasing device interface...
Re-attaching kernel driver...

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 of twrp-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.