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

Re: [nslu2-linux] Upgrade to Lenny from Etch

Expand Messages
  • Martin Michlmayr
    ... Yep, including flash: cat /dev/mtdblock? mtd-backup ... The first apt-get update (before changing the repository) is useless, unless you want to do an
    Message 1 of 14 , Dec 6, 2008
    • 0 Attachment
      * Adrian Oldacres <adrianoldacres@...> [2008-12-06 09:48]:
      > Can anyone advise on the safest way to upgrade an nslu2 currently
      > running etch to lenny? Is it just a case of:
      > - backup

      Yep, including flash:
      cat /dev/mtdblock? > mtd-backup

      > - apt-get update
      > - change repositories
      > - apt-get update

      The first apt-get update (before changing the repository) is useless,
      unless you want to do an update+upgrade to make sure you run the
      latest software before upgrading to the new release.
      --
      Martin Michlmayr
      http://www.cyrius.com/
    • Adrian Oldacres
      ... Thanks for the pointers. As it turns out the dist-upgrade went through without a problem, but on reboot, eth0 was renamed to eth1, which sort of made
      Message 2 of 14 , Dec 9, 2008
      • 0 Attachment
        --- In nslu2-linux@yahoogroups.com, Martin Michlmayr <tbm@...> wrote:
        >
        > * Adrian Oldacres <adrianoldacres@...> [2008-12-06 09:48]:
        > > Can anyone advise on the safest way to upgrade an nslu2 currently
        > > running etch to lenny? Is it just a case of:
        > > - backup
        >
        > Yep, including flash:
        > cat /dev/mtdblock? > mtd-backup
        >
        > > - apt-get update
        > > - change repositories
        > > - apt-get update
        >
        > The first apt-get update (before changing the repository) is useless,
        > unless you want to do an update+upgrade to make sure you run the
        > latest software before upgrading to the new release.
        > --
        > Martin Michlmayr
        > http://www.cyrius.com/
        >
        Thanks for the pointers.

        As it turns out the dist-upgrade went through without a problem, but
        on reboot, eth0 was renamed to eth1, which sort of made things a bit
        difficult as there was no network config for eth1 present on the slug.

        I had to plug the hdd into my virtualbox debian instance to a)
        identify the problem and b) configure eth1 correctly.

        slug1 has been running fine since.

        Time to try the same with slug2 (after adding in a suitable eth1
        config of course).

        Thanks for the help.

        Adrian.
      • Gordon Farquharson
        ... This seems like a problem. Can you describe your hardware setup? Were you using a USB to Ethernet adapter with the NSLU2, or did you just have the NSLU2
        Message 3 of 14 , Dec 9, 2008
        • 0 Attachment
          On Tue, Dec 9, 2008 at 10:56, Adrian Oldacres <adrianoldacres@...> wrote:

          > As it turns out the dist-upgrade went through without a problem, but
          > on reboot, eth0 was renamed to eth1, which sort of made things a bit
          > difficult as there was no network config for eth1 present on the slug.

          This seems like a problem. Can you describe your hardware setup? Were
          you using a USB to Ethernet adapter with the NSLU2, or did you just
          have the NSLU2 built-in Ethernet adapter?

          Gordon

          --
          Gordon Farquharson
          GnuPG Key ID: 32D6D676
        • Adrian Oldacres
          ... It s a standard nslu2 using the built-in Ethernet and a single external hdd. The only mod is the de-underclocking resistor snip. I have a script-log of the
          Message 4 of 14 , Dec 9, 2008
          • 0 Attachment
            --- In nslu2-linux@yahoogroups.com, "Gordon Farquharson"
            <gordonfarquharson@...> wrote:
            >
            > On Tue, Dec 9, 2008 at 10:56, Adrian Oldacres <adrianoldacres@...>
            wrote:
            >
            > > As it turns out the dist-upgrade went through without a problem, but
            > > on reboot, eth0 was renamed to eth1, which sort of made things a bit
            > > difficult as there was no network config for eth1 present on the slug.
            >
            > This seems like a problem. Can you describe your hardware setup? Were
            > you using a USB to Ethernet adapter with the NSLU2, or did you just
            > have the NSLU2 built-in Ethernet adapter?
            >
            > Gordon
            >
            > --
            > Gordon Farquharson
            > GnuPG Key ID: 32D6D676
            >
            It's a standard nslu2 using the built-in Ethernet and a single
            external hdd. The only mod is the de-underclocking resistor snip.

            I have a script-log of the upgrade which I can tidy up and pass on if
            it would be of any use.

            Adrian
          • Adrian Oldacres
            ... slug. ... I can see what has happened, though not why - the upgrade added a new udev rule: # cat /etc/udev/rules.d/70-persistent-net.rules # This file was
            Message 5 of 14 , Dec 9, 2008
            • 0 Attachment
              --- In nslu2-linux@yahoogroups.com, "Adrian Oldacres"
              <adrianoldacres@...> wrote:
              >
              > --- In nslu2-linux@yahoogroups.com, "Gordon Farquharson"
              > <gordonfarquharson@> wrote:
              > >
              > > On Tue, Dec 9, 2008 at 10:56, Adrian Oldacres <adrianoldacres@>
              > wrote:
              > >
              > > > As it turns out the dist-upgrade went through without a problem, but
              > > > on reboot, eth0 was renamed to eth1, which sort of made things a bit
              > > > difficult as there was no network config for eth1 present on the
              slug.
              > >
              > > This seems like a problem. Can you describe your hardware setup? Were
              > > you using a USB to Ethernet adapter with the NSLU2, or did you just
              > > have the NSLU2 built-in Ethernet adapter?
              > >
              > > Gordon
              > >
              > > --
              > > Gordon Farquharson
              > > GnuPG Key ID: 32D6D676
              > >
              > It's a standard nslu2 using the built-in Ethernet and a single
              > external hdd. The only mod is the de-underclocking resistor snip.
              >
              > I have a script-log of the upgrade which I can tidy up and pass on if
              > it would be of any use.
              >
              > Adrian
              >

              I can see what has happened, though not why - the upgrade added a new
              udev rule:

              # cat /etc/udev/rules.d/70-persistent-net.rules
              # This file was automatically generated by the /lib/udev/write_net_rules
              # program, probably run by the persistent-net-generator.rules rules file.
              #
              # You can modify it, as long as you keep each rule on a single line.
              # MAC addresses must be written in lowercase.

              # Unknown net device (/class/net/eth0) (ixp4xx_mac)
              SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:13:10:d7:19:e4",
              NAME="eth0"

              # Unknown net device (/class/net/eth0) (ixp4xx_eth)
              SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
              ATTR{address}=="00:0f:66:7d:b4:0a", ATTR{type}=="1", KERNEL=="eth*",
              NAME="eth1"

              Adrian
            • Martin Michlmayr
              ... It s strange that the MAC addresses are different. Which one is correct? -- Martin Michlmayr http://www.cyrius.com/
              Message 6 of 14 , Dec 9, 2008
              • 0 Attachment
                * Adrian Oldacres <adrianoldacres@...> [2008-12-09 21:43]:
                > I can see what has happened, though not why - the upgrade added a new
                > udev rule:

                It's strange that the MAC addresses are different. Which one is
                correct?

                --
                Martin Michlmayr
                http://www.cyrius.com/
              • Gordon Farquharson
                ... The other difference between the rules is that they apply to different kernel modules. This makes sense, because etch used Christian s driver (ixp4xx_mac)
                Message 7 of 14 , Dec 10, 2008
                • 0 Attachment
                  On Tue, Dec 9, 2008 at 14:48, Martin Michlmayr <tbm@...> wrote:
                  > * Adrian Oldacres <adrianoldacres@...> [2008-12-09 21:43]:
                  >
                  >> I can see what has happened, though not why - the upgrade added a new
                  >> udev rule:
                  >
                  > It's strange that the MAC addresses are different. Which one is
                  > correct?

                  The other difference between the rules is that they apply to different
                  kernel modules. This makes sense, because etch used Christian's driver
                  (ixp4xx_mac) whereas lenny uses Krzysztof's driver (ixp4xx_eth).
                  However, this difference should not affect the MAC address. What is
                  odd though is that both MAC addresses belong to Linksys.

                  00:13:10:d7:19:e4
                  MAC Address
                  Prefix Vendor
                  001310 Cisco-Linksys, LLC

                  00:0f:66:7d:b4:0a
                  MAC Address
                  Prefix Vendor
                  000F66 Cisco-Linksys

                  Adrian, did you manually change your MAC address at some stage in your
                  etch system, or did you ever use one of Martin's prepared images to
                  install etch? Martin, does one of those MAC addresses belong to you?

                  Gordon

                  --
                  Gordon Farquharson
                  GnuPG Key ID: 32D6D676
                • Martin Michlmayr
                  ... It s not my MAC address. Although you raise a very good point about my prepared tar ball: it contains my MAC address, so I wonder how it works for other
                  Message 8 of 14 , Dec 10, 2008
                  • 0 Attachment
                    * Gordon Farquharson <gordonfarquharson@...> [2008-12-10 06:59]:
                    > etch system, or did you ever use one of Martin's prepared images to
                    > install etch? Martin, does one of those MAC addresses belong to you?

                    It's not my MAC address. Although you raise a very good point about
                    my prepared tar ball: it contains my MAC address, so I wonder how it
                    works for other people... I need to investigate this, but this is a
                    separate issue.
                    --
                    Martin Michlmayr
                    http://www.cyrius.com/
                  • Adrian Oldacres
                    ... After a bit of poking around, I have found that the 00:13:10:d7:19:e4 mac address belongs to my slug#2 (as reported by ifconfig on that box). There is no
                    Message 9 of 14 , Dec 10, 2008
                    • 0 Attachment
                      --- In nslu2-linux@yahoogroups.com, "Gordon Farquharson"
                      <gordonfarquharson@...> wrote:
                      >
                      > On Tue, Dec 9, 2008 at 14:48, Martin Michlmayr <tbm@...> wrote:
                      > > * Adrian Oldacres <adrianoldacres@...> [2008-12-09 21:43]:
                      > >
                      > >> I can see what has happened, though not why - the upgrade added a new
                      > >> udev rule:
                      > >
                      > > It's strange that the MAC addresses are different. Which one is
                      > > correct?
                      >
                      > The other difference between the rules is that they apply to different
                      > kernel modules. This makes sense, because etch used Christian's driver
                      > (ixp4xx_mac) whereas lenny uses Krzysztof's driver (ixp4xx_eth).
                      > However, this difference should not affect the MAC address. What is
                      > odd though is that both MAC addresses belong to Linksys.
                      >
                      > 00:13:10:d7:19:e4
                      > MAC Address
                      > Prefix Vendor
                      > 001310 Cisco-Linksys, LLC
                      >
                      > 00:0f:66:7d:b4:0a
                      > MAC Address
                      > Prefix Vendor
                      > 000F66 Cisco-Linksys
                      >
                      > Adrian, did you manually change your MAC address at some stage in your
                      > etch system, or did you ever use one of Martin's prepared images to
                      > install etch? Martin, does one of those MAC addresses belong to you?
                      >
                      > Gordon
                      >
                      > --
                      > Gordon Farquharson
                      > GnuPG Key ID: 32D6D676
                      >
                      After a bit of poking around, I have found that the 00:13:10:d7:19:e4
                      mac address belongs to my slug#2 (as reported by ifconfig on that
                      box). There is no human-readable copy of the mac address on the
                      outside of either slug#1 or slug#2 unfortunately.

                      At some point in the past, the hdd on slug#1 _may_ have been used as
                      the source for a disk-disk copy from slug#2 following a hdd failure on
                      slug#1 - my memory is not what it used to be, sad to say.

                      I have commented the lines in the udev rule and reset the ip config
                      for eth0 in /etc/networks/interfaces back to how it was. After a
                      reboot, all now seems well with eth0, and no renames at startup.

                      Regards,

                      Adrian
                    • Gordon Farquharson
                      ... Thanks for the update. It looks like this problem wasn t caused by the installer, which is good news for Martin and me :-) Gordon -- Gordon Farquharson
                      Message 10 of 14 , Dec 10, 2008
                      • 0 Attachment
                        On Wed, Dec 10, 2008 at 14:29, Adrian Oldacres <adrianoldacres@...> wrote:

                        > After a bit of poking around, I have found that the 00:13:10:d7:19:e4
                        > mac address belongs to my slug#2 (as reported by ifconfig on that
                        > box). There is no human-readable copy of the mac address on the
                        > outside of either slug#1 or slug#2 unfortunately.
                        >
                        > At some point in the past, the hdd on slug#1 _may_ have been used as
                        > the source for a disk-disk copy from slug#2 following a hdd failure on
                        > slug#1 - my memory is not what it used to be, sad to say.

                        Thanks for the update. It looks like this problem wasn't caused by the
                        installer, which is good news for Martin and me :-)

                        Gordon

                        --
                        Gordon Farquharson
                        GnuPG Key ID: 32D6D676
                      • Ian Barton
                        ... Just to let you know that after reading this thread I upgraded my Slug from Etch to Lenny with only one minor problem. When I tried to run: script aptitude
                        Message 11 of 14 , Dec 13, 2008
                        • 0 Attachment
                          > Thanks for the update. It looks like this problem wasn't caused by the
                          > installer, which is good news for Martin and me :-)
                          >

                          Just to let you know that after reading this thread I upgraded my Slug
                          from Etch to Lenny with only one minor problem. When I tried to run:

                          script aptitude full-upgrade

                          it exited immediately without appearing to do anything. However running
                          aptitude full-upgrade on its own worked.

                          Ian.
                        • sdhippisleycox
                          Just to report that I have just had the same problem -- udev reassigning eth0 to eth1 on upgrade to lenny. Glad to find this post. Commented out the udev
                          Message 12 of 14 , Nov 22, 2009
                          • 0 Attachment
                            Just to report that I have just had the same problem -- udev reassigning eth0 to eth1 on upgrade to lenny.

                            Glad to find this post.

                            Commented out the udev rules, as suggested above, and on boot up it recreated a new one to use eth0. Everything fine from then onwards.

                            From /var/log/syslog:
                            Nov 22 23:06:30 debianslug kernel: [42949423.890000] eth0: MII PHY 1 on NPE-B
                            Nov 22 23:06:30 debianslug kernel: [42949424.160000] udev: renamed network interface eth0 to eth1

                            From 70-persistent-net.rules, after commenting out and rebooting:

                            # This file was automatically generated by the /lib/udev/write_net_rules
                            # program, probably run by the persistent-net-generator.rules rules file.
                            #
                            # You can modify it, as long as you keep each rule on a single line.
                            # MAC addresses must be written in lowercase.

                            # Unknown net device (/class/net/eth0) (ixp4xx_mac)
                            #SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:13:10:d6:1e:a7", NAME="eth0"

                            # Unknown net device (/class/net/eth0) (ixp4xx_eth)
                            #SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0f:66:7c:dd:11", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

                            # Unknown net device (/class/net/eth0) (ixp4xx_eth)
                            SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0f:66:7c:dd:11", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"


                            So, in summary, it looks like something from ipx4xx_mac is left behind. I think that I have used this USB disk on both this and a spare (backup) NSLU2 with etch installed. Unsure of exact history -- lovely thing about these things is that you set them up and then they just work...
                            The only problem I've ever had was with a power supply failure. Replacement from Maplins was fine.

                            Off topic - did the hardware mod. with an Atmel chip to auto power on after a power cut (I live in a village where we get one a week). V. straightforward, and well worth it.

                            --- In nslu2-linux@yahoogroups.com, "Gordon Farquharson" <gordonfarquharson@...> wrote:
                            >
                            > On Wed, Dec 10, 2008 at 14:29, Adrian Oldacres <adrianoldacres@...> wrote:
                            >
                            > > After a bit of poking around, I have found that the 00:13:10:d7:19:e4
                            > > mac address belongs to my slug#2 (as reported by ifconfig on that
                            > > box). There is no human-readable copy of the mac address on the
                            > > outside of either slug#1 or slug#2 unfortunately.
                            > >
                            > > At some point in the past, the hdd on slug#1 _may_ have been used as
                            > > the source for a disk-disk copy from slug#2 following a hdd failure on
                            > > slug#1 - my memory is not what it used to be, sad to say.
                            >
                            > Thanks for the update. It looks like this problem wasn't caused by the
                            > installer, which is good news for Martin and me :-)
                            >
                            > Gordon
                            >
                            > --
                            > Gordon Farquharson
                            > GnuPG Key ID: 32D6D676
                            >
                          Your message has been successfully submitted and would be delivered to recipients shortly.