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

Re: OpenSlug 2.7 --> Debian

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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.