Open slo-sleuth opened 10 years ago
Incidentally, same issue under Windows 7 with zadig drivers.
Newly built-from-Git Heimdall and newly-compiled libusb (on Arch Linux x86_64, compiled via ABS), flashing Clockwork Recovery (md5 of dcf73942083e269cfc2748aaf7450d0e
) to SCH-I605:
# heimdall flash --RECOVERY recovery.img --no-reboot --verbose
Heimdall v1.4.0
Copyright (c) 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: "SAMSUNG"
Product: "Gadget Serial"
length: 18
device class: 2
S/N: 0
VID:PID: 04E8:685D
bcdDevice: 021B
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: 83
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: 02
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...
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%
14%
28%
42%
56%
70%
84%
98%
100%
ERROR: Failed to unpack received 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...
Same issue with Samsung Galaxy ACE 3 S7275R
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
ERROR: Failed to receive handshake response. Retrying...
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%
12%
25%
37%
50%
63%
75%
88%
100%
ERROR: Failed to unpack received packet.
ERROR: Failed to confirm end of file transfer sequence!
ERROR: RECOVERY upload failed!
Ending session...
ERROR: libusb error -7 whilst receiving packet. Retrying...
ERROR: libusb error -7 whilst receiving packet. Retrying...
Releasing device interface...
Re-attaching kernel driver...
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.
Indeed, I had overlooked that it was still in tar. Thanks for pointing that out.
I can try again by Saturday, I'm away from home at the moment. I'm pretty sure I untarred it, but I can check.
I am having this problem too on my Verizon Galaxy S4. Did anyone find out the cause of this? Here is the output from mine.
$ sudo heimdall flash --RECOVERY recovery.img --no-reboot --verbose Heimdall v1.4.0
Copyright (c) 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% 10%
21%
32%
42%
53%
64%
74%
85%
96%
100% ERROR: Failed to unpack received packet.
ERROR: Failed to confirm end of file transfer sequence! ERROR: RECOVERY upload failed!
Ending session... Releasing device interface... Re-attaching kernel driver...
What did your device's screen show? Does Verizon expect a signed recovery? I know that some of the AT&T phones fail because the recovery is not signed. In that case, it is not a Heimdall issue.
On Tue, Apr 15, 2014 at 1:33 PM, baphelps18 notifications@github.comwrote:
I am having this problem too on my Verizon Galaxy S4. Did anyone find out the cause of this? Here is the output from mine.
$ sudo heimdall flash --RECOVERY recovery.img --no-reboot --verbose Heimdall v1.4.0
Copyright (c) 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 #1https://github.com/Benjamin-Dobell/Heimdall/pull/1failed. Result: -9 WARNING: Control transfer #2https://github.com/Benjamin-Dobell/Heimdall/issues/2failed. Result: -9 WARNING: Control transfer #3https://github.com/Benjamin-Dobell/Heimdall/issues/3failed. Result: -9 WARNING: Control transfer #4https://github.com/Benjamin-Dobell/Heimdall/pull/4failed. Result: -9 WARNING: Control transfer #5https://github.com/Benjamin-Dobell/Heimdall/pull/5failed. Result: -9 WARNING: Control transfer #6https://github.com/Benjamin-Dobell/Heimdall/pull/6failed. 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% 10%
21%
32%
42%
53%
64%
74%
85%
96%
100% ERROR: Failed to unpack received packet.
ERROR: Failed to confirm end of file transfer sequence! ERROR: RECOVERY upload failed!
Ending session... Releasing device interface... Re-attaching kernel driver...
Reply to this email directly or view it on GitHubhttps://github.com/Benjamin-Dobell/Heimdall/issues/191#issuecomment-40530648 .
The screen shows a completed blue bar. I am not sure if Verizon is expecting a signed recovery. However, when I try to flash a ROM from the stock system recovery I get an error about not being able to verify the signature
The progress bar will complete. The error message, if there is one, will be visible at the top of the screen.
On Tue, Apr 15, 2014 at 3:16 PM, baphelps18 notifications@github.comwrote:
The screen shows a completed blue bar. I am not sure if Verizon is expecting a signed recovery. However, when I try to flash a ROM from the stock system recovery I get an error about not being able to verify the signature
Reply to this email directly or view it on GitHubhttps://github.com/Benjamin-Dobell/Heimdall/issues/191#issuecomment-40541299 .
Same error with Galaxy Note II N7105 (t0lte), previously worked fine:
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: "SAMSUNG"
Product: "Gadget Serial"
length: 18
device class: 2
S/N: 0
VID:PID: 04E8:685D
bcdDevice: 021B
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: 83
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: 02
max packet size: 0200
polling interval: 00
Claiming interface...
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...
WARNING: Empty bulk transfer after receiving packet failed. Continuing anyway...
PIT file download successful.
Uploading RADIO
0%
2%
4%
6%
8%
11%
13%
15%
17%
19%
22%
24%
26%
28%
30%
33%
35%
37%
39%
41%
44%
46%
48%
50%
52%
55%
57%
59%
61%
63%
66%
68%
70%
72%
74%
77%
79%
81%
83%
85%
88%
90%
92%
94%
96%
99%
100%
ERROR: Failed to unpack received packet.
ERROR: Failed to confirm end of file transfer sequence!
ERROR: RADIO upload failed!
Ending session...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer.
ERROR: Failed to send end session packet!
Releasing device interface...
Can you people be so kind and help me out with a proper way to pack system.img? Mine fails at 6% with the same error :-) I've built make_ext4fs for Linux x86_64 from recent Android sources except that I've got rid of any reference to "selinux" stuff which I can bother to play with. Does it influence the composition of "system" anyhow? I really want to root this thing sm-j100y - system/recovery/boot anything will do!
@Lord-Evil i'm in same situation, did you manage to pack the system.img correctly?
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?
mine (using latest sources from github) failes after 100% -- not with libusb error
I experience the same issue with the latest HEAD of Heimdall.
Problem solved. I tryed a couple of times more and it worked. Il 24/Giu/2016 22:38, "alexxthehood" notifications@github.com ha scritto:
mine (using latest sources from github) failes after 100% -- not with libusb error
I experience the same issue with the latest HEAD of Heimdall.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Benjamin-Dobell/Heimdall/issues/191#issuecomment-228456117, or mute the thread https://github.com/notifications/unsubscribe/ATGmnaOu-uWWEupYFgI1v-Nn7yeWaeVIks5qPEBdgaJpZM4BfYre .
i'm using arch my phon sumsung n910v
flash --RECOVERY recovery.img --verbose
Heimdall v1.4.2
Copyright (c) 2010-2017 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...
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 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...
6%
12%
18%
24%
30%
37%
43%
49%
55%
61%
68%
74%
80%
86%
92%
99%
100%
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
RECOVERY upload successful
Ending session...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
ERROR: Failed to unpack received packet.
ERROR: Failed to receive session end confirmation!
Releasing device interface...
I get this error only when running with sudo (as root)
I also get the error message when I try to install TWRP using v1.4.2 under Windows 7, on a Galaxy S4 mini: "ERROR: Failed to confirm end of file transfer sequence" Lots of other people experiencing the same issue on various forums.
I've tried this using version v1.31, v1.4.0 and 1.4.2. Same result each time. Amazed that it still hasn't been fixed.
E:\Desktop\Heimdall\Heimdall Suite v1.4.2>heimdall flash --RECOVERY twrp-3.0.2-0-serranoveltexx.img --no-reboot
Heimdall v1.4.2
Copyright (c) 2010-2017 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...
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...
Releasing device interface...
Same issue than @polomora with also a S4 mini. Hope my device is not stuck now
Here is my output as I run as admin in cmd (windows 10), I moved heimdall files in folder at C:\ to make sure it is not a name size limit / space issue. But still :
Initialising connection...
Detecting device...
libusbx: error [init_device] device '\\.\USB#VID_1130&PID_1620&MI_02#6&3B60BAAF&0&0002' is no longer connected!
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...
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%
7%
14%
22%
29%
37%
44%
51%
59%
66%
74%
81%
88%
96%
100%
ERROR: Failed to unpack received packet.
ERROR: Failed to confirm end of file transfer sequence!
ERROR: RECOVERY upload failed!
Ending session...
Releasing device interface...
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/
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.
Had the exact same problem: it was actually my fault - I was trying to flash the wrong image.
I fixed it by flashing the correct .img
file
Still a problem, with a Galaxy S5 (SM-G900V) and Heimdall compiled from git, trying to flash twrp:
$ heimdall flash --RECOVERY twrp-3.1.1-0-klte.img --no-reboot
Heimdall v1.4.2
Copyright (c) 2010-2017 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...
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...
Releasing device interface...
The blue bar goes all the way across the S5's screen. The last few lines in the text at the top of the screen read:
SECURE DOWNLOAD : ENABLE (in blue)
UDC START (in red)
SECURE CHECK FAIL : recovery (in red)
I had previously tried to flash a bad file (when I downloaded twrp-3.1.1-0-klte.img I got a file by that name but it was HTML, and I didn't check it) but now it should be the right type:
$ file twrp-3.1.1-0-klte.img ~/Docs/droidsd/galaxysd twrp-3.1.1-0-klte.img: Android bootimg, kernel (0x8000), ramdisk (0x2000000), page size: 2048, cmdline (console=null androidboot.hardware=qcom androidboot.bootdevice=msm_sdcc.1 user_debug=31 msm_rtb.)
yet I still get the same error from heimdall as I did with the bad file.
@akkana Doesn't the Verizon S5 have a locked bootloader? If so, that'd be the issue, unfortunately not a lot Heimdall can do about that. Although, if you search XDA Developers there may be work-arounds.
Does it? How would I find out? I was following https://wiki.lineageos.org/devices/klte/install which talks about "Samsung devices" using "Download mode", and doesn't say anything about locked bootloaders or being specific to only certain models. In a web search I'm not finding anything suggesting the G900V is different from other S5 models, but I might not be using the right keywords. Sorry, I'm new to this and didn't even know it was an issue.
I found a few pages that agreed with polomora's comment in this bug that Odin works (even on the G900V specifically). So maybe I need to use Odin, but I was hoping I could use heimdall, partly because I don't have windows (I suppose I can borrow a windows machine) and partly because the only Odin downloads I've found are from sketchy download sites that I'm not sure I should trust, especially for Windows software.
I'm having the same problem with a SM-G900F aka klte
. @akkana Did you have any success?
Nope, no progress. I found a few pages on ways of unlocking the bootloader using odin (which requires windows) but they're quite elaborate and looks like there's a fairly high risk of bricking. If I try it at all, it'll have to wait until I have several days of free time, a Windows box, and a replacement phone lined up in case this one gets bricked. I'm debating just buying a different phone, but I haven't found a way to get a list of phone models that work easily (the lineage wiki said mine would) so I guess buying any phone is a crapshoot.
I was able to flash the S5 with Odin on windows. Heimdall on Linux and windows didn’t work for me.
Am 23.10.2017 um 17:39 schrieb Akkana Peck notifications@github.com:
Nope, no progress. I found a few pages on ways of unlocking the bootloader using odin (which requires windows) but they're quite elaborate and looks like there's a fairly high risk of bricking. If I try it at all, it'll have to wait until I have several days of free time, a Windows box, and a replacement phone lined up in case this one gets bricked. I'm debating just buying a different phone, but I haven't found a way to get a list of phone models that work easily (the lineage wiki said mine would) so I guess buying any phone is a crapshoot.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Getting the same libusb
issue when flashing SM-T110 stock system.img
Heimdall v1.4.2
Copyright (c) 2010-2017 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...
Product: "SAMSUNG USB"
Serial No: "SAMSUNG USB SERIAL"
length: 18
device class: 2
S/N: 3
VID:PID: 04E8:685D
bcdDevice: 0000
iMan:iProd:iSer: 1:2:3
nb confs: 1
interface[0].altsetting[0]: num endpoints = 1
Class.SubClass.Protocol: 02.02.01
endpoint[0].address: 83
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: 02
max packet size: 0200
polling interval: 00
Claiming interface...
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 receiving packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
PIT file download successful.
Uploading SYSTEM
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
0%WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
1%
2%
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
3%
4%
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
5%
6%
7%
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
8%
9%
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
WARNING: Empty bulk transfer after sending packet failed. Continuing anyway...
10%
WARNING: Empty bulk transfer before sending packet failed. Continuing anyway...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer.
ERROR: Failed to send file part packet!
ERROR: SYSTEM upload failed!
Ending session...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer.
ERROR: Failed to send end session packet!
Releasing device interface...
My solution was to install twrp old version https://eu.dl.twrp.me/zeroflte/twrp-3.3.1-0-zeroflte.img.html
@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!
trying to flash xcover 4s under manjaro, same problem:
`Heimdall v1.4.2
Copyright (c) 2010-2017 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... 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 SYSTEM 0% 1%
ERROR: Failed to confirm end of file transfer sequence! ERROR: SYSTEM upload failed!
Ending session... `
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 (c) 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 (c) 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"
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...