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

RE: [partman] Thinking of changing my partitionning scheme, plz help!

Expand Messages
  • Antoine Leca
    ... Went nice here (I should highlight it, since this is not always the case ... If I understand you correctly, you want the following scheme 0 MBR Master
    Message 1 of 4 , Dec 3, 2007
      > Hi ! This is Czerno. I would welcome advice from the
      > collective Brain ;=) Here's my actual partitionning scheme,
      > hand-formatted from Ranish 2.43(b) display
      > - Hopefully Yahoo! won't disturb my reformatting.

      Went nice here (I should highlight it, since this is not always the case
      :-) Hope it would be preserved.

      > ____________________________________________________________________
      > HD1 39,205 Mbytes [ 4,998 cyl x 255 hd x 63 sect ]
      > Using LBA
      >
      > 0 MBR Master Boot Record 0 0 1 / 0 0 1 / 0
      > 1 Pri Unused 0 0 2 / 0 0 63 / 31
      > 2 Pri 1 DOS FAT-16 0 1 1 / 2 254 63 / 24,066
      > 3 >Pri 2 Windows FAT-32 LBA 3 0 1 / 1,046 254 63 / 8,385,930
      >
      > 4 Pri 4 Extended LBA 1,047 0 1 / 1,866 254 63 / 6,586,650
      > 5 |-Log Linux swap 1,047 1 1 / 1,076 254 63 / 240,943
      > 6 |=Ext Extended LBA 1,077 0 1 / 1,866 254 63 / 6,345,675
      > 7 |-Log Linux ext2fs 1,077 1 1 / 1,866 254 63 / 6,345,643
      >
      > 8 Pri Unused 1,867 0 1 / 1,867 254 63 / 8,032
      > 9 Pri 3 Win FAT-32 LBA 1,868 0 1 / 2,887 254 63 / 8,193,150
      > 10 Pri Windows NT NTFS 2,888 0 1 / 4,997 245 63 / 16,948,291
      > 11 Pri Boot Manager 4,997 246 1 / 4,998 5 63 / 472
      > ____________________________________________________________________
      >
      > Now what if I could I "extend the extended" (#4), rebuilding a chain
      > that would include the FAT32 (#9) and subsequent partitionned
      > or to-be-repartitionned space #10 ?

      If I understand you correctly, you want the following scheme

      0 MBR Master Boot Record 0 0 1 / 0 0 1 / 0
      1 Pri Unused 0 0 2 / 0 0 63 / 31
      2 Pri 1 DOS FAT-16 0 1 1 / 2 254 63 / 24,066
      3 >Pri 2 Windows FAT-32 LBA 3 0 1 / 1,046 254 63 / 8,385,930

      4 Pri 4 Extended LBA 1,047 0 1 / 4,997 245 63 / xxxxxxxxxx
      5 |-Log Linux swap 1,047 1 1 / 1,076 254 63 / 240,943
      6 |=Ext Extended LBA 1,077 0 1 / 1,866 254 63 / 6,345,675
      7 |-Log Linux ext2fs 1,077 1 1 / 1,866 254 63 / 6,345,643

      8 |=Ext Extended LBA 1,867 0 1 / 1,867 254 63 / xxxxxxxxx
      9 |-Log Win FAT-32 LBA 1,868 0 1 / 2,887 254 63 / 8,193,150
      XX |=Ext Extended LBA 2,887 254 63 / 2,887 254 63 / xxxxxxxxx
      10 |-Log Windows NT NTFS 2,888 0 1 / 4,997 245 63 / 16,948,291
      11 Pri Boot Manager 4,997 246 1 / 4,998 5 63 / 472

      This can be done. I only see two mitigation points (related to
      partitionning), plus quite a number of "small changes" which you might
      want to expect beforehand...

      As you can see from the above scheme, you are required to have an
      additional "extended LBA" entry between 9 and 10 (XX above). This
      requires you to reduce the size of partition #9 by one sector. I have
      not done the maths (what you can see in the lower frame when the
      partition is selected), so I do not know if the 8GB FAT32 volume which
      is inside it have a spare sector at the end (this is usually the case),
      so you do not need to do anything there, or if it is full in which case
      you should make very sure there is no data in the last cluster of this
      volume (because it would be lost after you reduce it by one sector).
      The other problem is only important for MS-DOS 7.1, if you have another
      disk mounted in the case: due to a bug in FAT32 handling in MSDOS (not
      Windows9x), the last partition in the chain (here the NTFS one) when not
      recognized by DOS, will partially erase the discovery of the next disk,
      leading to obscure problems (even inside Windows 98). Since the symptoms
      are already here anyway, I guess this is not a real problem for you.

      There is some details I am not 100% sure, but it should be easy to try;
      see below.

      Changes you'll experiment:
      - the associated numbers under Linux will likely change (the logical
      volumes are numbered after the primary ones). It could even be a problem
      to boot Linux on the first place. If this occurs, make your entry of RPM
      (part #11) part of the MBR at #3, so Linux will see a supplementary
      entry before the logical, and you'll back on normal path (3 primaries,
      Linux as 2nd logical, swap as 1st logical).
      - it would be impossible to boot directly from BIOS into volume #9
      (until you hack the boot chain, but it comes to hard trickery; also see
      below)
      - while you could boot Windows 98 from the DOS partition (assuming it
      is DOS 7.1), it will see the #9 volume as disk D:; this may mean paths
      in Windows may become wrong (this could turns out as a stopover); I do
      not know (never actually tested) if running from inside VMWare will
      experiment the same or not
      - the only way to make volume #9 being C: is to hide the DOS partition,
      then I guess you will experiment difficulties to boot even under VMWare
      - booting directly in the NTFS partition (from NTLDR/BOOT.INI) requires
      first installing it on the DOS partition if it is not here already, then
      creating/editing the correct entry to boot NT
      - probably others...

      Changes which will not occur:
      - under DOS the Windows 98 volume will still be disk D:, no change
      (unless you install another disk, but see above first, this is a
      BadIdea)
      - under NT (200x, XP) the letters assigned will stay the same (they are
      assigned according to the signature and the starting sector of each
      volume, and you do not move any volume); if you do the optional
      save/restore of the NT signature above this is 100% certain; if you did
      not, I believe that while enumerating the volume the NT kernel will find
      the same volumes in the same order, so will assign the same letters (D:
      to Win98, E: to NTFS) so the end result will be the same IMHO


      How to do it (not tested!):
      - warmly recommanded, save to backup anything precious you have
      - make sure you have some hours of undisturbed time (if need arise)
      - print on paper the present scheme
      - make 100% sure you can make some wrong move, save it to disk, then
      recover from it (booting from floppy or whatever then retyping the data
      from the paper). TEST IT FOR REAL.
      - optionally, use some disk editing tool to record the NT signature in
      the MBR (at bytes 1b8-1bb)
      - boot DOS, enter PART
      - you have to enlarge the extended (#4) to go until cyl 4997
      - change type of #8 to extendedLBA (0F)
      - change the link of #9 from Pri to Log (press X)
      - reduce the size of #9 by one sector (go to the sector field and press
      -); this will create a supplementary entry (XX above) and renumbering; I
      shall keep number #10 here for my own sanity, but of course you will
      need to adjust...)
      - change the link of the NTFS (was #10) from Pri to Log (press X)
      - make sure the new entry (XX, now 10) is typed extended LBA and
      logical, if not change it that it shows this way
      - make the BootManager entry being the #3 in the MBR, just to keep Linux
      happy as described above
      - check all is correct and the only red indications are for the extended
      entries (which will be handled next)
      - press F2 to let RPM rebuild the intermediary parts (say thanks to
      Mikhail!)
      - return to DOS, print on paper (with raw datas)
      - optionally, use the disk editing tool to restore the NT signature in
      the MBR (at bytes 1b8-1bb), because RPM always wipe it to 0 while
      writing a MBR
      - check the values are correct
      - cross the fingers and reboot... at least under DOS it should be OK...

      One thing I am not 100% sure is whether your version of RPM will handle
      correctly the more-than-one-track (63 sectors) extendedLBA pseudo-part
      #8. In fact, I am fairly confident since I did things very much like
      that with various versions, only that it was smaller than one track. If
      it turns to be a problem, just create a dummy logical entry of 253
      sectors starting at 1867:1:1, it will create another extended link entry
      at 1867:254:1 for 63 sectors and you are back to a "standard" scheme.
      However I really think this is overkill, so do not try until necessary.


      Antoine
    • y31415926536
      Message from Czerno to : partman@yahoogroups.com ... Glad it worked out right. I had to give much attention to the formatting, esp; avoiding long lines. And a
      Message 2 of 4 , Dec 4, 2007
        Message from Czerno to : partman@yahoogroups.com

        "Antoine Leca" <aleca@...> wrote:

        >> - Hopefully Yahoo! won't disturb my reformatting.
        > Went nice here (I should highlight it, since this is not always the case

        Glad it worked out right. I had to give much attention to the
        formatting, esp; avoiding long lines.

        And a grand merci! for your amazingly detailed analysis of my
        specifics, sure you had to divert an appreciable part of your time to
        do it.

        > If I understand you correctly, you want the following scheme
        >
        > 0 MBR Master Boot Record 0 0 1 / 0 0 1 / 0
        > 1 Pri Unused 0 0 2 / 0 0 63 / 31
        > 2 Pri 1 DOS FAT-16 0 1 1 / 2 254 63 / 24,066
        > 3 >Pri 2 Windows FAT-32 LBA 3 0 1 / 1,046 254 63 / 8,385,930
        >
        > 4 Pri 4 Extended LBA 1,047 0 1 / 4,997 245 63 / xxxxxxxxxx
        > 5 |-Log Linux swap 1,047 1 1 / 1,076 254 63 / 240,943
        > 6 |=Ext Extended LBA 1,077 0 1 / 1,866 254 63 / 6,345,675
        > 7 |-Log Linux ext2fs 1,077 1 1 / 1,866 254 63 / 6,345,643
        >
        > 8 |=Ext Extended LBA 1,867 0 1 / 1,867 254 63 / xxxxxxxxx
        > 9 |-Log Win FAT-32 LBA 1,868 0 1 / 2,887 254 63 / 8,193,150
        > XX |=Ext Extended LBA 2,887 254 63 / 2,887 254 63 / xxxxxxxxx
        > 10 |-Log Windows NT NTFS 2,888 0 1 / 4,997 245 63 / 16,948,291
        > 11 Pri Boot Manager 4,997 246 1 / 4,998 5 63 / 472

        Right, this would be the idea.

        > This can be done. I only see two mitigation points (related to
        > partitionning), plus quite a number of "small changes" which you might
        > want to expect beforehand...

        > As you can see from the above scheme, you are required to have an
        > additional "extended LBA" entry between 9 and 10 (XX above). This
        > requires you to reduce the size of partition #9 by one sector. I have
        > not done the maths (what you can see in the lower frame when the
        > partition is selected), so I do not know if the 8GB FAT32 volume which
        > is inside it have a spare sector at the end (this is usually the case),
        > so you do not need to do anything there, or if it is full

        The latter, I think. IOW, RPM says, actual partition size equals
        maximum size already = 16,386,300 sectors.

        > in which case
        > you should make very sure there is no data in the last cluster of this
        > volume (because it would be lost after you reduce it by one sector).

        Several questions come to mind at this point :

        - if I read correctly, you are saying it suffices to regain 1 sector
        (just one) between existing parts #9 & #10 - partition #XX in your
        above scheme. That sector would be the EMBR, I gather. Good news. I
        thought we'd need an entire track, i.e. 63 sectors, at this place, for
        compatibility. Even though I understand of course those "tracks" are
        purely fictitious...

        - I'm concerned if having that EMBR at the end of a "track" (viz.
        2,887 254 63) won't get me into trouble with some OSes.

        - I'd rather have the new "XX" partition start at the 1st of the next
        cylinder, where the NTFS #10 has its startpoint now. And rather than
        trying to slide the NTFS by one (or 63?) sectors, delete/recreate it
        using the windows 2k partition manager after saving its contents of
        course. Any objection ?

        > The other problem is only important for MS-DOS 7.1, if you have another
        > disk mounted in the case: due to a bug in FAT32 handling in MSDOS (not
        > Windows9x), the last partition in the chain (here the NTFS one) when not
        > recognized by DOS, will partially erase the discovery of the next disk,
        > leading to obscure problems (even inside Windows 98). Since the symptoms
        > are already here anyway, I guess this is not a real problem for you.

        There is a second disk indeed, which is seen by all OSes. For
        DOS/Windows, it is D:

        > There is some details I am not 100% sure, but it should be easy to try;
        > see below.

        > Changes you'll experiment:
        > - the associated numbers under Linux will likely change (the logical
        > volumes are numbered after the primary ones). It could even be a problem
        > to boot Linux on the first place. If this occurs, make your entry of RPM
        > (part #11) part of the MBR at #3, so Linux will see a supplementary
        > entry before the logical, and you'll back on normal path (3 primaries,
        > Linux as 2nd logical, swap as 1st logical).
        > - it would be impossible to boot directly from BIOS into volume #9
        > (until you hack the boot chain, but it comes to hard trickery; also see
        > below)the .ini and bootsectors

        Not a problem : Volume 9 is not made bootable even today. I boot to
        either volume #2 (C:) which has the NTLDR and an appropriate boot
        menu, or direct to GRUB in the #7 ext2, which has the gears for
        booting to Linux - more and more my Os of choice - or one of the
        Windows if I change my mind ;=)


        > - while you could boot Windows 98 from the DOS partition (assuming it
        > is DOS 7.1),

        Primary #1 ? Oh no! that's a small FAT16/DOS 6.2 for work and rescue
        purposes, with it's own multi-boot config.sys menu for a choice of
        regular DOS / Linux again (by way of Loadlin) / or... another copy of
        Ranish :=)

        > it will see the #9 volume as disk D: ....

        Not applicable since DOS 6 does not see FAT32 volumes at all.

        /snipping some of your precious comments,/ ....

        > - the only way to make volume #9 being C: is to hide the DOS
        partition, ....

        Hmmm. I hate having to (try to) predict what the drive letters will
        turn being, but IMHO if I do as you tell, DOS and Win 98 will assign
        C: to the first (and only) primary of the second physical drive. Maybe
        you'll suggest I hide/destroy that second disk ?


        > then I guess you will experiment difficulties to boot even under VMWare
        > - booting directly in the NTFS partition (from NTLDR/BOOT.INI) requires
        > first installing it on the DOS partition if it is not here already, then
        > creating/editing the correct entry to boot NT
        > - probably others...

        This may well turn in a bigger problem than the partition table
        wizzardry after all...


        > Changes which will not occur:
        > - under DOS the Windows 98 volume will still be disk D:, no change
        > (unless you install another disk, but see above first, this is a
        > BadIdea)

        Too late

        > - under NT (200x, XP) the letters assigned will stay the same
        / other interesting details snipped/

        Nice. I'll have to Google about signature saving.


        > How to do it (not tested!):
        ........snipped again but carefully saved...

        As you say, this change will require more than a moment free time,
        calm and method (some aspirin maybe). It is not appearing so much
        desirable now as it looked before studying your indications.

        OTOH I found another approach to securing the booting of the physical
        disk under a VMware virtual machine running from an OS on same disk,
        which I've been expereminting with success. In a word, since I fear
        hairy details would be off topic in this group, (and need even more
        aspirin) : the disk that the VMware machine sees as a whle can be made
        from several pieces, in this case the bulk of the disk is my physical
        medium but I substitute a "fake MBR" (an image file) and fake Ranish
        partition, or rather fake Ranish disk tables (hardly 8 sectors) from a
        nother file. This way the Oses and Ranish on the virtual system see a
        different image of the disk partitions than when running Windows
        "native", I may secure the whole virtual system without interference
        to the physical partitionning.

        Warning! : using VMware in this way is not for the casual "player".


        > Antoine

        Thanks again

        --
        Czerno

        EOM __________________________________________________________
      • Antoine Leca
        ... Which one? :-) As you know, those tracks are pure fiction. Furthermore, we are quite a bit above the 8GB/1024-cylinder barrier, so CHS addressing is out of
        Message 3 of 4 , Dec 5, 2007
          Czerno wrote:
          > "Antoine Leca" <aleca@...> wrote:
          > > If I understand you correctly, you want the following scheme
          > >
          > > 0 MBR Master Boot Record 0 0 1 / 0 0 1 / 0
          > > 1 Pri Unused 0 0 2 / 0 0 63 / 31
          > > 2 Pri 1 DOS FAT-16 0 1 1 / 2 254 63 / 24,066
          > > 3 >Pri 2 Windows FAT-32 LBA 3 0 1 / 1,046 254 63 / 8,385,930
          > >
          > > 4 Pri 4 Extended LBA 1,047 0 1 / 4,997 245 63 / xxxxxxxxxx
          > > 5 |-Log Linux swap 1,047 1 1 / 1,076 254 63 / 240,943
          > > 6 |=Ext Extended LBA 1,077 0 1 / 1,866 254 63 / 6,345,675
          > > 7 |-Log Linux ext2fs 1,077 1 1 / 1,866 254 63 / 6,345,643
          > >
          > > 8 |=Ext Extended LBA 1,867 0 1 / 1,867 254 63 / xxxxxxxxx
          > > 9 |-Log Win FAT-32 LBA 1,868 0 1 / 2,887 254 63 / 8,193,150

          > > XX |=Ext Extended LBA 2,887 254 63 / 2,887 254 63 / xxxxxxxxx
          > > 10 |-Log Windows NT NTFS 2,888 0 1 / 4,997 245 63 / 16,948,291
          > > 11 Pri Boot Manager 4,997 246 1 / 4,998 5 63 / 472
          >
          > Right, this would be the idea.
          >
          > > This can be done. I only see two mitigation points (related to
          > > partitionning), plus quite a number of "small changes"
          > which you might
          > > want to expect beforehand...
          >
          > > As you can see from the above scheme, you are required to have an
          > > additional "extended LBA" entry between 9 and 10 (XX above). This
          > > requires you to reduce the size of partition #9 by one
          > > sector. I have
          > > not done the maths (what you can see in the lower frame when the
          > > I do not know if the 8GB FAT32 volume which is inside it have
          > > a spare sector at the end (this is usually the case),
          > > so you do not need to do anything there, or if it is full
          >
          > The latter, I think. IOW, RPM says, actual partition size equals
          > maximum size already = 16,386,300 sectors.

          >
          > > in which case
          > > you should make very sure there is no data in the last
          > cluster of this
          > > volume (because it would be lost after you reduce it by one sector).
          >
          > Several questions come to mind at this point :
          >
          > - if I read correctly, you are saying it suffices to regain 1 sector
          > (just one) between existing parts #9 & #10 - partition #XX in your
          > above scheme. That sector would be the EMBR, I gather. Good news. I
          > thought we'd need an entire track, i.e. 63 sectors, at this place, for
          > compatibility. Even though I understand of course those "tracks" are
          > purely fictitious...
          >
          > - I'm concerned if having that EMBR at the end of a "track" (viz.
          > 2,887 254 63) won't get me into trouble with some OSes.

          Which one? :-)
          As you know, those tracks are pure fiction.
          Furthermore, we are quite a bit above the 8GB/1024-cylinder barrier, so
          CHS addressing is out of question for any OS, only very strange tools
          like RPM still uses it.
          Furthermore, I can confirm this works OK with DOS and FreeDOS (I used
          this scheme on a RAID array), which are the main "problematic" OS you
          might encounter because of legacy, most if not all others sticks to LBA
          at every moment.

          What is likely to give you problem are some tools which insist upon
          those "whole track" concept, even if proves to be wrong from day 1.
          Partition Magic is likely to choke (and refuse to do anything), for
          example.


          > - I'd rather have the new "XX" partition start at the 1st of the next
          > cylinder, where the NTFS #10 has its startpoint now. And rather than
          > trying to slide the NTFS by one (or 63?) sectors, delete/recreate it
          > using the windows 2k partition manager after saving its contents of
          > course. Any objection ?

          No. But you understand you will need to reformat this partition.

          > > The other problem is only important for MS-DOS 7.1, if you
          > > have another disk mounted in the case:
          >
          > There is a second disk indeed, which is seen by all OSes. For
          > DOS/Windows, it is D:

          OK, so there is only one primary on it, so problem.

          For the record, here are the details of the bug:

          When MS-DOS enumerates all the volumes, it first goes through all the
          disk and register the active or if there are none, the first
          (recognized, i.e. FAT, id 1-4-6-E-C-B) volume and gives it a DPB (hence
          a letter): those are named C: D: etc.
          Then (from 3.3 upward) it does a second pass through all disks again,
          wlaking the EMBR chains, and give every encountered (recongnized) volume
          another DPB: so here the target system will get the E: letter, for
          example
          Then (from 5.0 upward) it does a third pass, and gives DPB to every
          supplementary primary recognized: for your presnet system, this creates
          the E: letter.

          Until there, no particular problem.

          Now the bug: for DOS 7.1, the FAT32 patch preallocates various fields in
          the DPB on each encountered volume, even it turns out to not be
          recognized a few seconds latter. For you, this would occur during the
          2nd pass, for every volume except #9. Usually, those pre-allocated
          fields are cleaned up (usually by being erades by the next candidate.)
          But the bug is taht at the end of the 2nd-pass chain walking, the loop
          is exited a bit abruptely, and the cleaning does not occur; and the
          result is a "ghost" volume, which can create bad problem and even data
          loss. As a result, when you have two disks (or more) with two (or more)
          chains of logical volumes, and if any chain (except the last one) ends
          with a non-recognized volume, you are at risk. Personnaly I now create a
          dummy FAT12 volume at the end of any chain, just to avoid any problem.

          > > - while you could boot Windows 98 from the DOS partition
          > > (assuming it is DOS 7.1),
          >
          > Primary #1 ? Oh no! that's a small FAT16/DOS 6.2 for work and rescue
          > purposes, with it's own multi-boot config.sys menu for a choice of
          > regular DOS / Linux again (by way of Loadlin) / or... another copy of
          > Ranish :=)

          You can certainly boot Windows 98 with the DOS being in C: and the
          WINDOWS directory being in another volume, here E:.
          The only problematic point doing so, is that if you add a disk to the
          case, it will get the E: letter, and Windows won't boot anymore (unless
          major surgery occurs in the registry and several other places)
          Of course it needs to have a version of DOS able to boot the Windows :-)
          which is not your case !



          > > - the only way to make volume #9 being C: is to hide the DOS
          > partition, ....
          >
          > Hmmm. I hate having to (try to) predict what the drive letters will
          > turn being, but IMHO if I do as you tell, DOS and Win 98 will assign
          > C: to the first (and only) primary of the second physical drive.

          Correct.

          > Maybe you'll suggest I hide/destroy that second disk ?

          Maybe it would have been easier to me to guess if you mentionned it at
          all :-)


          > > then I guess you will experiment difficulties to boot even
          > under VMWare
          > > - booting directly in the NTFS partition (from
          > NTLDR/BOOT.INI) requires
          > > first installing it on the DOS partition if it is not here
          > already, then
          > > creating/editing the correct entry to boot NT
          > > - probably others...
          >
          > This may well turn in a bigger problem than the partition table
          > wizzardry after all...

          I meant, to boot into volumes #9 or #10 (I forgot about volume #2 at
          this point of my earlier post, sorry for that.) Of course, if they are
          solely data volumes, there is no problem.
          Even if they are somewhat involved in Windows but are not either the
          start volume (where NTLDR lives) or the boot volume (where SYSTEM32
          directory lives; sorry for the terminology, but that's MS' fault), there
          is nothing needed to be fixed, because NT 5.x registers the volumes by
          disk_sigature + starting_byte_on_disk, and only changes the letters if
          those values change, the primary/logical status is not considered.
          In fact, I believe this should happen for the boot volume as well, with
          only one exception: in BOOT.INI you may be required to fix the ARCpath
          whenever you touch the setup, including when you add (resp. remove) an
          otherwise irrelevant primary partition, because the numbers of the
          logical partitions then goes up (desp. down) one.


          > > - under NT (200x, XP) the letters assigned will stay the same
          > / other interesting details snipped/
          >
          > Nice. I'll have to Google about signature saving.

          http://www.sysint.no/nedlasting/mbrfix.htm
          http://www.diydatarecovery.nl/mbrtool.htm

          Reading Wikipedia is also worthwhile (and if you do it and are not a
          native speaker, you certainly can improve it by translating the English
          version to your native language; correcting mistakes or errors is also
          quite possible ;-))


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