hi..

I've got a package .ipk built with the Barrier Breaker 14.07 linux x86_64 SDK that i'm trying to pull into a rootfs built with the corresponding Image Builder. The rootfs is running in a Docker image, but opkg is complaining that the .ipk has a bad magic number so perhaps the .ipk is corrupted in some way. I'm building on Ubuntu 14.04. I've put a bash script which reproduces the problem at https://gist.github.com/wrabbit-revisit … 67686fa056 . Perhaps i should try adding the package to the Image Builder? I've put that off because i think my method should work, but would appreciate it if someone could identify possible causes.

BTW i tried building from  git://git.openwrt.org/14.07/openwrt.git, but menuconfig only shows an x86 target so i'm not sure how the x86_64 used in the downloads is built. I did get a build working by pulling in a package from git://git.openwrt.org/14.07/packages.git but this is a bit of a blocker.

thanks!

Just to make sure everything was on the right page, i checked out openwrt Barrier Breaker from github and generated the rootfs (containing opkg) and the SDK then added the package to the SDK and created the .ipk. STILL the same problem. Looking at the code of opkg it is complaining because it doesn't find the binary signature it's expecting. Looking at the rather frequent posts about similar problems, i suspect it's because opkg is expecting the .ipk to be in gzipped format.. or ar or something.

I pulled an ipk from https://downloads.openwrt.org/barrier_b … /packages/ , renamed it to <pkg>.tar.gz then did a 'tar xvf' on it. No problem. Did the same with the file built from the SDK. No problem.

So i dig a little further. http://www.sown.org.uk/wiki/OpenWRT_Pac … kg_package claims that an opkg file should use ar instead of tar to compress the contents of the package. Sure enough.. when i use ar to add the components extracted from the original .ipk to generate a new .ipk the problem is solved.

The .ipk files created by the SDK use tar and gzip to compress the control.tar.gz/data.tar.gz/debian-binary files into <package>.ipk . It is equivalent to <package>.tar.gz .

The opkg placed in the rootfs by the Image Builder is assuming that the <package>.ipk files are compressed using ar.

Perhaps a small, unencrypted, header for version/compression/... metadata in the .ipk would help opkg to decipher what it is getting. Or perhaps the SDK should not be using tar/gzip to create .ipk files. Personally, I've found a plaintext header to be useful.

Hope this saves someone some time.

(Last edited by wombat365 on 26 Jan 2015, 00:09)

That sounds extremely odd, I never heard of such a problem. Can you provide such a failing .ipk file somewhere?

The .ipk doesn't fail. The opkg expects a different format.

That is what I mean. The opkg here never had issues processing .tar.gz packed archives. In order to find out why your .ipk was not accepted I'd like to examine its file header.

ok - I've added a built/fixed .ipk file to https://gist.github.com/wrabbit-revisit … c79b5a987c .