1 (edited by cmdr 2009-01-28 01:17:31)

Topic: Update to "resize-windows.txt" - Draft to discuss

----> This is a draft to update "resize-windows.txt",
----> which is a part of "GParted" info package.
----> Not all suggestions are based on personal experience
----> or testing (estimated 20 % do NOT !).
----> There might be grammatical or other faults, because
----> English is not my native language.
----> Important question to the programmers of "Gparted":
----> Why does "fdisk (i)" not work as expected or what
----> am I doing wrong ? I also tried "sudo fdisk ..."
----> with no effect !
----> This text refers to Version 0.3.9-1

----> New "resize-windows.txt" starts here:


IMPORTANT : READ THIS FIRST IF YOU WANT TO WORK ON WINDOWS XP OR VISTA

RULE No.1 : BACKUP EVERYTHING, you don't want to loose in a worst
            case scenario, BEFORE you use "GParted" !

RULE No.2 : ALWAYS USE NEWEST (STABLE) RELEASE OF "GParted" !
            (http://gparted.sourceforge.net/download.php)
            If "GParted" is integrated in other Linux distros (e.g.
            UBUNTU) or Linux partition tools (e.g. Parted Magic)
            it might not be the NEWEST release !
            
RULE No.3 : NEVER ABORT RUNNING "GParted" OPERATIONS !
            NEVER DO "GParted" OPERATIONS ON BATTERY DRIVEN LAPTOPS,
            BECAUSE NEEDED TIME MIGHT EXCEED BATTERY CAPACITY BY FAR!
            AVOID ANY POWER BREAKDOWN ON ALL SYSTEMS, WHILE "GParted"
            IS RUNNING !          

HINT No.1 : Use CD RW as boot media (download ISO image and burn it;
            burning an ISO-Image is a SEPARATE task in your burning software;
            do not confuse it with creating a data CD) or USB Stick (download
            ZIP file and unpack it to a Linux bootable stick; this isn't a
            recommended way for novices !).
            It's simply easier, always to be up-to-date.

HINT No.2 : If you are not quite sure, how to proceed with an operation,
            modifying your storage device, ask the "Gparted" Community
            on "http://gparted-forum.surf4.info". Generally, you save 
            more time, expecting a qualified answer, than to get out of
            trouble, if you do it yourself by trial and error. The more
            details, you give about your system and the wanted changes
            with your question, the better is the answer.

HINT No.3 : Print out this information text for better overview.
            Use "Wordpad" under Windows to get it easy readable.
            To have a proper page layout, cut and paste it to "Works"
            or "Word" and print it with your favourite printer.
            See "Windows XP / I. From within "GParted" / Variant B /
            second Note, how to mount an USB Stick. Copy this text
            with "cp /root/resize-windows.txt /mnt/usb" to the stick.



 
************************************************************************
---   Windows XP   ---
************************************************************************

WHAT'S THE PROBLEM ?
----------------------------

Windows' "brain", the Registry, contains informations on partition data
of the drives, it works with, no matter, if they are yet connected
or not. It even stores the assigned Drive letters. If you resize, move or
clone such a disk and boot, any differences are noticed. Maybe login
is still possible, but followed immediately by automatic logout ( fault on
virtual memory or "pagefile.sys" is often indicated); maybe a STOP
error (blue screen) occurs or you get "missing NTLDR"-message.

CRITICAL ACTIONS :

1. Resizing/Moving a Windows boot device (C:)

2. "Cloning" (Cut and Paste) the Windows boot drive (only one partition)
   to a bigger new drive (filesystem gets automatically resized by
   "GParted" to fill the whole drive).

Note: The bootflag of the source device's boot partition in MBR does not get
      copied to the target device, you have to add it manually with "GParted".
      Volume ID gets also not copied. If you resized or moved the boot
      partition, you must not use the source's Volume ID for the target (see below). 
      If you clone a multipartitioned drive and leave the boot device (C:)
      untouched ( MBR, no resize, no move, restored bootflag), you
      should be able to access Windows immediately on the cloned drive,
      which you should ALWAYS do BEFORE you resize or delete other 
      partitions of that drive, to flush a certain Registry key (see below) .
      Be careful with NTFS partitions. Do operations step by step, not in
      a batch, reboot after each and let Windows "settle" NTFS. 
      Try accessability with Windows and ALWAYS delete the above mentioned
      Registry key (see below) before continuing.

      Before you shrink a Windows partition you should always delete superfluous
      files and directories (temporary files / update recovery files etc.) AND 
      DEFRAGMENT the drive. Why ? The amount of free space to gain is bigger !
      Be aware that fragmentation is a Windows issue; Linux partitions do NOT
      need to be defragmented. There is a quick and fool-proof GNU defragger
      JkDefrag ( http://portableapps.com/apps/utilities/jkdefrag_portable ),
      which works on VISTA, too (with some minor limitations).


HOW TO AVOID THIS TROUBLE ?
--------------------------------------

You simply have to delete ONE Registry key BEFORE you use "GParted":

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

(Start - Run "regedit" - Search "mounteddevices"- Delete whole key)

NOTE: BE SURE, NOT TO ALTER ANYTHING ELSE, THERE IS NO "UNDO" !
      Don't worry, this  Registry key regenerates "slim"
      (not connected drives have gone) on next boot. If you changed drive
      letter assignment before, i.e. "renamed" a drive to a new drive letter,
      this has also gone afterwards. Drives are redetected and "named" in
      Windows-given sequence.

      AVOID RUNNING INTO NEW TROUBLE : DO NOT CONNECT (ON ONE
      SYSTEM) SOURCE DRIVE AND TARGET DRIVE OF A CLONED PAIR
      SIMULTANEOUSLY OR SEQUENTIALLY, IF YOU RUN WINDOWS.
      Duplicate Drive IDs are not allowed under Windows !
      You MUST change one ID at least (HowTo below !).



WHAT IF YOUR DRIVE REFUSES TO BOOT,
I.E. YOU NOTICED THIS INFORMATION TOO LATE ?
-----------------------------------------------------------

Replace the  drive ID in
MBR (Master Boot Record) with a new one.


H o w T o :

I. From within "GParted"

Variant A
=============================================================================

----> Up to now (Version 0.3.9-1) this variant is NOT working !!!! <----

a. Launch "Gparted" (corrupted Windows drive connected), note Linux disk name
   (e.g. /dev/hda; replace "/dev/hda" with your specific disk name,
    whenever "/dev/hda" is used below !)

alternative : b2.

IMPORTANT :  "/dev/hda1" is the DEVICE name of the first primary partition
             on DISK "/dev/hda".
             KEEP IN MIND, THAT WE WORK ON DISK BASIS (PHYSICAL DRIVE) HERE
             AND NOT ON DEVICE BASIS (LOGICAL DRIVES). THERFORE LINUX DISK
             NAMES USED IN THIS CONTEXT DO  N E V E R  CONTAIN NUMBERS.
             YOU MAY SEVERELY DAMAGE YOUR SYSTEM, IF YOU OVERWRITE THE WRONG
             STORAGE BLOCK BY USING NUMBERED DEVICE NAMES.

             ALL COMMANDS ARE ENCLOSED IN QUOTATION MARKS. DO NOT TYPE THEM !
             TO AVOID OPERATION OF COMMANDS BY CLICKING ON THIS TEXTFILE, ALL
             CRITICAL COMMANDS ARE "COMMENTED OUT", I.E. HAVE A PRECEEDING
             NUMBER SIGN ("#"). YOU MUST OMIT IT.

b1. Start a second "Terminal" window ( this information is the first )
    by double-clicking on Desktop icon

Note: Quit "Terminal" with "exit" or by closing window with mouse (X),
      when finished. You can resize terminal window by using the mouse
      on lower left or right window corner, same as with Windows.

b2. (alternative to a.)
    Type "fdisk -l" at prompt, confirm; note Linux Disk name of Drive,
    containing bootable Windows C: device

c. Type "#fdisk /dev/hda", confirm (omit "#", see above)

Note : If you want to abort an "fdisk" action, press [CTRL] + [C].
       Regular exit is "q".

d. Type "x" (Expert mode), confirm  and then "i" (Change disk ID), confirm
e. Fill in a different 4-Byte hexadecimal number (e.g. 0x1234ABCD), confirm
f. Type "r", confirm ( Return from Expert mode; may be omitted)
g. Type "p", confirm ( Control changes; not yet stored ! )
h. Type "w", confirm ( Write changes to drive and exit )
   ( This obviously does NOT happen !!!!)
 
=============================================================================

Variant B
=============================================================================

Use "GParted"'s built-in HexEditor !

1. Load MBR to HexEditor, replace disk ID, store changed MBR temporarily :

(e.g Disk is "/dev/sda"; replace it with your disk's name, whenever it's
 used below;  see Variant A, a. or b2. to get it.)

a. Start a second instance of "Terminal" (per Desktop icon)

Note: Quit "Terminal" with "exit" or by closing window with mouse (X),
      when finished. You can resize terminal window by using the mouse
      on lower left or right window corner , same as with Windows.

b. Type at the prompt (omit quotation marks, ignore possible linefeed):

   "mbr=/root/mbr_sda.bin; dd if=/dev/sda bs=512 count=1 > $mbr & mc -v $mbr"

Note: "mbr_sda.bin" is a file name. It contains the sample's Drive ID (sda)
       in its name. Feel free to choose an other name, but keep the path
       "/root". If you mount an USB Stick (to "/mnt/usb"), you can
       permanently store the MBR file for documentation or rescue.

       HowTo:
       - Plug in USB Stick (wait a few seconds; stick's LED must flicker !)
       - Type "dmesg | tail -4", confirm (no quotation marks !)
       - You see the (logical) device name of your stick (e.g. sdb1), which
       - you need (and NOT the physical disk name, e.g. sdb).
       - Type "mkdir /mnt/usb", confirm
       - Type "mount /dev/sdb1 /mnt/usb", confirm (use YOUR device's name !)
       - If you want to have a new subfolder, type "mkdir /mnt/usb/MyHDD",
         confirm
       - Type "cp /root/mbr_sda.bin /mnt/usb/MyHDD", confirm

c. [F4] (Hex), scroll down to Line 000001B0 with arrow down key
   (Sorry, mouse isn't working !)

d. In Line 000001B0 proceed to column 8 (watch the offset header (0x000001b8);
   first column is 0) with arrow right key. You are now exactly behind a
   column border line.

e. [F2] (Edit)

f. Overwrite 4-Byte hexadecimal value with a new one or change one 4-bit pair
   at least (e.g. 5F 32 16 AB  to  F5 32 16 AB).

Note: Hexadecimal numbers use 0 to 9 and A to F

Hínt: To be less cryptic, you can press [TAB] key and move the active cursor
      to the right, where you can use 4 readable characters or numbers as ID.
      Perhaps you prefer "HDD1" as disk ID (which is 48 44 44 31 hexadecimal).
      
g. Do not forget to save changes, [F6] and exit, [F3] or [F10].

Note: Be sure NOT TO CHANGE ANYTHING ELSE !


2. Write new MBR to disk

Type "#dd if=/root/mbr_sda.bin of=/dev/sda bs=512 count=1" (NO #, no quotation marks !)

NOTE: THIS IS THE MOST CRITICAL ACTION !
      You MUST NOT make any fault in typing this !
      Keep in mind, that your disk name might differ,
      (of=) . . . and NEVER contains any numbers !!!
      DO NOT FORGET TO USE YOUR INDIVIDUALIZED FILENAME
      (instead of "mbr_sda.bin", if used) !

=============================================================================




II. Using Windows

Download a Windows Hexadecimal Editor
(e.g HxD; free download at "http://mh-nexus.de/en/programs.php")
and open MBR (Physical Drive 2 or higher probably, sector 0) for editing.

Note: You need a working Windows OS on another system (beware of duplicate
      drive IDs !) and the corrupted drive connected to it ! The repair
      procedure is the same as described above (Variant B under "GParted").




*****************************************************************************
---   Windows VISTA   ---
*****************************************************************************


WHAT ARE THE PROBLEMS ?
--------------------------------

At the moment, no one is cloning a VISTA drive, because drives are yet big enough.
Theoretically you might run into the same issues as described above with XP.

Changing/Deleting partitions on a VISTA drive might confuse its bootmanager and
most often there is no access to Boot Recovery Tools, which solve the problem,
because they were not "shipped" with the system !
If you plan to delete a partition in front of VISTA's partition and move VISTA to
the beginning (usually block 63) of your harddisk, use "BCDEdit" in advance to
direct "bootmgr" to the new first partition (locking you out for the moment !).
Maybe that doesn't work, because VISTA tests its partitioning before writing
nonsense (at the moment !) to the Registry ( I could not test it ! Perhaps you
need to delete Registry key "MountedDevices", too, as described with XP).

Operation on NTFS partitions is always a challenge for "GParted", because
Microsoft does not publicate NTFS technical data, which must then be researched
- with more or less success - by the programmers of "Gparted" !

Shrinking VISTA, which is the top hit at the moment, because many users wish to
have a supplemental XP or Linux distro on their system, isn't that easy, because
VISTA spreads some system data over its partition, which limits the amount of
space, you can get by shrinking. Even if you defragment your drive, this data
stays fixed. Some third party commercial defragmentation tools however cope
with that issue. The best way to do the job with "GParted" is to shrink in
small steps, booting VISTA after each, to "settle" NTFS structure. Another
method is to use VISTA's own partition tool in drive manager, which seems to
work well, if you are happy with the limited space, you get.


ISSUES :
======

1. VISTA DOESN'T BOOT ANYMORE


This might happen, if you delete a primary partition, which was physically located
in front of VISTA (often Diagnostic or Recovery stuff). VISTA RECOVERY TOOLS
are able to restore the boot records (MBR / PBR) and scan the drive to find VISTA
again. If you don't delete the preceeding first partition totally, but shrink it
to minimal size (and hide it for example by using a Linux filesystem ID), you avoid
this problem, provided, that moving VISTA was successful. If only the MBR / PBR gets 
overwritten by an older Windows version in a planned Multi Boot Configuration, you
find a solution on EVERY VISTA installation disk, even OEM-Recovery, see 2.c. below.

If you installed a Linux bootmanager ( see 4. for an appropriate bootmanager),
it's the wanted effect, that VISTA doesn't boot directly anymore. You can
start VISTA's "bootmgr" with the Linux bootmenu and get access this way.
The Linux bootmanager must be on the bootable primary partition, i.e. the former
VISTA startup partition (always drive C:). On preconfigured systems VISTA normally
is located on drive C:, too. But a split design is also possible (startup on
drive C: , e.g. system on drive D:). In that case "bootmgr" can even be moved
to the system drive (but must perhaps be renamed, see below). 

Hint : If you plan a Windows Multiboot Configuration on one new harddisk, you should
       spend some time thinking about the sequence of installation to risk minimal
       trouble. Generally you should start with the oldest Windows version, because
       newer versions are able to coexist with older ones since Windows 2000. It is
       simply the "normal state", that a newer version has to cope with that situation,
       but not the other way round ! Even if you have a pure Windows multiboot
       surrounding, you can use a Linux bootloader (see 4. below) to handle a 
       flexible startup with an easy potential integration of Linux tools or 
       distributions, even as drive images. Do not underestimate the problems,
       that occur with hardware drivers! The older the Windows version, the more
       likely it is, that you don't get appropriate drivers for your new hardware.
       E.g. not all Windows XP drivers work with Windows 2000 and vice versa. 
       Consult the download pages of your system supplier or component producer,
       before you start, to avoid deception. A surprising fact is, that Windows
       2000 installation is not possible on NTFS formatted drives. They are even
       hidden for the setup system. Keep in mind, that the Registry "knows" the
       Drive letter, where the system was installed. It is not changeable afterwards. 
       With Windows 2000 / XP and VISTA it is possible to split boot and system
       partitions, i.e. Linux bootmanager resides on C: together with 2000,
       XP on D: and VISTA on E: (due to the sequence of installation!), 
       F: is DVD/CDROM/Burner. You can create a fourth extended partition with a
       maximum of 20 logical drives (G: to Z:) for data, pictures, music,
       Linux distibutions or whatever gets packed into bits and bytes !  


2. WHERE DO I GET VISTA RECOVERY TOOLS ?


a. On an original Installation DVD/CDROM (no OEM "Recovery" media !)
   (see "http://support.microsoft.com/kb/927392/en-us", also for b.)
b. By free Download
   ("http://neosmart.net/blog/2008/windows-vista-recovery-disc-download/")
c. If you know, that only the MBR/PBR were replaced by an older Windows OS
   and you did not delete any partitions in front of the VISTA partition :
   Try "X:\boot\Bootsect.exe /NT60 All", a program, which you can find on 
   ANY media, able to install VISTA, where "X:" is your DVD/CDROM drive.
   Use it in a console window of the older working Windows version or an
   Emergency Boot Floppy (see "http://support.microsoft.com/kb/919529/en-us")
d. If you install a Linux bootmanager, there is no need for recovery in
   most cases ( if there are no changes in partition sequence respectively,
   see 4. below ) ! 


3. WHAT IF YOU INSIST ON USING "GPARTED" FOR RESIZING VISTA ?


   Do it manually at your own risk!

a. Start a second "Terminal" window ( this information is the first )
   by double-clicking on Desktop icon

Note: Quit "Terminal" with "exit" or by closing window with mouse (X),
      when finished. You can resize terminal window by using the mouse
      on lower left or right window corner, same as with Windows.

b. Shrinking the filesystem NTFS (= changes on PBR and device partition)

   (e.g. shrinking "/dev/hda1" from 40 GB to 25GB; this step might be too
    big. You better do it -  always b. and c. together - in several smaller
    steps !)

   "#ntfsresize -s 25G /dev/hda1", (omit # and quotation marks !)

c. Shrinking the partition (= new partition table entry in MBR )

   "#fdisk /dev/hda",
   (note, that you are working on disk, "hda", and not on device basis, "hda1" !)

   hit "p" ( show drive layout )

   Example :
   Device     Boot   Start  End     Blocks  ID  System
   /dev/hda1    *      1    962    7727234   7  HTFS/NTFS

Note : Be sure you choose the right partition ("*" at Boot; System HTFS/NTFS)

   Type "d" (delete the partition)
   Then type "p" (you see : partition is gone).
   Type "n" (create a new partition) and
        "p" ( use primary );
   type the right number = the same ("1") as it was before you deleted
   the partition ! At First cylinder type the value you saw in "Start"
   column ("1" here !).
   At last cylinder (be careful), type the size of the file system
   plus  about one GB (to be safe; 25GB +1GB = 26 GB).
   Then type "p" to see the result.

   The suggested default file system is "83 Linux", which gets corrected by
   "t", then the number of the partition you want to have the filesystem type
   ("1"),then type "7" (for HTFS/NTFS filesystem).
   type "p" to see the result.
   type "w" to write the changes and exit,
   or type "q" to quit without making any change, if you want to abort !


4. WHICH BOOTLOADER / BOOTMANAGER SHOULD YOU USE ?

As a Windows user you are perhaps familiar with NTLDR and its BOOT.INI, if you use a
Multiboot Configuration. This is a unified bootloader and -manager. With VISTA these
two functions are split into BOOTMGR (Manager, reads BCD and presents menu) and
WINLOAD.EXE (Loader). Easy to handle "boot.ini" has gone, you have to cope with
"BCDEdit". VISTA automatically detects former Windows versions and integrates them
into its menu. If you don't plan to integrate Linux distributions or tools on your
harddisk, there is no need for you, to change anything.

If Linux is an option for you, you expect perhaps some advice on Linux Bootloaders /
-managers. Maybe you heard already names like LiLo, Grub, Syslinux. Today Grub might
be number one. All these programs have in common , that they change MBR and PBR
(on boot partition), i.e a "rollback" means, that the former MBR / PBR have to be
restored. There is another program, GRUB4DOS, which does NOT change any boot records
and consists minimally of two files, "GRLDR" and "menu.lst" ( a textfile with the 
Menu script). The easiest way to integrate it, is "renaming". If VISTA's bootmgr
is your actual bootmanager, just rename it to "vistamgr". Next, rename "GRLDR" to
"bootmgr". Here is a sample "menu.lst", which boots VISTA, XP (NTLDR=>XPLDR) / W2K
(NTLDR=>W2KLDR), a floppy disk image (e.g. a Windows 98 Emergency Boot Disk) and 
a "GParted" Version (the syntax of "menu.lst" is very similar to GRUB !):

>--------- snip ------------<
# ***** This text comments the following script commands (no #)******
# color scheme is clear, after you saw the menu for the first time !
# wait(timeout) 30 seconds before starting (default) VISTA (item 0)
# ("default 0" can be omitted, because it's the default value !)
# Countdown gets interrupted, if you choose another menu item with arrow key.
# rootnoverify hd(0,0) = select first partition ( ,0) of first HDD (0, )
# as starting point, but do not mount it.

color black/cyan yellow/cyan
timeout 30
default 0
rootnoverify (hd0,0)

# Menu item sequence
# You have to separate each with at least one empty line.
# title = visible menu item
# fallback=in case of (GRLDR) fault, try menu item 1 ( the second !) automatically
# find = search for /vistamgr (absolute path necessary) in all mountable partitions of
# preselected (rootnoverify hd(0,0), see above) drive. If successful, select
# partition as root (it doesn't matter, if it's bootable or not !)
# chainloader = search file /vistamgr on selected partition and start it.


title Windows VISTA
fallback 1
find --set-root /vistamgr
chainloader /vistamgr

#xpldr is renamed NTLDR
title Windows XP
fallback 2
find --set-root /xpldr
chainloader /xpldr

#w2kldr is renamed NTLDR
title Windows 2000
fallback 3
find --set-root /w2kldr
chainloader /w2kldr

# floppy.img is a floppy image = a file, containing all bytes of 
# an 1.44 MB bootable Windows 98 EBD (= Emergency Boot Disk).
# With the following commands, it gets mounted in memory as
# virtual Floppy drive (= map commands) and started by its
# bootable Volume Boot Record (+1 = First sector).
# This is also useful, if you want to integrate "KNOPPIX",
# which has a Floppy image ("boot.img") as loader.

title 1.44 MB W98 EBD
find --set-root /floppy.img
map --mem /floppy1.img (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)

# Next item shows, how Linux tools or distros are invoked, here "GParted".
# Note, that "kernel" and "initrd" are NOT located in the original folder "live",
# which doesn't matter at this point, but think of "filesystem.squashfs", which
# is located in the same folder. You have to indicate by parameter "live-media-path"
# where it is, otherwise it is not found (because "live" doesn't exist, which is 
# the default folder !). Of course you could store it separately in a folder "live",
# but then you cannot keep more than one version on the drive, which sometimes is
# useful (stable release and test version together on one drive) !
# boot=live doesn't indicate a folder, but a bash script file, which is invoked
# in the boot process, do not omit or alter this entry. 
# Further note, that all parameters (kernel AND initrd) are written to the kernel line.

title GPartEd 0.3.9-1
rootnoverify (hd0,0)
kernel /live391/vmlinuz1 live-media-path=live391 boot=live union=aufs   noswap noprompt vga=791
initrd /live391/initrd1.img

#Interesting is the "help" command, which shows all possible commands.
#Keep in mind, that there are less commands than "classical" GRUB offers !
#Return to menu with [ESC]

title Start Console
savedefault --wait=2
commandline

#"Cold" reboot
#You do no harm, if you force "power off" by power switch, while in this menu !
#Remember MS-DOS, if you are old enough !

title Restart
reboot
>------- snap -------<  
   
Note: Lines starting with "#" are comments and can be omitted.
      You must use a Linux texteditor (type "nano" in Terminal window) to create
      "menu.lst", because Windows editors use CR/LF ( Carriage Return / LineFeed )
      for new line, whereas Linux uses only LF. CR/LF is not tolerated by "GRLDR".
      To Mount an USB Stick, see Windows XP/ I. From within Gparted/
      Variant B (second Note), above.  Store "menu.lst" in "/root", exit "nano" and
      copy it to the stick with "cp /root/menu.lst /mnt/usb"

      Last but not least, you can use "classical" GRUB as well, if you don't mind,
      that MBR and PBR get replaced. I would not use LiLo or Syslinux for that
      purpose. 

************************************************************************
       If you found a technical or language bug in this information or have any suggestions,
       feel free to contact
       "http://gparted-forum.surf4.info/viewforum.php?id=6",
       where this text will be discussed, I assume.
************************************************************************
EOF

2

Re: Update to "resize-windows.txt" - Draft to discuss

Wow cmdr, that is quite the detailed document you posted.

Following are responses to some of your questions:

cmdr wrote:

----> Important question to the programmers of "Gparted":
----> Why does "fdisk (i)" not work as expected or what
----> am I doing wrong ? I also tried "sudo fdisk ..."
----> with no effect !

After a quick search of the manual page for fdisk, I did not observe an option "i" or "-i".  Perhaps you meant something else (e.g., "-l" lowercase L instead of lowercase I)?
What operation were you trying to perform?


cmdr wrote:

Operation on NTFS partitions is always a challenge for "GParted", because
Microsoft does not publicate NTFS technical data, which must then be researched
- with more or less success - by the programmers of "Gparted" !

Much of the credit for the NTFS functionality belongs with the team that wrote the ntfsprogs tools.
http://www.linux-ntfs.org/doku.php
The GParted graphical user interface makes calls to these command line tools to perform operations on NTFS file systems.
GParted itself updates the boot sector of the NTFS file system with the new starting sector when the file system is moved/resized.


Other members of this forum will likely have suggestions on how to improve resize operations, by performing tasks in Windows such as:
   - Defragmenting the file system
   - Turning off the disk swap space

3 (edited by cmdr 2008-09-30 00:34:46)

Re: Update to "resize-windows.txt" - Draft to discuss

gedakc wrote:

After a quick search of the manual page for fdisk, I did not observe an option "i" or "-i".  Perhaps you meant something else (e.g., "-l" lowercase L instead of lowercase I)?
What operation were you trying to perform?

I tried to change MBR's 4-Byte drive ID (address 0x1B8 to 0x1BB)  with "fdisk" console ( key/command sequence : x i 0x1234ABCD p w ), which worked well within fdisk, but did not get written to real MBR, neither on a harddisk, nor on an USB Stick, I tested.  (Detailed description, see "Variant A" in my draft).
Command "i" seems to be very new ! If there is a writing convention to distinguish a bash script commandline parameter "i" of a program and  the "i" key within its console state, I don't know it up to now. I thought that ("sheltered") "(i)" would be understandable.

gedakc wrote:

Much of the credit for the NTFS functionality belongs with the team that wrote the ntfsprogs tools.
http://www.linux-ntfs.org/doku.php

Credit, where credit is due ! Either the right team gets honoured or the sentence gets reworded
neutral.

gedakc wrote:

Other members of this forum will likely have suggestions on how to improve resize operations, ...

A fast, effective GNU defragmentation tool would be a dream ...

Anyone, who wants to shrink a partition, should defragment it before.

Does "Gparted" move fragments of files, that would else block shrinking the partition to a wanted size ? Or limits the first detected file fragment the offered space for shrinking (as it is in VISTA) ?

4

Re: Update to "resize-windows.txt" - Draft to discuss

cmdr wrote:

I tried to change MBR's 4-Byte drive ID (address 0x1B8 to 0x1BB)  with "fdisk" console ( key/command sequence : x i 0x1234ABCD p w ), which worked well within fdisk, but did not get written to real MBR, neither on a harddisk, nor on an USB Stick, I tested.  (Detailed description, see "Variant A" in my draft).
Command "i" seems to be very new ! If there is a writing convention to distinguish a bash script commandline parameter "i" of a program and  the "i" key within its console state, I don't know it up to now. I thought that ("sheltered") "(i)" would be understandable.

Which version of fdisk and on what platform (operating system) is this new "(i)" option available?

Did you use the (w) write to disk option before you exited from fdisk?  If so then perhaps there is a bug that should be logged with the fdisk team.

cmdr wrote:

Does "Gparted" move fragments of files, that would else block shrinking the partition to a wanted size ? Or limits the first detected file fragment the offered space for shrinking (as it is in VISTA) ?

In the case of a move operation, gparted simply moves the partition block by block.  No additional processing is performed to determine the content of the block.
In the case of a resize operation, the ntfsresize command is called.  To find out how the file system is shrunk, you could either review the source code, or perhaps contact the ntfsprogs team.  Personally I have not reviewed the ntfsprogs source code.

5

Re: Update to "resize-windows.txt" - Draft to discuss

gedakc wrote:

Which version of fdisk and on what platform (operating system) is this new "(i)" option available?

Did you use the (w) write to disk option before you exited from fdisk?

Version :  fdisk (util-linux-ng 2.13.1.1)
This version is contained in "GParted 0.3.9-1", to which I referred in my draft.

After typing "w" , fdisk ends with :
--------------------------------------------
The partition table has been altered !
Calling ioctl() to re-read partition table.
Syncing disks.
--------------------------------------------

It's clear, that it doesn't work on mounted drives.

gedakc wrote:

To find out how the file system is shrunk, you could either review the source code, or perhaps contact the ntfsprogs team.

I think, this would exceed my curiosity at the moment.

6

Re: Update to "resize-windows.txt" - Draft to discuss

A fast, effective GNU defragmentation tool would be a dream ...

Dream fulfilled : I found Portable JKDefrag Version 3.36, a GNU project. It's a fool-proof (background) defragmenter for Windows, which uses Windows API functions and is therefore very safe. It works with some limitations on VISTA, too.

Advantages versus Windows Defragger are :

- Much faster.
- Totally automatic, extremely easy to use.
- Optimized for daily use.
- Disk optimization, several strategies ( parameter driven ).
- Directories are moved to the beginning of the disk.
- Reclaims MFT reserved space after disk-full.
- Maintains free spaces for temporary files.
- Can defragment very full harddisks.
- Can defragment very large files.
- Can defragment individual directories and files.
- Can be run automatically with the Windows Scheduler.
- Can be used from the commandline.
- Can be used as a screen saver.
- Can be run from cdrom or memory stick.
- Sources available, can be customized.

I put it into my draft of "resize-windows.txt".

7

Re: Update to "resize-windows.txt" - Draft to discuss

cmdr wrote:

A fast, effective GNU defragmentation tool would be a dream ...

Dream fulfilled : I found Portable JKDefrag Version 3.36, a GNU project. It's a fool-proof (background) defragmenter for Windows, which uses Windows API functions and is therefore very safe. It works with some limitations on VISTA, too.

Cool!  I was not aware of any other defragmenters.  This one appears to run under Windows.  If you happen to come across one that runs under GNU/Linux I would like to know.  It could be a useful tool on the GParted-Live CD.

8

Re: Update to "resize-windows.txt" - Draft to discuss

A link to this post has been added from the GParted web site FAQ

Thank goes to cmdr for writing the detailed resize-windows.txt instructions found at the beginning of this forum post.

9 (edited by Bigrad 2009-10-14 03:36:24)

Re: Update to "resize-windows.txt" - Draft to discuss

nice topic. thanks for the material.

10

Re: Update to "resize-windows.txt" - Draft to discuss

Cool!  I was not aware of any other defragmenters.  This one appears to run under Windows.  If you happen to come across one that runs under GNU/Linux I would like to know.  It could be a useful tool on the GParted-Live CD.

11

Re: Update to "resize-windows.txt" - Draft to discuss

Hello BlackKlaus13,

the problem is, that fragmentation is a Windows issue. Linux filesystems generally need no defragmentation, so the "level of suffering" isn't high enough to develop a "cross-system" defragmentation tool.  A big problem also is, that M$ doesn't publish specified details of its present filesystems. So it's rather difficult to always "stay tuned", and therefore it might be risky to use such a hypothetical Linux tool. On the other hand, Windows API offers (safe!) defragmentation commands for all its filesystems, so why looking elsewhere ? I didn't yet test it, but it's possible, that "jkdefrag" works from a free "Vista Recovery CD", so that even systemfiles (e.g. pagefile.sys)  get defragmented, which are always blocked, when Windows is running. BTW, there is also a recommendable Windows commandline tool "pagedefrag.exe", which does the job !  And to complete the list, you should know "contig.exe", which defragments one or a smaller group of files. As you might know, Linux bootmanager Grub4DOS is able to boot a CDROM image ... and it complains, if the image isn't contiguous. Use "contig.exe", and it runs ! Keep in mind, that EVERY total defragmentation tool needs 15 to 20% of  unused volume space as a minimum for its work.

Regards
cmdr

12

Re: Update to "resize-windows.txt" - Draft to discuss

I have a couple of suggestions for the resize-windows.txt file, in the section for how to manually resize a Vista partition. When I followed the instructions therein I rendered my Vista installation unable to boot. The problem was that I had used the default setting in fdisk for the units, and the partition was being moved slightly to be on a cylinder boundary, while the filesystem stayed in the same place. (Thankfully I had taken a note of the position of the partition (in sectors) before I resized it, so I could restore the original partition table.) I suggest that the instructions include a step to issue the "u" command to fdisk before anything else to avoid this problem.

I also suggest that the presence of this file is made more clear. I only stumbled upon it by accident, and had been trying to use the GParted graphical utility to do the job. Unless the user looks in "/root" for some reason they won't see it.

13

Re: Update to "resize-windows.txt" - Draft to discuss

I shrunk my XP NTFS (single) partition and created a new one at the empty space 4 hours ago, which rendered it unbootable. 4 hours later, what do I find out? That it comes back to life by deleting the new partition and filling the empty space with the XP partition again.

Anyone had the same experience?

14

Re: Update to "resize-windows.txt" - Draft to discuss

Good material thanks.
лазерная коррекция зрения

15

Re: Update to "resize-windows.txt" - Draft to discuss

cmdr wrote:

IMPORTANT : READ THIS FIRST IF YOU WANT TO WORK ON WINDOWS XP OR VISTA

Can I work in windows 7 With it?

16

Re: Update to "resize-windows.txt" - Draft to discuss

Yes, these tips also apply to Windows 7.

17 (edited by mako 2010-11-24 17:19:46)

Re: Update to "resize-windows.txt" - Draft to discuss

Sorry, can you clarify your massive instruction-- does one delete that registry key before you clone the drive or disc on the OLD drive, or on the NEW drive before you change any other partitions??? You delete the whole key (named MountedDevices in the left window of the Registry) or the info in the right box? 
--Is this entire problem a function of XP on NTFS- if you have it on Fat32 copied to Fat 32, is it an  issue??
--I've copied the XP C drive onto bigger partition on an external USB new drive Fat32 to Fat32 , with different other partitions from external drives, then changed and moved several partitions with Eassus and GParted. So I might have a problem, but I haven't booted up the new drive yet.

--Can one delete that key on an external USB drive somehow- is there a registry editor that works without Windows, or works on an externally connected drive's registry???

18

Re: Update to "resize-windows.txt" - Draft to discuss

Hi!
Kudo's to original posters for the tips!
Here is what worked for me when I had clone a partition with Windows 7 Pro from a 60 GB SSD to a 120 GB SSD:

delete HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices key
copy/resize partition
mark new partition as boot
disconnect original disk from the system
repair MBR on new disk using Windows install disk

Cheers!