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

HDD switching and Ranish restore

Expand Messages
  • stock_market_player
    Hello, I currently have 3 HHDs in my computer and the 2nd one is dying and will be replaced. All of them are SATA drives. Only the first drive is a boot drive,
    Message 1 of 6 , Aug 19 1:04 AM
    • 0 Attachment
      Hello,

      I currently have 3 HHDs in my computer and the 2nd one is dying and will be replaced. All of them are SATA drives. Only the first drive is a boot drive, the other 2 are storage/backups.
      They are 74GB, 500GB (dead one), 1024GB.

      I don't recall the details but I remember that there was one time that I went into Ranish menu and it messed the partitions of a new drive I added (maybe I didn't use Ranish to create the partitions, I don't remember).


      Anyway, I'm fearfull that:
      1) if I remove the 2nd harddrive and enter the RPM menu it will see that I only have 2 harddrives and will think that the 3rd harddrive is the 2nd one and will try to "fix" its partition table, corrupting it instead.
      (I was surprised to see that the device names changed in Linux when I unplugged my 2nd harddrive, even when I was using the same SATA connector... it seems it's the way SATA works)

      2) when I replace the 2nd harddrive with a new one, how exactly will RPM see it?
      Isn't there any risk of mixing drives/partition tables? Even if there are drives which are the same model (as the one replaced or the existing ones).

      How exactly is RPM information stored? Does each HDD only has information about itself? Or can a HDD have the information (stored in the RPM partition) about all the drives in the system?

      I was thinking on removing RPM from all HDDs except the first one (so that no automatic fixing happens in these drives). Does this only require removing the boot loader and deleting the RPM partition. Maybe I only need to remove the boot loader?


      What I want to ensure is that when I remove *or* replace the 2nd HDD and enter into RPM, it will not try to "fix" anything automatically.


      Thank you very much for your help.
    • Antoine Leca
      stock_market_player wrote on Wednesday, August 19, 2009 10:05 AM ... *UNLESS* you are using a strange setup of a customized version of Ranish boot manager to
      Message 2 of 6 , Aug 27 3:35 AM
      • 0 Attachment
        stock_market_player wrote on Wednesday, August 19, 2009 10:05 AM
        > Subject: [partman] HDD switching and Ranish restore
        >
        > I currently have 3 HHDs in my computer and the 2nd one is
        > dying and will be replaced. All of them are SATA drives. Only
        > the first drive is a boot drive, the other 2 are storage/backups.
        > They are 74GB, 500GB (dead one), 1024GB.
        >
        >
        > Anyway, I'm fearfull that:
        > 1) if I remove the 2nd harddrive and enter the RPM menu it
        > will see that I only have 2 harddrives and will think that
        > the 3rd harddrive is the 2nd one and will try to "fix" its
        > partition table, corrupting it instead.

        *UNLESS* you are using a strange setup of a customized version of Ranish
        boot manager to boot directly to the 2nd or 3rd disk _and_ hiding some
        other partitions meanwhile, it is very unlikely to have RPM writing
        partition tables of the _other_ drives "automagically."

        (Of course it is very easy to shot oneself in the foot and to edit the
        wrong table: partition editors are dangerous tools, this is a known
        fact.)


        > (I was surprised to see that the device names changed in
        > Linux when I unplugged my 2nd harddrive, even when I was
        > using the same SATA connector... it seems it's the way SATA works)

        No: that's the way Linux works: it renumbers the drives every time it
        boots, so when one is dead or put offline, its position is "skipped";
        BTW, BIOS (used by RPM, GRUB/LILO, NTLDR etc.) and Windows NT kernel do
        the same; I think I read some xxxBSD does not, but I am unsure.


        > 2) when I replace the 2nd harddrive with a new one, how
        > exactly will RPM see it?

        (Probably) as an unpartitionned one ("probably" because it is always
        possible that the drive were partitionned, either at the mfg plant or in
        another computer where it was used earlier.)

        If you attach it to the same SATA channel as the dead one, it should
        show up as "Hard disk 2."


        > Isn't there any risk of mixing drives/partition tables?

        There is always a risk; but not any risk specific to this task.

        > Even if there are drives which are the same model (as the one
        > replaced or the existing ones).

        Well, you aill have to adjust the size of the volumes to fit the size of
        the disk; usually, if the replaced drive is of the "same" size (here
        .5TB), you will adjust the cylinder of the end of last partition (the
        one in the 60,000 range); note it may appears twice if you are using
        extended partitions, one for the container (of type 0F) and one for the
        very last logical partition.


        > How exactly is RPM information stored?

        There are two places:
        - one is the standard place, the partition table which is stored as part
        of the first sector on disk (the MBR.) This place is common to any other
        tool and any operating system, it is the MBR standard way to partition a
        disk (there exist other standards like GPT, but RPM does not support
        them.)
        - the other is optional and specific to RPM 2.4x, it is the VTOC used to
        store the 32 volumes you can create on each disk; you should use RPM
        beta version 2.42/43/44, _and_ you should have created a type F0
        partition. The volumes stored there are not visible to any other tool or
        operating system, unless you also put an entry in the MBR (the digit 1
        to 4 in the 2nd column.)
        Again, this function is entirely optionnal, and it is very likely you
        are not using it (particularly on a 2nd drive...)


        > Does each HDD only has information about itself?

        Yes.

        > Or can a HDD have the information
        > (stored in the RPM partition) about all the drives in the system?

        Not usually.
        It was perhaps a function of earlier version (<2.38), but AFAIK it was
        not carried over (implemented) to the 2.4x line. I think the structure
        on disk could be able to store the information, but the boot manager
        code is not able to either put values or get them while booting.


        > I was thinking on removing RPM from all HDDs except the first
        > one (so that no automatic fixing happens in these drives).
        > Does this only require removing the boot loader and deleting
        > the RPM partition. Maybe I only need to remove the boot loader?

        First, removing the bootloader (the code part of the MBR) on any drive
        beside the first one in the system has NO effect, UNTIL a disk fails.
        Then, if you wiped the bootloader of a surviving disk, you are not able
        to boot...
        In other words: the bootloader on the 2nd disk is only there for
        disaster recovery reasons.

        Then, removing the F0 partition from the 2nd etc. drives have two
        possible effects:
        - if you are booting directly to a volume on the 2nd drive _and_ the
        volume is not present in the MBR, only in RPM's VTOC (which is stored
        inside this partition), removing this partition prevents such boot to
        occur: chances are high you are not using this feature.
        - if your 1st drive dies, and if you kept the RPM bootloader on the
        second disk, you'll get the possibility to enter RPM at boot. This
        might, or might not, be a good thing for you, it all depends opn your
        recovery plan.



        Antoine
      • Frank R.
        Hallo, ich bin seit Jahren in der Verteilerliste und möchte daraus gelöscht werden. Danke To: partman@yahoogroups.com From: aleca@arcesa.com Date: Thu, 27
        Message 3 of 6 , Aug 28 1:27 AM
        • 0 Attachment
          Hallo,
          ich bin seit Jahren in der Verteilerliste und möchte daraus gelöscht werden.

          Danke

          To: partman@yahoogroups.com
          From: aleca@...
          Date: Thu, 27 Aug 2009 12:35:15 +0200
          Subject: RE: [partman] HDD switching and Ranish restore























          stock_market_player wrote on Wednesday, August 19, 2009 10:05 AM

          > Subject: [partman] HDD switching and Ranish restore

          >

          > I currently have 3 HHDs in my computer and the 2nd one is

          > dying and will be replaced. All of them are SATA drives. Only

          > the first drive is a boot drive, the other 2 are storage/backups.

          > They are 74GB, 500GB (dead one), 1024GB.

          >

          >

          > Anyway, I'm fearfull that:

          > 1) if I remove the 2nd harddrive and enter the RPM menu it

          > will see that I only have 2 harddrives and will think that

          > the 3rd harddrive is the 2nd one and will try to "fix" its

          > partition table, corrupting it instead.



          *UNLESS* you are using a strange setup of a customized version of Ranish

          boot manager to boot directly to the 2nd or 3rd disk _and_ hiding some

          other partitions meanwhile, it is very unlikely to have RPM writing

          partition tables of the _other_ drives "automagically."



          (Of course it is very easy to shot oneself in the foot and to edit the

          wrong table: partition editors are dangerous tools, this is a known

          fact.)



          > (I was surprised to see that the device names changed in

          > Linux when I unplugged my 2nd harddrive, even when I was

          > using the same SATA connector... it seems it's the way SATA works)



          No: that's the way Linux works: it renumbers the drives every time it

          boots, so when one is dead or put offline, its position is "skipped";

          BTW, BIOS (used by RPM, GRUB/LILO, NTLDR etc.) and Windows NT kernel do

          the same; I think I read some xxxBSD does not, but I am unsure.



          > 2) when I replace the 2nd harddrive with a new one, how

          > exactly will RPM see it?



          (Probably) as an unpartitionned one ("probably" because it is always

          possible that the drive were partitionned, either at the mfg plant or in

          another computer where it was used earlier.)



          If you attach it to the same SATA channel as the dead one, it should

          show up as "Hard disk 2."



          > Isn't there any risk of mixing drives/partition tables?



          There is always a risk; but not any risk specific to this task.



          > Even if there are drives which are the same model (as the one

          > replaced or the existing ones).



          Well, you aill have to adjust the size of the volumes to fit the size of

          the disk; usually, if the replaced drive is of the "same" size (here

          .5TB), you will adjust the cylinder of the end of last partition (the

          one in the 60,000 range); note it may appears twice if you are using

          extended partitions, one for the container (of type 0F) and one for the

          very last logical partition.



          > How exactly is RPM information stored?



          There are two places:

          - one is the standard place, the partition table which is stored as part

          of the first sector on disk (the MBR.) This place is common to any other

          tool and any operating system, it is the MBR standard way to partition a

          disk (there exist other standards like GPT, but RPM does not support

          them.)

          - the other is optional and specific to RPM 2.4x, it is the VTOC used to

          store the 32 volumes you can create on each disk; you should use RPM

          beta version 2.42/43/44, _and_ you should have created a type F0

          partition. The volumes stored there are not visible to any other tool or

          operating system, unless you also put an entry in the MBR (the digit 1

          to 4 in the 2nd column.)

          Again, this function is entirely optionnal, and it is very likely you

          are not using it (particularly on a 2nd drive...)



          > Does each HDD only has information about itself?



          Yes.



          > Or can a HDD have the information

          > (stored in the RPM partition) about all the drives in the system?



          Not usually.

          It was perhaps a function of earlier version (<2.38), but AFAIK it was

          not carried over (implemented) to the 2.4x line. I think the structure

          on disk could be able to store the information, but the boot manager

          code is not able to either put values or get them while booting.



          > I was thinking on removing RPM from all HDDs except the first

          > one (so that no automatic fixing happens in these drives).

          > Does this only require removing the boot loader and deleting

          > the RPM partition. Maybe I only need to remove the boot loader?



          First, removing the bootloader (the code part of the MBR) on any drive

          beside the first one in the system has NO effect, UNTIL a disk fails.

          Then, if you wiped the bootloader of a surviving disk, you are not able

          to boot...

          In other words: the bootloader on the 2nd disk is only there for

          disaster recovery reasons.



          Then, removing the F0 partition from the 2nd etc. drives have two

          possible effects:

          - if you are booting directly to a volume on the 2nd drive _and_ the

          volume is not present in the MBR, only in RPM's VTOC (which is stored

          inside this partition), removing this partition prevents such boot to

          occur: chances are high you are not using this feature.

          - if your 1st drive dies, and if you kept the RPM bootloader on the

          second disk, you'll get the possibility to enter RPM at boot. This

          might, or might not, be a good thing for you, it all depends opn your

          recovery plan.



          Antoine




















          _________________________________________________________________
          http://redirect.gimas.net/?n=M0908axFotos2
          -> Für Fotos hier abdrücken <-

          [Non-text portions of this message have been removed]
        • britonusa
          ... Frank Zu kündigen, gefallen, zu mailen: partman-unsubscribe@yahoogroups.com Oder verwenden Sie die Verbindung am Ende dieser eMail. If that doesn t come
          Message 4 of 6 , Aug 29 7:52 AM
          • 0 Attachment
            --- In partman@yahoogroups.com, Frank R. <frank_rud@...> wrote:
            >
            >
            > Hallo,
            > ich bin seit Jahren in der Verteilerliste und möchte daraus gelöscht werden.
            >
            > Danke

            Frank

            Zu kündigen, gefallen, zu mailen: partman-unsubscribe@yahoogroups.com Oder verwenden Sie die Verbindung am Ende dieser eMail.

            If that doesn't come across clearly in translation, here is the English version ;)

            To unsubscribe, please, email to: partman-unsubscribe@yahoogroups.com

            Or use the link at the end of this email.

            briton
          • stock_market_player
            Thank you very much for your reply Antoine. So RPM only tries to automatically restore the partition table when he sees that the partitions in the MBR don t
            Message 5 of 6 , Sep 14, 2009
            • 0 Attachment
              Thank you very much for your reply Antoine.


              So RPM only tries to automatically restore the partition table when he sees that the partitions in the MBR don't match the information in the special RPM partion at the end of the disk, correct?

              So, in principle there shouldn't be any problem with removing one HDD. From RPM point of view, all the HDDs are coherent, in the sense that the information in the MBR matches with the info in the special RPM partition at the end of the disk.

              > *UNLESS* you are using a strange setup of a customized version of
              > Ranish boot manager to boot directly to the 2nd or 3rd disk
              > _and_ hiding some other partitions meanwhile, it is very unlikely
              > to have RPM writing partition tables of the _other_ drives
              > "automagically."

              I'm using either RPM 2.43 or 2.44 (I don't remember which one), which was downloaded from here a long time ago (3 years ago I think).

              What exactly is the meaning of "to boot directly to the ..."?
              I only boot to the first hard drive, but my other 2 drives have the boot flag enabled in order to silent RPM warning of them not having any boot partition set.

              Once again thank you.
            • Antoine Leca
              ... You are welcome. ... Yes, something along those lines. To be certain your understanding is correct, you can use the simulation tools: first using
              Message 6 of 6 , Sep 29, 2009
              • 0 Attachment
                stock_market_player wrote on September 15th:
                > Thank you very much for your reply Antoine.

                You are welcome.

                > So RPM only tries to automatically restore the partition
                > table when he sees that the partitions in the MBR don't match
                > the information in the special RPM partion at the end of the
                > disk, correct?

                Yes, something along those lines.
                To be certain your understanding is correct, you can use the simulation
                tools: first using part244sim.exe you create several partitions, some of
                them in the VTOC and lacking entries in the MBR (be sure to include a F0
                partition); then use part240sim.exe (which only edits the MBR and will
                not touch to the VTOC) to modfiy the MBR, to simulate the effect of a
                "foreign" tool; last, check what will show part244sim.exe when it mixes
                the entries in VTOC _and_ the "new" entries in the MBR: I expect red
                entries...


                > So, in principle there shouldn't be any problem with removing
                > one HDD. From RPM point of view, all the HDDs are coherent,
                > in the sense that the information in the MBR matches with the
                > info in the special RPM partition at the end of the disk.
                >
                > > *UNLESS* you are using a strange setup of a customized version of
                > > Ranish boot manager to boot directly to the 2nd or 3rd disk _and_
                > > hiding some other partitions meanwhile, it is very unlikely to have
                > > RPM writing partition tables of the _other_ drives "automagically."
                >
                > What exactly is the meaning of "to boot directly to the ..."?

                Long ago (2.37 ?), RPM allowed to boot directly to the 2nd+ harddisk,
                and also allowed to select an entry which would select up to 3
                partitions, "hiding" the others; I am not sure official version of RPM
                allowed the mix of the two options (i.e. booting the 2nd disk _and_
                hiding partitions on say the 1st disk), but it exists boot managers
                around which do have such possibility (plus RPM was open sourced.)

                I do not believe the 2.4x serie still have such options, but there are
                stigmates of them in the UI. And it is certainly possible to build them
                in a "customized version"...


                Antoine
              Your message has been successfully submitted and would be delivered to recipients shortly.