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

Re: Upgrade to Lenny from Etch

Expand Messages
  • Stefan Luetje
    ... Look here: Rgds Stefan -- Stefan Lütje Skelli@jabber.ccc.de
    Message 1 of 14 , Dec 6, 2008
    • 0 Attachment
      Am 06. Dec 2008 um 10:48 CET schrieb Adrian Oldacres:

      > Can anyone advise on the safest way to upgrade an nslu2 currently
      > running etch to lenny? Is it just a case of:
      > - backup
      > - apt-get update
      > - change repositories
      > - apt-get update
      > - apt-get dist-upgrade
      >
      > What could _possibly_ go wrong!
      >
      > I really don't want to re-install from scratch...

      Look here:
      <http://blog.schmehl.info/Debian/releasing-lenny>


      Rgds
      Stefan

      --
      Stefan Lütje <stefan.luetje@...> Skelli@...
      Key fingerprint = BCB2 48E4 9211 C975 5A3F B192 9B6E CCCF 99CC 44FA
      "Ich weiß, dass der Mensch und der Fisch in friedlicher Koexistenz
      leben können." George W. Bush
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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.