Closed GoogleCodeExporter closed 8 years ago
GoogleCodeExporter
commented
8 years ago The extract-ng.sh script properly extracts this firmware. build-ng.sh builds
the new firmware, but the resulting firmware size is larger than the original
firmware image.
Other than the file size, the new firmware looks OK, but I don't have this
router so it is untested - tread with caution.Original comment by heffne...@gmail.com on 5 Sep 2011 at 12:56
GoogleCodeExporter
commented
8 years ago It used to be the case that DD-WRT uses a variant of squashfs-lzma that tries
various compression parameters to determine the most optimal. I would imagine
this is still the case. IIRC, I limited the search for the most optimal
parameters so it didn't take all day. This may be the cause of what should be a
slight difference in file size.Original comment by jeremy.collake@gmail.com on 5 Sep 2011 at 12:58
GoogleCodeExporter
commented
8 years ago One more thing: make sure you get the latest repo updates, some bug fixes for
extract-ng.sh and build-ng.sh were checked in today.Original comment by heffne...@gmail.com on 5 Sep 2011 at 12:58
GoogleCodeExporter
commented
8 years ago Just confirmed that the mksquashfs-lzma from the dd-wrt svn repo builds a
smaller squashfs image than the current version in FMK (in fact, even smaller
than the squashfs image in the dd-wrt firmware). Will update the damn-small
varient in FMK after further testing.Original comment by heffne...@gmail.com on 5 Sep 2011 at 1:40
GoogleCodeExporter
commented
8 years ago [deleted comment]Sounds good. If no output is shown during its very long compression process, I
will add some status indicator to it. I could even throw in a keypress, 'hit a
key to just use the best we found so far'.Original comment by jeremy.collake@gmail.com on 5 Sep 2011 at 1:47
GoogleCodeExporter
commented
8 years ago The extra size is only an issue as the new scripts expect the size to not
change and the CRC's and size values in the firmware headers won't be properly
updated if the size of the image changes.
Of course, this can be - and probably should be - changed, but I also like to
keep the sizes the same in order to ensure we aren't going to accidentally
overwrite something critical in flash. Without knowing the MTD layout for each
and every router, this can be kind of important. :POriginal comment by heffne...@gmail.com on 5 Sep 2011 at 1:50
GoogleCodeExporter
commented
8 years ago Indeed it is, you are very right. Related, one of the most common issues users
have had is going over the size threshold for their device. Whether we should
warn if the new size is larger than the original, I don't know. We could infer
from the original firmware image size the likely MTD layout and firmware size
limit, then check against it. However, all that is more trouble than I want to
go to, so its one of those 'put off until forever' ideas ;p.Original comment by jeremy.collake@gmail.com on 5 Sep 2011 at 1:59
GoogleCodeExporter
commented
8 years ago New squashfs code checked in, resulting firmware image is now the same size as
the original firmware image.
Right now, the build-ng script will throw an error and quit if the resulting
firmware image gets larger than the original.Original comment by heffne...@gmail.com on 5 Sep 2011 at 4:24
GoogleCodeExporter
commented
8 years ago many thanks to all of above comments.
btw, the extract-ng.sh needs binwalk to work properly. this tools can be found
at http://code.google.com/p/binwalk/.Original comment by mornin...@gmail.com on 5 Sep 2011 at 12:47
GoogleCodeExporter
commented
8 years ago Yes, the latest FMK check in includes and builds the binwalk 0.3.9 source.Original comment by heffne...@gmail.com on 5 Sep 2011 at 2:31
Original issue reported on code.google.com by
mornin...@gmail.comon 4 Sep 2011 at 5:43