Your customized firmware may not boot up correctly after creating the jffs2 partition.  This happens if the padding added by mksquashfs happens to be layed out across the erase_size (0x10000) boundary.  In tihs situation, the kernel sets starting offset of the OpenWrt partition within the CRC-calculated range and that leads to a CRC error once you reboot the router.

Edit: added the diagram
You'll hit the problem if an address 0x????0000 comes within the "JACKPOT" zone below.

     ...
 |  "pmon"    |
A+------------+ <- 0x00040000: "linux" partition starts here
 | trx header |                                                     
B|------------|                                                     
 |            |                                                             
 |            |                                                             
 |  kernel    |                                                             
 |            |                                                             
 |            |                                                     
 |------------|                                                     
C|------------| <- 4 byte boundary (base:B,forced by trx)
 |            |                                                             
 |            |                                                             
 | squashfs   |                                                             
 |            |                                                             
 |            |                                                             
 |------------| <- end of squashfs                                  
 |000000000000|                                                     
 | ---------- | <- +2048 bytes safety margin by the kernel
>|000000000000|<<<<- [JACKPOT!!!]
 |------------| <- 4K byte boundary (base:C,forced by mksquashfs)
 |ffffffffffff|                                                     
 |------------| <- 4K byte boundary (base:A,forced by trx)
 |ffffffffffff| <- more padding by addpattern                                             
 |------------|
 |  (free)    | <- still in the "linux" partition...
     ...

Here is a fix:

Hi mtakahar, you are my lifesaver

Just run into this issue with my freifunk-firmware yesterday I presume. I'll attach a little perl script which outputs some trx file offsets.

Can you verify this: the bug you are talking about as "Jackpot zone" will show up if the script outputs a different fsize= if mksquasfs is issued with/without the -nopad parameter?

TIA, Sven-Ola

I knew it, I wasn't alone hitting this problem!

You need to read the squashfs header to see where the actual used area ends.  The check would be something like what I added to your script.  (Not well tested.  Maybe you can run it against your files and tweak it if necessary.)

I think you are aware of it, but this script doesn't work against the files with the CyberTAN header (aka addpattern stuff.)

According to your changed script - as expected - it outputs the "bingo" term with the trx file in question. Here's the output. Many thanks from my side. Hopefully the OpenWRT source repository gurus will include your patch soon.

styx:/tmp # ./trxcheck2.pl openwrt-freifunk-0.6.5-de.trx
filesize: 28
fsize:  2035712
magic:  HDR0
len:    2035712 (0x1f1000)
crc32:          (0xfef658bf)
vers:   0       (0x0)
flags:  1       (0x1)
ofs1:   28      (0x1c)
ofs2:   676084  (0xa50f4)
ofs3:   0       (0x0)

squashfs header:
s_magic:        hsqs
inodes:         317
bytes_used:     1351701 (0x14a015)
  ...

squashfs used range:    0x000a50f4 - 0x001ef109
rounded range:          0x000a50f4 - 0x001effff
*** Danger zone:        0x001ef909 - 0x001f0fff
OpenWrt partition starts at 0x001f0000
*** bingo!!! ***