What is the best way to copy datas from an old dying HDD to a new HDD?
ANT...@zimage.com
It appears that my old Maxtor HDD (hdparm says: Model=Maxtor 53073U6, FwRev=DA620CQ0, SerialNo=K60BMHKC) is
dying (reads slower and slower these days). I need to copy all of its data to a new bigger HDD (not sure what
brand and size yet) soon.
What's the best way of doing this? I have never actually had to do this before. I usually do a clean
installation because it was already too late (did have data stored). Since the drive still works but slow, I
would like to keep the data while it is alive. Reinstalling and reconfiguring is a pain even if my important
datas backed up!
In Windows, I just use Norton Ghost (12/24/2003) via a DOS boot disk/CD to copy drives. It is very easy. Can
I do the same for Linux's EXT3 FS? It is currently running Debian (2.6.12-1-k7 #1 Tue Sep 27 13:22:07 JST
2005 i686 GNU/Linux). Her'es my partition setup on the old drive:
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda1 270969 171539 84974 67% /
tmpfs 518220 0 518220 0% /dev/shm
/dev/hda11 2324384 65660 2140648 3% /extra
/dev/hda5 14421344 4782236 8906548 35% /home
/dev/hda10 918322 16463 852863 2% /swap
/dev/hda8 918322 16538 852788 2% /tmp
/dev/hda6 4807056 2137356 2425516 47% /usr
/dev/hda9 4807056 185284 4377588 5% /usr/local
/dev/hda7 918322 280052 589274 33% /var
/dev/hdb1 861728 16420 801536 3% /stuff
/dev/hdb5 5336664 814760 4250812 17% /storage
tmpfs 10240 108 10132 2% /dev
Disk /dev/hda: 30.7 GB, 30735581184 bytes
255 heads, 63 sectors/track, 3736 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hda1 1 36 289138+ 83 Linux
/dev/hda2 37 3736 29720250 5 Extended
/dev/hda5 37 1860 14651248+ 83 Linux
/dev/hda6 1861 2468 4883728+ 83 Linux
/dev/hda7 2469 2590 979933+ 83 Linux
/dev/hda8 2591 2712 979933+ 83 Linux
/dev/hda9 2713 3320 4883728+ 83 Linux
/dev/hda10 3321 3442 979933+ 83 Linux
/dev/hda11 3443 3736 2361523+ 83 Linux
Disk /dev/hdb: 6448 MB, 6448619520 bytes
255 heads, 63 sectors/track, 784 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hdb1 1 109 875511 83 Linux
/dev/hdb2 110 784 5421937+ 5 Extended
/dev/hdb5 110 784 5421906 83 Linux
As you can see, I have two HDDs. The second HDD is just a storage area for archives. It will not be used for
backing up data. Hence why I need to buy a bigger drive.
If I do use Ghost to copy the old partitions and datas, how will Ghost handle the bigger disk size on the new
HDD? Will it expand partitions? Keep the same sizes and leave the unformatted area?
Thank you in advance. :)
--
Allah's Apostle said, "Once while a prophet amongst the prophets was taking a rest underneath a tree, an ant bit him. He, therefore, ordered that his luggage be taken away from underneath that tree and then ordered that the dwelling place of the ants should be set on fire. Allah sent him a revelation: 'Wouldn't it have been sufficient to burn a single ant (that bit you)?'" --Translation of Sahih Bukhari, Book 54, Number 536
/\___/\
/ /\ /\ \ Phillip (Ant) @ http://antfarm.ma.cx (Personal Web Site)
| |o o| | Ant's Quality Foraged Links (AQFL): http://aqfl.net
\ _ / Please remove ANT if replying by e-mail.
( )
Nico Kadel-Garcia
<ANT...@zimage.com> wrote in message
news:FqSdnfiAJIW...@mminternet.net...
First, make a backup of your OS disk by hook or by crook. Anytime you start
playing with disk images and are unfamiliar with the tools, it's very easy
to accidentally wipe the wrong disk. There's plenty of space on your second
disk to make an "rsync" image of the used partitions of your first disk: do
it so you have a backup to work with.
You will potentially want to re-arrange or reset your partitions in any case
for a newly installed OS. Instead, once you have that OS image backed up to
your second disk, install a much larger first disk with an installation or
rescue disk or the Knoppix live CD, partition it the way you want, copy back
the OS image and maybe the other spare disk data to the much larger first
disk, and edit the /etc/fstab of the OS image to the new partition layout.
Edit the OS image's /boot/grub/grub.conf to match, and do a "chroot
/mntpoint grub-install /dev/hda", then take out the CD and reboot.
I've installed roughly 15,000 machines using OS tarballs this way. It's
pretty efficient, and you can use the OS image as a template for making new
network install tarballs.
ray
Don't mount it. Use dd to read the partition(s) and make a disk file. You
can then 'loop' mount the file and read all the data. The exact dd command
will be something like:
dd if=/dev/hda9 of=/nameofoutputfile conv=noerror conv=sync
noerror keeps going if it encounters read errors and sync fills in any bad
blocks with zeroes so things don't get all jumbled.
ANT...@zimage.com
I am not familiar with hook command. Reading man guide seems to show it as a programming
debugger or something. I tried to install crook via apt-get but it didn't exist.
http://packages.debian.org/cgi-bin/search_packages.pl?keywords=crook&searchon=names&subword=1&version=all&release=all
resulted nothing on crook.
> playing with disk images and are unfamiliar with the tools, it's very easy
> to accidentally wipe the wrong disk. There's plenty of space on your second
> disk to make an "rsync" image of the used partitions of your first disk: do
> it so you have a backup to work with.
I don't see how I can copy all those datas to the 6.4 GB HDD. I would need about 7-8 GB which
doesn't exist on the second smaller HDD (5 GB free or so).
My plan was just to disconnect the small 6.4 GB drive. Hook up the new drive as the second
drive. Then, copy everything from old hda to new hdb (new HDD). Swap them when done, hook up the
old 6.4 GB HDD and hope everything works again.
> You will potentially want to re-arrange or reset your partitions in any case
> for a newly installed OS. Instead, once you have that OS image backed up to
> your second disk, install a much larger first disk with an installation or
> rescue disk or the Knoppix live CD, partition it the way you want, copy back
> the OS image and maybe the other spare disk data to the much larger first
> disk, and edit the /etc/fstab of the OS image to the new partition layout.
> Edit the OS image's /boot/grub/grub.conf to match, and do a "chroot
> /mntpoint grub-install /dev/hda", then take out the CD and reboot.
Hmm, this sounds really complex. Aren't there automated scripts or GUI programs to do this
migration easily? I prefer not to tamper with my existing partitions. Can't I just use some
partition resizer (PartitinoMagic v8.0?) programs to adjust the partitions after the migration?
> I've installed roughly 15,000 machines using OS tarballs this way. It's
> pretty efficient, and you can use the OS image as a template for making new
> network install tarballs.
Yeah, I am not experienced with this. :) In Windows/DOS, it's easy with Ghost, PartitionMagic,
etc. It seems very different with Linux. :(
ANT...@zimage.com
Can't I just do a direct disk image copy from old HDD to new HDD directly like in Norton Ghost?
Why bother with making a disk image? :)
Basically, my plan was to disconnect the 6.4 GB small HDD. Hook up the new big HDD. Copy all
datas from old slow HDD to the new HDD directly with some disk image tool (e.g., Norton Ghost)
via a 3.5" boot disk or a bootable CD.
Nico Kadel-Garcia
<ANT...@zimage.com> wrote in message
news:rqSdnefBMPD...@mminternet.net...
> In comp.os.linux.setup Nico Kadel-Garcia <nka...@comcast.net> wrote:
>> First, make a backup of your OS disk by hook or by crook. Anytime you
>> start
>
> I am not familiar with hook command. Reading man guide seems to show it as
> a programming
> debugger or something. I tried to install crook via apt-get but it didn't
> exist.
> http://packages.debian.org/cgi-bin/search_packages.pl?keywords=crook&searchon=names&subword=1&version=all&release=all
> resulted nothing on crook.
Oh, my. English is not your native language, I suspect. "by hook or by
crook" means "by any means possible", it's a very old phrase.
>> playing with disk images and are unfamiliar with the tools, it's very
>> easy
>> to accidentally wipe the wrong disk. There's plenty of space on your
>> second
>> disk to make an "rsync" image of the used partitions of your first disk:
>> do
>> it so you have a backup to work with.
>
> I don't see how I can copy all those datas to the 6.4 GB HDD. I would need
> about 7-8 GB which
> doesn't exist on the second smaller HDD (5 GB free or so).
Ahh. I mis-added, thank you for correcting me. I thought there was plenty of
space left.
> My plan was just to disconnect the small 6.4 GB drive. Hook up the new
> drive as the second
> drive. Then, copy everything from old hda to new hdb (new HDD). Swap them
> when done, hook up the
> old 6.4 GB HDD and hope everything works again.
That can work, but "swapping them when done" can be a bit of an adventure if
you're not comfortable with editing your grub files or your fstab yourself.
I'd be inclined to use the big disk as hda, and use a rescue CD or a liveCD
to image the old material to the new disk. And I'd make absolutely sure to
have some form of offline backup while this is going on, because it's easy
to type the wrong command and blow up your data.
>> You will potentially want to re-arrange or reset your partitions in any
>> case
>> for a newly installed OS. Instead, once you have that OS image backed up
>> to
>> your second disk, install a much larger first disk with an installation
>> or
>> rescue disk or the Knoppix live CD, partition it the way you want, copy
>> back
>> the OS image and maybe the other spare disk data to the much larger first
>> disk, and edit the /etc/fstab of the OS image to the new partition
>> layout.
>> Edit the OS image's /boot/grub/grub.conf to match, and do a "chroot
>> /mntpoint grub-install /dev/hda", then take out the CD and reboot.
>
> Hmm, this sounds really complex. Aren't there automated scripts or GUI
> programs to do this
> migration easily? I prefer not to tamper with my existing partitions.
> Can't I just use some
> partition resizer (PartitinoMagic v8.0?) programs to adjust the partitions
> after the migration?
You can waste a lot of time and effort re-adjusting partitions. Some folks
think you benefit from having lots of individual partitions: I gave up on
that approach over 5 years ago, becuase I wound up switching machines from
one use to another and generating huge /usr/src one day, /var/spool another,
/home on a third day, etc.
>> I've installed roughly 15,000 machines using OS tarballs this way. It's
>> pretty efficient, and you can use the OS image as a template for making
>> new
>> network install tarballs.
>
> Yeah, I am not experienced with this. :) In Windows/DOS, it's easy with
> Ghost, PartitionMagic,
> etc. It seems very different with Linux. :(
PartitionMagic and Ghost are cool and cute: But they do some very, very
stupid things like *renumbering* your partitions to be out of order when you
least expect it. (Partition Magic does this in particular.) There are some
tools for resizing Linux partitions, but they tend to be a lot slower than
building a partition and doing a "tar" or "rsync" duplication.
Michael Heiming
>> > It appears that my old Maxtor HDD (hdparm says: Model=Maxtor 53073U6, FwRev=DA620CQ0, SerialNo=K60BMHKC) is
>> > dying (reads slower and slower these days). I need to copy all of its data to a new bigger HDD (not sure what
>> > brand and size yet) soon.
[..]
>> > If I do use Ghost to copy the old partitions and datas, how will Ghost handle the bigger disk size on the new
>> > HDD? Will it expand partitions? Keep the same sizes and leave the unformatted area?
>> Don't mount it. Use dd to read the partition(s) and make a disk file. You
>> can then 'loop' mount the file and read all the data. The exact dd command
>> will be something like:
>> dd if=/dev/hda9 of=/nameofoutputfile conv=noerror conv=sync
> Can't I just do a direct disk image copy from old HDD to new HDD directly like in Norton Ghost?
> Why bother with making a disk image? :)
> Basically, my plan was to disconnect the 6.4 GB small HDD. Hook up the new big HDD. Copy all
> datas from old slow HDD to the new HDD directly with some disk image tool (e.g., Norton Ghost)
> via a 3.5" boot disk or a bootable CD.
Why would you need any tool for it? Simply plugin the disk,
create partitions to your needs, create fs, mount them somewhere
and rsync the stuff over, done. A fresh backup of your data is
always a good idea before proceeding.
Good luck
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 249: Unfortunately we have run out of
bits/bytes/whatever. Don't worry, the next supply will be...
dog...@noemail.com
Take a look at the dd command (man dd). If your distro has it. Its
often not the greatest and I'd recommend having an exactly same
size drive that youre dd'ng to. Plus, at least in solaris, you'd
ultimately want to format the drive exactly the same as that of
the drive youre copying from. But it may help.
Also, I find disk dupers to be much more efficient than ghost
as well as more
costly. However if youre in a shop that does alot of replication
its worth the purchase. Just remember to ensure that youre dupes
are using the same hardware, then you'll not have to worry about
hardware updates/patches/drivers etc. Check out logicube.com,
its truly worth the investment. Oh, and I've timed the dupe process
and you'll roughly save around 30 minutes to an hour using a
duper over ghost.
dogdog
ray
Because the subject line indicated that the disk is dying. If it isn't,
then there is no problem. A simple straight-forward copy will do fine.
ANT...@zimage.com
> >> start
> >
> > I am not familiar with hook command. Reading man guide seems to show it as
> > a programming
> > debugger or something. I tried to install crook via apt-get but it didn't
> > exist.
> > http://packages.debian.org/cgi-bin/search_packages.pl?keywords=crook&searchon=names&subword=1&version=all&release=all
> > resulted nothing on crook.
> Oh, my. English is not your native language, I suspect. "by hook or by
> crook" means "by any means possible", it's a very old phrase.
Ahhh. Thanks for the explaination. Actually, English is my native language but I never heard of
that one before. It must be an old generation saying. :)
> >> playing with disk images and are unfamiliar with the tools, it's very
> >> easy
> >> to accidentally wipe the wrong disk. There's plenty of space on your
> >> second
> >> disk to make an "rsync" image of the used partitions of your first disk:
> >> do
> >> it so you have a backup to work with.
> >
> > I don't see how I can copy all those datas to the 6.4 GB HDD. I would need
> > about 7-8 GB which
> > doesn't exist on the second smaller HDD (5 GB free or so).
> Ahh. I mis-added, thank you for correcting me. I thought there was plenty of
> space left.
No problems. I thought you were crazy or something. [grin]
> > My plan was just to disconnect the small 6.4 GB drive. Hook up the new
> > drive as the second
> > drive. Then, copy everything from old hda to new hdb (new HDD). Swap them
> > when done, hook up the
> > old 6.4 GB HDD and hope everything works again.
> That can work, but "swapping them when done" can be a bit of an adventure if
> you're not comfortable with editing your grub files or your fstab yourself.
Shouldn't GRUB autodetect these partition changes? I thought the whole point of disk copy was
basically the exact copy of the original (maybe partition sizes changed if there were any during
the image copy)? Or is this different in Linux's world? Again, this is all new to me. :)
> I'd be inclined to use the big disk as hda, and use a rescue CD or a liveCD
> to image the old material to the new disk. And I'd make absolutely sure to
> have some form of offline backup while this is going on, because it's easy
> to type the wrong command and blow up your data.
Hmmm, good point. I do have a bootable KNOPPIX v4.1 CD (not DVD). I hope that's enough with its
tools. Is there an instruction on how to use it to do what I want to do?
And yes, I do have my important datas backed up (my work!).
> >> You will potentially want to re-arrange or reset your partitions in any
> >> case
> >> for a newly installed OS. Instead, once you have that OS image backed up
> >> to
> >> your second disk, install a much larger first disk with an installation
> >> or
> >> rescue disk or the Knoppix live CD, partition it the way you want, copy
> >> back
> >> the OS image and maybe the other spare disk data to the much larger first
> >> disk, and edit the /etc/fstab of the OS image to the new partition
> >> layout.
> >> Edit the OS image's /boot/grub/grub.conf to match, and do a "chroot
> >> /mntpoint grub-install /dev/hda", then take out the CD and reboot.
> >
> > Hmm, this sounds really complex. Aren't there automated scripts or GUI
> > programs to do this
> > migration easily? I prefer not to tamper with my existing partitions.
> > Can't I just use some
> > partition resizer (PartitinoMagic v8.0?) programs to adjust the partitions
> > after the migration?
> You can waste a lot of time and effort re-adjusting partitions. Some folks
> think you benefit from having lots of individual partitions: I gave up on
> that approach over 5 years ago, becuase I wound up switching machines from
> one use to another and generating huge /usr/src one day, /var/spool another,
> /home on a third day, etc.
Well, I don't really need to resize my current partition setup. I can use the extra space for
a new partition or something.
> >> I've installed roughly 15,000 machines using OS tarballs this way. It's
> >> pretty efficient, and you can use the OS image as a template for making
> >> new
> >> network install tarballs.
> >
> > Yeah, I am not experienced with this. :) In Windows/DOS, it's easy with
> > Ghost, PartitionMagic, etc. It seems very different with Linux. :(
> PartitionMagic and Ghost are cool and cute: But they do some very, very
> stupid things like *renumbering* your partitions to be out of order when you
> least expect it. (Partition Magic does this in particular.) There are some
> tools for resizing Linux partitions, but they tend to be a lot slower than
> building a partition and doing a "tar" or "rsync" duplication.
Interesting. I just need a quick and easy way to do this due to: 1) Lack of free time and 2)
newbie. :)
ANT...@zimage.com
I have dd command already installed in Debian/Linux (Kernel 2.6.12-K7):
# dd --version
dd (coreutils) 5.93
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software. You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.
Written by Paul Rubin, David MacKenzie, and Stuart Kemp.
What parameters do I want to use? Let's say I want to copy old dying HDD (hda) to new HDD (hdb)?
Would it be dd /dev/hda /dev/hdb? I assume I cannot do this in Debian and I will have to use
KNOPPIX v4.1 or some other LiveCD. Am I correct? Like I said earlier, I am a newbie so this is
all new to me. :)
I highly doubt I will be able to find the same size HDD. The old HDD is from 1999 or so! Hence,
why it is dying. Maybe I will end up with a Seagate 250 GB HDD (7200 RPM; IDE).
> Also, I find disk dupers to be much more efficient than ghost
> as well as more
Interesting.
> costly. However if youre in a shop that does alot of replication
> its worth the purchase. Just remember to ensure that youre dupes
> are using the same hardware, then you'll not have to worry about
> hardware updates/patches/drivers etc. Check out logicube.com,
> its truly worth the investment. Oh, and I've timed the dupe process
> and you'll roughly save around 30 minutes to an hour using a
> duper over ghost.
Nope, I am just a basic user. Basically, it is my workstation (backup machine if my other
computers have issues) private little server. I like having variety of operating systems. I have
Windows (95 to XP) and Mac OS X 10.2.8 as well.
ANT...@zimage.com
> In comp.os.linux.setup ANT...@zimage.com:
> >> > It appears that my old Maxtor HDD (hdparm says: Model=Maxtor 53073U6, FwRev=DA620CQ0, SerialNo=K60BMHKC) is
> >> > dying (reads slower and slower these days). I need to copy all of its data to a new bigger HDD (not sure what
> >> > brand and size yet) soon.
> [..]
> >> > If I do use Ghost to copy the old partitions and datas, how will Ghost handle the bigger disk size on the new
> >> > HDD? Will it expand partitions? Keep the same sizes and leave the unformatted area?
> >> Don't mount it. Use dd to read the partition(s) and make a disk file. You
> >> can then 'loop' mount the file and read all the data. The exact dd command
> >> will be something like:
> >> dd if=/dev/hda9 of=/nameofoutputfile conv=noerror conv=sync
> > Can't I just do a direct disk image copy from old HDD to new HDD directly like in Norton Ghost?
> > Why bother with making a disk image? :)
> > Basically, my plan was to disconnect the 6.4 GB small HDD. Hook up the new big HDD. Copy all
> > datas from old slow HDD to the new HDD directly with some disk image tool (e.g., Norton Ghost)
> > via a 3.5" boot disk or a bootable CD.
> Why would you need any tool for it? Simply plugin the disk,
> create partitions to your needs, create fs, mount them somewhere
> and rsync the stuff over, done. A fresh backup of your data is
> always a good idea before proceeding.
I prefer to do a disk copy if possible so I don't have to deal with reinstalling, reconfiguring,
recopy, etc. Lack of time is my problem. :I
Unruh
>> > My plan was just to disconnect the small 6.4 GB drive. Hook up the new
>> > drive as the second
>> > drive. Then, copy everything from old hda to new hdb (new HDD). Swap them
>> > when done, hook up the
>> > old 6.4 GB HDD and hope everything works again.
>> That can work, but "swapping them when done" can be a bit of an adventure if
>> you're not comfortable with editing your grub files or your fstab yourself.
>Shouldn't GRUB autodetect these partition changes? I thought the whole point of disk copy was
No. It cannot "autodetect" It is a low level program. You have to specify.
>basically the exact copy of the original (maybe partition sizes changed if there were any during
>the image copy)? Or is this different in Linux's world? Again, this is all new to me. :)
And locations on the disk that need to be loaded.
The tiny stub of a program stuck into the mbr ( a few bytes long) MUST use
the bios disk commands to load from an absolute memory location on the disk
the main grub loader. It has zero ability to do or find anything.
It MUST have the correct absolute location programmed in. An absolute
location which will have almost certainly changed when you changed the
disk.
No.
Michael Heiming
> In comp.os.linux.setup Michael Heiming <michael...@www.heiming.de> wrote:
>> In comp.os.linux.setup ANT...@zimage.com:
>> >> > It appears that my old Maxtor HDD (hdparm says:
>> >> > Model=Maxtor 53073U6, FwRev=DA620CQ0, SerialNo=K60BMHKC)
>> >> > is dying (reads slower and slower these days). I need to
>> >> > copy all of its data to a new bigger HDD (not sure what
>> >> > brand and size yet) soon.
[ snip stuff + line length fixed ]
>> Why would you need any tool for it? Simply plugin the disk,
>> create partitions to your needs, create fs, mount them somewhere
>> and rsync the stuff over, done. A fresh backup of your data is
>> always a good idea before proceeding.
> I prefer to do a disk copy if possible so I don't have to deal
> with reinstalling, reconfiguring, recopy, etc. Lack of time is
> my problem. :I
Sorry, but what do you have to reinstall/reconfigure? Presuming
you make the same partitions, size can be different and take out
the old hd, and change the new to be what the old was, there's
nothing to reinstall/reconfigure, despite rerunning 'lilo' which
takes hardly more then 2 seconds.
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 380: Operators killed when huge stack of backup
tapes fell over.
dog...@noemail.com
I guess the real question would be "what information do you want
to save from the old disk?"
If its just directories you could tar them up and write them out
to cd (burn a cd). Then reload a new disk with a fresh OS install.
I read over the entire post and I'm not clear on what you exactly
need from the old disk.
Also, check this out, it explains the dd and how to use it with
non-exact hdd. http://www.linuxplanet.com/linuxplanet/tutorials/986/4/
That should be about all you need. Plus dont forget to read the
man dd to better understand it.
Remember its linux so theres more than one way to do everything. Its
just a matter of experimenting and so forth.
Hope that helps
dogdog
ANT...@zimage.com
> >> > My plan was just to disconnect the small 6.4 GB drive. Hook up the new
> >> > drive as the second
> >> > drive. Then, copy everything from old hda to new hdb (new HDD). Swap them
> >> > when done, hook up the
> >> > old 6.4 GB HDD and hope everything works again.
> >> That can work, but "swapping them when done" can be a bit of an adventure if
> >> you're not comfortable with editing your grub files or your fstab yourself.
> >Shouldn't GRUB autodetect these partition changes? I thought the whole point of disk copy was
> No. It cannot "autodetect" It is a low level program. You have to specify.
Great.
> >basically the exact copy of the original (maybe partition sizes changed if there were any during
> >the image copy)? Or is this different in Linux's world? Again, this is all new to me. :)
> And locations on the disk that need to be loaded.
> The tiny stub of a program stuck into the mbr ( a few bytes long) MUST use
> the bios disk commands to load from an absolute memory location on the disk
> the main grub loader. It has zero ability to do or find anything.
> It MUST have the correct absolute location programmed in. An absolute
> location which will have almost certainly changed when you changed the
> disk.
How would I fix this after copying over?
> No.
ANT...@zimage.com
> >> >> > Model=Maxtor 53073U6, FwRev=DA620CQ0, SerialNo=K60BMHKC)
> >> >> > is dying (reads slower and slower these days). I need to
> >> >> > copy all of its data to a new bigger HDD (not sure what
> >> >> > brand and size yet) soon.
> [ snip stuff + line length fixed ]
> >> Why would you need any tool for it? Simply plugin the disk,
> >> create partitions to your needs, create fs, mount them somewhere
> >> and rsync the stuff over, done. A fresh backup of your data is
> >> always a good idea before proceeding.
> > I prefer to do a disk copy if possible so I don't have to deal
> > with reinstalling, reconfiguring, recopy, etc. Lack of time is
> > my problem. :I
> Sorry, but what do you have to reinstall/reconfigure? Presuming
> you make the same partitions, size can be different and take out
> the old hd, and change the new to be what the old was, there's
> nothing to reinstall/reconfigure, despite rerunning 'lilo' which
> takes hardly more then 2 seconds.
From the other reply, it sounded like I have to install new OS and make new partitions on the
new drive. Then, copy old datas from the old drive to overwrite the new installation.
I don't use lilo though. I use Grub.
Michael Heiming
[ replace root hard disk ]
> From the other reply, it sounded like I have to install new OS
> and make new partitions on the new drive. Then, copy old datas
> from the old drive to overwrite the new installation.
Nope, there's no need, you can just copy the stuff over and
reinstall your bootloader on the new disk.
> I don't use lilo though. I use Grub.
Doesn't matter, you have to reinstall grub if you want to boot of
the new hd.
Try this howto, not that new but looks still usable:
http://www.tldp.org/HOWTO/Hard-Disk-Upgrade/
Exchange 'mkfs.ext2' with 'mkfs.ext3' if creating fs. Again a
complete backup (USB hd/etc) should be your first step.
Good luck
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 296: The hardware bus needs a new token.
Nico Kadel-Garcia
<ANT...@zimage.com> wrote in message
news:_sGdnY7WRelFjQbe...@mminternet.net...
Umm. dd duplications are notoriously slow: because they duplicate the
contant of *deleted* files and no-longer-used blocks, they are notoriously
inefficient. And if your drive is starting to fail, it can get stuck at the
bad block and repeatedly fail because of the bad block or blocks, even if
that block is from a single file or two that you don't really need.
That's why I like using rsync or tar.gz techniques for duplicating the
contents of the file system, not the raw blocks.
Nico Kadel-Garcia
"Michael Heiming" <michael...@www.heiming.de> wrote in message
news:reqr63-...@news.heiming.de...
> In comp.os.linux.setup ANT...@zimage.com:
>
> [ replace root hard disk ]
>
>> From the other reply, it sounded like I have to install new OS
>> and make new partitions on the new drive. Then, copy old datas
>> from the old drive to overwrite the new installation.
>
> Nope, there's no need, you can just copy the stuff over and
> reinstall your bootloader on the new disk.
>
>> I don't use lilo though. I use Grub.
>
> Doesn't matter, you have to reinstall grub if you want to boot of
> the new hd.
>
> Try this howto, not that new but looks still usable:
>
> http://www.tldp.org/HOWTO/Hard-Disk-Upgrade/
>
> Exchange 'mkfs.ext2' with 'mkfs.ext3' if creating fs. Again a
> complete backup (USB hd/etc) should be your first step.
>
> Good luck
If he winds up re-arranging the disks, then trying to run grub, then it can
be an issue.
Michael Heiming
What issue? Don't use grub, but it can and must be reinstalled in
this case, 'grub-install' or so the man page should tell.
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 264: Your modem doesn't speak English.
Alan Adams
"Nico Kadel-Garcia" <nka...@comcast.net> wrote:
So, to clarify things for me, and maybe the OP as well, it sounds as if it's
possible to copy the installed copy of Linux to another disc, while running
that copy of Linux? (And then edit the Grup or Lilo boot program to now what
you've done).
That most definitely isn't possible with Windows, and may be causing the OP
to think he has to reinstall or Ghost - the two ways to do it with Windows.
Does anyone know (off-topic a bit) whether Windows Ghost can copy
non-Windows file systems? Looking at the help the other day there seemed to
be a command-line switch to handle discs "raw".
--
Alan Adams
alan....@orchard-way.freeserve.co.uk
http://www.nckc.org.uk/
Michael Heiming
>> "Michael Heiming" <michael...@www.heiming.de> wrote in message
>> > [ replace root hard disk ]
>> > Try this howto, not that new but looks still usable:
>> >
>> > http://www.tldp.org/HOWTO/Hard-Disk-Upgrade/
>> >
>> > Exchange 'mkfs.ext2' with 'mkfs.ext3' if creating fs. Again a
>> > complete backup (USB hd/etc) should be your first step.
[..]
> So, to clarify things for me, and maybe the OP as well, it
> sounds as if it's possible to copy the installed copy of Linux
> to another disc, while running that copy of Linux? (And then
> edit the Grup or Lilo boot program to now what you've done).
Sure it is possible, even remote through the network. And there's
nothing special about it, any unix can do it since decades and
there are several ways to clone a system.
> That most definitely isn't possible with Windows, and may be
> causing the OP to think he has to reinstall or Ghost - the two
> ways to do it with Windows.
You can take the hd out of an installed Linux box and put it into
another (different) and the system will boot just fine, some
pop-ups might tell you that some hardware changed and if you'd
like to accept changes, that's all. The box will run as usual.
You are welcome!
[..]
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 87: Password is too complex to decrypt
Enrique Perez-Terron
>> > It appears that my old Maxtor HDD (hdparm says: Model=Maxtor 53073U6,> FwRev=DA620CQ0, SerialNo=K60BMHKC) is
>> > dying (reads slower and slower these days). I need to copy all of its> data to a new bigger HDD (not sure what
>> > brand and size yet) soon.
Slower and slower? How is that possible? It makes me think that the controller
is getting lots of read errors, and so is retrying over and over. It could mean
data corruption is imminent. Hurry up.
[...]
>> > $ df
>> > Filesystem 1K-blocks Used Available Use% Mounted on
>> > /dev/hda1 270969 171539 84974 67% /
>> > tmpfs 518220 0 518220 0% /dev/shm
>> > /dev/hda11 2324384 65660 2140648 3% /extra
>> > /dev/hda5 14421344 4782236 8906548 35% /home
>> > /dev/hda10 918322 16463 852863 2% /swap
>> > /dev/hda8 918322 16538 852788 2% /tmp
>> > /dev/hda6 4807056 2137356 2425516 47% /usr
>> > /dev/hda9 4807056 185284 4377588 5% /usr/local
>> > /dev/hda7 918322 280052 589274 33% /var
>> > /dev/hdb1 861728 16420 801536 3% /stuff
>> > /dev/hdb5 5336664 814760 4250812 17% /storage
>> > tmpfs 10240 108 10132 2% /dev
[...]
>> Don't mount it. Use dd to read the partition(s) and make a disk file. You
>> can then 'loop' mount the file and read all the data. The exact dd command
>> will be something like:
>>
>> dd if=/dev/hda9 of=/nameofoutputfile conv=noerror conv=sync
>
> Can't I just do a direct disk image copy from old HDD to new HDD directly like in Norton Ghost?
> Why bother with making a disk image? :)
You can, I think. Just follow this piece of wild heresy:
First, I suggest you connect the new drive as hdc, not hdb, because
IDE controllers are not able to run disk transactions on the master
and slave device in parallel. In other words, you save a few seconds
using hdc. Next, because you plan to connect the new disk as hda,
that is, as master. By provisionally making it master on the secondary
ide channel, you don't have to remember to change the master/slave
setting on the disk.
Then, run the command
dd if=/dev/hda of=/dev/hdc conv=noerror conv=sync bs=1M
Just don't mix up "if" and "of"!!!!
This will copy the partition table(s) and all, so when you move
the new disk to the primary ide, it will appear with all the paritions
you used to have. Even the boot loader will be happy because it will
find everything at the same sector address as before.
Your new disk must be at least as large as the old one. If it is
larger, it will have unpartitioned space at the end. You can use
this space however you like, creating additional partitions or moving
partitions around and growing their size.
There are two things that can go wrong here: First, if there are
disk read errors during the copy, and the errors affect e.g. the
partition table, the partition table on the new disk will appear
dammaged or even unusable. However, if this happens, anything else
you could have done would also have been prone to to fail. You
simply lost the race to replace the disk before the growing disk
defects made it impossible. Second, this is somewhat academic,
the new disk may have a different exported disk geometry, and some
operations may depend on the geometry. Academic, because nowadays
all new disks have 63 sectors/track and 255 tracks/cylinder. Both
your existing disks have that. Also, nowadays all systems use
LBA ("Logical block addressing"), meaning they rely on sector numbers
exclusively, even the BIOS.
Assuming there is no errors, you can take out the old disk, put the
new disk in its place, and keep the old disk as a backup during the
first days. If something goes completely wrong, just swap the old
disk back in as hda the new one again as hdc, and repeat.
-----
That said, Ray's suggestion has its merits. I think he should have
explained it a little more fully. Building upon his idea, I suggest:
Attach the new disk as hda. Place your old disk as hdc. (Keep this
straight, this proposal is the opposite of the one above.) Boot with
a live CD.
Make sure the /dev/hdc (the old disk) is *not* mounted. If the live
CD automatically mounts it, unmount it. This is a safety measure.
Run "fdisk /dev/hda"
The program will tell you the exact size of the new disk, and other
info. Take a sheet of paper and decide on the new layout of your
future system. I tend to agree with Nico, too many partitions becomes
a liability. I would
1. /var on a separate partition, so that wild-running loggers don't
grab all space on the system partition. Son't make it too small,
though, e.g. yum may cache all updated rpm's, and you may want to
keep them so you don't have to download them again in the case
of a serious screw-up. Not a very real concern, actually, but
you get the idea. Right now my /var has 160M of data. I gave it 1G.
2. /home, and all non-system data, on partitions other than /
3. /boot on a small separate partition... a matter of taste, as
the original reasons why this was necessary no longer apply
on most systems. A kernel needs a few MB, so 50-100MB is ample.
4. / the system partition. I tend to install lots of development
gear and other things that go in /usr/{bin,lib,share}, and at
times 10G have been too little. Your current system seems to
fit well in 5G, though. Make up your mind.
5. A swap partition. I saw you have a /swap mounted partition, but
that is not what I mean. I mean a partition that will not be
mounted, and the "partition type" should be set to "83" (which is
0x83, or 128+3=131, but you will only see "83" in fdisk). It is
possible to swap to ordinary files in the fs, and if that is what
you use the /swap for, I don't know any particular reason not to
do so, so this is up to you.
Make it about twice the size of your ram. Perhaps you should
plan ahead for a day you get a newer computer with faster cpu
and more ram, and want to carry over the disk to that computer.
Your next computer is likely to have at least 512Mbyte ram, more
likely 1G.
Create the partitions you want on the new disk. "m" gives a "menu".
When asked "Primary/logical/extended": The partition table in sector zero
(aka mbr, "master boot record") has only room for four entries. That makes
up to four "primary" partitons. To have more partitions, one of the
primaries is subdivided, into so-called "logical" partitions. That
primary must have its type set to "extended". There should really not be
necessary to expose such distinctions to the user, unless you choose
"expert mode", but for dual-boot Windows/Linux it is necessary to be aware
of the distinction.
Create file systems inside each partition except the swap partition.
Command: mkfs /dev/hda{n}
Mount the partition that is going to hold your / partition, e.g.
mount /dev/hda6 /mnt
In the new partition, create the directories that will be mount
points in the new system. Just the disk mount points, e.g.
mkdir /mnt/boot /mnt/var /mnt/home
Mount a partition with ample space even after data is copied into it,
likely /home: "mount /hda7 /mnt/home"
Now the fun begins.
dd if=/dev/hdc1 of=/mnt/home/old-hda1 conv=noerror conv=sync
dd if=/dev/hdc5 of=/mnt/home/old-hda5 conv=noerror conv=sync
...
dd if=/dev/hdc11 of=/mnt/home/old-hda11 conv=noerror conv=sync
(The old disk was moved to hdc, remember?)
At this point you have the contents of the old disk on the new one,
but you are in no way bound by the partitioning of the old disk.
You have made a completely new partitioning.
In the event that you somehow swap "if" and "of" above, the command
will simply fail because there is no "old-hda5" file. No harm.
After the first "dd" command, you use the bash up-arrow mechanism
to edit a copy of the previous command. In that way you are not
likely to overwrite the old disk. Just be extra carefull with the
first command.
Now,
mkdir /mnt/old-system
mount /mnt/home/old-hda1 /mnt/old-system -o loop,ro
This will treat the contents of the file old-hda1 as if it were
a device or partition, and mount it as a file system. It will mount
it read-only. Files will still have the write permission bits, but
no write will be possible through the mount.
Keep mounting the rest of the old system, possibly except the old hdb.
mount /mnt/home/old-hda5 /mnt/old-system/home
etc. Have a list of your old mount table handy on a paper! If you printed
out this post, the output of fd is at the top. You also can do
cat /mnt/old-system/etc/fstab
Then do
cp -a /mnt/old-system /mnt
Everything should get copied with the right permissions.
Before you reboot, you need to fix two things: /mnt/etc/fstab and
grub.
vi /mnt/etc/fstab
Watch out. Redhat/Fedora is fond of using partition labels instead of
device files in the fstab. At times like these, where you may have
multiple partitions with old and new "/home" data, you could easily
end up with the wrong one mounted. Better use "/dev/hda{n}" for devices,
or you should make sure you *label* your new partitions in an unambiguous
way, using "e2label".
And
chroot /mnt /bin/bash
grub-install /dev/hda
exit
sync
sync
reboot
-Enrique
Alf Tanner
> Hello.
>
> It appears that my old Maxtor HDD (hdparm says: Model=Maxtor 53073U6,
> FwRev=DA620CQ0, SerialNo=K60BMHKC) is dying (reads slower and slower these
> days). I need to copy all of its data to a new bigger HDD (not sure what
> brand and size yet) soon.
>
> What's the best way of doing this?
Never ever use something for window$.
Use dd_rescue called from dd_rhelp:
http://www.kalysto.org/utilities/dd_rhelp/index.en.html
http://www.garloff.de/kurt/linux/ddrescue/
It will save your data.
Nico Kadel-Garcia
"Alan Adams" <alan....@orchard-way.freeserve.co.uk> wrote in message
news:f6e340d74d...@orchard-way.freeserve.co.uk...
> So, to clarify things for me, and maybe the OP as well, it sounds as if
> it's
> possible to copy the installed copy of Linux to another disc, while
> running
> that copy of Linux? (And then edit the Grup or Lilo boot program to now
> what
> you've done).
Yes, but it's a bit risky. Database files, in particular, may wind up with
one bit being modified but not in the other, especially if it is still in
RAM and hasn't synced to disk yet. You probably don't care if you miss a few
bits of /var/log/messages, but if you mess up your /var/lib/ldap/ database
files, you're potentailly in deep trouble. If you mess up an *ORACLE*
database, you're seriously screwed. So for reliable system duplication, it's
better to be running from a rescue or live CD, and keep the source files in
read-only mode.
> That most definitely isn't possible with Windows, and may be causing the
> OP
> to think he has to reinstall or Ghost - the two ways to do it with
> Windows.
Agreed. But ghosting a live OS is also something I've never seen done. I've
only seen Ghost done from an idle partition, via booting into a
one-time-only limited boot system set up by Ghost or using a PXE network
Ghost setup.
> Does anyone know (off-topic a bit) whether Windows Ghost can copy
> non-Windows file systems? Looking at the help the other day there seemed
> to
> be a command-line switch to handle discs "raw".
I dunno, I'll ask around.
ANT...@zimage.com
Everything. Every bits! :) Again, that is how I do it with Windows and DOS. I just make Ghost
images or copy the drives. Only if the OS' are fine.
> If its just directories you could tar them up and write them out
> to cd (burn a cd). Then reload a new disk with a fresh OS install.
> I read over the entire post and I'm not clear on what you exactly
> need from the old disk.
Everything. Including my OS, GRUB, etc. Bascially, I just want to move everthing from the old
dying WORKING HDD to the new one. I don't have to reinstall my OS because I just did that like
six years old that took forever to finish (pain in the butt) due to lack of free time.
> Also, check this out, it explains the dd and how to use it with
> non-exact hdd. http://www.linuxplanet.com/linuxplanet/tutorials/986/4/
> That should be about all you need. Plus dont forget to read the
> man dd to better understand it.
Yea, I briefly looked at dd man. Looks confusing. I wish there was a GUI version to avoid using
all these parameters and making errors (I tend to do that a lot). Plus, I am playing with datas!
> Remember its linux so theres more than one way to do everything. Its
> just a matter of experimenting and so forth.
Yea, I wished I had more time to experiment. 1) Who knows when the HDD will finally stop
working. 2) Busy with non-computing stuff. 3) New to this.
ANT...@zimage.com
Great link! Would I be using this to copy my old slow HDD (hda) to new bigger HDD (hdb)? And
would I do this with KNOPPIX or can I do this in Debian (is that safe?) as root user?
dd if=/dev/hda of=/dev/hdb bs=1024k
I noticed it mentioned lilo. I don't use lilo. What do I run for Grub to fix my broken MBR?
Again, is this done via KNOPPIX?
ANT...@zimage.com
> [ replace root hard disk ]
> > From the other reply, it sounded like I have to install new OS
> > and make new partitions on the new drive. Then, copy old datas
> > from the old drive to overwrite the new installation.
> Nope, there's no need, you can just copy the stuff over and
> reinstall your bootloader on the new disk.
> > I don't use lilo though. I use Grub.
> Doesn't matter, you have to reinstall grub if you want to boot of
> the new hd.
> Try this howto, not that new but looks still usable:
> http://www.tldp.org/HOWTO/Hard-Disk-Upgrade/
> Exchange 'mkfs.ext2' with 'mkfs.ext3' if creating fs. Again a
> complete backup (USB hd/etc) should be your first step.
> Good luck
Thanks.
ANT...@zimage.com
I am not using Windows Ghost. I am using the one that requires DOS boot disk from 2003. I think
it was Ghost 2003 DOS version. I don't trust Windows at all. I never do Ghosting in Windows. Too
scary and risky. Things change too much in Windows too.
ANT...@zimage.com
> > it's
> > possible to copy the installed copy of Linux to another disc, while
> > running
> > that copy of Linux? (And then edit the Grup or Lilo boot program to now
> > what
> > you've done).
> Yes, but it's a bit risky. Database files, in particular, may wind up with
> one bit being modified but not in the other, especially if it is still in
> RAM and hasn't synced to disk yet. You probably don't care if you miss a few
> bits of /var/log/messages, but if you mess up your /var/lib/ldap/ database
> files, you're potentailly in deep trouble. If you mess up an *ORACLE*
> database, you're seriously screwed. So for reliable system duplication, it's
> better to be running from a rescue or live CD, and keep the source files in
> read-only mode.
Yeah, I was told to boot LiveCD instead of my working OS to do these disk activities. I think I
will do that. I hope KNOPPIX v4.1 has all the tools I need. I just hope the older tool versions
will work because the tools in my Debian OS are newer.
FYI. I don't run a database server. Just a basic workstation.
ANT...@zimage.com
Hmm, why would I need tar.gz? I am not compressing to a file. I just need to copy the disk.
So, would I boot with KNOPPIX v4.1 CD, mount the drives (automatic I think already), tar
How do I rsync command to copy from old HDD to new HDD locally? It seems like it is only for
network (remote).
Nico Kadel-Garcia
<ANT...@zimage.com> wrote in message
news:D-WdnXtrTrm...@mminternet.net...
Cool. The Knoppix v4.2 seems to have everything needed, I was using it last
week.
Nico Kadel-Garcia
<ANT...@zimage.com> wrote in message
news:D-WdnXprTrl...@mminternet.net...
> Hmm, why would I need tar.gz? I am not compressing to a file. I just need
> to copy the disk.
>
> So, would I boot with KNOPPIX v4.1 CD, mount the drives (automatic I think
> already), tar
> How do I rsync command to copy from old HDD to new HDD locally? It seems
> like it is only for
> network (remote).
.tar.gz is handy when you want to make a compressed tarball if you don't hve
the space for an rsync (as you apparently do not), or if you want to make a
single file that you can transfer and download for other uses more easily.
I've used them to keep filesystems around for doing base local insallations
without having to do all the updates nad configurations: I just untar the
tarball to local disk, "chroot" to it, do the updates or configuration
changes, then exit the chroot and bundle back up the tarball. It's very
convenient when installing, say, more than 10,000 identical machines.
ANT...@zimage.com
> >> > dying (reads slower and slower these days). I need to copy all of its> data to a new bigger HDD (not sure what
> >> > brand and size yet) soon.
> Slower and slower? How is that possible? It makes me think that the controller
> is getting lots of read errors, and so is retrying over and over. It could mean
> data corruption is imminent. Hurry up.
Yeah. Hence, why I need to copy my stuff over. However, I couldn't find any evidences of
errors. See
http://groups.google.com/group/comp.sys.ibm.pc.hardware.storage/browse_thread/thread/63da7694fdf44462/627634836c873c47?tvc=2&q=antant%40zimage.com&hl=en
or http://tinyurl.com/bfxg3 for details.
Hmm good point on that.
> Then, run the command
> dd if=/dev/hda of=/dev/hdc conv=noerror conv=sync bs=1M
> Just don't mix up "if" and "of"!!!!
Yeah, no kidding. Scary stuff. I hope it warns me about this (we detected data -- are you sure?)
> This will copy the partition table(s) and all, so when you move
> the new disk to the primary ide, it will appear with all the paritions
> you used to have. Even the boot loader will be happy because it will
> find everything at the same sector address as before.
> Your new disk must be at least as large as the old one. If it is
> larger, it will have unpartitioned space at the end. You can use
> this space however you like, creating additional partitions or moving
> partitions around and growing their size.
Hmm, can I resize the partition on the fly during the copy? IIRC, Norton Ghost does this with
FAT32/NTFS partitions. It asked me about the bigger disk space. To use or leave it alone.
> There are two things that can go wrong here: First, if there are
> disk read errors during the copy, and the errors affect e.g. the
> partition table, the partition table on the new disk will appear
> dammaged or even unusable. However, if this happens, anything else
> you could have done would also have been prone to to fail. You
> simply lost the race to replace the disk before the growing disk
> defects made it impossible. Second, this is somewhat academic,
> the new disk may have a different exported disk geometry, and some
> operations may depend on the geometry. Academic, because nowadays
> all new disks have 63 sectors/track and 255 tracks/cylinder. Both
> your existing disks have that. Also, nowadays all systems use
> LBA ("Logical block addressing"), meaning they rely on sector numbers
> exclusively, even the BIOS.
> Assuming there is no errors, you can take out the old disk, put the
> new disk in its place, and keep the old disk as a backup during the
> first days. If something goes completely wrong, just swap the old
> disk back in as hda the new one again as hdc, and repeat.
> -----
> That said, Ray's suggestion has its merits. I think he should have
> explained it a little more fully. Building upon his idea, I suggest:
> Attach the new disk as hda. Place your old disk as hdc. (Keep this
> straight, this proposal is the opposite of the one above.) Boot with
> a live CD.
OK. KNOPPIX v4.1 is what I have for LiveCD.
> Make sure the /dev/hdc (the old disk) is *not* mounted. If the live
> CD automatically mounts it, unmount it. This is a safety measure.
OK.
> Run "fdisk /dev/hda"
> The program will tell you the exact size of the new disk, and other
> info. Take a sheet of paper and decide on the new layout of your
> future system. I tend to agree with Nico, too many partitions becomes
> a liability. I would
Yeah, this is messy and confusing for me, newbie. I only wanted to a straight HDD copy like I do
with Norton Ghost with Windows and DOS partitions. It looks like this method requires recreating
partitions.
I am planning to reuse my HDDs on the next computer that will be over a year or so (Athlon 64).
> Now the fun begins.
> Now,
> mount /mnt/home/old-hda5 /mnt/old-system/home
> cat /mnt/old-system/etc/fstab
> Then do
> cp -a /mnt/old-system /mnt
> vi /mnt/etc/fstab
> And
> -Enrique
Wow, this is long and complex. Yet scary. :I I wished we had a way just to do disk copy image.
Heh. very different from Windows' world.
ANT...@zimage.com
> http://www.kalysto.org/utilities/dd_rhelp/index.en.html
> http://www.garloff.de/kurt/linux/ddrescue/
I downloaded, compiled (apt-get didn't have the latest versions) and installed both. I am a bit
overwhelmed with the help and limited documents. How do I use these tools in my situation to
copy the old drive to the new drive (mirroring)?
Example: hda (old dying HDD) and hdb (new bigger HDD).
dog...@noemail.com
>
>> Also, check this out, it explains the dd and how to use it with
>> non-exact hdd. http://www.linuxplanet.com/linuxplanet/tutorials/986/4/
>> That should be about all you need. Plus dont forget to read the
>> man dd to better understand it.
>
> Great link! Would I be using this to copy my old slow HDD (hda) to new bigger HDD (hdb)? And
> would I do this with KNOPPIX or can I do this in Debian (is that safe?) as root user?
>
> dd if=/dev/hda of=/dev/hdb bs=1024k
>
> I noticed it mentioned lilo. I don't use lilo. What do I run for Grub to fix my broken MBR?
> Again, is this done via KNOPPIX?
I cut alot of the above text out. What is the problem with or what
is it you want to do with KNOPPIX. As far as I can tell if you dd
over the setup its going to take it all. So you'll have all the
information etc. If the bootloader got hosed in your MBR then
thats another problem altogether. From what I remember, when you
install linux it places a small "image" for lack of a better
word(s) into the MBR, which in turn reads over the setting from
your grub.conf or lilo.conf, which in turn points to the image
on the disk that you want to boot. Could you reiterate your problem
with the MBR and your bootloader.
dog...@noemail.com
Only one comment here, dont take offense, GUI's are the downfall
in my opionion and linux is falling into that GUI driven sys admin
approach, whereas the admins can only do it with a GUI and they
dont understand the underlying scripts, code, apps etc etc that
are really driving the system. I say NO to GUI's. And yes the dd
man page is confusing as are most man pages, but I think they
write them like that to make people think. Just my 2 cents there.
Again please dont take offense on my opionion here.
ANT...@zimage.com
4.2?!?!? Where? I only see 4.0.2 online. Correction on my earlier post. I have v4.0.2, not v4.1.
--
"The general, unable to control his irritation, will launch his men to the assault like swarming ants, with the result that one-third of his men are slain, while the town still remains untaken. Such are the disastrous effects of a siege." --Chapter 3 in Sun Tzu's The Ancient Art of War (Translated by Lionel Giles)
Enrique Perez-Terron
[...]
>> > Can't I just do a direct disk image copy from old HDD to new HDD directly like in Norton Ghost?
>> > Why bother with making a disk image? :)
>
>> You can, I think. Just follow this piece of wild heresy:
>
>> First, I suggest you connect the new drive as hdc, not hdb, because
>> IDE controllers are not able to run disk transactions on the master
>> and slave device in parallel. In other words, you save a few seconds
>> using hdc. Next, because you plan to connect the new disk as hda,
>> that is, as master. By provisionally making it master on the secondary
>> ide channel, you don't have to remember to change the master/slave
>> setting on the disk.
>
> Hmm good point on that.
>
>
>> Then, run the command
>
>> dd if=/dev/hda of=/dev/hdc conv=noerror conv=sync bs=1M
>
>> Just don't mix up "if" and "of"!!!!
>
> Yeah, no kidding. Scary stuff. I hope it warns me about this (we detected data -- are you sure?)
>
>
>> This will copy the partition table(s) and all, so when you move
>> the new disk to the primary ide, it will appear with all the paritions
>> you used to have. Even the boot loader will be happy because it will
>> find everything at the same sector address as before.
>> -----
>> That said, Ray's suggestion has its merits. I think he should have
>> explained it a little more fully. Building upon his idea, I suggest:
>> Attach the new disk as hda. Place your old disk as hdc. (Keep this
>> straight, this proposal is the opposite of the one above.) Boot with
>> a live CD.
[... large snip ]
> Wow, this is long and complex. Yet scary. :I I wished we had a way just to do disk copy image.
> Heh. very different from Windows' world.
You have a way to just do a disk copy, that is the first proposal above.
The long and complecated stuff is the second proposal, based on an idea
offered by Ray. (I know, you have received many hours' worth of advice
reading! Easy to miss a detail then.)
You asked if you can grow the partition in the same step as doing the
copying. But then you are not copying the whole disk over to an
identical image. You will have to specify the size of the new partition,
at least, so you are doing partition-by-partition copying. If you grow a
partition, the boot loader may no longer find things at the same absolute
sector address as before. You must then either know that everything the
boot loader needs to find at specific sector adresses, has not moved, or
just re-run grub-install (or whatever boot loader you use).
Anyway, no, there are no tools I know about that do that easily. In some
ways one notes that Unix is an older OS than Windows, and unix people
have been happy with a more primitive toolset. (Until fairly recently,
Dos/Windows users have been _un_happy with _even_ more primitive tools.)
The combination of specialized knowledgeable administrators and powerfull
but 1970-vintage tools were sufficient so that a need for a really slick
gui-style tool was never felt strongly enough. This may change.
I mention fdisk in my recipe. That is the oldest, most primitive one.
There is also parted, but I have never used it. It appears to be able to
do more things like resizing partitions, but I think others should advice
about that, who have actually used the tool.
With the primitive tools, you need to have a basic mental picture of the
parts and how they fit together. That, of course, may come handy in many
later situations. It is just a bit much to take in all at once. I will
describe just three basic concepts of relevance:
Partitions are rather simple animals, they just say e.g., partition 1 starts
in sector X and extends for Y sectors. When Linux operates on hda1, if a
program wants to read sector Z, the kernel reads sector X+Z, after checking
that Z<Y.
File systems are the on-disk data structures that keep track of the sectors,
which are in use, which are free, which belong to the same file or directory,
and what is the the file's name. Every file file system has a "superblock",
and all other information is found using information derived from the
superblock. The superblock itself is found at a fixed offset from the start
of the partition or device. All disk addresses are relative to the start
of the partition, so you can copy the partition to another, provided the new
one is large enough. The superblock also contains (redundantly) the
size of the file system. If you copy a partition to a larger partition,
without changing the superblock, the extra space will never be used.
This is what you change when you "grow" a file system. It's not just a matter
of changing a simple number in the superblock, it may also mean increasing
the size of free-block bitmaps, file allocation tables (fat), or whatever
the file system in question uses.
The boot loader does its work before the kernel is running, so it cannot use
the facilities of the kernel. The first problem the boot loader must overcome,
is how to get started. If all its fantasically clever codes only sit in
a disk sector, they do no good until they somehow get loaded into memory
and get executed by the processor. When you power on you computer, the
processor executes code from the BIOS eprom. That code eventually reads
one - 1 - sector from the start of hda, and lets the processor execute
whatever codes were found there. One sector is just 512 bytes, not much
if you want to create a program that understands partitions, file systems,
file names, etc. The partition table occupies 64 bytes of this precious
space, and there are a few other things there. When you have Grub loaded
into that first sector, the codes there are patched with the absolute
addresses of a few more sectors, to read next. This is what goes wrong if
you move partitions. You need to setup the grub boot sector again with new
sector addresses. Eventually, Grub will have loaded the rest of itself
into memory, and from that point on, grub does understand partitions and
file systems just like the kernel does. Grub will then find the config
file using a file name, /boot/grub/menu.lst, or /grub/menu.lst. (Some
distributions chage "menu.lst" to "grub.conf".) If you modify the config
file, the editor will ceratinly write the new version into different sectors.
No problem, grub finds them, using the file name and the file system
structures. The config file names the files containing the kernel, and
again, if you recompile the kernel, the new version will not sit in the same
sectors, but Grub still finds them. You don't need to rerun grub-install
when any of these files change, only if the files containing "the rest of
grub" change or move.
I should perhaps also mention that when Grub loads "the rest of itself",
that rest may reside on a different disk too. This means that grub
specifies both sector addresses and disk number. If you move disks around,
that too can necessitate running grub-install anew.
-Enrique
Jason L. Woodruff
> Hello.
I made a help doc on this! Check it out @
http://home.centurytel.net/jlw-tech/copy.htm . Good Luck!
-Jason
--
Registered Linux user #339721
Visit me @ http://home.centurytel.net/jlw-tech
Alan Adams
"Enrique Perez-Terron" <en...@online.no> wrote:
An excellent description. The same sort of thing happens on all operating
systems. Just a note from the past:
boot is short for bootstrap, which is taken from the phrase "pulling
yourself up by your bootstraps". The above description shows how truly this
describes the exercise.
>
> I should perhaps also mention that when Grub loads "the rest of itself",
> that rest may reside on a different disk too. This means that grub
> specifies both sector addresses and disk number. If you move disks around,
> that too can necessitate running grub-install anew.
>
> -Enrique
--
Alf Tanner
>> Use dd_rescue called from dd_rhelp:
>
>> http://www.kalysto.org/utilities/dd_rhelp/index.en.html
>> http://www.garloff.de/kurt/linux/ddrescue/
>
>> It will save your data.
>
> I downloaded, compiled (apt-get didn't have the latest versions) and
> installed both. I am a bit overwhelmed with the help and limited
> documents. How do I use these tools in my situation to copy the old drive
> to the new drive (mirroring)?
>
> Example: hda (old dying HDD) and hdb (new bigger HDD).
Overwhelmed?
$ dd_rhelp
Need 2 arguments...
usage: dd_rhelp {filename|device} {output-file} [{info}]
you want to rescue say hda1 on an iso file on hdb1, mounted as /rescue:
dd_rhelp /dev/hda1 /rescue/file.iso
At this point you have your iso file. Now mount it as loop and use
normally.
Nico Kadel-Garcia
<ANT...@zimage.com> wrote in message
news:NeOdndED4u1...@mminternet.net...
>> Cool. The Knoppix v4.2 seems to have everything needed, I was using it
>> last
>> week.
>
> 4.2?!?!? Where? I only see 4.0.2 online. Correction on my earlier post. I
> have v4.0.2, not v4.1.
You're right. 4.0.2 What's with teeny version number increments?
ANT...@zimage.com
> > Heh. very different from Windows' world.
> You have a way to just do a disk copy, that is the first proposal above.
> The long and complecated stuff is the second proposal, based on an idea
> offered by Ray. (I know, you have received many hours' worth of advice
> reading! Easy to miss a detail then.)
> You asked if you can grow the partition in the same step as doing the
> copying. But then you are not copying the whole disk over to an
> identical image. You will have to specify the size of the new partition,
> at least, so you are doing partition-by-partition copying. If you grow a
> partition, the boot loader may no longer find things at the same absolute
> sector address as before. You must then either know that everything the
> boot loader needs to find at specific sector adresses, has not moved, or
> just re-run grub-install (or whatever boot loader you use).
Yeah, I just need to figure out which method to do. I think I am
going to use the dd method to copy exact partitions to the newer
bigger HDD. Rerun grub-install to fix the MBR. Then, I can make new
partition(s) out of the extra unused space.
> Anyway, no, there are no tools I know about that do that easily. In some
> ways one notes that Unix is an older OS than Windows, and unix people
> have been happy with a more primitive toolset. (Until fairly recently,
> Dos/Windows users have been _un_happy with _even_ more primitive tools.)
> The combination of specialized knowledgeable administrators and powerfull
> but 1970-vintage tools were sufficient so that a need for a really slick
> gui-style tool was never felt strongly enough. This may change.
You know, I thought by now this would exist for non-Linux experts
like me. When I installed Linux (Red Hat and Debian), the installers
came with disk utilites (Disk Druid?) that did these partitions. In
Windows, we have PartitionMagic, Ghost, etc. In Linux, I don't see
them (native Linux ones).
Interesting even though some parts was a bit technical to me. Does
lilo have this problem too?
--
"The general, unable to control his irritation, will launch his men to the assault like swarming ants, with the result that one-third of his men are slain, while the town still remains untaken. Such are the disastrous effects of a siege." --Chapter 3 in Sun Tzu's The Ancient Art of War (Translated by Lionel Giles)
ANT...@zimage.com
> dd_rhelp /dev/hda1 /rescue/file.iso
Can't I skip the ISO file part? I just want to copy from old HDD to new one directly. I think making ISO will
be slower. Remember, my old HDD can be read/written less than 1 MB/sec!! In Norton Ghost, I didn't need to make
disk images. Just copy the disk to the new disk.
--
"The general, unable to control his irritation, will launch his men to the assault like swarming ants, with the result that one-third of his men are slain, while the town still remains untaken. Such are the disastrous effects of a siege." --Chapter 3 in Sun Tzu's The Ancient Art of War (Translated by Lionel Giles)
ANT...@zimage.com
> I made a help doc on this! Check it out @
> http://home.centurytel.net/jlw-tech/copy.htm . Good Luck!
> -Jason
Thanks.
Alf Tanner
>> Overwhelmed?
>> $ dd_rhelp
>> Need 2 arguments...
>> usage: dd_rhelp {filename|device} {output-file} [{info}]
>
>> you want to rescue say hda1 on an iso file on hdb1, mounted as /rescue:
>
>> dd_rhelp /dev/hda1 /rescue/file.iso
>
>
>> At this point you have your iso file. Now mount it as loop and use
>> normally.
>
> Can't I skip the ISO file part? I just want to copy from old HDD to new
> one directly. I think making ISO will be slower. Remember, my old HDD can
> be read/written less than 1 MB/sec!! In Norton Ghost, I didn't need to
> make disk images. Just copy the disk to the new disk.
Great. Then go ahead and use ghost, but please do not come back
complaining that it won't even see your linux fs and that norton toasted
the whole disk.
This method works regardless of fs used. I saved 160G of broken disk, the
partitions were barely recognised, let alone mounted.
Again, read
http://www.kalysto.org/utilities/dd_rhelp/index.en.html
imotgm
> Yeah, I just need to figure out which method to do. I think I am
> going to use the dd method to copy exact partitions to the newer
> bigger HDD. Rerun grub-install to fix the MBR. Then, I can make new
> partition(s) out of the extra unused space.
With everyone touting their own favorite method, I was going to stay out
of this, because you have enough to confuse you as is. However, I think it
should be pointed out that dd copies bit for bit, meaning it copies the
empty space on each partition just as meticulously as the important data.
Using cp -a copies only the actual data. You can change partition sizes,
and file systems, if you desire, and then use cp -a to transfer the
information, on a partition to partition basis. dd will copy the
formatting also, as well as the partition table, so no changes can be
made. If you have 4 primary partitions on a small hard drive, say 20GB,
and you use dd to copy the disk to a large hard drive, say 100GB, the
partition table for the 100GB drive will show 4 primary partitions, using
20GB, and, being as 4 primaries is the disk limit, the other 80GB will be
inaccessible.
For what you are doing, where getting the data transferred as quickly as
possible, to avoid lose, is a prime consideration, cp -a will be quicker
than dd.
First attach the new disk as hdc, master on the second IDE cable.
You said you have a knoppix live disk. Use it, as root, for all of the
following.
From an X term/Konsole, (I don't have a Knoppix disk, so don't know what
desktop they use.) do the following;
Partition the new disk whichever way you choose.
Format it as you wish.
Create two mount points /mnt/new, and /mnt/old.
Mount the partition that will be / on the new drive to /mnt/new.
# mount -t <filesystem> /dev/hdc? /mnt/new <Enter>
Use mkdir to create mount points for each new partition, as in;
# mkdir /mnt/new/boot <Enter>
# mkdir /mnt/new/home <Enter>
or better yet,
# cd /mnt/new <Enter>
# mkdir boot home usr [whatever else] <Enter>
Now mount the actual partitions to the mount points,
# mount -t <filesystem> /dev/hdc? /mnt/new/boot <Enter>
# mount -t <filesystem> /dev/hdc? /mnt/new/home <Enter>
# mount -t <filesystem> /dev/hdc? /mnt/new/usr <Enter>
until you have them all mounted.
Now mount the / partition of your old drive to /mnt/old.
# mount -t <filesystem> /dev/hda? /mnt/old
If you have other partitions on the old drive, mount them as they would be
mounted on the running system.
# mount -t <filesystem> /dev/hda? /mnt/old/boot <Enter>
# mount -t <filesystem> /dev/hda? /mnt/old/home <Enter>
until you have them all mounted.
Now the biggy.
# cp -a /mnt/old/* /mnt/new/
You are still in /mnt/new, as your pwd, so when you get your prompt back,
# ls <Enter>
will show a normal / directory. Or open a Konqueror or Nautilus file
manager window, and browse around to see that everything is normal.
You're root still, so go to /mnt/new/etc and open fstab in whichever
editor trips your trigger, and edit it to reflect the mount points for the
new disk as they should be when the disk is reinstalled as hda. Save fstab.
Install grub to hdc's MBR, and shut down. Swap the new drive for the old
at hda, and reboot.
>> Anyway, no, there are no tools I know about that do that easily. In
>> some ways one notes that Unix is an older OS than Windows, and unix
>> people have been happy with a more primitive toolset. (Until fairly
>> recently, Dos/Windows users have been _un_happy with _even_ more
>> primitive tools.) The combination of specialized knowledgeable
>> administrators and powerfull but 1970-vintage tools were sufficient so
>> that a need for a really slick gui-style tool was never felt strongly
>> enough. This may change.
>
> You know, I thought by now this would exist for non-Linux experts like
> me. When I installed Linux (Red Hat and Debian), the installers came
> with disk utilities (Disk Druid?) that did these partitions. In Windows,
> we have PartitionMagic, Ghost, etc. In Linux, I don't see them (native
> Linux ones).
The problem here, is that you are still thinking in Windows mode. You are
looking for a specific, complicated, application to do this one job. There
is no real reason to create such a thing for Linux. The standard small
tools that are part of the system can do this.
Look back at what I wrote. For all the lines written, it sums up;
Install the drive, partition, format, mount, copy, edit one file, run
grub-install, or grub setup, shut down to move the disk, and reboot.
Partitioning, formatting, and mounting partitions are so basic you should
not have to think twice about it, except for how big, and which fs. The
commands themselves are basic simplicity. Fdisk is basically a multiple
choice menu; the answers are all there. Mkfs is a one liner; name of app,
(an abbreviation of it's function) type of fs, what partition. Mount is
again; name of app, (which is also a description of what you're doing)
what, where. Same for cp; (name of app is an abbreviation for the desired
function) what, where.
While I was writing this, I moved one of my OSs (SUSE 9.3) to a different
drive, used fdisk to delete three small partitions, and then joined the
entire space into one larger partition, fixed the partition order and
wrote it to disk. After I send this, I will reboot, so the new partition
table will be read, and then I'll format the new partition and copy back
SUSE to where it was.
You are making this task a giant grizzly bear, in your mind, when it's
just a bunny rabbit, in fact.
--
imotgm
"Lost? Lost? I've never been lost... Been a tad confused for a
month or two, but never lost."
Peter T. Breuer
> You know, I thought by now this would exist for non-Linux experts
> like me. When I installed Linux (Red Hat and Debian), the installers
> came with disk utilites (Disk Druid?) that did these partitions. In
> Windows, we have PartitionMagic, Ghost, etc. In Linux, I don't see
> them (native Linux ones).
Partition resizers can't know anything about the boot manager, so
there's no way to change the boot record code to match whatever the
resizer's done to the partitions (actually, there IS a way, but it's
insufficient - they could look for a load or a jump bios instruction in
the mbr, see where it pointed on disk, figure out the file it points to,
then work out where that file has gone to in the copy, etc. ... but
that's NOT enough in the general case because the first address may
point to a file that contains further addresses, like with lilo).
Windows tools can't do it it either. The tools only work sometimes,
WHEN you use a standard windows bootloader.
Peter
ANT...@zimage.com
ANT...@zimage.com
Interesting. I wonder if the tools I used, in Windows, does this part
automatically. Hence, why I don't see this step.
Peter T. Breuer
> In comp.os.linux.setup Peter T. Breuer <p...@oboe.it.uc3m.es> wrote:
>> Partition resizers can't know anything about the boot manager, so
>> there's no way to change the boot record code to match whatever the
>> resizer's done to the partitions (actually, there IS a way, but it's
>> insufficient - they could look for a load or a jump bios instruction in
>> the mbr, see where it pointed on disk, figure out the file it points to,
>> then work out where that file has gone to in the copy, etc. ... but
>> that's NOT enough in the general case because the first address may
>> point to a file that contains further addresses, like with lilo).
>> Windows tools can't do it it either. The tools only work sometimes,
>> WHEN you use a standard windows bootloader.
> Interesting. I wonder if the tools I used, in Windows, does this part
> automatically. Hence, why I don't see this step.
Why WONDER when I TOLD you?
Saying that makes one wonder about other things.
Peter
Enrique Perez-Terron
> In comp.os.linux.setup Peter T. Breuer <p...@oboe.it.uc3m.es> wrote:
>
>> Partition resizers can't know anything about the boot manager, so
>> there's no way to change the boot record code to match whatever the
>> resizer's done to the partitions (actually, there IS a way, but it's
>> insufficient - they could look for a load or a jump bios instruction in
>> the mbr, see where it pointed on disk, figure out the file it points to,
>> then work out where that file has gone to in the copy, etc. ... but
>> that's NOT enough in the general case because the first address may
>> point to a file that contains further addresses, like with lilo).
>
>> Windows tools can't do it it either. The tools only work sometimes,
>> WHEN you use a standard windows bootloader.
>
> Interesting. I wonder if the tools I used, in Windows, does this part
> automatically. Hence, why I don't see this step.
I know the first steps of how the standard Windows bootloader works,
but I have to guess about the rest.
Essentially, my answer is no, but as long as you stick to a pure
Windows setup, it does not have to do what Peter describes.
(Notice that Peter actually answered this question already,
saying no, and added that the Windows scheme sometimes fails.)
Windows boots in several stages, more stages than Grub/Linux.
As described before, first the BIOS loads the MBR, the first sector
of the disk. In my earlier description, I assumed this sector
contains Grub stage 1. Now assume it contains the standard Windows
MBR code, which we could call Windows loader stage 1 - wlstage1.
What wlstage1 does, is, it looks in the partition table (only the
primary, with the four primary entries. It knows nothing about
"logical" partitions inside any "extended" - Windows knows, but
wlstage1 does not) ...eh, yes, looks in the primary partition table,
and checks if one of the entries has the "active" flag set. That is
another byte, each partition table entry has a byte, just like the
"partition type" byte, but this one is called the "active flag".
If it's zero, the partition is not active. If no partition has
the active flag set to some non-zero value, or if more than one
partition has it set, then wlstage1 just hangs forever.
But if exactly one primary partition has the active flag set, the
wlstage1 repeats quite exactly what the Bios did: it now loads *one*
- 1 - sector from the start of the active partition, and runs the
code found there. Notice the difference, the Bios loads one sector
from the start of the disk - the wlstage1. Wlstage1 loads one sector
from the start of the active partition. We can call this wlstage2
This is how far I can say I know what the standard MS boot program
does.
Wlstage2 is probably a little more capable than the wlstage1,
since it does not have a partition table embedded, and so it has
room for a little more code.
Now comes the guessing. If the active partition has a regular
Windows install, then I guess the wlstage2 figures out what sector
it was loaded from (looking in an in-memory copy of the partition
table wlstage1 left behind), and then also loads the next few
sectors. In that way, the wlstage2 too, will load "the rest of itself".
However:
- it does not need to have sector addresses patched if the
partition is moved
- this is because "the rest of itself" invariably is at
the start of the partition, and the partition can still
be found in the partition table.
The price Windows pays for this, is that it cannot boot from a
"logical" partition. It can only boot from an "active" "primary"
partition.
Another price is that to boot off a different partiton you have to
rewrite the MBR with a different partition being marked "active".
However, see below about BOOT.INI.
Once wlstage2 has loaded the rest of itself, it is slightly more
capable, and can examine the partition file-system data structures.
I guess the NT file system (NTFS) gives the file NTLOADER a
preferential treatment, so the boot code does not need to understand
all of NTFS to locate that file by name. I just guess there is a fixed
location in the NTFS' Master File Table reserved for that file, or
something else that makes it particularly easy to load that file into
memory. Once the NTLOADER is loaded, you have at last something really
capable, that fully understands the NTFS datastructures, and also knows
what files to look for, to load the actual Windows kernel.
(Actually I have seen that there are a few more files involved, so
NTLOADER may not be the third stage but the forth or more.)
Also notice that with Windows, you cannot have multiple kernels
lying around in the same partition. The Windows kernel uses a few
fixed file names, and there can only be one of each. With Linux,
you can
- boot from logical partions
- boot any of a row of kernels in the same directory
in the same partition.
This is handy for upgrades; if something goes wrong with an upgraded
kernel, you can still revert to the previous kernel. It remains
there until you decide to delete it. Not to mention if you want to
experiment with modified kernels of your own invention.
However, in Windows, you can still have multiple installs of
Windows lying around, each in a different partition. Only, you must
use one partition as a stepping stone in the boot process. That
partition can contain a file BOOT.INI, which NTLOADER will process,
and use to pick a partition to use as the system partition.
In the end, I believe the system partition does not have to be a
primary partition, but you do need a primary partition to contain
the NTLOADER file. This too is a guess, anyone who has tried can
tell about it.
- Enrique
Alan Adams
"Enrique Perez-Terron" <en...@online.no> wrote:
> On Mon, 12 Dec 2005 20:55:05 +0100, <ANT...@zimage.com> wrote:
>
> > In comp.os.linux.setup Peter T. Breuer <p...@oboe.it.uc3m.es> wrote:
> >
<big snip>
>
> Also notice that with Windows, you cannot have multiple kernels
> lying around in the same partition. The Windows kernel uses a few
> fixed file names, and there can only be one of each. With Linux,
> you can
>
> - boot from logical partions
> - boot any of a row of kernels in the same directory
> in the same partition.
>
> This is handy for upgrades; if something goes wrong with an upgraded
> kernel, you can still revert to the previous kernel. It remains
> there until you decide to delete it. Not to mention if you want to
> experiment with modified kernels of your own invention.
>
> However, in Windows, you can still have multiple installs of
> Windows lying around, each in a different partition. Only, you must
> use one partition as a stepping stone in the boot process. That
> partition can contain a file BOOT.INI, which NTLOADER will process,
> and use to pick a partition to use as the system partition.
You can also have multiple installs in different directories in one
partition. Again, boot.ini is used to find them.
>
> In the end, I believe the system partition does not have to be a
> primary partition, but you do need a primary partition to contain
> the NTLOADER file. This too is a guess, anyone who has tried can
> tell about it.
>
> - Enrique
--
Enrique Perez-Terron
> In comp.os.linux.hardware Alf Tanner <alft...@despammed.com> wrote:
>> On Sat, 10 Dec 2005 21:27:56 -0600, ANTant wrote:
>
>
>> >> Use dd_rescue called from dd_rhelp:
>> >
>> >> http://www.kalysto.org/utilities/dd_rhelp/index.en.html
>> >> http://www.garloff.de/kurt/linux/ddrescue/
>> >
>> >> It will save your data.
>> >
>> > I downloaded, compiled (apt-get didn't have the latest versions) and
>> > installed both. I am a bit overwhelmed with the help and limited
>> > documents. How do I use these tools in my situation to copy the old drive
>> > to the new drive (mirroring)?
>> >
>> > Example: hda (old dying HDD) and hdb (new bigger HDD).
>
>> Overwhelmed?
>> $ dd_rhelp
>> Need 2 arguments...
>> usage: dd_rhelp {filename|device} {output-file} [{info}]
>
>> you want to rescue say hda1 on an iso file on hdb1, mounted as /rescue:
>
>> dd_rhelp /dev/hda1 /rescue/file.iso
>
>
>> At this point you have your iso file. Now mount it as loop and use
>> normally.
>
> Can't I skip the ISO file part? I just want to copy from old HDDto new one directly. I think making ISO will be slower. Remember,my old HDD can be read/written less than 1 MB/sec!! In Norton Ghost,I didn't need to make disk images. Just copy the disk to the newdisk.
From what I gather from the web pages describing these tools,
they look very nice. These are essentially replecements for "dd",
and you probably can use them instead of "dd" even if you chose
the simple "copy the entire disk" strategy.
To get info on how to use dd_rescue, run this command:
dd_rescue -h
To use dd_rescue,
dd_rescue /dev/hda /dev/hdc
will READ /dev/hda, and WRITE /dev/hdc -- make sure this is what
you want, depending on how you wired up the old and new disk.
The help (-h) says there are some sanity checks, but I don't know
what these are.
Hint: Just before running dd_rescue or dd, run this command:
fdisk -l
This command will just list out the partition tables on all disk,
and so you can easily see if the old disk, which has partitions,
and has around 40G (Do I recall correctly?), really is the one
you think it is. Just for comparison, here is the start of
output from my system:
Disk /dev/hda: 10.0 GB, 10005037056 bytes
240 heads, 63 sectors/track, 1292 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 14 105808+ 6 FAT16
/dev/hda2 15 1291 9654120 f W95 Ext'd (LBA)
/dev/hda5 15 1291 9654088+ 7 HPFS/NTFS
Disk /dev/hdb: 203.9 GB, 203928109056 bytes
255 heads, 63 sectors/track, 24792 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hdb1 1 11 88326 83 Linux
I don't know when to use options like -A (see the help text). The
explanation is too short, and any intelligent guess can just as well
be a stupid one. (Too short for me, at least.)
Perhaps it is better to use dd_rhelp, as this one will probably take
care of -A or not -A to dd_rescue, and you won't have to worry.
I just downoaded and installed dd_rescue to my system, just to look at
whatever help files come bundled. I found an "rpm" made for SuSE, even
I am running Fedora :).
It turned out that the package includes dd_rhelp. I don't know if that
is the case for you, you run debian, was it not?
Caveat:
If you are going to use a Knoppix live CD, is dd_rescue and dd_help
on the live CD?
If not, does the live CD create a ram-fs that you can copy the files
into, from the old disk? Or will you have to mount the old disk, and
run dd_rhelp off the old disk? You will have to do
"PATH=<mountpoint>/path/to/dir:$PATH; export PATH.
Also, notice that dd_rescue/rr_rhelp creates a log file, which
probably will sit in a ram-fs, and get lost if you reboot.
If you don't have dd_rescue on the live CD, I would not use it, I would
use "dd", and only worry about using dd_rescue if "dd" runs into trouble.
Even if "dd" runs into trouble, the difference will be marginal.
Just make sure to include the options "conv=noerror" and "conv=sync"
on the command line, and "dd" will do almost the same effort as dd_rhelp/
dd_rescue. (These two options can be combined into one, like this:
"conv=noerror,sync". Carefull not to have a space after the comma.)
The difference is, as far as I can see, that if you ask "dd" to transfer,
say, 1Mbyte at a time, and there is an error in the middle of that 1Mbyte
transfer, it is *possible* (because I don't have any info about it) that
"dd" will fill the rest of that 1MByte region with zeros, while dd_rescue
says in its help that it will switch to 512-byte blocks for regions with
errors, in order to get at much as possible.
To ask "dd" to transfer 1Mb at a time, use the option "bs=1M". Some
posters have written "ibs=1M obs=1M" - that is the same, specifying
input and output block sizes separately.
Actually, I would not strive for high efficiency for this operation.
You start it, and if it takes four hours or 11 hours, you just go to
bed and let it run, don't you? So, you could even ask "dd" to copy
one sector at a time: just say "bs=512". At least, "dd" does
double buffering, it reads more data into a second buffer while at
the same time writing the previous buffer out to the destination
disk. If the source disk also buffers a track, or even a cylinder at
a time in its internal circuitry, the difference in performance will
not be unbearable for such a one-time operation.
Another poster commented that "cp -a" is more efficient than
"dd", because "dd" copies even blocks that are not in use. But that
is a question of
"Copy entire disk at once"
vs
"create partitions (choose sizes),
create filesystems inside partitions
create mount points inside (future) root fs
mount all new fs'es
mount all old fs'es
cp -a oldroot newroot
chroot newrot
grub-install"
-Enrique
ANT...@zimage.com
Sorry, I think I got a bit confused with the technical explaination. My
apologies.
ANT...@zimage.com
> dd_rescue -h
> To use dd_rescue,
> dd_rescue /dev/hda /dev/hdc
> fdisk -l
Yeah, I was going to ask what's the best way to check my disks before
I goof (I tend to do that!).
> Caveat:
I researched (I am at work). It is either yes or no. Some people had to
download and compile it. I guess if it is not there, I will have to do that.
Does anyone know if it is in 4.0.2 CD (not DVD)?
> If not, does the live CD create a ram-fs that you can copy the files
> into, from the old disk? Or will you have to mount the old disk, and
> run dd_rhelp off the old disk? You will have to do
> "PATH=<mountpoint>/path/to/dir:$PATH; export PATH.
I hope so!
> Also, notice that dd_rescue/rr_rhelp creates a log file, which
> probably will sit in a ram-fs, and get lost if you reboot.
Is that bad? Can I copy to a 3.5" disk?
> If you don't have dd_rescue on the live CD, I would not use it, I would
> use "dd", and only worry about using dd_rescue if "dd" runs into trouble.
OK.
> Even if "dd" runs into trouble, the difference will be marginal.
> Just make sure to include the options "conv=noerror" and "conv=sync"
> on the command line, and "dd" will do almost the same effort as dd_rhelp/
> dd_rescue. (These two options can be combined into one, like this:
> "conv=noerror,sync". Carefull not to have a space after the comma.)
> The difference is, as far as I can see, that if you ask "dd" to transfer,
> say, 1Mbyte at a time, and there is an error in the middle of that 1Mbyte
> transfer, it is *possible* (because I don't have any info about it) that
> "dd" will fill the rest of that 1MByte region with zeros, while dd_rescue
> says in its help that it will switch to 512-byte blocks for regions with
> errors, in order to get at much as possible.
> To ask "dd" to transfer 1Mb at a time, use the option "bs=1M". Some
> posters have written "ibs=1M obs=1M" - that is the same, specifying
> input and output block sizes separately.
> Actually, I would not strive for high efficiency for this operation.
> You start it, and if it takes four hours or 11 hours, you just go to
> bed and let it run, don't you? So, you could even ask "dd" to copy
Yep, or go to work. I hope it gives me statistics. I am just scare with
all the disk activitites, HDD will just stop. Well from Maxtor disk scan
and a benchmark program, no problems. Just took forever! I went to bed
and did something else during those hours. I think this would be longer.
1 MB/sec and I have about 30 GB. I believe that's about 52 minutes?
> one sector at a time: just say "bs=512". At least, "dd" does
> double buffering, it reads more data into a second buffer while at
> the same time writing the previous buffer out to the destination
> disk. If the source disk also buffers a track, or even a cylinder at
> a time in its internal circuitry, the difference in performance will
> not be unbearable for such a one-time operation.
> Another poster commented that "cp -a" is more efficient than
> "dd", because "dd" copies even blocks that are not in use. But that
> is a question of
> "Copy entire disk at once"
Yeah, I like this method. ;)
> vs
> "create partitions (choose sizes),
> create filesystems inside partitions
> create mount points inside (future) root fs
> mount all new fs'es
> mount all old fs'es
> cp -a oldroot newroot
> chroot newrot
> grub-install"
I will try this one if I can't do the quickest way.
Enrique Perez-Terron
>> Also, notice that dd_rescue/rr_rhelp creates a log file, which
>> probably will sit in a ram-fs, and get lost if you reboot.
>
> Is that bad? Can I copy to a 3.5" disk?
One advertised benefit of dd_rhelp is that you can stop the transfer any time,
and continue it afterwards. In order to continue, not just start from the
beginning, it needs to know what had happened before. That is what the log
file is for. If everything works reasonably smooth, you don't need it.
I would not up-end my life just to have this log file, at least not before
I saw that the operation was going to be a very long and unstable one.
There is nothing so far, as I understand it, to indicate things are that
bad.
So, again, if dd_rescue or even also dd_rhelp, are there on the live CD,
beautiful!! Give it a try. If not, don't worry until you see some sign that
its virtues will be needed. The old disk just slowing down is a bad sign
that it may crash soon, in a day, in a month, or in a year. It hasn't
crashed yet!
Once it begins to fail irreparably for some sectors, it becomes
increasingly *convenient* to have tools like dd_rhelp. But in the
end, dd does the same thing, just less conveniently.
dd does output messages about bad sectors it fails to copy.
I have not used it with conv=noerror,sync, so I cannot vouch for
how it behaves in that case. But I have used it in cases where it
stopped because of errors, and it gave me all the info I needed to
issue new commands to copy the rest, had I wanted to. "dd" can
skip the first X blocks when reading, just say "skip=X". Nice if,
say, blocks 0-999 have already been copied, and block 1000 cannot
be copied because of hard defects. "skip=1001". But then you don't
want the output to start at block zero in the destination! Say
"seek=1001" too. That is the kind of inconvenience of "dd".
Except that with "conv=noerror,sync" it does continue automatically,
and you don't have to restart it with skip and seek.
Dd_rescue will stop and retry failed blocks a large number of
times. That is its advantage over dd. But it is also its disadvantage.
if there is an error in an unused block, or in an unimportant file
(how do you know where the error is! this is a tad academic)
dd_rescue will not move on to more important things before it has
tried thoughroughly with every single failing block.
dd_rhelp will record the failures in a log file, and come back to
those spots after having completed copying all that is easy to copy.
In that way, if you prefer to give up those hard defects, you can
just stop any time.
[...]
>> "Copy entire disk at once"
>
> Yeah, I like this method. ;)
I can understand that. One learns a few things from doing the other
approach, but there are more occasions later in life, to learn, and you
don't have to risk ruining your installation because of a mistake.
-Enrique
ANT...@zimage.com
> [...]
Thanks for the detailed "easy-to-understand" explaination. :)