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

Re: [nslu2-general] Problem after trying dd to clone new drive - wont boot on old disk

Expand Messages
  • Mike Westerhof
    ... Don t use dd to copy filesystems - it only works in very specific situations. You are far better off to format the target partition, then copy the
    Message 1 of 8 , Dec 1, 2009
    • 0 Attachment
      montyny1 wrote:
      > Hi,
      > So, I wanted to upgrade from my 750GB Hitachi to a 1TB Fantom. I plugged the Fantom in to the 2nd USB port and started dd. After 15hours I controlled C the dd, shutdown the slug and powered it off. I took the drives to a laptop and planned to copy them from there, but the Fantom would not be recognized - seems like others have this problem.
      >
      Don't use dd to copy filesystems - it only works in very specific
      situations. You are far better off to format the target partition, then
      copy the contents from one to another using a tool like rsync. (Do this
      on a desktop; the small memory on the NSLU2 makes that a painful thing.)
      > Ok, I thought, plug the 750GB back in to the slug and go with that - no big deal. However, the slug beeps, flashes the lights then does nothing. I left it for many hours and the ethernet flashes green, the top led flashes yellow (with a tint of red). I disconnected the power - reconnected the drive to a laptop running linux and ran ext3fs - which completed OK.
      >
      > Reconnected the drive and powered on the slug - again after 12 hours or so, still the same flashing LED. I think the slug is running slugos.
      >
      > Any thoughts on what I can do get the slug working again?

      Unplug everything from the USB ports, then boot up the NSLU2 -- if it is
      running SlugOS, it will boot up and you'll be able to login to the
      device. Now you can plug in the external disk -- check the messages
      (dmesg) and see if it detects it and mounts it. Fix whatever is wrong
      until it mounts.

      -Mike (mwester)
    • montyny1
      Thanks for the tip. Without drives connected the slug boots as you said it would, and I can ssh to it. At this time I m copying the old disk to the new disk
      Message 2 of 8 , Dec 2, 2009
      • 0 Attachment
        Thanks for the tip. Without drives connected the slug boots as you said it would, and I can ssh to it. At this time I'm copying the old disk to the new disk using my laptop running clonezilla.

        We'll see what happens when I reconnect the USB drives.

        Bryan.

        --- In nslu2-general@yahoogroups.com, Mike Westerhof <mwester@...> wrote:
        >
        > montyny1 wrote:
        > > Hi,
        > > So, I wanted to upgrade from my 750GB Hitachi to a 1TB Fantom. I plugged the Fantom in to the 2nd USB port and started dd. After 15hours I controlled C the dd, shutdown the slug and powered it off. I took the drives to a laptop and planned to copy them from there, but the Fantom would not be recognized - seems like others have this problem.
        > >
        > Don't use dd to copy filesystems - it only works in very specific
        > situations. You are far better off to format the target partition, then
        > copy the contents from one to another using a tool like rsync. (Do this
        > on a desktop; the small memory on the NSLU2 makes that a painful thing.)
        > > Ok, I thought, plug the 750GB back in to the slug and go with that - no big deal. However, the slug beeps, flashes the lights then does nothing. I left it for many hours and the ethernet flashes green, the top led flashes yellow (with a tint of red). I disconnected the power - reconnected the drive to a laptop running linux and ran ext3fs - which completed OK.
        > >
        > > Reconnected the drive and powered on the slug - again after 12 hours or so, still the same flashing LED. I think the slug is running slugos.
        > >
        > > Any thoughts on what I can do get the slug working again?
        >
        > Unplug everything from the USB ports, then boot up the NSLU2 -- if it is
        > running SlugOS, it will boot up and you'll be able to login to the
        > device. Now you can plug in the external disk -- check the messages
        > (dmesg) and see if it detects it and mounts it. Fix whatever is wrong
        > until it mounts.
        >
        > -Mike (mwester)
        >
      • John Grange
        Hi, I ve got an FSG3 that I ve upgraded to debian (etch first using http://wpkg.org/Running_Debian_on_Freecom_FSG-3, then Lenny using
        Message 3 of 8 , Dec 2, 2009
        • 0 Attachment
          Hi,

          I've got an FSG3 that I've upgraded to debian (etch first using
          http://wpkg.org/Running_Debian_on_Freecom_FSG-3, then Lenny using
          http://www.debian.org/releases/stable/arm/release-notes/ch-upgrading.en.html
          #newkernel). I seem, however, to still have the 2.6.20 kernel installed. I
          need the newer kernel for some of the new libertas wireless drivers. I've
          tried the instructions for upgrading the kernel (to
          linux-image-2.6.26-2-ixp4xx, installed as per the lenny notes above), but
          this upgrade says (strongly) to update your bootloader (which, of course, is
          redboot) to get it to use initramfs. I don't know how to do this and,
          though I've searched for information, I can't find out how to configure
          redboot.

          I did find some redboot-tools-0.7 from ubuntu, which look promising, but the
          scripts are full of offsets in the flash and, without knowing what I'm
          doing, really don't want to just run the scripts.

          Is there anybody out there who can help?

          Thanks in advance,

          John Grange
        • docbillnet
          ... That statement is completely absurd. dd always works when copying filesystems, provided you use the correct block sizes. System administrators have
          Message 4 of 8 , Dec 4, 2009
          • 0 Attachment
            > Don't use dd to copy filesystems - it only works in very specific
            > situations. You are far better off to format the target partition,

            That statement is completely absurd. "dd" always works when copying filesystems, provided you use the correct block sizes. System administrators have been doing this to backup filesystems for more than 30 years. I have personally been doing it for more than 15 years, and I have never had problems.

            That said, chances are the problem is not copying the filesystem, but the disk image. e.g.

            dd if=/dev/sda1 of=/dev/sdb1 bs=2048

            works ok. But

            dd if=/dev/sda of=/dev/sdb bs=2048

            will only work if both hard drives have the same physical partitioning.

            However, you can still recover the data by dd'ing back to the original drive if you erased it...

            That said, I do NOT advice using dd to copy filesystems unless they contain features not supported by higher level programs. Usually "rsync" is both faster and better. However, a common exception to this rule is when copying the root partition of a file system with SELinux enabled. "dd" will preserve all the SELinux settings, "rsync" even with the appropriate settings might not be able to.

            I also tend to use "dd" when backing up windows partitions. The reason being is I've yet to find a linux method of copying windows file systems that preserves windows ACL's and such. Meaning if I want C: drive to boot and start, I better copy it with dd.

            Bill
          • Mike Westerhof (mwester)
            ... Thanks for your polite response. Note that after that very strong statement you make, you then go on to (correctly) identify the very specific situations
            Message 5 of 8 , Dec 4, 2009
            • 0 Attachment
              docbillnet wrote:
              >> Don't use dd to copy filesystems - it only works in very specific
              >> situations. You are far better off to format the target partition,
              >>
              >
              > That statement is completely absurd.

              Thanks for your polite response. Note that after that very strong
              statement you make, you then go on to (correctly) identify the very
              specific situations where dd *does* actually work.

              Thanks for your commentary.

              -Mike (mwester)

              > "dd" always works when copying filesystems, provided you use the correct block sizes. System administrators have been doing this to backup filesystems for more than 30 years. I have personally been doing it for more than 15 years, and I have never had problems.
              >
              > That said, chances are the problem is not copying the filesystem, but the disk image. e.g.
              >
              > dd if=/dev/sda1 of=/dev/sdb1 bs=2048
              >
              > works ok. But
              >
              > dd if=/dev/sda of=/dev/sdb bs=2048
              >
              > will only work if both hard drives have the same physical partitioning.
              >
              > However, you can still recover the data by dd'ing back to the original drive if you erased it...
              >
              > That said, I do NOT advice using dd to copy filesystems unless they contain features not supported by higher level programs. Usually "rsync" is both faster and better. However, a common exception to this rule is when copying the root partition of a file system with SELinux enabled. "dd" will preserve all the SELinux settings, "rsync" even with the appropriate settings might not be able to.
              >
              > I also tend to use "dd" when backing up windows partitions. The reason being is I've yet to find a linux method of copying windows file systems that preserves windows ACL's and such. Meaning if I want C: drive to boot and start, I better copy it with dd.
              >
              > Bill
              >
            • John Grange
              Hi, I ve got an FSG3 that I ve upgraded to debian (etch first using http://wpkg.org/Running_Debian_on_Freecom_FSG-3, then Lenny using
              Message 6 of 8 , Dec 4, 2009
              • 0 Attachment
                Hi,



                I've got an FSG3 that I've upgraded to debian (etch first using
                http://wpkg.org/Running_Debian_on_Freecom_FSG-3, then Lenny using
                http://www.debian.org/releases/stable/arm/release-notes/ch-upgrading.en.html
                #newkernel). I seem, however, to still have the 2.6.20 kernel installed. I
                need the newer kernel for some of the new libertas wireless drivers. I've
                tried the instructions for upgrading the kernel (to
                linux-image-2.6.26-2-ixp4xx, installed as per the lenny notes above), but
                this upgrade says (strongly) to update your bootloader (which, of course, is
                redboot) to get it to use initramfs. I don't know how to do this and,
                though I've searched for information, I can't find out how to configure
                redboot.



                I did find some redboot-tools-0.7 from ubuntu, which look promising, but the
                scripts are full of offsets in the flash and, without knowing what I'm
                doing, really don't want to just run the scripts.



                Is there anybody out there who can help?



                Thanks in advance,



                John Grange





                [Non-text portions of this message have been removed]
              • montyny1
                Thanks. I ended up installing one of the drives in to an older PC, connecting the other with USB ( I should really invest in eSATA) and used the Parted Magic
                Message 7 of 8 , Dec 9, 2009
                • 0 Attachment
                  Thanks. I ended up installing one of the drives in to an older PC, connecting the other with USB ( I should really invest in eSATA) and used the Parted Magic live CD to first use clonezilla, then gparted to resize the new disk.

                  After that, I reconnected the drive and the slug was quite happy. At this time everything seems to be working perfectly!

                  --- In nslu2-general@yahoogroups.com, "Mike Westerhof (mwester)" <mwester@...> wrote:
                  >
                  > docbillnet wrote:
                  > >> Don't use dd to copy filesystems - it only works in very specific
                  > >> situations. You are far better off to format the target partition,
                  > >>
                  > >
                  > > That statement is completely absurd.
                  >
                  > Thanks for your polite response. Note that after that very strong
                  > statement you make, you then go on to (correctly) identify the very
                  > specific situations where dd *does* actually work.
                  >
                  > Thanks for your commentary.
                  >
                  > -Mike (mwester)
                  >
                  > > "dd" always works when copying filesystems, provided you use the correct block sizes. System administrators have been doing this to backup filesystems for more than 30 years. I have personally been doing it for more than 15 years, and I have never had problems.
                  > >
                  > > That said, chances are the problem is not copying the filesystem, but the disk image. e.g.
                  > >
                  > > dd if=/dev/sda1 of=/dev/sdb1 bs=2048
                  > >
                  > > works ok. But
                  > >
                  > > dd if=/dev/sda of=/dev/sdb bs=2048
                  > >
                  > > will only work if both hard drives have the same physical partitioning.
                  > >
                  > > However, you can still recover the data by dd'ing back to the original drive if you erased it...
                  > >
                  > > That said, I do NOT advice using dd to copy filesystems unless they contain features not supported by higher level programs. Usually "rsync" is both faster and better. However, a common exception to this rule is when copying the root partition of a file system with SELinux enabled. "dd" will preserve all the SELinux settings, "rsync" even with the appropriate settings might not be able to.
                  > >
                  > > I also tend to use "dd" when backing up windows partitions. The reason being is I've yet to find a linux method of copying windows file systems that preserves windows ACL's and such. Meaning if I want C: drive to boot and start, I better copy it with dd.
                  > >
                  > > Bill
                  > >
                  >
                Your message has been successfully submitted and would be delivered to recipients shortly.