Re: UNS: Re: Update APEX for fatted nslu2 (FatSlug)

[Rod Whitby <rod@whitby.id.au>]

Asier wrote:
> There's something I'm worring about. This morning I've made a backup of the 
> flash: 
> 
> # cat /dev/mtdblock* >nslu2-backup.bin
> 
> I have reflashed the nslu2 a few times with it without any problem. But if 
> I "explode" the backup with 
> 
> # slugimage -u -i ../nslu2-backup.bin 
> 
> and create a new file with:
> 
> # slugimage -p -o di-nslu2-newapex.bin -b RedBoot -s SysConf -L apex.bin -k 
> vmlinuz -r ramdisk.gz -t Trailer
> 
> but... 
> 
> # cmp di-nslu2-newapex.bin ../nslu2-backup.bin
> di-nslu2-newapex.bin ../nslu2-backup.bin differ: char 1945801, line 6788
> 
> The files are different  And if I try to flash the nslu2 with the new file it 
> gets freezed! slugimage is the debian packaged version for amd64 and have 
> tryed also the version from the unslung cvs
> 
> Why I can't recreate the firmware file?

Very good question.  slugimage unpack and pack should always work.  It's
one of the tests in the slugimage regression test suite
(http://svn.nslu2-linux.org/svnroot/slugimage/trunk/tests/debian/standard.test)
so it should work and explicitly be tested for all versions of slugimage.

Note that I think Debian chose to pack the image using the -l
(little-endian) switch, instead of just allowing Apex to swap the images
on load, so you may well need to give the -l switch on unpack and pack
to get the same result.  You should look at the slugimage call in the
debian installer source to find out which you need.

Feel free to send me a private URL where I can download the original 8MB
image and I can try and reproduce your results ...

-- Rod