Loading ...
Sorry, an error occurred while loading the content.

Re: slugimage issue or operator error?

Expand Messages
  • Rob Lockhart
    One thing I forgot to mention - where I got slugimage . It is installed as part of the crosscompiler process in here:
    Message 1 of 10 , May 4, 2008
    • 0 Attachment
      One thing I forgot to mention - where I got "slugimage". It is
      installed as part of the crosscompiler process in here:
      slugos/tmp/work/i686-linux/slugimage-native-1.0-r12/slugimage
      which is same as here:
      slugos/tmp/staging/i686-linux/usr/bin/slugimage

      so I assume it's up-to-date.

      -Rob
    • Rod Whitby
      ... Try just: slugimage -F -p -o test.bin -L apex.bin -k vmlinuz -r Flashdisk If that works, then start adding options until you find the one that breaks it.
      Message 2 of 10 , May 5, 2008
      • 0 Attachment
        Rob Lockhart wrote:
        > Hello, group. I just finished going through and updating the Wiki
        > instructions for CentOS, and everything seems to build fine. Except I
        > need to replace the MAC address, obviously (using slugimage). The
        > build image is "slugosbe-4.10-alpha-nslu2-16mb.bin". Note I replaced
        > the last octet of my MAC address with "XX".
        >
        > First I disassemble the image:
        >
        > [slug@Linux ~/tmp]$ slugimage -F -u -i slugosbe-4.10-alpha-nslu2-16mb.bin
        > Read 2 blocks into <RedBoot>
        > Read 0x00006 bytes into <EthAddr>
        > Read 1 blocks into <SysConf>
        > Read 0x0BE28 bytes into <Loader>
        > Read 9 blocks into <Kernel>
        > Read 114 blocks into <Flashdisk>
        > Read 1 blocks into <FIS directory>
        > Read 1 blocks into <FIS directory>
        > Read 0x02EBC bytes into <Microcode>
        > Read 0x00010 bytes into <Trailer>
        > Wrote 0x00040000 bytes from <RedBoot> into "RedBoot"
        > Wrote 0x00020000 bytes from <SysConf> into "SysConf"
        > Wrote 0x0000BE28 bytes from <Loader> into "apex.bin"
        > Wrote 0x00101A74 bytes from <Kernel> into "vmlinuz"
        > Wrote 0x00E40000 bytes from <Flashdisk> into "Flashdisk"
        > Wrote 0x00020000 bytes from <FIS directory> into "FIS directory"
        > Wrote 0x00002EBC bytes from <Microcode> into "NPE-B"
        > Wrote 0x00000010 bytes from <Trailer> into "Trailer"
        >
        > Now I use a modified version of RedBoot (to support 16MB flash):
        >
        > [slug@Linux ~/tmp]$ slugimage -F -p -o test.bin -b RedBoot.16MBflash \
        > -s SysConf -L apex.bin -k vmlinuz -r Flashdisk -f FIS\ directory \
        > -m NPE-B -t Trailer -e 000F667BFEXX

        Try just:

        slugimage -F -p -o test.bin -L apex.bin -k vmlinuz -r Flashdisk

        If that works, then start adding options until you find the one that
        breaks it.

        -- Rod
      • Rod Whitby
        ... Note that slugimage has a regression test suite in: http://svn.nslu2-linux.org/svnroot/slugimage/trunk/tests/ So if you find a case that doesn t work,
        Message 3 of 10 , May 5, 2008
        • 0 Attachment
          Rod Whitby wrote:
          > Try just:
          >
          > slugimage -F -p -o test.bin -L apex.bin -k vmlinuz -r Flashdisk
          >
          > If that works, then start adding options until you find the one that
          > breaks it.

          Note that slugimage has a regression test suite in:

          http://svn.nslu2-linux.org/svnroot/slugimage/trunk/tests/

          So if you find a case that doesn't work, please add it to there (or send
          me the testcase so I can add it).

          [I note that I don't have any tests that use -F in there at the moment,
          so it won't be a surprise if something doesn't work - if someone want to
          write some -F test cases I'll happily add them.]

          -- Rod
        • Rob Lockhart
          [apologies for long debugging output] ... Hmm, looks like this won t go very far: [slug@Linux ~/tmp]$ slugimage -F -p -o test.bin -L apex.bin -k vmlinuz -r
          Message 4 of 10 , May 5, 2008
          • 0 Attachment
            [apologies for long debugging output]

            On Mon, May 5, 2008 at 5:15 AM, Rod Whitby <rod@...> wrote:
            >
            > Rob Lockhart wrote:
            > > Hello, group. I just finished going through and updating the Wiki
            > > instructions for CentOS, and everything seems to build fine. Except I
            > > need to replace the MAC address, obviously (using slugimage). The
            > > build image is "slugosbe-4.10-alpha-nslu2-16mb.bin". Note I replaced
            > > the last octet of my MAC address with "XX".
            > >
            > > First I disassemble the image:
            > >
            > Try just:
            >
            > slugimage -F -p -o test.bin -L apex.bin -k vmlinuz -r Flashdisk
            >
            > If that works, then start adding options until you find the one that
            > breaks it.

            Hmm, looks like this won't go very far:

            [slug@Linux ~/tmp]$ slugimage -F -p -o test.bin -L apex.bin -k vmlinuz
            -r Flashdisk
            Read 0x00040000 bytes from "RedBoot" into <RedBoot> (2 blocks / 2 blocks)
            Read 0x00020000 bytes from "SysConf" into <SysConf> (1 blocks / 1 blocks)
            Read 0x0000BE28 bytes from "apex.bin" into <Loader> (1 blocks / 1 blocks)
            Read 0x00101A74 bytes from "vmlinuz" into <Kernel> (9 blocks / 9 blocks)
            Read 0x00E40000 bytes from "Flashdisk" into <Ramdisk> (115 blocks / 115 blocks)
            Read 0x00002EBC bytes from "NPE-B" into <Microcode> (0x02ECC bytes /
            0x03FE0 bytes)
            Read 0x00000010 bytes from "Trailer" into <Trailer> (0x00010 bytes /
            0x00010 bytes)
            Ran out of flash space in <Ramdisk> - 0x00010 bytes too large.

            I currently did a "make distclean" and rebuilding again from scratch.
            I'll try the disassembly and re-assembly again once the image is
            rebuilt.

            Note that with the debug statements, the disassembly doesn't show a
            Ramdisk. Disassembly with -d option:

            [slug@Linux ~/tmp]$ slugimage -d -u -F -i slugosbe-4.10-alpha-nslu2-16mb.bin
            Initial partition map:
            RedBoot 0x00000000 0x00040000
            EthAddr 0x0003FFB0 0x00000006
            SysConf 0x00040000 0x00020000
            Loader (undefined) (undefined)
            Kernel (undefined) (undefined)
            Ramdisk (undefined) (undefined)
            FIS directory 0x00FE0000 0x00020000
            Loader config 0x00FF8000 0x00004000
            Microcode 0x00FFC000 0x00003FE0
            Trailer 0x00FFFFF0 0x00000010
            Read 0x01000000 bytes from "slugosbe-4.10-alpha-nslu2-16mb.bin"
            Found <RedBoot> at 0x00000000 (2 blocks)
            Found <SysConf> at 0x00040000 (1 blocks)
            Found skip region at 0x00000, size 0x00010
            Found <Loader> at 0x00060000 (1 blocks) [0x00000/0x00010]
            Found skip region at 0x00000, size 0x00010
            Found skip region at 0xE0000, size 0x00010
            Found <Kernel> at 0x00080000 (9 blocks) [0x00000/0x00010, 0xE0000/0x00010]
            Found <Flashdisk> at 0x001A0000 (114 blocks)
            Found <FIS directory> at 0x00FE0000 (1 blocks)
            Found terminator for <FIS directory>
            Locating <RedBoot> at 0x00000000 (2 blocks)
            Skipped <EthAddr> (pseudo partition)
            Locating <SysConf> at 0x00040000 (1 blocks)
            Locating <Loader> at 0x00060000 (1 blocks)
            Locating <Kernel> at 0x00080000 (9 blocks)
            Splicing new partition <Flashdisk> before <Ramdisk>
            Locating <Flashdisk> at 0x001A0000 (114 blocks)
            Splicing new partition <FIS directory> before <Ramdisk>
            Locating <FIS directory> at 0x00FE0000 (1 blocks)
            Read 2 blocks into <RedBoot>
            Read 0x00006 bytes into <EthAddr>
            Read 1 blocks into <SysConf>
            Found header size of 0x0000BE28 bytes for <Loader>
            Read 0x0BE28 bytes into <Loader>
            Found header size of 0x00101A84 bytes for <Kernel>
            Removing 0x00010 bytes from offset 0xE0000
            Read 9 blocks into <Kernel>
            Read 114 blocks into <Flashdisk>
            Read 1 blocks into <FIS directory>
            Read 1 blocks into <FIS directory>
            Skipping empty pseudo partition <Loader config>
            Found header size of 0x00002EBC bytes for <Microcode>
            Read 0x02EBC bytes into <Microcode>
            Read 0x00010 bytes into <Trailer>
            After reading firmware:
            RedBoot 0x00000000 0x00040000
            EthAddr 0x0003FFB0 0x00000006
            SysConf 0x00040000 0x00020000
            Loader 0x00060000 0x00020000 [0x00000/0x00010]
            Kernel 0x00080000 0x00120000 [0x00000/0x00010,
            0xE0000/0x00010]
            Flashdisk 0x001A0000 0x00E40000
            FIS directory 0x00FE0000 0x00020000
            Ramdisk (undefined) (undefined)
            FIS directory 0x00FE0000 0x00020000
            Loader config 0x00FF8000 0x00004000
            Microcode 0x00FFC000 0x00003FE0
            Trailer 0x00FFFFF0 0x00000010
            Wrote 0x00040000 bytes from <RedBoot> into "RedBoot"
            Skipping <EthAddr> (no filename specified)
            Wrote 0x00020000 bytes from <SysConf> into "SysConf"
            Wrote 0x0000BE28 bytes from <Loader> into "apex.bin"
            Wrote 0x00101A74 bytes from <Kernel> into "vmlinuz"
            Wrote 0x00E40000 bytes from <Flashdisk> into "Flashdisk"
            Wrote 0x00020000 bytes from <FIS directory> into "FIS directory"
            Skipping <Ramdisk> (no data to write)
            Skipping <FIS directory> (no filename specified)
            Skipping <Loader config> (no filename specified)
            Wrote 0x00002EBC bytes from <Microcode> into "NPE-B"
            Wrote 0x00000010 bytes from <Trailer> into "Trailer"

            See the interesting "Found SkipRegion" with same size as overflow (10
            bytes) - coincidence? Also note it's skipping Ramdisk but yet the
            option is specified when re-assembling, if Ramdisk is different than
            Flashdisk.

            Regards,
            -Rob
          • Rob Lockhart
            ... Interesting, I went to the URL above. http://svn.nslu2-linux.org/svnroot/slugimage/trunk/tests/slugos/ looking at file: large-flashdisk.expected shows: Ran
            Message 5 of 10 , May 5, 2008
            • 0 Attachment
              On Mon, May 5, 2008 at 5:21 AM, Rod Whitby <rod@...> wrote:
              > Note that slugimage has a regression test suite in:
              >
              > http://svn.nslu2-linux.org/svnroot/slugimage/trunk/tests/
              >
              > So if you find a case that doesn't work, please add it to there (or send
              > me the testcase so I can add it).
              >
              > [I note that I don't have any tests that use -F in there at the moment,
              > so it won't be a surprise if something doesn't work - if someone want to
              > write some -F test cases I'll happily add them.]

              Interesting, I went to the URL above.
              http://svn.nslu2-linux.org/svnroot/slugimage/trunk/tests/slugos/
              looking at file:
              large-flashdisk.expected

              shows:

              Ran out of flash space in <Flashdisk> - 0x00010 bytes too large.

              Same error message I'm getting. Coincidence?

              Thanks for your help,
              -Rob
            • Rod Whitby
              ... Nope, it just means that your flashdisk file that you are providing to slugimage is 16 bytes too large. There is a 16 byte length header that is prepended
              Message 6 of 10 , May 5, 2008
              • 0 Attachment
                Rob Lockhart wrote:
                > Interesting, I went to the URL above.
                > http://svn.nslu2-linux.org/svnroot/slugimage/trunk/tests/slugos/
                > looking at file:
                > large-flashdisk.expected
                >
                > shows:
                >
                > Ran out of flash space in <Flashdisk> - 0x00010 bytes too large.
                >
                > Same error message I'm getting. Coincidence?

                Nope, it just means that your flashdisk file that you are providing to
                slugimage is 16 bytes too large.

                There is a 16 byte length header that is prepended to the kernel and
                ramdisks that you provide to slugimage before they are put in the flash
                image (this is required by the vendor RedBoot). If you provide files
                that are the exact size of the flash partitions, then they will actually
                by 16 bytes too large due to this header which must be prepended.

                So you need to work out why your Flashdisk file is too large.

                -- Rod
              • Rod Whitby
                ... I just checked in some regression tests for -F and added unpacking and repacking to all existing tests - and found a small bug. I don t think it s the
                Message 7 of 10 , May 5, 2008
                • 0 Attachment
                  Rod Whitby wrote:
                  > Rod Whitby wrote:
                  >> Try just:
                  >>
                  >> slugimage -F -p -o test.bin -L apex.bin -k vmlinuz -r Flashdisk
                  >>
                  >> If that works, then start adding options until you find the one that
                  >> breaks it.
                  >
                  > Note that slugimage has a regression test suite in:
                  >
                  > http://svn.nslu2-linux.org/svnroot/slugimage/trunk/tests/
                  >
                  > So if you find a case that doesn't work, please add it to there (or send
                  > me the testcase so I can add it).
                  >
                  > [I note that I don't have any tests that use -F in there at the moment,
                  > so it won't be a surprise if something doesn't work - if someone want to
                  > write some -F test cases I'll happily add them.]

                  I just checked in some regression tests for -F and added unpacking and
                  repacking to all existing tests - and found a small bug. I don't think
                  it's the cause of your problem, but you might want to try the latest
                  slugimage from svn trunk.

                  -- Rod
                • Rod Whitby
                  ... I finally realised the problem - you re asking slugimage to put a jffs2 Flashdisk partition into the predefined Ramdisk partition. That won t work,
                  Message 8 of 10 , May 6, 2008
                  • 0 Attachment
                    Rob Lockhart wrote:
                    > [apologies for long debugging output]
                    >
                    > On Mon, May 5, 2008 at 5:15 AM, Rod Whitby <rod@...> wrote:
                    >> Rob Lockhart wrote:
                    >> > Hello, group. I just finished going through and updating the Wiki
                    >> > instructions for CentOS, and everything seems to build fine. Except I
                    >> > need to replace the MAC address, obviously (using slugimage). The
                    >> > build image is "slugosbe-4.10-alpha-nslu2-16mb.bin". Note I replaced
                    >> > the last octet of my MAC address with "XX".
                    >> >
                    >> > First I disassemble the image:
                    >> >
                    >> Try just:
                    >>
                    >> slugimage -F -p -o test.bin -L apex.bin -k vmlinuz -r Flashdisk
                    >>
                    >> If that works, then start adding options until you find the one that
                    >> breaks it.
                    >
                    > Hmm, looks like this won't go very far:
                    >
                    > [slug@Linux ~/tmp]$ slugimage -F -p -o test.bin -L apex.bin -k vmlinuz
                    > -r Flashdisk
                    > Read 0x00040000 bytes from "RedBoot" into <RedBoot> (2 blocks / 2 blocks)
                    > Read 0x00020000 bytes from "SysConf" into <SysConf> (1 blocks / 1 blocks)
                    > Read 0x0000BE28 bytes from "apex.bin" into <Loader> (1 blocks / 1 blocks)
                    > Read 0x00101A74 bytes from "vmlinuz" into <Kernel> (9 blocks / 9 blocks)
                    > Read 0x00E40000 bytes from "Flashdisk" into <Ramdisk> (115 blocks / 115 blocks)
                    > Read 0x00002EBC bytes from "NPE-B" into <Microcode> (0x02ECC bytes /
                    > 0x03FE0 bytes)
                    > Read 0x00000010 bytes from "Trailer" into <Trailer> (0x00010 bytes /
                    > 0x00010 bytes)
                    > Ran out of flash space in <Ramdisk> - 0x00010 bytes too large.

                    I finally realised the problem - you're asking slugimage to put a jffs2
                    Flashdisk partition into the predefined Ramdisk partition. That won't
                    work, because a Ramdisk needs the length header, whereas a Flashdisk
                    doesn't.

                    I've added code to slugimage to catch this specific situation and give a
                    better error message:

                    $ ./slugimage -F -p -o slugosbe-4.10-alpha-nslu2-16mb.bin -L apex.bin -r
                    Flashdisk
                    Read 0x00040000 bytes from "RedBoot" into <RedBoot> (2 blocks / 2 blocks)
                    Read 0x00020000 bytes from "SysConf" into <SysConf> (1 blocks / 1 blocks)
                    Read 0x0000BE28 bytes from "apex.bin" into <Loader> (1 blocks / 1 blocks)
                    Read 0x00101A88 bytes from "vmlinuz" into <Kernel> (9 blocks / 9 blocks)
                    Read 0x00E40000 bytes from "Flashdisk" into <Ramdisk> (115 blocks / 115
                    blocks)
                    Read 0x00002EBC bytes from "NPE-B" into <Microcode> (0x02ECC bytes /
                    0x03FE0 bytes)
                    Read 0x00000010 bytes from "Trailer" into <Trailer> (0x00010 bytes /
                    0x00010 bytes)
                    Ran out of flash space in <Ramdisk> - 0x00010 bytes too large.
                    Perhaps you meant to use the -r Flashdisk:<filename> syntax instead?

                    What you need to do is:

                    $ slugimage -F -p -o test.bin -L apex.bin -k vmlinuz -r Flashdisk:Flashdisk

                    This tells slugimage that you're giving it a Flashdisk partition, with
                    the contents in the Flashdisk filename. Slugimage then removes the
                    requirement for a partition header (since you're not giving it a
                    Ramdisk, and it's already added a skip region in the previous partition
                    for the special 16 bytes at 0x160000), and this means the sizes now match:

                    $ ./slugimage -F -p -o slugosbe-4.10-alpha-nslu2-16mb.bin -L apex.bin -r
                    Flashdisk:Flashdisk
                    Read 0x00040000 bytes from "RedBoot" into <RedBoot> (2 blocks / 2 blocks)
                    Read 0x00020000 bytes from "SysConf" into <SysConf> (1 blocks / 1 blocks)
                    Read 0x0000BE28 bytes from "apex.bin" into <Loader> (1 blocks / 1 blocks)
                    Read 0x00101A88 bytes from "vmlinuz" into <Kernel> (9 blocks / 9 blocks)
                    Read 0x00E40000 bytes from "Flashdisk" into <Flashdisk> (114 blocks /
                    114 blocks)
                    Read 0x00002EBC bytes from "NPE-B" into <Microcode> (0x02ECC bytes /
                    0x03FE0 bytes)
                    Read 0x00000010 bytes from "Trailer" into <Trailer> (0x00010 bytes /
                    0x00010 bytes)
                    Wrote 2 blocks (0x00000000 to 0x00040000) from <RedBoot> into
                    "slugosbe-4.10-alpha-nslu2-16mb.bin"
                    Wrote 1 blocks (0x00040000 to 0x00060000) from <SysConf> into
                    "slugosbe-4.10-alpha-nslu2-16mb.bin"
                    Wrote 1 blocks (0x00060000 to 0x00080000) from <Loader> into
                    "slugosbe-4.10-alpha-nslu2-16mb.bin"
                    Wrote 9 blocks (0x00080000 to 0x001A0000) from <Kernel> into
                    "slugosbe-4.10-alpha-nslu2-16mb.bin"
                    Wrote 114 blocks (0x001A0000 to 0x00FE0000) from <Flashdisk> into
                    "slugosbe-4.10-alpha-nslu2-16mb.bin"
                    Wrote 1 blocks (0x00FE0000 to 0x01000000) from <FIS directory> into
                    "slugosbe-4.10-alpha-nslu2-16mb.bin"
                    Wrote 0x03FE0 bytes (0x00FFC000 to 0x00FFFFE0) from <Microcode> into
                    "slugosbe-4.10-alpha-nslu2-16mb.bin"
                    Wrote 0x00010 bytes (0x00FFFFF0 to 0x01000000) from <Trailer> into
                    "slugosbe-4.10-alpha-nslu2-16mb.bin"

                    -- Rod
                  • Rob Lockhart
                    ... Thanks for the help, Rod. I modified the Slugimage wiki. Glad it was PEBKAC. -Rob
                    Message 9 of 10 , May 7, 2008
                    • 0 Attachment
                      On Tue, May 6, 2008 at 9:56 AM, Rod Whitby <rod@...> wrote:
                      >
                      > Rob Lockhart wrote:
                      > > [apologies for long debugging output]
                      > >
                      > > On Mon, May 5, 2008 at 5:15 AM, Rod Whitby <rod@...> wrote:
                      > >> Rob Lockhart wrote:
                      > >> > Hello, group. I just finished going through and updating the Wiki
                      > >> > instructions for CentOS, and everything seems to build fine. Except I
                      > >> > need to replace the MAC address, obviously (using slugimage). The
                      > >> > build image is "slugosbe-4.10-alpha-nslu2-16mb.bin". Note I replaced
                      > >> > the last octet of my MAC address with "XX".
                      > >> >
                      > >> > First I disassemble the image:
                      > >> >
                      > >> Try just:
                      > >>
                      > >> slugimage -F -p -o test.bin -L apex.bin -k vmlinuz -r Flashdisk
                      > >>
                      > >> If that works, then start adding options until you find the one that
                      > >> breaks it.
                      > >
                      > > Hmm, looks like this won't go very far:
                      > >
                      > > [slug@Linux ~/tmp]$ slugimage -F -p -o test.bin -L apex.bin -k vmlinuz
                      > > -r Flashdisk
                      > > Read 0x00040000 bytes from "RedBoot" into <RedBoot> (2 blocks / 2 blocks)
                      > > Read 0x00020000 bytes from "SysConf" into <SysConf> (1 blocks / 1 blocks)
                      > > Read 0x0000BE28 bytes from "apex.bin" into <Loader> (1 blocks / 1 blocks)
                      > > Read 0x00101A74 bytes from "vmlinuz" into <Kernel> (9 blocks / 9 blocks)
                      > > Read 0x00E40000 bytes from "Flashdisk" into <Ramdisk> (115 blocks / 115 blocks)
                      > > Read 0x00002EBC bytes from "NPE-B" into <Microcode> (0x02ECC bytes /
                      > > 0x03FE0 bytes)
                      > > Read 0x00000010 bytes from "Trailer" into <Trailer> (0x00010 bytes /
                      > > 0x00010 bytes)
                      > > Ran out of flash space in <Ramdisk> - 0x00010 bytes too large.
                      >
                      > I finally realised the problem - you're asking slugimage to put a jffs2
                      > Flashdisk partition into the predefined Ramdisk partition. That won't
                      > work, because a Ramdisk needs the length header, whereas a Flashdisk
                      > doesn't.
                      >
                      > I've added code to slugimage to catch this specific situation and give a
                      > better error message:
                      >
                      > $ ./slugimage -F -p -o slugosbe-4.10-alpha-nslu2-16mb.bin -L apex.bin -r
                      >
                      > Flashdisk
                      > Read 0x00040000 bytes from "RedBoot" into <RedBoot> (2 blocks / 2 blocks)
                      > Read 0x00020000 bytes from "SysConf" into <SysConf> (1 blocks / 1 blocks)
                      > Read 0x0000BE28 bytes from "apex.bin" into <Loader> (1 blocks / 1 blocks)
                      > Read 0x00101A88 bytes from "vmlinuz" into <Kernel> (9 blocks / 9 blocks)
                      >
                      > Read 0x00E40000 bytes from "Flashdisk" into <Ramdisk> (115 blocks / 115
                      > blocks)
                      > Read 0x00002EBC bytes from "NPE-B" into <Microcode> (0x02ECC bytes /
                      > 0x03FE0 bytes)
                      > Read 0x00000010 bytes from "Trailer" into <Trailer> (0x00010 bytes /
                      > 0x00010 bytes)
                      > Ran out of flash space in <Ramdisk> - 0x00010 bytes too large.
                      > Perhaps you meant to use the -r Flashdisk:<filename> syntax instead?
                      >
                      > What you need to do is:
                      >
                      > $ slugimage -F -p -o test.bin -L apex.bin -k vmlinuz -r Flashdisk:Flashdisk
                      >
                      > This tells slugimage that you're giving it a Flashdisk partition, with
                      > the contents in the Flashdisk filename. Slugimage then removes the
                      > requirement for a partition header (since you're not giving it a
                      > Ramdisk, and it's already added a skip region in the previous partition
                      > for the special 16 bytes at 0x160000), and this means the sizes now match:
                      >
                      > $ ./slugimage -F -p -o slugosbe-4.10-alpha-nslu2-16mb.bin -L apex.bin -r
                      > Flashdisk:Flashdisk
                      >
                      > Read 0x00040000 bytes from "RedBoot" into <RedBoot> (2 blocks / 2 blocks)
                      > Read 0x00020000 bytes from "SysConf" into <SysConf> (1 blocks / 1 blocks)
                      > Read 0x0000BE28 bytes from "apex.bin" into <Loader> (1 blocks / 1 blocks)
                      > Read 0x00101A88 bytes from "vmlinuz" into <Kernel> (9 blocks / 9 blocks)
                      > Read 0x00E40000 bytes from "Flashdisk" into <Flashdisk> (114 blocks /
                      > 114 blocks)

                      Thanks for the help, Rod. I modified the Slugimage wiki. Glad it was PEBKAC.

                      -Rob
                    Your message has been successfully submitted and would be delivered to recipients shortly.