3 May
2007
3 May
'07
4:04 p.m.
More disk copy questions..
Can you copy an entire disk using the UNIX dd command from a smaller disc to
a larger one and retain the capacity of the larger drive?
i.e. maybe create a partition on the larger drive which matches the smaller
drive?
Thanks,
Andy.
3 May
3 May
4:22 p.m.
Andy Piercy wrote:
More disk copy questions..
Can you copy an entire disk using the UNIX dd command from a smaller
disc to
a larger one and retain the capacity of the larger drive?
i.e. maybe create a partition on the larger drive which matches the smaller
drive?
Not without other tools, at least on any OS I work with. dd
overwrites the filesystem's index, superblock, etc, so even if the
partition is bigger than the filesystem, you can't use it.
Doc
5:46 p.m.
--- Doc Shipley <doc at mdrconsult.com> wrote:
dd also seems to have some implementation-specifics
baked into it. On Solaris I was completely unable to
transfer a raw VMS disk image from one drive to
another (identical) one using dd; however the same
transfer worked correctly under Linux.
-Dave
Can you copy
an entire disk using the UNIX dd
command from a smaller
disc to
a larger one and retain the capacity of the larger
drive?
Not without other tools, at least on any OS I
work with. dd
overwrites the filesystem's index, superblock, etc,
so even if the
partition is bigger than the filesystem, you can't
use it. 
6:06 p.m.
On 5/3/07, David Comley <david_comley at yahoo.com> wrote:
dd also seems to have some implementation-specifics
baked into it. On Solaris I was completely unable to
transfer a raw VMS disk image from one drive to
another (identical) one using dd; however the same
transfer worked correctly under Linux.
Hmm... that seems odd. I've worked with dd a lot, and it's pretty
stupid. It does what you ask it to and pretty much not anything else.
Could you have been having issues with the sd driver or with whatever
device you were asking dd to copy to/from? It's not tough to get into
situations where the device driver is doing things seemingly behind
your back because of specifics of the minor number attached to the
/dev/whatever device file and the baggage that implies. It's
especially important with tape devices (rewind/no rewind, compression,
etc.), but it's possible to have issues with using the wrong device
name with disks. If I had to guess, the most likely place for a
problem would be if the beginning of the device from dd's perspective
(its "block 0") didn't translate to physical block 0 on the device due
to the driver skipping over some part of the disk (a few blocks, a
cylinder, etc) masked off for a disk label region or some other
"reserved use".
I'm not disputing that you had problems, I'm just trying to come up
with a mechanism for how it happened.
-ethan
7:12 p.m.
Fully concur with your comments below. After I posted
this earlier I though back over what happened and I
realized that it's probably not dd's fault but more
likely to be some sort of oddball driver issue. I
forget the exact symptom of the failure but I think it
was along the lines of dd being unable to read enough
blocks off the input device despite the math/geometry
stuff working out correctly on paper.
-Dave
--- Ethan Dicks <ethan.dicks at gmail.com> wrote:
On 5/3/07, David Comley <david_comley at
yahoo.com>
wrote:
dd also seems to have some
implementation-specifics
baked into it. On Solaris I was completely unable
to
transfer a raw VMS disk image from one drive to
another (identical) one using dd; however the same
transfer worked correctly under Linux.
Hmm... that seems odd. I've worked with dd a lot,
and it's pretty
stupid. It does what you ask it to and pretty much
not anything else.
Could you have been having issues with the sd
driver or with whatever
device you were asking dd to copy to/from? It's not
tough to get into
situations where the device driver is doing things
seemingly behind
your back because of specifics of the minor number
attached to the
/dev/whatever device file and the baggage that
implies. It's
especially important with tape devices (rewind/no
rewind, compression,
etc.), but it's possible to have issues with using
the wrong device
name with disks. If I had to guess, the most likely
place for a
problem would be if the beginning of the device from
dd's perspective
(its "block 0") didn't translate to physical block 0
on the device due
to the driver skipping over some part of the disk (a
few blocks, a
cylinder, etc) masked off for a disk label region or
some other
"reserved use".
I'm not disputing that you had problems, I'm just
trying to come up
with a mechanism for how it happened.
-ethan
7:32 p.m.
On May 3, 2007, at 1:46 PM, David Comley wrote:
dd also seems to have some implementation-specifics
baked into it. On Solaris I was completely unable to
transfer a raw VMS disk image from one drive to
another (identical) one using dd; however the same
transfer worked correctly under Linux.
This is not dd, but the disk device drivers underlying OS.
-Dave
--
Dave McGuire
Port Charlotte, FL
8:23 p.m.
Dave McGuire wrote:
On May 3, 2007, at 1:46 PM, David Comley wrote:
More specifically, it's the Solaris volume manager, isn't it? I
forget the specific incantation, but it is possible to tell Solaris
"Forget about it" and treat a disk as a raw resource.
It's probably a good thing for most users/workloads, but mostly Sun's
volume manager just irritates me.
Doc
dd also seems to have some
implementation-specifics
baked into it. On Solaris I was completely unable to
transfer a raw VMS disk image from one drive to
another (identical) one using dd; however the same
transfer worked correctly under Linux.
This is not dd, but the disk device drivers underlying OS.
8:57 p.m.
On May 3, 2007, at 4:23 PM, Doc Shipley wrote:
More specifically, it's the Solaris volume manager, isn't it? I
forget the specific incantation, but it is possible to tell Solaris
"Forget about it" and treat a disk as a raw resource.
Nope, nothing at all to do with the volume manager. All it does
is deal with things like automatically mounting filesystems when they
come up, such as when a CDROM is inserted.
The issue concerns partitioning and where "data" starts on the
disk...and most importantly, whether or not that data includes the
block containing the partition table. Traditionally, the "c"
partition on a Unix system means "the whole disk" but unfortunately
(from what I've seen) that doesn't include the block containing the
partition table on some systems.
dd also seems to have some implementation-specifics
baked into it. On Solaris I was completely unable to
transfer a raw VMS disk image from one drive to
another (identical) one using dd; however the same
transfer worked correctly under Linux.
This is not dd, but the disk device
drivers underlying OS. It's probably a good thing for most
users/workloads, but mostly
Sun's volume manager just irritates me.
Same here. Edit /etc/vold.conf to make it ignore the stuff you
want it to.
-Dave
--
Dave McGuire
Port Charlotte, FL
4 May
4 May
8:39 a.m.
So basically you can only use dd to copy to a disk of the same size.
OK so here is the real issue:
I have a faulty Unis system disk that is 142 Mb, it had the sticky bumpers
issue, now repaired but I want to copy the OS and apps to a second
replacement disk, this is a 442 Mb drive.
There seems to be a bug with the standalone floppies in that the restore
program will not restore dump tapes created and verified in single user
mode. bummer!
I only have the Unix OS distribution floppies and not the applications.
So can I rebuild a working disk by..
1) Use the floppies to build a new operating system on to the 442Mb drive.
2) Mount the faulty 144 Mb drive with all of the apps etc.
3) Copy using cp, tar, cpio, all of the contents from the faulty drive to
the new drive and over write
all of the os, will this work? Unix should be in memory so maybe the system
wont crash? (would cp -r be the best command here)
4) Remake the root \Unix file from all of the newly copied data / files
5) Reboot the system..... and hope!
Any ideas on this approach?
Or I could create a second partition and copy the files from the faulty
drive to the it? and copy over the contents, but basically the same as above
because the app files are all over the file system.....
Or how about creating a complete cpio disk image to cart tape?
Ta,
Andy.
On 03/05/07, Dave McGuire <mcguire at neurotica.com> wrote:
On May 3, 2007, at 4:23 PM, Doc Shipley wrote:
More specifically, it's the Solaris volume manager, isn't it? I
forget the specific incantation, but it is possible to tell Solaris
"Forget aboit" and treat a disk as a raw resource.
Nope, nothing at all to do with the volume manager. All it does
is deal with things like automatically mounting filesystems when they
come up, such as when a CDROM is inserted.
The issue concerns partitioning and where "data" starts on the
disk...and most importantly, whether or not that data includes the
block containing the partition table. Traditionally, the "c"
partition on a Unix system means "the whole disk" but unfortunately
(from what I've seen) that doesn't include the block containing the
partition table on some systems.
dd also seems to have some implementation-specifics
baked into it. On Solaris I was completely unable to
transfer a raw VMS disk image from one drive to
another (identical) one using dd; however the same
transfer worked correctly under Linux.
This is not dd, but the disk device
drivers underlying OS. It's probably a good thing for most
users/workloads, but mostly
Sun's volume manager just irritates me.
Same here. Edit /etc/vold.conf to make it ignore the stuff you
want it to.
-Dave
--
Dave McGuire
Port Charlotte, FL
8 p.m.
Andy Piercy wrote:
I only have the Unix OS distribution floppies and not
the applications.
So can I rebuild a working disk by..
1) Use the floppies to build a new operating system on to the 442Mb drive.
2) Mount the faulty 144 Mb drive with all of the apps etc.
3) Copy using cp, tar, cpio, all of the contents from the faulty drive to
the new drive and over write
all of the os, will this work?
I think I'd do it something like:
1) 'dd' the small drive to temporary storage on a Linux box (or
whatever) "just in case"
2) Boot the system with the larger disk in and do an install from floppy.
3) Reboot the system with the smaller drive fitted as a second disk.
4) Use 'find', 'diff' etc. to work out differences between the two and
copy files across from the small disk accordingly.
If the small drive goes bang during that process you've always got the Linux
raw backup which can be put onto any old drive (raw) and booted from (I'd
suggest using a sacrificial drive to *test* your backup as step 1.5 above,
incidentally :-)
I can't remember what system it is now (or if you even said), but the
important thing to do is generally not to overwrite any boot information
(which on most systems also means not overwriting / moving the kernel).
Providing the system can execute the boot code, locate and start the kernel
the the filesystem driver(s) should take over and be able to find all the
other files on the disk.
cheers
Jules
3 May
3 May
7:33 p.m.
On May 3, 2007, at 12:04 PM, Andy Piercy wrote:
More disk copy questions..
Can you copy an entire disk using the UNIX dd command from a
smaller disc to
a larger one and retain the capacity of the larger drive?
i.e. maybe create a partition on the larger drive which matches the
smaller
drive?
Definitely not. dd does not understand filesystems, only bytes
and blocks.
-Dave
--
Dave McGuire
Port Charlotte, FL
6448
days inactive
6449
days old
10 comments
6 participants
participants (6)
-
andy.piercy＠gmail.com -
david_comley＠yahoo.com -
doc＠mdrconsult.com -
ethan.dicks＠gmail.com -
julesrichardsonuk＠yahoo.co.uk -
mcguire＠neurotica.com