after deleting files and rebuilding, image filesize is same as original

[dsw]

I already reported this as an issue on the google code site:

here the report:

What steps will reproduce the problem?
1. Using firmware mod kit 0.73 beta on fedora 16
2. extract latest dd-wrt atheros for broadcom chipset
(http://www.dd-wrt.com/site/support/other-downloads?path=others%2Feko%2FBrainSlayer-V24-preSP2%2F2011%2F12-20-11-r18024%2F)
3. use extract-ng.sh output/
4. delete from ./output/rootfs/usr/sbin the sputnik and chilli executables
5. rebuild with build-ng.sh output (alter build-ng.sh instead of 'cat' > 'sudo cat' when writing filesystem into bin, otherwise it fails > or run as root)
6. result is new bin, but it has exactly the same size as the original dd-wrt bin file.

What is the expected output? What do you see instead?
I expect the result bin file to be smaller than the original.

What version of the product are you using? On what operating system?
using build 0.73 beta on fedora 16

Added the binwalk.log and config.log that are made by the extract tool

Does anybody know how to solve this?

Regards,

Dennis

[dsw]

Oh and the reported issue is number 53 

[Jeremy Collake]

Most of the time firmware images are aligned, meaning they have 'blocks' of specific sizes, usually 64KB increments. So, unless the size change was enough to go down to the next lower alignment boundary, it wouldn't make a difference. Remove more, and it will eventually decrease by (most likely) 64KB.

[dsw]

Well I looked into what you said, but it's not the case.  The blocksize is 128kB and the deleted files are together a bit than 386kB.
Still the created bin file is the same size as the original.
Can it be the OS or something else?

At least keep the bugreport open till this is resolved.

Any ideas are welcome.

Regards
Dennis

[Jeremy Collake]

Ok, sure. I could be wrong. There may be another *reason*, but I don't think its errata to be honest.

[Jeremy Collake]

You saw, but for any readers:

Craig says: "The build-ng script pads the new firmware image out to match the size of the original. Any particular reason you want the firmware image to be smaller?"

So, there we go . I didn't realize he padded to the original size. He does pose a good question about the necessity of making it smaller, BUT you can probably clip out the padding in the script if you choose, now that you know the cause.

This applies only to the -ng scripts. The older ones didn't do this type of padding.

[dsw]

Hi, ok now I understand.
Well I will look into the script, to find the padding function. I hope I can turn it of.

I want the image to be smaller, because the router I use needs it to be just a little bit smaller, otherwise it is not loading after installing the firmware. (Router: belkin f5d8230-4 with installed Atheros wireless card)

Thank you for helping, i'll write here when I manage to get it working.

Regards,

Dennis

[Jeremy Collake]

I committed a change to build-ng.sh that allows an optional "-nopad" parameter. Update, try it, and make sure I didn't break anything in my haste, lol.

[dsw]

THX , I will try today!!!

Regards,
Dennis

[dsw]

Hi Support,

I tried with -nopad option (./build-ng.sh fmk -nopad)
But sadly  it didn't solve my problem... the new-firmware.bin is still the same size as the original.

Regards,

Dennis

[Jeremy Collake]

I just committed a fix .... Give that a try .  I did not test with a folder name specified on the command line (it defaults to 'fmk' so you can omit that), and was just moving too fast. This should work, though I still haven't tested. I am pretty darn confident though, as the issue was definitely what I said above.

And I had said to myself "this is too simple to screw up, no need to test" ;p. Famous last words. This should do ok though, it was just that I did not properly account for the user specifying the folder on the command line (though I mistakenly thought I had).

[dsw]

Testing right now...

[dsw]

Code Select Expand

Little endian filesystem, data block size 131072, compressed data, compressed metadata, compressed fragments
Filesystem size 2869.43 Kbytes (2.80 Mbytes)
30.05% of uncompressed filesystem size (9549.03 Kbytes)
Inode table size 4678 bytes (4.57 Kbytes)
21.84% of uncompressed inode table size (21421 bytes)
Directory table size 6204 bytes (6.06 Kbytes)
59.31% of uncompressed directory table size (10461 bytes)
Number of duplicate files found 0
Number of inodes 688
Number of files 436
Number of fragments 22
Number of symbolic links  208
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 44
Number of uids 1
root (0)
Number of gids 0
Padding of firmware image disabled via -nopad
Processing 1 header(s) from fmk/new-firmware.bin...
Processing header at offset 0...checksum update(s) failed!
CRC update failed.
Firmware header not supported; firmware checksums may be incorrect. New firmware image has been saved to: fmk/new-firmware.bin

That message about the header, is it a failure? Don't want to try the image if it not finished well.

please  advice...

Dennis

[dsw]

Well I tried the image, but somehow my wifi of the image wasn't loading, so i'll try a different image. Hope I didn't brick anything...

Regards,

Dennis

[Jeremy Collake]

Well, I can guarantee you all I did was remove the padding, as you requested, but can't guarantee anything else . Good luck.