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

OpenSlug 2.7 --> Debian

Expand Messages
  • Eric Swenson
    I m trying to install Debian on my NSLU2, which is currently running the OpenSlug firmware. I ve followed the directions at:
    Message 1 of 8 , Feb 1, 2006
    • 0 Attachment
      I'm trying to install Debian on my NSLU2, which is currently running
      the OpenSlug firmware. I've followed the directions at:

      http://www.nslu2-linux.org/wiki/DebianSlug/OpenDebianSlug

      quite a few times already, with the same results. When I reboot the
      system with the hard disk attached, the amber light alternates
      between on and off, and the gree light never comes up. I believe
      this means that we never get through the runlevel switching to the
      target runlevel (3 or 5?).

      How do you debug this kind of a problem? Since we never get far
      enough to get sshd running, I have no way of getting in and looking
      at anything. Of course, I can do a post-mortem on the file system
      after pulling the plug on the nslu2, disconnecting the hard drive,
      rebooting from flash, connecting the hard drive, mounting it, and
      examing it or the flash file system.

      I'm quite sure I've followed the directions correctly and believe I
      have configured all the files (e.g. /etc/networks/interfaces)
      correctly.

      Thinking that it was the hwclock program (as alluded to in the above
      twiki page), I've renamed all the Sxx links in all the init.d/rc?.d
      directories to sXX so that they won't be executed. I've also
      verified that the time is correct -- well, actually, it is correct,
      but in the wrong timezone (UTC versus PDT).

      I've so far resisted hardware modifications and therefore don't have
      a serial port to use as a console.

      Does anyone have any suggestions?

      Thanks much. -- Eric
    • guyug01
      Hi, ... For my first opendebianslug install, I had a similar issue. I just missed to kill the anacron process, as added by Joakim in #15, for the umount to be
      Message 2 of 8 , Feb 2, 2006
      • 0 Attachment
        Hi,
        --- In nslu2-linux@yahoogroups.com, "Eric Swenson" <eric@...> wrote:
        > When I reboot the
        > system with the hard disk attached, the amber light alternates
        > between on and off, and the gree light never comes up.

        For my first opendebianslug install, I had a similar issue.
        I just missed to kill the anacron process, as added by Joakim in #15,
        for the umount to be successful.
        Did you?
        guy
      • John Bowler
        From: Eric Swenson ... In older kernels (more than a week or so old) that happens as a result of the leds command in /linuxrc not being followed by an leds
        Message 3 of 8 , Feb 2, 2006
        • 0 Attachment
          From: Eric Swenson
          >When I reboot the
          >system with the hard disk attached, the amber light alternates
          >between on and off, and the gree light never comes up.

          In older kernels (more than a week or so old) that happens as
          a result of the 'leds' command in /linuxrc not being followed by
          an leds command from the new operating system root. At one time
          OpenDebianSlug simply didn't have the leds command so this always
          happened.

          In new kernels it happens anyway, because the old LED code has
          been removed and replaced with new stuff. ODS will have to be
          updated to handle this. On the other hand the latest OE systems
          follow the LED sequence previously discussed on nslu2-developers
          and this is significantly more informative about boot problems.

          >I believe
          >this means that we never get through the runlevel switching to the
          >target runlevel (3 or 5?).

          Maybe, it depends on how this is implemented in ODS. The OpenSlug
          documentation is irrelevant - it only applies to OpenSlug and,
          anyway, is out-of-date now. You know if you have the new stuff
          because the 'amber' flash tends to have traces of red in it.

          >How do you debug this kind of a problem? Since we never get far
          >enough to get sshd running, I have no way of getting in and looking
          >at anything.

          Boot without the disk attached to get into OpenSlug, make sure that
          the ODS root doesn't have a /.recovery file. Add a '-s10' to the
          turnup to ensure that the disk has time to 'settle' during boot. If
          that doesn't work then you need to debug the problem...

          Add an output redirection and a set -x to the head of /linuxrc:

          exec 2>/boot.log >&2
          set -x

          boot with the disk, wait, pull the power, disconnect the disk, reboot
          to OpenSlug, examine boot.log. You might want to add a 'set -x' to
          the /boot scripts too.

          If the boot is actually getting to Debian then you have to debug the
          Debian bootstrap. You might be able to find errors in the Debian
          /var/log files, if not the process is much as OpenSlug - redirect the
          output to an appropriate place from the Debian startup scripts.

          If you can get netconsole running (in theory this is possible from
          OpenSlug if you hack it into /boot/network and call /boot/network from
          /boot/disk) things might be debugged more quickly.

          John Bowler <jbowler@...>
        • fransmeulenbroeks
          ... possible from ... /boot/network from ... Alternately netconsole can be loaded by adding it in /etc/modutils or by creating a startup script. I did the
          Message 4 of 8 , Feb 2, 2006
          • 0 Attachment
            --- In nslu2-linux@yahoogroups.com, John Bowler
            <jbowler@...> wrote:
            >
            > If you can get netconsole running (in theory this is
            possible from
            > OpenSlug if you hack it into /boot/network and call
            /boot/network from
            > /boot/disk) things might be debugged more quickly.

            Alternately netconsole can be loaded by adding it in
            /etc/modutils or by creating a startup script.

            I did the latter by having a file

            /etc/rcS.d/S41netconsole

            which contains

            modprobe netconsole netconsole=@/,@<receiver ip
            address>/
            exit 0

            I assume modifing /boot/network will cause netconsole
            to load as early as possible.
            No idea on the handling order of the other two
            solutions (S41netconsole and modutils)

            FM
          • bobcox1955
            ... Further on down that page it says: Copy the LED-program to Debian and make the LED device: cp /initrd/sbin/leds /sbin; mknod /dev/leds c 126 0; chmod 660
            Message 5 of 8 , Feb 2, 2006
            • 0 Attachment
              --- In nslu2-linux@yahoogroups.com, "Eric Swenson" <eric@...> wrote:
              >
              > I'm trying to install Debian on my NSLU2, which is currently running
              > the OpenSlug firmware. I've followed the directions at:
              >
              > http://www.nslu2-linux.org/wiki/DebianSlug/OpenDebianSlug
              >
              > quite a few times already, with the same results. When I reboot the
              > system with the hard disk attached, the amber light alternates
              > between on and off, and the gree light never comes up. I believe
              > this means that we never get through the runlevel switching to the
              > target runlevel (3 or 5?).

              Further on down that page it says:

              Copy the LED-program to Debian and make the LED device: cp
              /initrd/sbin/leds /sbin; mknod /dev/leds c 126 0; chmod 660 /dev/leds
              (this will later be supplemented by the use of LED settings in the
              startup scripts).
              Try experimenting by typing leds and see the power LED go from
              blinking yellow to steady green.

              To make the leds react to changes in runlevels, copy the init scripts
              and update the runlevel links:
              cp /initrd/etc/init.d/zleds /initrd/etc/init.d/leds_startup /etc/init.d/
              update-rc.d zleds defaults 99 05
              update-rc.d leds_startup defaults 01


              HTH - I missed this at first and perhaps you have as well.

              Bob
            • Eric Swenson
              ... Thanks very much, Bob. This was indeed my problem -- at least it was for all attempts but my first. The first time I tried to install debian and
              Message 6 of 8 , Feb 2, 2006
              • 0 Attachment
                --- In nslu2-linux@yahoogroups.com, "bobcox1955" <bobcox1955@...>
                wrote:
                >
                > HTH - I missed this at first and perhaps you have as well.
                >
                > Bob

                Thanks very much, Bob. This was indeed my problem -- at least it
                was for all attempts but my first. The first time I tried to
                install debian and rebooted, I had no ssh access (and the leds were
                blinking amber). The reason, it turned out, was that I had
                incorrectly specified the kernel module names in
                my /etc/networks/interfaces. I had:

                pre-up modprobe -f ipx425_eth
                pre-up modprobe -f ipx400

                rather than:

                pre-up modprobe -f ixp425_eth
                pre-up modprobe -f ixp400

                This caused my network to not come up, and thus, sshd not to work.

                When I redid the installation subsequently (several times), it turns
                out that I must have successfully come up to runlevel 3, but assumed
                the same failure as the first time -- stupidly, I didn't try ssh
                again but assumed things weren't working.

                Eventually, I ssh'ed in, realized that it probably had been working
                all along (except the first time) and updated all the led stuff.

                Everything works fine now. Thanks again for your help. -- Eric
              • Eric Swenson
                ... Thanks. My problem is now resolved -- I just didn t realize that the alternately blinking amber lights just meant that I hadn t updated the init scripts
                Message 7 of 8 , Feb 2, 2006
                • 0 Attachment
                  --- In nslu2-linux@yahoogroups.com, "guyug01" <guyug01@...> wrote:
                  >
                  > Hi,
                  > --- In nslu2-linux@yahoogroups.com, "Eric Swenson" <eric@> wrote:
                  > > When I reboot the
                  > > system with the hard disk attached, the amber light alternates
                  > > between on and off, and the gree light never comes up.
                  >
                  > For my first opendebianslug install, I had a similar issue.
                  > I just missed to kill the anacron process, as added by Joakim in #15,
                  > for the umount to be successful.
                  > Did you?
                  > guy
                  >

                  Thanks. My problem is now resolved -- I just didn't realize that the
                  alternately blinking amber lights just meant that I hadn't updated the
                  init scripts to deal with setting the leds to reflect the runlevels.

                  In retrospect, the twiki page does point this out.

                  -- Eric
                • Eric Swenson
                  ... the ... looking ... If ... reboot ... the ... the ... from ... Thanks for the debugging tips. While I managed to resolve my issue (it *was* the led
                  Message 8 of 8 , Feb 2, 2006
                  • 0 Attachment
                    --- In nslu2-linux@yahoogroups.com, John Bowler <jbowler@...> wrote:
                    >
                    > From: Eric Swenson
                    > >When I reboot the
                    > >system with the hard disk attached, the amber light alternates
                    > >between on and off, and the gree light never comes up.
                    >
                    > In older kernels (more than a week or so old) that happens as
                    > a result of the 'leds' command in /linuxrc not being followed by
                    > an leds command from the new operating system root. At one time
                    > OpenDebianSlug simply didn't have the leds command so this always
                    > happened.
                    >
                    > In new kernels it happens anyway, because the old LED code has
                    > been removed and replaced with new stuff. ODS will have to be
                    > updated to handle this. On the other hand the latest OE systems
                    > follow the LED sequence previously discussed on nslu2-developers
                    > and this is significantly more informative about boot problems.
                    >
                    > >I believe
                    > >this means that we never get through the runlevel switching to
                    the
                    > >target runlevel (3 or 5?).
                    >
                    > Maybe, it depends on how this is implemented in ODS. The OpenSlug
                    > documentation is irrelevant - it only applies to OpenSlug and,
                    > anyway, is out-of-date now. You know if you have the new stuff
                    > because the 'amber' flash tends to have traces of red in it.
                    >
                    > >How do you debug this kind of a problem? Since we never get far
                    > >enough to get sshd running, I have no way of getting in and
                    looking
                    > >at anything.
                    >
                    > Boot without the disk attached to get into OpenSlug, make sure that
                    > the ODS root doesn't have a /.recovery file. Add a '-s10' to the
                    > turnup to ensure that the disk has time to 'settle' during boot.
                    If
                    > that doesn't work then you need to debug the problem...
                    >
                    > Add an output redirection and a set -x to the head of /linuxrc:
                    >
                    > exec 2>/boot.log >&2
                    > set -x
                    >
                    > boot with the disk, wait, pull the power, disconnect the disk,
                    reboot
                    > to OpenSlug, examine boot.log. You might want to add a 'set -x' to
                    > the /boot scripts too.
                    >
                    > If the boot is actually getting to Debian then you have to debug
                    the
                    > Debian bootstrap. You might be able to find errors in the Debian
                    > /var/log files, if not the process is much as OpenSlug - redirect
                    the
                    > output to an appropriate place from the Debian startup scripts.
                    >
                    > If you can get netconsole running (in theory this is possible from
                    > OpenSlug if you hack it into /boot/network and call /boot/network
                    from
                    > /boot/disk) things might be debugged more quickly.
                    >
                    > John Bowler <jbowler@...>

                    Thanks for the debugging tips. While I managed to resolve my issue
                    (it *was* the led thing), I'm going to give your debug suggestions a
                    try so that I figure some of this out in the future. Thanks. --
                    Eric
                  Your message has been successfully submitted and would be delivered to recipients shortly.