SEO

My 4GB HDD is dying. I need to transfer it ASAP to another HDD. I
tried copying it to an 8.4GB HDD I had lying around. I used Partition
Magic (hereby PM) to copy all partitions and at first all seemed well.
But when I tried to boot using the new HDD, it refused. I used Linux's
fdisk to view it and was surprised that Linux's "Extended" partition
(id=5)is not the same as the one PM placed while copying the various
partitions (id=f). I corrected it, but I am still having problem
copying the /boot partition so that it would boot.

My original (failing) HDD looks like this:

~> /sbin/fdisk -lu /dev/hda
Device Boot Start End Blocks Id System
/dev/hda1 63 40319 20128+ 83 Linux
/dev/hda2 40320 7814015 3886848 5 Extended
/dev/hda5 40383 3322367 1640992+ 83 Linux
/dev/hda6 3322431 6604415 1640992+ 83 Linux
/dev/hda7 6604479 7136639 266080+ 83 Linux
/dev/hda8 7136703 7668863 266080+ 83 Linux
/dev/hda9 7668927 7805951 68512+ 82 Linux swap


The new disk, OTOH, has for some reason (the way PM set it up), the
extended partition as /dev/hdb1 and the boot partition as /dev/hdb2
(all other partitions are correctly positioned/copied).

My questions are:
1) Why is PM and fdisk are having such a hard time "talking" to each
other?
2) How do I copy the /boot partition, so that not only its contents is
copied but it also boots when I replace the old HDD with the new HDD
(i.e. /dev/hdb becomes /deb/hda). Do I use LILO to do that? If so, how
do I change lilo.conf so that it doesn't change in anyway the original
drive (I still need it, in case something goes awfully wrong with the
new HDD. I cannot boot from a floppy).

Thanks in advance!

On 29 Sep 2003 09:38:25 -0700, Linux Lover <linuxlover992000@yahoo.com> wrote:

I'd mount the new drive and use cfdisk to lay out the partitions, then
format each one with mke2fs.

Then mount each partition and from each top-level directory to be copied, run
cp -a * /mnt/whatever.

Then edit /etc/fstab and /etc/lilo.conf on the new system and run lilo.

--
Later, Alan C
You can find my email address at the website:
elrav1.html --> ACKNOWLDEGEMENTS/CONTACT (20k or less, plain text)
take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a

Linux Lover <linuxlover992000@yahoo.com> wrote:
> My 4GB HDD is dying. I need to transfer it ASAP to another HDD. I
> tried copying it to an 8.4GB HDD I had lying around. I used Partition
> Magic (hereby PM) to copy all partitions and at first all seemed well.

Don't use PM. Just use normal tar. Or cp.


> But when I tried to boot using the new HDD, it refused. I used Linux's

Well, why would you expect it to boot? The mbr will be all wrong, no?

> fdisk to view it and was surprised that Linux's "Extended" partition
> (id=5)is not the same as the one PM placed while copying the various
> partitions (id=f). I corrected it, but I am still having problem

Doesn't matter. Just don't use PM anyway!

> copying the /boot partition so that it would boot.

Why are you copying! Don't! Just edit your $&&$&$$ lilo.conf to bvecome
correct and run lilo!

> 1) Why is PM and fdisk are having such a hard time "talking" to each
> other?

They aren't. You are. Don't use PM.

> 2) How do I copy the /boot partition, so that not only its contents is

What's your problem with "cp"?

Peter

> My 4GB HDD is dying. I need to transfer it ASAP to another HDD. I
> tried copying it to an 8.4GB HDD I had lying around. I used Partition
> Magic (hereby PM) to copy all partitions and at first all seemed well.
> But when I tried to boot using the new HDD, it refused. I used Linux's
> fdisk to view it and was surprised that Linux's "Extended" partition
> (id=5)is not the same as the one PM placed while copying the various
> partitions (id=f). I corrected it, but I am still having problem

Correcting it may not be the correct word. I guess PM corrected
the incorrect original table for you. Anyway 0x05 may be wrong,
0x0F won't be. Use 0x0F instead. (or 0x85 in your case as there are
only linux partitions inside)

> copying the /boot partition so that it would boot.

That won't work.
Make a bootflop, boot from that, and afterwards run lilo to fix
the MBR. Or use grub (I can't believe I said that ;-) ).

> My original (failing) HDD looks like this:
>
> ~> /sbin/fdisk -lu /dev/hda

Don't skip the geometry info.
For hda it's not that important, but to tell if PM fixed something
or just prefers to be on the safe side, the geometry info if hdb
is important

> Device Boot Start End Blocks Id System
> /dev/hda1 63 40319 20128+ 83 Linux
> /dev/hda2 40320 7814015 3886848 5 Extended
> /dev/hda5 40383 3322367 1640992+ 83 Linux
> /dev/hda6 3322431 6604415 1640992+ 83 Linux
> /dev/hda7 6604479 7136639 266080+ 83 Linux
> /dev/hda8 7136703 7668863 266080+ 83 Linux
> /dev/hda9 7668927 7805951 68512+ 82 Linux swap
>
>
> The new disk, OTOH, has for some reason (the way PM set it up), the
> extended partition as /dev/hdb1 and the boot partition as /dev/hdb2

I have no idea how you copied the disc in PM. If you can just say to
copy a disc as a whole, blame it on PM. If you manually selected the
partitions to be copied, you probably selected hem in the wrong order.

Anyway, use fdisk to partition the new disc, and use cp to copy the
data. (or tar or cpio or whatever)

> (all other partitions are correctly positioned/copied).
>
> My questions are:
> 1) Why is PM and fdisk are having such a hard time "talking" to each
> other?

?
They don't talk to each other. The follow a certain ruleset that
describes a valid partitiontable. linux fdisk doesn't have all
DOS/windows limitations incorporated though. PM is usually more strict.
(or more on the safe side)

> 2) How do I copy the /boot partition, so that not only its contents is
> copied but it also boots when I replace the old HDD with the new HDD
> (i.e. /dev/hdb becomes /deb/hda). Do I use LILO to do that? If so, how
> do I change lilo.conf so that it doesn't change in anyway the original
> drive (I still need it, in case something goes awfully wrong with the
> new HDD. I cannot boot from a floppy).

Booting from a floppy would be easiest.
If that's not possible, create a temporary lilo.conf that expicitly
states that hdb is known by the BIOS as 0x80. lilo will probably
complain when you run it, as that information is incorrect at that time.
It will however make hdb bootable after hda is disconnected.

Eric

Eric - thank you so much for your thoughtful answer!

Eric Moors <scare.crow@oz.land> wrote in message news:<pan.2003.09.30.08.52.49.798860.10893@oz.land >...
> > fdisk to view it and was surprised that Linux's "Extended" partition
> > (id=5)is not the same as the one PM placed while copying the various
> > partitions (id=f). I corrected it, but I am still having problem
>
> Correcting it may not be the correct word. I guess PM corrected
> the incorrect original table for you. Anyway 0x05 may be wrong,
> 0x0F won't be. Use 0x0F instead. (or 0x85 in your case as there are
> only linux partitions inside)

You may be correct (no pun intended ) but I have been running this
server for years while it was with id=5. I didn't specify it. RedHat
6.2's install program partitioned everything automatically (at the
time of the install back then, I just accepted the installation
program's defaults).

> > copying the /boot partition so that it would boot.
>
> That won't work.
> Make a bootflop, boot from that, and afterwards run lilo to fix
> the MBR. Or use grub (I can't believe I said that ;-) ).

That's exactly (sort of) what I did. I used Linuxcare's Bootable
Toolbox CD. (don't ask how difficult it was to burn that CD... Nero on
W2K wouldn't burn it *bootable*. Fortunately, my old Linux HDD was
still somehow operable, so I used cdrecord to do that.)

> Don't skip the geometry info.

What do you mean by that? Where did I skip the geometry info?

> > The new disk, OTOH, has for some reason (the way PM set it up), the
> > extended partition as /dev/hdb1 and the boot partition as /dev/hdb2
>
> I have no idea how you copied the disc in PM. If you can just say to
> copy a disc as a whole, blame it on PM. If you manually selected the
> partitions to be copied, you probably selected hem in the wrong order.

That was exactly the problem: I simplified my original posting by
describing th e destination disk as new. It is newer then the faulty
one, but it had one partition I couldn't loose (nor backup, since the
backup program was on the faulty drive and ceased functioning
properly). It was /home ...

so, I had to use PM to resize, move, add, delete, add, etc.
PM didn't have any problem with that: it reported the partitions
according to their physical order. I thought Linux's fdisk would do
that, too. It didn't.

> Anyway, use fdisk to partition the new disc, and use cp to copy the
> data. (or tar or cpio or whatever)

I couldn't. I used the convoluted ordering as above. Used LBT to run
lilo (very carefully) and bingo - it works! MBR now on /dev/hda, which
happens to be reported by fdisk ad /dev/hda2. Weird (but works ).

>> > fdisk to view it and was surprised that Linux's "Extended" partition
>> > (id=5)is not the same as the one PM placed while copying the various
>> > partitions (id=f). I corrected it, but I am still having problem
>>
>> Correcting it may not be the correct word. I guess PM corrected
>> the incorrect original table for you. Anyway 0x05 may be wrong,
>> 0x0F won't be. Use 0x0F instead. (or 0x85 in your case as there are
>> only linux partitions inside)
>
> You may be correct (no pun intended ) but I have been running this
> server for years while it was with id=5.

0x05 is correct as far as linux is concerned. Even for DOS/windows
it may be correct. Depends on the location of the partition. If it is
even partly beyond cylinder 1024, DOS/windows requires the type to be
0x0F.

> I didn't specify it. RedHat
> 6.2's install program partitioned everything automatically (at the
> time of the install back then, I just accepted the installation
> program's defaults).

There's no harm in having it 0x05 in your case. Linux doesn't care.
Windows get's confused if it isn't correct. That's why PM tries to fix
the table if something doesn't match the windows requirements.

>> Don't skip the geometry info.
>
> What do you mean by that? Where did I skip the geometry info?

The output from fdisk -l also contains geometry info. (CHS values)
You didn't include them in your post.

> That was exactly the problem: I simplified my original posting by
> describing th e destination disk as new. It is newer then the faulty
> one, but it had one partition I couldn't loose (nor backup, since the
> backup program was on the faulty drive and ceased functioning
> properly). It was /home ...
>
> so, I had to use PM to resize, move, add, delete, add, etc.
> PM didn't have any problem with that: it reported the partitions

Then that's how they got shuffled. It doesn't really matter though.

> according to their physical order. I thought Linux's fdisk would do
> that, too. It didn't.

both programs report the table as found on disc. If the output is
different, there is something weird with your table. I do trust the
output of fdisk though, so I believe they are shuffled. This isn't
wrong, just a bit awkward. You could easily reorder the partitions
with sfdisk, but I wouldn't bother.

>> Anyway, use fdisk to partition the new disc, and use cp to copy the
>> data. (or tar or cpio or whatever)
>
> I couldn't.

From a rescue system you would have been able to do this.

> I used the convoluted ordering as above. Used LBT to run
> lilo (very carefully) and bingo - it works! MBR now on /dev/hda, which
> happens to be reported by fdisk ad /dev/hda2. Weird (but works ).

?
The MBR is *never* part of a partition.
I think you mean your boot partition (I guess) is now hda2 instead of
hda1. That may hold a boot record, but not the master boot record.

Eric

Eric Moors <scare.crow@oz.land> wrote in message news:<pan.2003.09.30.16.28.25.38915.12123@oz.land> ...
> The MBR is *never* part of a partition.
> I think you mean your boot partition (I guess) is now hda2 instead of
> hda1. That may hold a boot record, but not the master boot record.

Thanks for this clarification. I am ashamed to admit that I wasn't
aware of this distinction. I thought that the boot record of the first
sector in a HDD (usually hda1, but in my case is hda2) is also the
boot record of hda (which is the MBR). Obviously, this is not so.

(To my defense, I would just mention that I *used* to know what you've
just explained. I just fell asleep for a week or two... )

You guessed correctly that my boot partition is now hda2 (which is
physically located *before* hda1).

Linux Lover wrote:

> Eric Moors <scare.crow@oz.land> wrote in message news:<pan.2003.09.30.16.28.25.38915.12123@oz.land> ...
>
>>The MBR is *never* part of a partition.
>>I think you mean your boot partition (I guess) is now hda2 instead of
>>hda1. That may hold a boot record, but not the master boot record.

??? It most certainly can be, or what do you think "grub-install
/dev/hda1" does?

The MBR is typically installed at the beginning of the disk, but it can
also be accessed via a partition marked as "active". I'm not sure how
many other ways there are to locate one.

> Thanks for this clarification. I am ashamed to admit that I wasn't
> aware of this distinction. I thought that the boot record of the first
> sector in a HDD (usually hda1, but in my case is hda2) is also the
> boot record of hda (which is the MBR). Obviously, this is not so.

That is correct. One of the most confusing things to run into is when
one person or tool installed an MBR in /dev/hda, and another tool put
one in /dev/hda1, and the one iin /dev/hda takes precedence.

> (To my defense, I would just mention that I *used* to know what you've
> just explained. I just fell asleep for a week or two... )
>
> You guessed correctly that my boot partition is now hda2 (which is
> physically located *before* hda1).

Why would you ever do this? I know Compaq does this sort of whackiness
with their system management tools, putting it on /dev/sda3 which is
located at the beginning of the disk, and it still irritates the hell
out of me....

On Thu, 02 Oct 2003 06:54:03 +0200, Nico Kadel-Garcia wrote:

> Linux Lover wrote:
>
>> Eric Moors <scare.crow@oz.land> wrote in message news:<pan.2003.09.30.16.28.25.38915.12123@oz.land> ...
>>
>>>The MBR is *never* part of a partition.
>>>I think you mean your boot partition (I guess) is now hda2 instead of
>>>hda1. That may hold a boot record, but not the master boot record.
>
> ??? It most certainly can be, or what do you think "grub-install
> /dev/hda1" does?

It installs the bootloader GRUB in hda1.
NOT in the MBR
grub-install /dev/hda would do that (I guess: I'm a lilo user)

The MBR is *always* located at CHS=001
try `fdisk -lu`
check where hda1 starts.

> The MBR is typically installed at the beginning of the disk, but it can
> also be accessed via a partition marked as "active".

no way.
mark eg. hda5 active. and reboot.
nothing changes. (unless your MBR contains the default DOS loader)
grub and lilo, usually installed partly in the MBR will ignore
this.

> I'm not sure how many other ways there are to locate one.

There can be only one. (finally a highlander quote I can use ;-))
The MBR is always at cyl 0, head 0, sector 1.
There is always discussion whether you can call the MBR at a second
disc (hdb) also MBR, 'cause there can be only one (Did it again :-))
You cannot remove it, you cannot relocate it.
You obviously can blank it, and remove all bootcode from it.
You can even remove the partitiontable entries from it.
But that's basically it.

>> Thanks for this clarification. I am ashamed to admit that I wasn't
>> aware of this distinction. I thought that the boot record of the first
>> sector in a HDD (usually hda1, but in my case is hda2) is also the
>> boot record of hda (which is the MBR). Obviously, this is not so.
>
> That is correct. One of the most confusing things to run into is when
> one person or tool installed an MBR in /dev/hda, and another tool put
> one in /dev/hda1, and the one iin /dev/hda takes precedence.

You are mixing up bootrecords with bootcode.

>> (To my defense, I would just mention that I *used* to know what you've
>> just explained. I just fell asleep for a week or two... )
>>
>> You guessed correctly that my boot partition is now hda2 (which is
>> physically located *before* hda1).
>
> Why would you ever do this? I know Compaq does this sort of whackiness
> with their system management tools, putting it on /dev/sda3 which is
> located at the beginning of the disk, and it still irritates the hell
> out of me....

Please read the original post. The OP did this unintentionally.
Though I agree that it is annoying, it is not incorrect as far as I know.

Eric