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

upslug2: A new implementation of upslug

Expand Messages
  • John Bowler
    I have just checked in a new (completely rewritten) implementation of upslug called upslug2 This implementation should be considerably more portable than
    Message 1 of 17 , Sep 2, 2005
      I have just checked in a new (completely rewritten) implementation of upslug
      called 'upslug2'

      This implementation should be considerably more portable than upslug -
      indeed there is a configuration option (--with-libpcap) which causes it to
      use libpcap on Linux (not tested on anything else yet).

      I had a number of reasons for doing this:

      1) Although this code is command-line it is modularised in such a way as to
      make a GUI trivial (in so far as a GUI is ever trivial).
      2) The OS specific 'talk to the wire' code is separated out into two
      modules - one for Linux (using packet(7)) and one for everything else (using
      libpcap). Thanks to Wim Lewis for showing me how to do this. This code,
      once any bugs are removed, should work fine on a Mac.
      3) upslug2 can flash given just the kernel and the rootfs (jffs2 partition).
      There is no need for that chunk of RedBoot code which had to be extracted
      (before) from a LinkSys flash image. As a consequence if you use it that
      way it is a *lot* faster - it doesn't write the bits which have no
      corresponding data.
      4) upslug2 is MIT copyright, not GPL, so if you need to do something
      proprietary based on it you are free to do so without extra conditions.
      5) The progress bar is better, IMO.
      6) The verify actually happens (at the same time I fixed upslug so that it
      is now verifying the flash - it hasn't been for a while, if it ever did.)
      7) upslug was a big security hole, such that making upslug 'setuid' was an
      extremely bad idea on a public network. upslug2 doesn't have that hole - it
      only uses setuid root privelege to open the socket so it is not possible to
      use it to read other peoples files. (Specifically I believe it is safer to
      make upslug2 setuid - 4755 - than to use it with sudo).

      At present the code is only in the NSLU sourceforge CVS project - module
      'upslug2':

      http://sourceforge.net/cvs/?group_id=116564

      If you want to build it you have to run 'autoreconf -i' to bootstrap the
      build:

      autoreconf -i
      ./configure
      make

      Or use ./configure --with-libpcap to get the libpcap version. There are
      probably still some bugs. Use --help for a list of options.

      John Bowler <jbowler@...>
    • Tim Ansell
      I can t compile upslug2. It dies with the following errors, root@ultralight:/home/tim/oss/upslug2/upslug2# make g++ -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c
      Message 2 of 17 , Sep 4, 2005
        I can't compile upslug2. It dies with the following errors,

        root@ultralight:/home/tim/oss/upslug2/upslug2# make
        g++ -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c linux_wire.cc
        g++ -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c pcap_wire.cc
        g++ -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c nslu2_image.cc
        nslu2_image.cc: In function ‘void NSLU2Image::SafeRead(std::ifstream*,
        char*, size_t, const char*)’:
        nslu2_image.cc:19: error: ‘errno’ was not declared in this scope
        nslu2_image.cc:25: error: ‘errno’ was not declared in this scope
        nslu2_image.cc: In function ‘void NSLU2Image::SafeSeek(std::ifstream*,
        int, const char*)’:
        nslu2_image.cc:32: error: ‘errno’ was not declared in this scope
        nslu2_image.cc: In constructor ‘NSLU2Image::RealImage::RealImage(bool,
        const char*)’:
        nslu2_image.cc:40: error: ‘errno’ was not declared in this scope
        nslu2_image.cc: In member function ‘int
        NSLU2Image::SynthesiseImage::SizeOf(std::ifstream&)’:
        nslu2_image.cc:113: error: ‘errno’ was not declared in this scope
        nslu2_image.cc: In constructor
        ‘NSLU2Image::SynthesiseImage::SynthesiseImage(const char*, bool, const
        char*, const char*, const char*, short unsigned int, short unsigned int,
        short unsigned int, short unsigned int)’:
        nslu2_image.cc:249: error: ‘errno’ was not declared in this scope
        nslu2_image.cc:278: error: ‘errno’ was not declared in this scope
        nslu2_image.cc:305: error: ‘errno’ was not declared in this scope
        nslu2_image.cc:347: error: ‘errno’ was not declared in this scope

        I'm sure these are most probably easily fixed errors.

        Mithro



        On Fri, 2005-09-02 at 19:23 -0700, John Bowler wrote:
        > I have just checked in a new (completely rewritten) implementation of upslug
        > called 'upslug2'
        >
        > This implementation should be considerably more portable than upslug -
        > indeed there is a configuration option (--with-libpcap) which causes it to
        > use libpcap on Linux (not tested on anything else yet).
        >
        > I had a number of reasons for doing this:
        >
        > 1) Although this code is command-line it is modularised in such a way as to
        > make a GUI trivial (in so far as a GUI is ever trivial).
        > 2) The OS specific 'talk to the wire' code is separated out into two
        > modules - one for Linux (using packet(7)) and one for everything else (using
        > libpcap). Thanks to Wim Lewis for showing me how to do this. This code,
        > once any bugs are removed, should work fine on a Mac.
        > 3) upslug2 can flash given just the kernel and the rootfs (jffs2 partition).
        > There is no need for that chunk of RedBoot code which had to be extracted
        > (before) from a LinkSys flash image. As a consequence if you use it that
        > way it is a *lot* faster - it doesn't write the bits which have no
        > corresponding data.
        > 4) upslug2 is MIT copyright, not GPL, so if you need to do something
        > proprietary based on it you are free to do so without extra conditions.
        > 5) The progress bar is better, IMO.
        > 6) The verify actually happens (at the same time I fixed upslug so that it
        > is now verifying the flash - it hasn't been for a while, if it ever did.)
        > 7) upslug was a big security hole, such that making upslug 'setuid' was an
        > extremely bad idea on a public network. upslug2 doesn't have that hole - it
        > only uses setuid root privelege to open the socket so it is not possible to
        > use it to read other peoples files. (Specifically I believe it is safer to
        > make upslug2 setuid - 4755 - than to use it with sudo).
        >
        > At present the code is only in the NSLU sourceforge CVS project - module
        > 'upslug2':
        >
        > http://sourceforge.net/cvs/?group_id=116564
        >
        > If you want to build it you have to run 'autoreconf -i' to bootstrap the
        > build:
        >
        > autoreconf -i
        > ./configure
        > make
        >
        > Or use ./configure --with-libpcap to get the libpcap version. There are
        > probably still some bugs. Use --help for a list of options.
        >
        > John Bowler <jbowler@...>
        >
        >
        >
        >
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
      • Tim Ansell
        This appears to be a g++-4.0 bug. I was able to compile with g++-3.3 Tim
        Message 3 of 17 , Sep 4, 2005
          This appears to be a g++-4.0 bug. I was able to compile with g++-3.3

          Tim

          On Sun, 2005-09-04 at 18:48 +0200, Tim Ansell wrote:
          > I can't compile upslug2. It dies with the following errors,
          >
          > root@ultralight:/home/tim/oss/upslug2/upslug2# make
          > g++ -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c linux_wire.cc
          > g++ -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c pcap_wire.cc
          > g++ -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c nslu2_image.cc
          > nslu2_image.cc: In function ‘void NSLU2Image::SafeRead(std::ifstream*,
          > char*, size_t, const char*)’:
          > nslu2_image.cc:19: error: ‘errno’ was not declared in this scope
          > nslu2_image.cc:25: error: ‘errno’ was not declared in this scope
          > nslu2_image.cc: In function ‘void NSLU2Image::SafeSeek(std::ifstream*,
          > int, const char*)’:
          > nslu2_image.cc:32: error: ‘errno’ was not declared in this scope
          > nslu2_image.cc: In constructor ‘NSLU2Image::RealImage::RealImage(bool,
          > const char*)’:
          > nslu2_image.cc:40: error: ‘errno’ was not declared in this scope
          > nslu2_image.cc: In member function ‘int
          > NSLU2Image::SynthesiseImage::SizeOf(std::ifstream&)’:
          > nslu2_image.cc:113: error: ‘errno’ was not declared in this scope
          > nslu2_image.cc: In constructor
          > ‘NSLU2Image::SynthesiseImage::SynthesiseImage(const char*, bool, const
          > char*, const char*, const char*, short unsigned int, short unsigned int,
          > short unsigned int, short unsigned int)’:
          > nslu2_image.cc:249: error: ‘errno’ was not declared in this scope
          > nslu2_image.cc:278: error: ‘errno’ was not declared in this scope
          > nslu2_image.cc:305: error: ‘errno’ was not declared in this scope
          > nslu2_image.cc:347: error: ‘errno’ was not declared in this scope
          >
          > I'm sure these are most probably easily fixed errors.
          >
          > Mithro
          >
          >
          >
          > On Fri, 2005-09-02 at 19:23 -0700, John Bowler wrote:
          > > I have just checked in a new (completely rewritten) implementation of upslug
          > > called 'upslug2'
          > >
          > > This implementation should be considerably more portable than upslug -
          > > indeed there is a configuration option (--with-libpcap) which causes it to
          > > use libpcap on Linux (not tested on anything else yet).
          > >
          > > I had a number of reasons for doing this:
          > >
          > > 1) Although this code is command-line it is modularised in such a way as to
          > > make a GUI trivial (in so far as a GUI is ever trivial).
          > > 2) The OS specific 'talk to the wire' code is separated out into two
          > > modules - one for Linux (using packet(7)) and one for everything else (using
          > > libpcap). Thanks to Wim Lewis for showing me how to do this. This code,
          > > once any bugs are removed, should work fine on a Mac.
          > > 3) upslug2 can flash given just the kernel and the rootfs (jffs2 partition).
          > > There is no need for that chunk of RedBoot code which had to be extracted
          > > (before) from a LinkSys flash image. As a consequence if you use it that
          > > way it is a *lot* faster - it doesn't write the bits which have no
          > > corresponding data.
          > > 4) upslug2 is MIT copyright, not GPL, so if you need to do something
          > > proprietary based on it you are free to do so without extra conditions.
          > > 5) The progress bar is better, IMO.
          > > 6) The verify actually happens (at the same time I fixed upslug so that it
          > > is now verifying the flash - it hasn't been for a while, if it ever did.)
          > > 7) upslug was a big security hole, such that making upslug 'setuid' was an
          > > extremely bad idea on a public network. upslug2 doesn't have that hole - it
          > > only uses setuid root privelege to open the socket so it is not possible to
          > > use it to read other peoples files. (Specifically I believe it is safer to
          > > make upslug2 setuid - 4755 - than to use it with sudo).
          > >
          > > At present the code is only in the NSLU sourceforge CVS project - module
          > > 'upslug2':
          > >
          > > http://sourceforge.net/cvs/?group_id=116564
          > >
          > > If you want to build it you have to run 'autoreconf -i' to bootstrap the
          > > build:
          > >
          > > autoreconf -i
          > > ./configure
          > > make
          > >
          > > Or use ./configure --with-libpcap to get the libpcap version. There are
          > > probably still some bugs. Use --help for a list of options.
          > >
          > > John Bowler <jbowler@...>
          > >
          > >
          > >
          > >
          > >
          > > Yahoo! Groups Links
          > >
          > >
          > >
          > >
          > >
          > >
          >
          >
          >
          >
          >
          >
          >
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
        • John Bowler
          From: Tim Ansell ... Neither should it have been with the current code. Looks like the broken Linux g++ is partying on the namespace (introducing a #include
          Message 4 of 17 , Sep 4, 2005
            From: Tim Ansell
            >nslu2_image.cc:347: error: ‘errno’ was not declared in this scope

            Neither should it have been with the current code. Looks like the broken
            Linux g++ is partying on the namespace (introducing a #include of <errno.h>
            somehow).

            Ok, I'll change it to use <cerrno> throughout, can you try #include
            <errno.h> in nslu2_image.cc? (That will fix it I believe, but the cerrno
            fix is safer - I mixed C and C++ headers a bit too much...).

            What's the compiler/environment, what where the configure options?

            John Bowler <jbowler@...>
          • Attila Csipa
            ... BTW this errno namespace problem is also present with the 3.4.x series, I have encountered this in several projects unrelated to upslug.
            Message 5 of 17 , Sep 4, 2005
              On Sunday 04 September 2005 19:15, John Bowler wrote:
              > >nslu2_image.cc:347: error: ‘errno’ was not declared in this scope
              > Neither should it have been with the current code. Looks like the broken
              > Linux g++ is partying on the namespace (introducing a #include of <errno.h>
              > somehow).
              > What's the compiler/environment, what where the configure options?

              BTW this errno namespace problem is also present with the 3.4.x series, I have
              encountered this in several projects unrelated to upslug.
            • John Bowler
              From: Attila Csipa ... have ... It s not actually a compiler problem, rather it is a problem with the libc implementation. Somehow glibc (2.3.5) on gentoo
              Message 6 of 17 , Sep 4, 2005
                From: Attila Csipa
                >BTW this errno namespace problem is also present with the 3.4.x series, I
                have
                >encountered this in several projects unrelated to upslug.

                It's not actually a compiler problem, rather it is a problem with the libc
                implementation. Somehow glibc (2.3.5) on gentoo (the build environment I
                used) manages to include a definition of errno even though I didn't include
                errno.h, so it hid the bug in nslu2_image.cc

                The problems arise when using something different - e.g. maybe uclibc or,
                presumably, a later version of glibc with the bug fixed.

                John Bowler <jbowler@...>
              • Marcel Nijenhof
                ... I have made an upslug2.mk for optware and made a ipk . I have installed that ipkg on a slug and upgraded a second slug. It worked. ... I didn t use this
                Message 7 of 17 , Sep 4, 2005
                  On Fri, 2005-09-02 at 19:23 -0700, John Bowler wrote:
                  > I have just checked in a new (completely rewritten) implementation of
                  > upslug
                  > called 'upslug2'
                  >

                  I have made an upslug2.mk for optware and made a "ipk". I have
                  installed that "ipkg" on a slug and upgraded a second slug.

                  It worked.

                  > This implementation should be considerably more portable than upslug -
                  > indeed there is a configuration option (--with-libpcap) which causes
                  > it to use libpcap on Linux (not tested on anything else yet).

                  I didn't use this option so it's still using the "packet" code.

                  PS:
                  I didn't submit the upslug2.mk yet.

                  Marceln
                • John Bowler
                  From: Marcel Nijenhof ... That s better on Linux, indeed to get the libpcap stuff to work on Linux I had to do some of the Linux specific stuff done in the
                  Message 8 of 17 , Sep 4, 2005
                    From: Marcel Nijenhof
                    >> This implementation should be considerably more portable than upslug -
                    >> indeed there is a configuration option (--with-libpcap) which causes
                    >> it to use libpcap on Linux (not tested on anything else yet).
                    >
                    >I didn't use this option so it's still using the "packet" code.

                    That's better on Linux, indeed to get the libpcap stuff to work on Linux I
                    had to do some of the Linux specific stuff done in the 'native' Linux code.
                    (In essence libpcap timeouts don't work on Linux).

                    I've made various header file fixes and checked in version upslug2_3 - this
                    won't be visible on the sourceforge anonymous pserver until tomorrow (it
                    only updates once per day).

                    I've also checked in the relevant OE bitbake files (upslug2_3.bb and
                    upslug2-native_3.bb). The somewhat weird NSLU2 version does, at least,
                    verify that the code now compiles with glibc >2.3.5

                    John Bowler <jbowler@...>
                  • Attila Csipa
                    ... Then I m puzzled even more - on my Debian system with both gcc-3.3 and gcc-3.4, with the same glibc (2.3.5) gcc 3.3.5 manages to compile without errors and
                    Message 9 of 17 , Sep 4, 2005
                      On Sunday 04 September 2005 19:45, John Bowler wrote:
                      > It's not actually a compiler problem, rather it is a problem with the libc
                      > implementation. Somehow glibc (2.3.5) on gentoo (the build environment I
                      > used) manages to include a definition of errno even though I didn't include
                      > errno.h, so it hid the bug in nslu2_image.cc

                      Then I'm puzzled even more - on my Debian system with both gcc-3.3 and
                      gcc-3.4, with the same glibc (2.3.5) gcc 3.3.5 manages to compile without
                      errors and 3.4.3 has the errno problems ?
                    • John Bowler
                      From: Attila Csipa ... Ok, then it is in the C++ headers themselves which are associated with the compiler version, not the glibc version (i.e. my assertion
                      Message 10 of 17 , Sep 4, 2005
                        From: Attila Csipa
                        >Then I'm puzzled even more - on my Debian system with both gcc-3.3 and
                        >gcc-3.4, with the same glibc (2.3.5) gcc 3.3.5 manages to compile without
                        >errors and 3.4.3 has the errno problems ?

                        Ok, then it is in the C++ headers themselves which are associated with the
                        compiler version, not the glibc version (i.e. my assertion was incorrect -
                        it is the g++ compiler version which matters):

                        Before I fixed it (it is fixed in upslug2_3) nslu2_image.cc included the
                        following headers:

                        stdexcept
                        cstring
                        fstream
                        nslu2_image.h -->
                        stdexcep
                        nslu2_protocol.h -->
                        cstring

                        (So only stdexcept, cstring and fstream). By my reading of the ANSI C
                        standard (but I haven't, I admit, read the C++ standards) "errno" should not
                        be defined, therefore nslu2_image.cc should fail to compile. The fact that
                        it doesn't indicates that one of those three headers is erroneously pulling
                        in errno.h (or cerrno).

                        After some experiment it appears that fstream is at fault, so presumably
                        later versions of g++ have fixed this. (It's a somewhat serious bug - ANSI
                        C permits errno to be a macro, so defining it without the programmer's
                        consent is bad news.)

                        John Bowler <jbowler@...>
                      • Dave Coutts
                        Hi All I have just done a csv pull of upslug2 and tried to build it. I get the errors seen below when I autoreconf. Im using Debian 3.1 on a K7 PC. Anybody
                        Message 11 of 17 , Sep 5, 2005
                          Hi All

                          I have just done a csv pull of upslug2 and tried to build it.
                          I get the errors seen below when I autoreconf.
                          Im using Debian 3.1 on a K7 PC.

                          Anybody else having the same problem?

                          Dave :-)

                          ~/upslug2$ autoreconf -iv
                          autoreconf: Entering directory `.'
                          autoreconf: configure.ac: not using Gettext
                          autoreconf: running: aclocal --output=aclocal.m4t
                          autoreconf: `aclocal.m4' is created
                          autoreconf: configure.ac: tracing
                          autoreconf: configure.ac: not using Libtool
                          autoreconf: running: /usr/bin/autoconf
                          autoreconf: running: /usr/bin/autoheader
                          autoreconf: running: automake --add-missing --copy
                          configure.ac: 8: `automake requires `AM_CONFIG_HEADER', not
                          `AC_CONFIG_HEADER'
                          automake: configure.ac: installing `./install-sh'
                          automake: configure.ac: installing `./mkinstalldirs'
                          automake: configure.ac: installing `./missing'
                          automake: configure.ac: installing `./config.guess'
                          automake: configure.ac: installing `./config.sub'
                          automake: Makefile.am: installing `./INSTALL'
                          configure.ac: 8: required file `./[config.h].in' not found
                          autoreconf: automake failed with exit status: 1

                          --- In nslu2-linux@yahoogroups.com, Tim Ansell <yahoo@m...> wrote:
                          > This appears to be a g++-4.0 bug. I was able to compile with g++-3.3
                          >
                          > Tim
                          >
                          > On Sun, 2005-09-04 at 18:48 +0200, Tim Ansell wrote:
                          > > I can't compile upslug2. It dies with the following errors,
                          > >
                          > > root@ultralight:/home/tim/oss/upslug2/upslug2# make
                          > > g++ -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c linux_wire.cc
                          > > g++ -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c pcap_wire.cc
                          > > g++ -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c nslu2_image.cc
                          > > nslu2_image.cc: In function `void NSLU2Ima
                          ge::SafeRead(std::ifstream*,
                          > > char*, size_t, const char*)':
                          > > nslu2_image.cc:19: error: `errno' was not declared in
                          this scope
                          > > nslu2_image.cc:25: error: `errno' was not declared in
                          this scope
                          > > nslu2_image.cc: In function `void NSLU2Ima
                          ge::SafeSeek(std::ifstream*,
                          > > int, const char*)':
                          > > nslu2_image.cc:32: error: `errno' was not declared in
                          this scope
                          > > nslu2_image.cc: In constructor `NSLU2Image
                          ::RealImage::RealImage(bool,
                          > > const char*)':
                          > > nslu2_image.cc:40: error: `errno' was not declared in
                          this scope
                          > > nslu2_image.cc: In member function `int
                          > > NSLU2Image::SynthesiseImage::SizeOf(std::ifstream&)':
                          > > nslu2_image.cc:113: error: `errno' was not declared in
                          this scope
                          > > nslu2_image.cc: In constructor
                          > > `NSLU2Image::SynthesiseImage::SynthesiseImage(const char*,
                          bool, const
                          > > char*, const char*, const char*, short unsigned int, short
                          unsigned int,
                          > > short unsigned int, short unsigned int)':
                          > > nslu2_image.cc:249: error: `errno' was not declared in
                          this scope
                          > > nslu2_image.cc:278: error: `errno' was not declared in
                          this scope
                          > > nslu2_image.cc:305: error: `errno' was not declared in
                          this scope
                          > > nslu2_image.cc:347: error: `errno' was not declared in
                          this scope
                          > >
                          > > I'm sure these are most probably easily fixed errors.
                          > >
                          > > Mithro
                          > >
                          > >
                          > >
                          > > On Fri, 2005-09-02 at 19:23 -0700, John Bowler wrote:
                          > > > I have just checked in a new (completely rewritten)
                          implementation of upslug
                          > > > called 'upslug2'
                          > > >
                          > > > This implementation should be considerably more portable than
                          upslug -
                          > > > indeed there is a configuration option (--with-libpcap) which
                          causes it to
                          > > > use libpcap on Linux (not tested on anything else yet).
                          > > >
                          > > > I had a number of reasons for doing this:
                          > > >
                          > > > 1) Although this code is command-line it is modularised in such
                          a way as to
                          > > > make a GUI trivial (in so far as a GUI is ever trivial).
                          > > > 2) The OS specific 'talk to the wire' code is separated out
                          into two
                          > > > modules - one for Linux (using packet(7)) and one for everything
                          else (using
                          > > > libpcap). Thanks to Wim Lewis for showing me how to do this.
                          This code,
                          > > > once any bugs are removed, should work fine on a Mac.
                          > > > 3) upslug2 can flash given just the kernel and the rootfs (jffs2
                          partition).
                          > > > There is no need for that chunk of RedBoot code which had to be
                          extracted
                          > > > (before) from a LinkSys flash image. As a consequence if you
                          use it that
                          > > > way it is a *lot* faster - it doesn't write the bits which have
                          no
                          > > > corresponding data.
                          > > > 4) upslug2 is MIT copyright, not GPL, so if you need to do
                          something
                          > > > proprietary based on it you are free to do so without extra
                          conditions.
                          > > > 5) The progress bar is better, IMO.
                          > > > 6) The verify actually happens (at the same time I fixed upslug
                          so that it
                          > > > is now verifying the flash - it hasn't been for a while, if it
                          ever did.)
                          > > > 7) upslug was a big security hole, such that making upslug
                          'setuid' was an
                          > > > extremely bad idea on a public network. upslug2 doesn't have
                          that hole - it
                          > > > only uses setuid root privelege to open the socket so it is not
                          possible to
                          > > > use it to read other peoples files. (Specifically I believe it
                          is safer to
                          > > > make upslug2 setuid - 4755 - than to use it with sudo).
                          > > >
                          > > > At present the code is only in the NSLU sourceforge CVS project
                          - module
                          > > > 'upslug2':
                          > > >
                          > > > http://sourceforge.net/cvs/?group_id=116564
                          > > >
                          > > > If you want to build it you have to run 'autoreconf -i' to
                          bootstrap the
                          > > > build:
                          > > >
                          > > > autoreconf -i
                          > > > ./configure
                          > > > make
                          > > >
                          > > > Or use ./configure --with-libpcap to get the libpcap version.
                          There are
                          > > > probably still some bugs. Use --help for a list of options.
                          > > >
                          > > > John Bowler <jbowler@a...>
                          > > >
                          > > >
                          > > >
                          > > >
                          > > >
                          > > > Yahoo! Groups Links
                          > > >
                          > > >
                          > > >
                          > > >
                          > > >
                          > > >
                          > >
                          > >
                          > >
                          > >
                          > >
                          > >
                          > >
                          > > Yahoo! Groups Links
                          > >
                          > >
                          > >
                          > >
                          > >
                          > >
                        • Jochen Rüter
                          Hi, I just wanted to reorganize my nslu harddisk, but I can t boot off the partition I would like to. Can the slug use only primary partitions as rootfs? Or
                          Message 12 of 17 , Sep 5, 2005
                            Hi,

                            I just wanted to reorganize my nslu harddisk, but I can't boot off the
                            partition I would like to.
                            Can the slug use only primary partitions as rootfs? Or partitions below
                            a certain sector?

                            I have a 250G harddisk, the last 2,5G I wanted to use as rootfs for the
                            slug. I did a
                            turnup disk -i /dev/sda7
                            the filesystems is correctly copied and linuxrc is created correctly,
                            but the slug still boots to flash.

                            Any hints?

                            Thanks,
                            Jochen
                          • John Bowler
                            From: Dave Coutts ... `AC_CONFIG_HEADER What version of the tools? (i.e. the autotools - particularly autorecong and automake.) John Bowler
                            Message 13 of 17 , Sep 5, 2005
                              From: Dave Coutts
                              >configure.ac: 8: `automake requires `AM_CONFIG_HEADER', not
                              `AC_CONFIG_HEADER'

                              What version of the tools? (i.e. the autotools - particularly autorecong
                              and automake.)

                              John Bowler <jbowler@...>
                            • Dave Coutts
                              Hi John I have, automake (GNU automake) 1.4-p6 autoreconf (GNU Autoconf) 2.59 automake 1.9 is installed but the automake link points to 1.4. automake -
                              Message 14 of 17 , Sep 5, 2005
                                Hi John

                                I have,

                                automake (GNU automake) 1.4-p6
                                autoreconf (GNU Autoconf) 2.59

                                automake 1.9 is installed but the automake link points to 1.4.
                                'automake -> /usr/bin/automake-1.4'.

                                If I change the automake link to 'automake -> /usr/bin/automake-1.9' I
                                get the following errors

                                autoreconf -iv
                                autoreconf: Entering directory `.'
                                autoreconf: configure.ac: not using Gettext
                                autoreconf: running: aclocal --output=aclocal.m4t
                                autoreconf: `aclocal.m4' is created
                                autoreconf: configure.ac: tracing
                                autoreconf: configure.ac: not using Libtool
                                autoreconf: running: /usr/bin/autoconf
                                autoreconf: running: /usr/bin/autoheader
                                autoreconf: running: automake --add-missing --copy
                                configure.ac:6: version mismatch. This is Automake 1.9.6,
                                configure.ac:6: but the definition used by this AM_INIT_AUTOMAKE
                                configure.ac:6: comes from Automake 1.4-p6. You should recreate
                                configure.ac:6: aclocal.m4 with aclocal and run automake again.
                                configure.ac: installing `./install-sh'
                                configure.ac: installing `./missing'
                                configure.ac:11: installing `./config.guess'
                                configure.ac:11: installing `./config.sub'
                                Makefile.am: installing `./INSTALL'
                                Makefile.am: installing `./depcomp'
                                /usr/share/automake-1.9/am/depend2.am: am__fastdepCXX does not appear
                                in AM_CONDITIONAL
                                /usr/share/automake-1.9/am/depend2.am: AMDEP does not appear in
                                AM_CONDITIONAL
                                autoreconf: automake failed with exit status: 63


                                Dave

                                --- In nslu2-linux@yahoogroups.com, John Bowler <jbowler@a...> wrote:
                                > From: Dave Coutts
                                > >configure.ac: 8: `automake requires `AM_CONFIG_HEADER', not
                                > `AC_CONFIG_HEADER'
                                >
                                > What version of the tools? (i.e. the autotools - particularly
                                autorecong
                                > and automake.)
                                >
                                > John Bowler <jbowler@a...>
                              • John Bowler
                                From: Dave Coutts ... I have autoreconf 2.59 with automake 1.95 If I change the AC_CONFIG_HEADER(config.h) line to AM_CONFIG_HEADER(config.h) it still works
                                Message 15 of 17 , Sep 5, 2005
                                  From: Dave Coutts
                                  >automake (GNU automake) 1.4-p6
                                  >autoreconf (GNU Autoconf) 2.59

                                  I have autoreconf 2.59 with automake 1.95

                                  If I change the AC_CONFIG_HEADER(config.h) line to
                                  AM_CONFIG_HEADER(config.h) it still works for me - does it work for you with
                                  automake-1.4?

                                  In the documentation for automake 1.7.8 (the latest available documentation)
                                  AM_CONFIG_HEADER is described as obsolete, but my guess is that using it in
                                  this case is harmless - anyone who knows otherwise please speak up!

                                  If the configure.ac change does not work (but I think it will) then you have
                                  the following choices:

                                  1) properly install your automake 1.9.6 (so that when autoreconf builds the
                                  aclocal it gets the right one). This may break other things on your Debian
                                  system.
                                  2) fix the configure.ac
                                  3) wait for someone to build a release tarball (i.e. the result of 'make
                                  dist' on a system where the configure.ac works) and release it. That might
                                  happen in a couple of weeks when more problems have been
                                  detected/eliminated.

                                  John Bowler <jbowler@...>
                                • Dave Coutts
                                  Hi John I stumbled on the solution. When I link both automake and aclocal to versions 1.9 the upslug2 build works. automake - /usr/bin/automake-1.9 aclocal
                                  Message 16 of 17 , Sep 5, 2005
                                    Hi John

                                    I stumbled on the solution.
                                    When I link both automake and aclocal to versions 1.9 the upslug2
                                    build works.

                                    automake -> /usr/bin/automake-1.9
                                    aclocal -> /usr/bin/aclocal-1.9

                                    I tried all the things you suggested using automake-1.4 but I had no
                                    joy. I guess that automake-1.9 and aclocal-1.9 are required to be able
                                    to build upslug2.

                                    As a test,I reinstalled automake 1.9 using debian APT and found that
                                    the links stay pointing to automake 1.4 as standard. I guess that
                                    other debian 3.1 users may encounter the same automake version problem.

                                    Thanks a lot for your help

                                    Dave
                                    --- In nslu2-linux@yahoogroups.com, John Bowler <jbowler@a...> wrote:
                                    > From: Dave Coutts
                                    > >automake (GNU automake) 1.4-p6
                                    > >autoreconf (GNU Autoconf) 2.59
                                    >
                                    > I have autoreconf 2.59 with automake 1.95
                                    >
                                    > If I change the AC_CONFIG_HEADER(config.h) line to
                                    > AM_CONFIG_HEADER(config.h) it still works for me - does it work for
                                    you with
                                    > automake-1.4?
                                    >
                                    > In the documentation for automake 1.7.8 (the latest available
                                    documentation)
                                    > AM_CONFIG_HEADER is described as obsolete, but my guess is that
                                    using it in
                                    > this case is harmless - anyone who knows otherwise please speak up!
                                    >
                                    > If the configure.ac change does not work (but I think it will) then
                                    you have
                                    > the following choices:
                                    >
                                    > 1) properly install your automake 1.9.6 (so that when autoreconf
                                    builds the
                                    > aclocal it gets the right one). This may break other things on your
                                    Debian
                                    > system.
                                    > 2) fix the configure.ac
                                    > 3) wait for someone to build a release tarball (i.e. the result of 'make
                                    > dist' on a system where the configure.ac works) and release it.
                                    That might
                                    > happen in a couple of weeks when more problems have been
                                    > detected/eliminated.
                                    >
                                    > John Bowler <jbowler@a...>
                                  • John Bowler
                                    From: Dave Coutts ... There certainly is a way to make a configure.ac which will work with automake 1.4, the upslug2 configure.ac is really simple. Can you run
                                    Message 17 of 17 , Sep 5, 2005
                                      From: Dave Coutts
                                      >I guess that automake-1.9 and aclocal-1.9 are required to be able
                                      >to build upslug2.

                                      There certainly is a way to make a configure.ac which will work with
                                      automake 1.4, the upslug2 configure.ac is really simple.

                                      Can you run autoscan on your automake-1.4 system and send me the
                                      configure.scan which it outputs? (If necessary rename the configure.ac
                                      first so that autoscan doesn't try to use it).

                                      John Bowler <jbowler@...>
                                    Your message has been successfully submitted and would be delivered to recipients shortly.