I know this is a little off topic. I did google around looking for the correct forum to post this question but had little luck. If anyone can make an informed suggestion I'd very much appreciate it.
I have a 150GB ATA disk, /dev/hdb, containing winxp. I'd like to move the contents to an spare 80GB ATA disk, /dev/hda, to make room for a full install of FC10 on the larger disk in preparation for ultimately getting the winxp install running under a linux based VM.
From knoppix, I started by using ntfsresize to shrink the xp partition down to 20GB. That worked suprisingly fine.
I then installed the smaller drive and used dd to copy over the image of the xp installation: dd if=/dev/hdb of=/dev/hda bs=10000000 count=2000
I rebooted and voila! it worked - sort of. The new disk boots xp but it still, according to fdisk, thinks its 150GB. So I used fdisk to delete and redefine the xp partition (primary, bootable type=7) with the new size of the drive, 20GB. After rebooting xp came up but then started quickly blue screening a message I couldn't read, and rebooting. This repeated in a loop until I just rebooted. I tried the whole process over again but this time specified 80GB to dd and fdisk, same disaster.
I tried everything again, but this time instead of fdisk I fired up gparted to see if I could resize from there hoping that if it could some magic would also fix the invalid sizing detected by fdisk. gparted could see the drive but couldn't recognize it as having anything it could work with. I highlighted the drive and the progress bar stayed gray.
So far it seems I can use the drive this way without causing xp any problems. The issue is things just don't look right and I suspect it will come back to bite me one day. I'm not an expert at manipulating bits on a hard drive just yet. Could someone point me to my error? Is what I'm trying do-able? If its a conceptual problem a little education would come in handy too.
Thanks in advance - Tod
Tod Thomas wrote:
I know this is a little off topic. I did google around looking for the correct forum to post this question but had little luck. If anyone can make an informed suggestion I'd very much appreciate it.
I have a 150GB ATA disk, /dev/hdb, containing winxp. I'd like to move the contents to an spare 80GB ATA disk, /dev/hda, to make room for a full install of FC10 on the larger disk in preparation for ultimately getting the winxp install running under a linux based VM.
From knoppix, I started by using ntfsresize to shrink the xp partition down to 20GB. That worked suprisingly fine. I then installed the smaller drive and used dd to copy over the image of the xp installation: dd if=/dev/hdb of=/dev/hda bs=10000000 count=2000
I rebooted and voila! it worked - sort of. The new disk boots xp but it still, according to fdisk, thinks its 150GB. So I used fdisk to delete and redefine the xp partition (primary, bootable type=7) with the new size of the drive, 20GB. After rebooting xp came up but then started quickly blue screening a message I couldn't read, and rebooting. This repeated in a loop until I just rebooted. I tried the whole process over again but this time specified 80GB to dd and fdisk, same disaster.
I tried everything again, but this time instead of fdisk I fired up gparted to see if I could resize from there hoping that if it could some magic would also fix the invalid sizing detected by fdisk. gparted could see the drive but couldn't recognize it as having anything it could work with. I highlighted the drive and the progress bar stayed gray.
So far it seems I can use the drive this way without causing xp any problems. The issue is things just don't look right and I suspect it will come back to bite me one day. I'm not an expert at manipulating bits on a hard drive just yet. Could someone point me to my error? Is what I'm trying do-able? If its a conceptual problem a little education would come in handy too.
You would be better off using parted or one of the GUI interfaces for it. It will resize, as well as copy/move partitions. It is a much better tool for doing things like this then dd is.
One other note - make sure you run defrag on the disk in windows before trying to resize partitions.
Mikkel
Mikkel L. Ellertson wrote:
Tod Thomas wrote:
I know this is a little off topic. I did google around looking for the correct forum to post this question but had little luck. If anyone can make an informed suggestion I'd very much appreciate it.
I have a 150GB ATA disk, /dev/hdb, containing winxp. I'd like to move the contents to an spare 80GB ATA disk, /dev/hda, to make room for a full install of FC10 on the larger disk in preparation for ultimately getting the winxp install running under a linux based VM.
From knoppix, I started by using ntfsresize to shrink the xp partition down to 20GB. That worked suprisingly fine. I then installed the smaller drive and used dd to copy over the image of the xp installation: dd if=/dev/hdb of=/dev/hda bs=10000000 count=2000
That was a bad idea. You've copied the MBR of hdb to the MBR of hda. That's why the hda disk "thinks" the disk is 150 GB. What you should do is zero the mbr of hda
dd if=/dev/zero of=/dev/hda bs=512 count=1
Then, use GParted (or whatever) to create a partition on hda (probably hda1) of the exact same size as the old XP partition (probably hdb1) You may as well partition the other 60 GB of hda at the same time.
Then, you should be able to do:
dd if=/dev/hdb1 of=/dev/hda1 bs=512
to copy over the XP partition.
As usual, you should do backups before such operations and understand the risks if you do not.
Matt Flaschen
Matthew Flaschen wrote:
Mikkel L. Ellertson wrote:
Tod Thomas wrote:
I know this is a little off topic. I did google around looking for the correct forum to post this question but had little luck. If anyone can make an informed suggestion I'd very much appreciate it.
I have a 150GB ATA disk, /dev/hdb, containing winxp. I'd like to move the contents to an spare 80GB ATA disk, /dev/hda, to make room for a full install of FC10 on the larger disk in preparation for ultimately getting the winxp install running under a linux based VM.
From knoppix, I started by using ntfsresize to shrink the xp partition down to 20GB. That worked suprisingly fine. I then installed the smaller drive and used dd to copy over the image of the xp installation: dd if=/dev/hdb of=/dev/hda bs=10000000 count=2000
That was a bad idea. You've copied the MBR of hdb to the MBR of hda. That's why the hda disk "thinks" the disk is 150 GB. What you should do is zero the mbr of hda
dd if=/dev/zero of=/dev/hda bs=512 count=1
Then, use GParted (or whatever) to create a partition on hda (probably hda1) of the exact same size as the old XP partition (probably hdb1) You may as well partition the other 60 GB of hda at the same time.
Then, you should be able to do:
dd if=/dev/hdb1 of=/dev/hda1 bs=512
to copy over the XP partition.
As usual, you should do backups before such operations and understand the risks if you do not.
Matt Flaschen
Thanks. I thought that recreating the partition using fdisk would have accomplished the same thing - no? If not what does the fdisk process I followed do or not do?
Tod
On Sat, 2009-02-28 at 16:25 -0500, Tod Thomas wrote:
Matthew Flaschen wrote:
Mikkel L. Ellertson wrote:
Tod Thomas wrote:
I know this is a little off topic. I did google around looking for the correct forum to post this question but had little luck. If anyone can make an informed suggestion I'd very much appreciate it.
I have a 150GB ATA disk, /dev/hdb, containing winxp. I'd like to move the contents to an spare 80GB ATA disk, /dev/hda, to make room for a full install of FC10 on the larger disk in preparation for ultimately getting the winxp install running under a linux based VM.
From knoppix, I started by using ntfsresize to shrink the xp partition down to 20GB. That worked suprisingly fine. I then installed the smaller drive and used dd to copy over the image of the xp installation: dd if=/dev/hdb of=/dev/hda bs=10000000 count=2000
That was a bad idea. You've copied the MBR of hdb to the MBR of hda. That's why the hda disk "thinks" the disk is 150 GB. What you should do is zero the mbr of hda
dd if=/dev/zero of=/dev/hda bs=512 count=1
Then, use GParted (or whatever) to create a partition on hda (probably hda1) of the exact same size as the old XP partition (probably hdb1) You may as well partition the other 60 GB of hda at the same time.
Then, you should be able to do:
dd if=/dev/hdb1 of=/dev/hda1 bs=512
to copy over the XP partition.
As usual, you should do backups before such operations and understand the risks if you do not.
Matt Flaschen
Thanks. I thought that recreating the partition using fdisk would have accomplished the same thing - no? If not what does the fdisk process I followed do or not do?
---- Just an FYI...
The anaconda installer on F10 allows you to resize NTFS partitions on the fly (as part of the installation process itself) so there really is no need for other tool kits but as Mikkel suggested before, it's really important to 'defrag' before you shrink an NTFS partition to minimize the likelihood of having files lost during the shrink process.
Craig
Craig White wrote:
Just an FYI...
The anaconda installer on F10 allows you to resize NTFS partitions on the fly (as part of the installation process itself) so there really is no need for other tool kits but as Mikkel suggested before, it's really important to 'defrag' before you shrink an NTFS partition to minimize the likelihood of having files lost during the shrink process.
Craig
In this case there is - he is moving the Windows install to a new, smaller drive, and using all of the current drive for Linux.
Mikkel
On Sat, 2009-02-28 at 16:14 -0600, Mikkel L. Ellertson wrote:
Craig White wrote:
Just an FYI...
The anaconda installer on F10 allows you to resize NTFS partitions on the fly (as part of the installation process itself) so there really is no need for other tool kits but as Mikkel suggested before, it's really important to 'defrag' before you shrink an NTFS partition to minimize the likelihood of having files lost during the shrink process.
Craig
In this case there is - he is moving the Windows install to a new, smaller drive, and using all of the current drive for Linux.
---- ok - sorry for intruding...carry on.
Craig
Tod Thomas wrote:
Thanks. I thought that recreating the partition using fdisk would have accomplished the same thing - no? If not what does the fdisk process I followed do or not do?
Tod
It will if you create a new partition table that reflects the new disk size, and do not copy the mbr from the larger disk. You will need to re-install the Windows boot loader to the mbr of the new drive, or install the Grub boot loader there, and use it to select Windows or Linux.
Mikkel
Mikkel L. Ellertson wrote:
Tod Thomas wrote:
Thanks. I thought that recreating the partition using fdisk would have accomplished the same thing - no? If not what does the fdisk process I followed do or not do?
Tod
It will if you create a new partition table that reflects the new disk size, and do not copy the mbr from the larger disk. You will need to re-install the Windows boot loader to the mbr of the new drive, or install the Grub boot loader there, and use it to select Windows or Linux.
Mikkel
Ok, I think I understand:
/dev/hda - spare 80GB drive /dev/hdb - old 150GB xp drive (primary partition ntfsresized to 20GB)
dd if=/dev/zero of=/dev/hda
fdisk /dev/hda - create new primary partition(hda1), bootable, type 7 (NTFS) - this then creates the windows MBR?
dd if=/dev/hdb1 of=/dev/hda1 bs=10000000 count=2000 - copies resized xp partition to new drive
Reboot to new drive and all is well. Defragging is factored in somewhere prior to this operation. I think upon reboot this will trigger xp to perform a chkdisk. Does this make sense?
- Tod
Tod Thomas wrote:
Mikkel L. Ellertson wrote:
Tod Thomas wrote:
Thanks. I thought that recreating the partition using fdisk would have accomplished the same thing - no? If not what does the fdisk process I followed do or not do?
Tod
It will if you create a new partition table that reflects the new disk size, and do not copy the mbr from the larger disk. You will need to re-install the Windows boot loader to the mbr of the new drive, or install the Grub boot loader there, and use it to select Windows or Linux.
Mikkel
Ok, I think I understand:
/dev/hda - spare 80GB drive /dev/hdb - old 150GB xp drive (primary partition ntfsresized to 20GB)
dd if=/dev/zero of=/dev/hda
This will write zero's to the entire drive - a bit excessive, and time consuming. Add count=1 to the command.
fdisk /dev/hda
- create new primary partition(hda1), bootable, type 7 (NTFS)
- this then creates the windows MBR?
It does not put the Windows boot loader one the drive, but it does create a new MBR.
dd if=/dev/hdb1 of=/dev/hda1 bs=10000000 count=2000
- copies resized xp partition to new drive
If the partitions are the same size, you should be able to do:
dd if=/dev/sdb1 of=/dev/sda1
But I still like using parted instead of dd for this. It will handle any differences between the partitions.
Reboot to new drive and all is well. Defragging is factored in somewhere prior to this operation. I think upon reboot this will trigger xp to perform a chkdisk. Does this make sense?
I would defrag before shrinking the partition, but I guess you have already shrunk it. You are also going to have to boot from the windows CD, start the recovery console, and run fixmbr. (Or you can do your Linux install, install Grub, and let it boot Windows/Linux.)
Mikkel
Mikkel L. Ellertson wrote:
Tod Thomas wrote:
Mikkel L. Ellertson wrote:
Tod Thomas wrote:
Thanks. I thought that recreating the partition using fdisk would have accomplished the same thing - no? If not what does the fdisk process I followed do or not do?
Tod
It will if you create a new partition table that reflects the new disk size, and do not copy the mbr from the larger disk. You will need to re-install the Windows boot loader to the mbr of the new drive, or install the Grub boot loader there, and use it to select Windows or Linux.
Mikkel
Ok, I think I understand:
/dev/hda - spare 80GB drive /dev/hdb - old 150GB xp drive (primary partition ntfsresized to 20GB)
dd if=/dev/zero of=/dev/hda
This will write zero's to the entire drive - a bit excessive, and time consuming. Add count=1 to the command.
fdisk /dev/hda
- create new primary partition(hda1), bootable, type 7 (NTFS)
- this then creates the windows MBR?
It does not put the Windows boot loader one the drive, but it does create a new MBR.
dd if=/dev/hdb1 of=/dev/hda1 bs=10000000 count=2000
- copies resized xp partition to new drive
If the partitions are the same size, you should be able to do:
dd if=/dev/sdb1 of=/dev/sda1
But I still like using parted instead of dd for this. It will handle any differences between the partitions.
Reboot to new drive and all is well. Defragging is factored in somewhere prior to this operation. I think upon reboot this will trigger xp to perform a chkdisk. Does this make sense?
I would defrag before shrinking the partition, but I guess you have already shrunk it. You are also going to have to boot from the windows CD, start the recovery console, and run fixmbr. (Or you can do your Linux install, install Grub, and let it boot Windows/Linux.)
Mikkel
Ok, great. Thanks everybody for the information.
- Tod
Tod Thomas wrote:
dd if=/dev/zero of=/dev/hda
As noted, this is greatly excessive. Do:
dd if=/dev/zero of=/dev/hda bs=512 count=1
dd if=/dev/hdb1 of=/dev/hda1 bs=10000000 count=2000
- copies resized xp partition to new drive
That's a bs bs, if you follow me. If you're going to use bs (byte-size) and count, use a sane value of bs like the the logical block size. Otherwise, just leave it out; there's no need.
Reboot to new drive and all is well.
As noted, you'll need to fix the MBR of hda with fixmbr (or use GRUB).
Defragging is factored in somewhere prior to this operation.
There is no need to defrag, since you've already done ntfsresize and are simply going to do a bit-for-bit copy from hdb1 to hda1. It might have helped to do a defrag /before/ ntfsresize (since you were "squeezing" the NTFS filesystem), but no point now.
I think upon reboot this will trigger xp to perform a chkdisk.
Possibly, due to the earlier ntfsresize.
Does this make sense?
Mostly.
Matt Flaschen
On Sat, Feb 28, 2009 at 12:05 PM, Tod Thomas fr33zone@gmail.com wrote:
I know this is a little off topic. I did google around looking for the correct forum to post this question but had little luck. If anyone can make an informed suggestion I'd very much appreciate it.
I have a 150GB ATA disk, /dev/hdb, containing winxp. I'd like to move the contents to an spare 80GB ATA disk, /dev/hda, to make room for a full install of FC10 on the larger disk in preparation for ultimately getting the winxp install running under a linux based VM.
From knoppix, I started by using ntfsresize to shrink the xp partition down to 20GB. That worked suprisingly fine. I then installed the smaller drive and used dd to copy over the image of the xp installation: dd if=/dev/hdb of=/dev/hda bs=10000000 count=2000
I rebooted and voila! it worked - sort of. The new disk boots xp but it still, according to fdisk, thinks its 150GB. So I used fdisk to delete and redefine the xp partition (primary, bootable type=7) with the new size of the drive, 20GB. After rebooting xp came up but then started quickly blue screening a message I couldn't read, and rebooting. This repeated in a loop until I just rebooted. I tried the whole process over again but this time specified 80GB to dd and fdisk, same disaster.
I tried everything again, but this time instead of fdisk I fired up gparted to see if I could resize from there hoping that if it could some magic would also fix the invalid sizing detected by fdisk. gparted could see the drive but couldn't recognize it as having anything it could work with. I highlighted the drive and the progress bar stayed gray.
So far it seems I can use the drive this way without causing xp any problems. The issue is things just don't look right and I suspect it will come back to bite me one day. I'm not an expert at manipulating bits on a hard drive just yet. Could someone point me to my error? Is what I'm trying do-able? If its a conceptual problem a little education would come in handy too.
I wouldn't use dd for this. Gparted has been more helpful to me in a situation similar to yours. Using Gparted (a) I'd first create a NTFS partition (make sure to create it As Primary), (b) copy the partition from the source drive to the target drive, and (c) if there's a problem booting the target drive with xp in it, use a winxp cd to go into rescue mode and use FIXMBR to fix the master boot record.
Gparted copies partitions pretty well.
~af
I use the g4u disk cloning tool for chores like this. Forget the 80 Gb spare drive. It is too small for what should be done. Instead get a new spare drive.
I make sure I have a spare disk of the same type, physical dimensions and capacity as the source disk and I use the g4u software to clone from the source drive to the spare. This is usually means putting the spare drive in an external drive enclosure which I know can be a chore.
When the cloning operation is done, I remove the source disk from the machine of interest and replace it with the spare disk. This lets me ensure that Windows XP boots. From then on all disk operations are done on this disk. The steps I follow are:
* Defragment the NTFS partition * Download the very latest gparted live cd and boot to it * Resize the ntfs partition with gparted. It is quite reliable. * Boot the resized NTFS partition. Windows XP will probably start chkdsk at boot time, and that can take a little while, but all should be well.
Once you are sure you can boot into XP, shut down the computer and install Fedora with the unallocated free space.
If something terrible happens...no problem! You still have the original disk. You can re-clone as needed.
Bob Cochran
Tod Thomas wrote:
I know this is a little off topic. I did google around looking for the correct forum to post this question but had little luck. If anyone can make an informed suggestion I'd very much appreciate it.
I have a 150GB ATA disk, /dev/hdb, containing winxp. I'd like to move the contents to an spare 80GB ATA disk, /dev/hda, to make room for a full install of FC10 on the larger disk in preparation for ultimately getting the winxp install running under a linux based VM.
From knoppix, I started by using ntfsresize to shrink the xp partition down to 20GB. That worked suprisingly fine. I then installed the smaller drive and used dd to copy over the image of the xp installation: dd if=/dev/hdb of=/dev/hda bs=10000000 count=2000
I rebooted and voila! it worked - sort of. The new disk boots xp but it still, according to fdisk, thinks its 150GB. So I used fdisk to delete and redefine the xp partition (primary, bootable type=7) with the new size of the drive, 20GB. After rebooting xp came up but then started quickly blue screening a message I couldn't read, and rebooting. This repeated in a loop until I just rebooted. I tried the whole process over again but this time specified 80GB to dd and fdisk, same disaster.
I tried everything again, but this time instead of fdisk I fired up gparted to see if I could resize from there hoping that if it could some magic would also fix the invalid sizing detected by fdisk. gparted could see the drive but couldn't recognize it as having anything it could work with. I highlighted the drive and the progress bar stayed gray.
So far it seems I can use the drive this way without causing xp any problems. The issue is things just don't look right and I suspect it will come back to bite me one day. I'm not an expert at manipulating bits on a hard drive just yet. Could someone point me to my error? Is what I'm trying do-able? If its a conceptual problem a little education would come in handy too.
Thanks in advance - Tod
On 02/28/2009 03:05 PM, Tod Thomas wrote:
I know this is a little off topic. I did google around looking for the correct forum to post this question but had little luck. If anyone can make an informed suggestion I'd very much appreciate it.
I have a 150GB ATA disk, /dev/hdb, containing winxp. I'd like to move the contents to an spare 80GB ATA disk, /dev/hda, to make room for a full install of FC10 on the larger disk in preparation for ultimately getting the winxp install running under a linux based VM.
From knoppix, I started by using ntfsresize to shrink the xp partition down to 20GB. That worked suprisingly fine. I then installed the smaller drive and used dd to copy over the image of the xp installation: dd if=/dev/hdb of=/dev/hda bs=10000000 count=2000
I rebooted and voila! it worked - sort of. The new disk boots xp but it still, according to fdisk, thinks its 150GB. So I used fdisk to delete and redefine the xp partition (primary, bootable type=7) with the new size of the drive, 20GB. After rebooting xp came up but then started quickly blue screening a message I couldn't read, and rebooting. This repeated in a loop until I just rebooted. I tried the whole process over again but this time specified 80GB to dd and fdisk, same disaster.
I tried everything again, but this time instead of fdisk I fired up gparted to see if I could resize from there hoping that if it could some magic would also fix the invalid sizing detected by fdisk. gparted could see the drive but couldn't recognize it as having anything it could work with. I highlighted the drive and the progress bar stayed gray.
So far it seems I can use the drive this way without causing xp any problems. The issue is things just don't look right and I suspect it will come back to bite me one day. I'm not an expert at manipulating bits on a hard drive just yet. Could someone point me to my error? Is what I'm trying do-able? If its a conceptual problem a little education would come in handy too.
I think that Tod got a lot of good solutions have been proposed. I just want to make some clarifications.
ntsfresize (and resize.e2fs, etc) resize file systems, not partitions. This is why fdisk things the disk is 150GB. fdisk only looks at the partition tables. So, resizing a partition is physically a 2-step operation that gparted, qtparted, et. al. do as if it were a single step. If you ever have to resize an LVM, it is much the same. To shring, first shrink the file system, then the logical volume, to make it larger, do just the opposite.
Please report your success once you have virtualized XP into F10, and what virtual manager you have used.
-
Aldo Foot -
Craig White -
Jerry Feldman -
Matthew Flaschen -
Mikkel -
Robert L Cochran -
Tod Thomas