Yes I see, "OS/Drive Imaging" (TroveTrove)
On Mon, 2008-04-28 at 12:32 -0400, William Case wrote:
> Hi;
> How do you move a whole system from the 40Gb drive to the new SATA
> drive?
= Simple Answer:
Ensure that the image you dd to the SATA drive includes the first
sectors (MBR, boot sectors, boot partition and loader in tact.)
So long as it's the same machine, disconnect the PATA drive (master
volume) and change the SATA drive in BIOS to become the primary boot
device and it should just work provided the BIOS drive is the same and
the boot loader drive numbering remains identical.
Linux should reassign the new drive to hda if it is now the primary BIOS
boot drive, unlike some other *nix which use the interface/channel as
probed in the hardware outside of BIOS drive numbering, even when you do
not have disks connected to the other channel.
Otherwise, it is a simple edit to "make it work" where you reassign
device specifiers in the boot-loader (grub) and then under the OS on the
imaged volume, updating mount points appropriately. If you are keeping
the other drive, you can just reinstall grub versus changing the boot
ordering in the BIOS and use the first disk to host the MBR for grub.
= Long Answer: -
There are numerous methods including:
1. Full Rebuild: Repartition/OS reinstall and then restore from
backup (safest?)
1. Your master volume is backed up and disconnected first
2. You then proceed to partition the new drive and reinstall the
OS/boot loader
3. Packages are re-installed, data and site specific configurations are
restored/copied
* If this seems like the long way around there are trade-offs:
- You might save some time using a direct imaging approach but it
can be limiting
- You don't get to do an update and repartition during hardware u/g
- You cannot be adequately thorough and look what is
installed/necessary if such a re-evaluation would otherwise amortize
well with the upgrade
- You might need to reinstall the bootloader anyway
- If your imaging technique is not adequately stringent you could
damage the master/source volume using partitioning or OS tools including
some Windows utilities that may at one point have become "confused" when
new drives were introduced to a system. Hopefully that is no longer the
case. "Always backup first" before trying to make a major OS change.
2. DD/imaging method
1. image the drive using dd and you might get the bootloader for free -
just change your BIOS drive boot order and/or disconnect the master PATA
volume after imaging to the new disk
2. Optional resizing of the partitions using tools such as ext2resize
allow you to grow the volumes to the larger disk, if you are using LVMs
you can also grow or shrink these logical volumes - but if not no
worries
- ext2resize and other file system/partitioning tools Recommends a
backup - however if there is a master volume in tact, this becomes your
master backup and the new drive is your working image
- You might also find GPart or Linux LiveCD's with these tools of
use
- You may need to install the bootloader even on an imaged volume,
unless it just happens to fit in the footprint of the previous install
including BIOS drive numbering (grub doesn't care which disk it was
loaded from, just as long as your drive spec is right, and you can
chainload Windows off any other drive.)
3. Dump and restore
No matter which method you choose, always ensure your master drive is
unmodified or read-only during the system transfer unless you have a
backup. This can include boot loader mangling, partitioning "troubles"
and other gotchas (below) that people don't always consider.
In the computer forensics field there is a tool called a: Write Block
which allows drives to be used read-only during imaging / blocks all
write instructions between the drive and the host. While primarily for
forensic purposes they are becoming affordable for commercial purposes.
Packages like Norton Ghost do not do any writing, so if you extract an
image to a network share first you are safe (it just depends how much
infrastructure/resources you got to spare.)
Most drives also have jumpers which prevent writes in the on-board drive
electronics, which you should reference your drive technical manual.
Though fiddling with jumpers might not always be wise in case you jumper
the "terminate" one next to 'WP' by mistake. (Hence the Write Block and
specialized data acquisition hardware.)
For this reason dd is the safest method over proprietary / commercial
disk tools which might take any number of inadvertent actions based on
the menu system unless/even if you are 100% confident and have read the
manual. This has been an ongoing concern with hardware RAID systems w/
inadequate documentation / poor disk labeling.
> I have seen techies with the box open and a new drive attached
> to a bus while 'something' was 'copying' the contents of the old drive
> to the new.
> I suspect that the copying was not files directly but an
> 'image ??' and that they might be using 'dd'.
Often they will just use commercial imaging tools. One such tool for
Windows is Norton Ghost. (Other suggestions such as OSS? Some people
prefer a GUI, but doesn't that mean that you are giving "macroscopic
oversight" to a detailed and painstaking task?) The single most common
concern with drive imaging is that the target volume is resized
appropriately.
> I am asking because I have read on some mailing lists (not ours) about
> people getting into trouble; needing exact match and pre-partioning etc.
> I have read the 'man' on 'dd' and it seems straight forward, but I am
> not sure.
As long as the bootloader and boot sectors remain in-tact then you
shouldn't have any difficulty with the dd approach. But this still
doesn't address the volume resizing issue, which you can carry out after
using a simple imaging tool.
> Is 'dd' the way to go about it? If so, is there any tips, traps or
> gotchas I have to watch out for?
1. dd from the wrong drive or get the devices reversed.. Oops!
2. potential for confusion: dd works on devices directly - it doesn't
care about partitions, you need to know the difference between a raw
device, a partition and a file system/logic volume which reside on each
disk partition.
3. install the bootloader onto the wrong drive/partition - doh! may not
be fatal of course.
4. use some sort of a windows tool to format a non-windows FS
ad nausea - I think the thing to note is that certain individuals only
make mistakes because the environment itself is not optimal.
> If 'dd' is not the right program, what
> is the usual way of doing this new disk installation? My motherboard is
> rigged for both IDE and SATA. Will there be a problem using 1 IDE/PATA
> disk and 1 SATA disk together?
Nope, not unless Windows makes it an issue, but that is a risk you run
by being multi-booted and was there before anyway.
> I have backup partitions on both drives,
> one to backup the other.
>
> Will Grub immediately recognize the new disk, or, do I have to fiddle
> with Grub? Grub fiddling is OK, if I am forewarned.
Yes, you will likely have to edit grub settings unless your BIOS drive
numbering is changed to make the SATA appear as the drive number your
PATA disk was assigned to.
Regards,
Allan Fields <afields [ at ] ncf [ dot ] ca>
= Tools Links, References:
* Ext2resize - http://ext2resize.sourceforge.net/
* http://gparted-livecd.tuxfamily.org/
* http://gparted.sourceforge.net/features.php (Feature Matrix of the
GParted)
* Managing RAID on Linux, O'Reilly - describes partitioning and
LVM/volume resize concepts among other references -
http://www.oreilly.com/catalog/mraidlinux/
* Symantec/Norton Ghost: http://www.symantec.com/themes/ghost/index.jsp
* Paragon: http://www.paragon-software.com/products.htm
* Write Block: http://www.cftt.nist.gov/hardware_write_block.htm
= Story on System imaging with GNU tools for non-Linux OS:
I imaged a Mac volume using GNU tools (felt really proud) and then
found out that my 120GB disk could only use a portion of the imaged
proprietary volume due to requiring a vendor specific tool to resize
MacOS X HFS+ partitions, which I thought Apple's tools would handle.
This has now changed in newer releases and disktool handles it for free
while Linux and other commercial *nix vendors have for years, but that
was a limiting experience that actually cost more time in the end than a
fresh install, though I got rid of a noisey old HDD. Even if you add
extra file systems, that still isn't the same as simply starting with a
bigger partition layout in a fresh install or using native supported
volume resize. AIX has their own scheme. Linux has LVM and
Solaris/FBSD has ZFS now.Yes I see, "OS/Drive Imaging" (TroveTrove)
On Mon, 2008-04-28 at 12:32 -0400, William Case wrote:
> Hi;
> How do you move a whole system from the 40Gb drive to the new SATA
> drive?
= Simple Answer:
Ensure that the image you dd to the SATA drive includes the first
sectors (MBR, boot sectors, boot partition and loader in tact.)
So long as it's the same machine, disconnect the PATA drive (master
volume) and change the SATA drive in BIOS to become the primary boot
device and it should just work provided the BIOS drive is the same and
the boot loader drive numbering remains identical.
Linux should reassign the new drive to hda if it is now the primary BIOS
boot drive, unlike some other *nix which use the interface/channel as
probed in the hardware outside of BIOS drive numbering, even when you do
not have disks connected to the other channel.
Otherwise, it is a simple edit to "make it work" where you reassign
device specifiers in the boot-loader (grub) and then under the OS on the
imaged volume, updating mount points appropriately. If you are keeping
the other drive, you can just reinstall grub versus changing the boot
ordering in the BIOS and use the first disk to host the MBR for grub.
= Long Answer: -
There are numerous methods including:
1. Full Rebuild: Repartition/OS reinstall and then restore from
backup (safest?)
1. Your master volume is backed up and disconnected first
2. You then proceed to partition the new drive and reinstall the
OS/boot loader
3. Packages are re-installed, data and site specific configurations are
restored/copied
* If this seems like the long way around there are trade-offs:
- You might save some time using a direct imaging approach but it
can be limiting
- You don't get to do an update and repartition during hardware u/g
- You cannot be adequately thorough and look what is
installed/necessary if such a re-evaluation would otherwise amortize
well with the upgrade
- You might need to reinstall the bootloader anyway
- If your imaging technique is not adequately stringent you could
damage the master/source volume using partitioning or OS tools including
some Windows utilities that may at one point have become "confused" when
new drives were introduced to a system. Hopefully that is no longer the
case. "Always backup first" before trying to make a major OS change.
2. DD/imaging method
1. image the drive using dd and you might get the bootloader for free -
just change your BIOS drive boot order and/or disconnect the master PATA
volume after imaging to the new disk
2. Optional resizing of the partitions using tools such as ext2resize
allow you to grow the volumes to the larger disk, if you are using LVMs
you can also grow or shrink these logical volumes - but if not no
worries
- ext2resize and other file system/partitioning tools Recommends a
backup - however if there is a master volume in tact, this becomes your
master backup and the new drive is your working image
- You might also find GPart or Linux LiveCD's with these tools of
use
- You may need to install the bootloader even on an imaged volume,
unless it just happens to fit in the footprint of the previous install
including BIOS drive numbering (grub doesn't care which disk it was
loaded from, just as long as your drive spec is right, and you can
chainload Windows off any other drive.)
3. Dump and restore
No matter which method you choose, always ensure your master drive is
unmodified or read-only during the system transfer unless you have a
backup. This can include boot loader mangling, partitioning "troubles"
and other gotchas (below) that people don't always consider.
In the computer forensics field there is a tool called a: Write Block
which allows drives to be used read-only during imaging / blocks all
write instructions between the drive and the host. While primarily for
forensic purposes they are becoming affordable for commercial purposes.
Packages like Norton Ghost do not do any writing, so if you extract an
image to a network share first you are safe (it just depends how much
infrastructure/resources you got to spare.)
Most drives also have jumpers which prevent writes in the on-board drive
electronics, which you should reference your drive technical manual.
Though fiddling with jumpers might not always be wise in case you jumper
the "terminate" one next to 'WP' by mistake. (Hence the Write Block and
specialized data acquisition hardware.)
For this reason dd is the safest method over proprietary / commercial
disk tools which might take any number of inadvertent actions based on
the menu system unless/even if you are 100% confident and have read the
manual. This has been an ongoing concern with hardware RAID systems w/
inadequate documentation / poor disk labeling.
> I have seen techies with the box open and a new drive attached
> to a bus while 'something' was 'copying' the contents of the old drive
> to the new.
> I suspect that the copying was not files directly but an
> 'image ??' and that they might be using 'dd'.
Often they will just use commercial imaging tools. One such tool for
Windows is Norton Ghost. (Other suggestions such as OSS? Some people
prefer a GUI, but doesn't that mean that you are giving "macroscopic
oversight" to a detailed and painstaking task?) The single most common
concern with drive imaging is that the target volume is resized
appropriately.
> I am asking because I have read on some mailing lists (not ours) about
> people getting into trouble; needing exact match and pre-partioning etc.
> I have read the 'man' on 'dd' and it seems straight forward, but I am
> not sure.
As long as the bootloader and boot sectors remain in-tact then you
shouldn't have any difficulty with the dd approach. But this still
doesn't address the volume resizing issue, which you can carry out after
using a simple imaging tool.
> Is 'dd' the way to go about it? If so, is there any tips, traps or
> gotchas I have to watch out for?
1. dd from the wrong drive or get the devices reversed.. Oops!
2. potential for confusion: dd works on devices directly - it doesn't
care about partitions, you need to know the difference between a raw
device, a partition and a file system/logic volume which reside on each
disk partition.
3. install the bootloader onto the wrong drive/partition - doh! may not
be fatal of course.
4. use some sort of a windows tool to format a non-windows FS
ad nausea - I think the thing to note is that certain individuals only
make mistakes because the environment itself is not optimal.
> If 'dd' is not the right program, what
> is the usual way of doing this new disk installation? My motherboard is
> rigged for both IDE and SATA. Will there be a problem using 1 IDE/PATA
> disk and 1 SATA disk together?
Nope, not unless Windows makes it an issue, but that is a risk you run
by being multi-booted and was there before anyway.
> I have backup partitions on both drives,
> one to backup the other.
>
> Will Grub immediately recognize the new disk, or, do I have to fiddle
> with Grub? Grub fiddling is OK, if I am forewarned.
Yes, you will likely have to edit grub settings unless your BIOS drive
numbering is changed to make the SATA appear as the drive number your
PATA disk was assigned to.
Regards,
Allan Fields <afields [ at ] ncf [ dot ] ca>
= Tools Links, References:
* Ext2resize - http://ext2resize.sourceforge.net/
* http://gparted-livecd.tuxfamily.org/
* http://gparted.sourceforge.net/features.php (Feature Matrix of the
GParted)
* Managing RAID on Linux, O'Reilly - describes partitioning and
LVM/volume resize concepts among other references -
http://www.oreilly.com/catalog/mraidlinux/
* Symantec/Norton Ghost: http://www.symantec.com/themes/ghost/index.jsp
* Paragon: http://www.paragon-software.com/products.htm
* Write Block: http://www.cftt.nist.gov/hardware_write_block.htm
= Story on System imaging with GNU tools for non-Linux OS:
I imaged a Mac volume using GNU tools (felt really proud) and then
found out that my 120GB disk could only use a portion of the imaged
proprietary volume due to requiring a vendor specific tool to resize
MacOS X HFS+ partitions, which I thought Apple's tools would handle.
This has now changed in newer releases and disktool handles it for free
while Linux and other commercial *nix vendors have for years, but that
was a limiting experience that actually cost more time in the end than a
fresh install, though I got rid of a noisey old HDD. Even if you add
extra file systems, that still isn't the same as simply starting with a
bigger partition layout in a fresh install or using native supported
volume resize. AIX has their own scheme. Linux has LVM and
Solaris/FBSD has ZFS now.