On Thu Jul 01 1999 at 10:46, Robert Risch wrote in the Tom's RootBoot
mailing list:
> Ed G. schrieb:
[ heaps of stuff jettisoned ]
> > I don't mean to be rude, but I really don't see why disk geometry is
> > an issue. Perhaps you can help me understand why it is. Have I
> > missed something? Have you personally had bad experiences
> > using dd to copy partitions?
>
> This is a good idea. Can I make a 500 MB partition(with the batch version
> of fdisk: sfdisk) on any HD with
> at least 500 MB and than dd a 500MB partition installed on
> an other HD.
Yes, of course. But you need to be careful doing it, as the *inode*
structure (or FAT table or whatever) of the filesystem is also exactly
copied. The partitions need to be *exactly* the same size, or the
underlying filesystem format will be corrupted.
Better to do the data transfer with something like cp-a, cpio, or tar
(in a gzip9-compressed data stream if you are doing it over a network
link using something like netcat)... this way you don't have to worry
about coping the filesystem ext2/fat/hpfs/whatever format onto
different partition sizes.
> If this is possible, must the partition start at the
> same logical sector as on the original install.
The content of partitions is a different issue to the physical sectors
on which they reside. This is sorted out in the partition table
itself. It seems that you might be confusing the partition table with
the logical format of the filesystem(s) that they contain. These are
two different issues (although the partition table does contain an ID
that identifies the type of filesystem on each partition - you'll need
to be careful about this).
This is a matter for the partition *table* in the very first sectors of
the hard drive. It's not an issue here, since we are talking about
partition *content*.
> The question is
> how are the sectors addressed within the FS (ext2, OS/2 HPFS,
> DOS FAT, NTFS), relative to the start of the partition or with
> absolute values.
If, for example, a 500Mb partition image was dd'ed onto a bigger
partition, say 600Mb, then you'll have filesystem conflicts
(irrespective of what sort of partition it is) that are likely to
result as a consequence of only 500Mb of the 600Mb partition being
properly formatted. You'll either "loose" 100Mb, or the
inconsistencies will cause things to crash sooner or later.
> I think they use absolute values because
> partition moving tools like partition magic must know the FS
> of the moved partition.
Yes, of course. Utilities like PM need to know how to manipulate the
underlying filesystem, not just the partition table.
> An other question:
> Have somebody used a CDR with tomsrtbt? For me it is not
> importend to have a filesystem on the CD. A raw dd from
> my partition would be good for backup reasons.
I burn a lot of CDROMs, some with the tomsrtbt ElTorito image as the
boot image (which works well). But I suspect that using tomertbt by
dd'ing data directly into the CDR device would not work as you seem to
expect. But then again, I've never actually tried it.
There's a brilliant FAQ on CDROM recording that you should check out:
Andy McFadden's CD-Recordable FAQ
http://www.fadden.com/cdrfaq/
> OK, if I have
> a full installed Linux system I can use that. However, if I
> can go to a friend with a W95 System :-( I connect an
> ATAPI CD-Writer , insert my special CDR tomsrtbt and
> start an backup of his partition (If the compressed image
> has only 500 MB).
For such things, it would probably be better to put create a proper
ISO9660 image (with joliet/rockridge extensions) onto the disk so that
the data on it can be accessed easily (ie, "normally").
If you dd an image, you are also taking a "snapshot" of the underlying
filesystem structure on the partition, not just the data contained by
it. Consequently you would only be able to restore that entire
snapshot, and it must go onto a partition of exactly the same size it
was taken from. Restoring from your backup will totally obliterate
any changes that might have been made.
Restoring from the backup would be a simple matter (heh, simple
describes windoze very well! :) of (selectively) copying files off the
CDROM directly from a running system. Or you could boot from a dos
floppy with a cdrom driver and use fdisk.exe, format.exe, sys.exe and
so on, then copy everything you need from the cdrom. (With headaches
to solve resolving using dos with long filenames). Of course, you can
also boot tomsrtbt which knows all about FAT partitions and do
something like "cp -a", or a function similar to this:
bigmv () { ( cd $1 && tar cfps - . )|( cd $2 && tar xvvvpf - ) ; }
Better to create a second (linux ext2) disk with the mkisofs and
cdrecord utilities on it, mount it from tomsrtbt, and use them that
way.
It's possible to get mkisofs to create the iso image to standard
output, and for cdrecord to take the iso image from standard input, so
you can do it all without the need for extra space to create a large
iso image anywhere.
(Warning: tomsrtbt is built using the old obselete libc5 libraries, so
you'll be best to use libc5-built and linked versions of cdrecord and
mkisofs... I'm not even sure that the latest versions will compile
with glibc2.x).
> For this reason a HD filed with zero's is
> a good idea as Pierre mentioned.
No. Putting zero's into the raw device will destory the filesystem
format. It's still a good thing to do, but do the zero'ing and *then*
format the partition!
> I than can leave a tomsrtbt restore disk with a automatic
> restore script for him. If something gets broken, he put
> the disk and CDR I created into the PC and starts.
Perhaps, but I wouldn't do what you are suggesting for the purposes
that you describing - it's too inflexable.
> If the CD has a filesystem:
> mount /dev/hdc /cdrom
> dd if=/cdrom/imageofw95 | gzip -d9v | dd of=/dev/hda
> Or if a raw write to the CDR is possible and there is
> no filesystem nessesary:
> dd if=/dev/hdc | gzip -d9v | dd of=/dev/hda
I wouldn't do it like this myself, but I'd like to know if anyone has
actually been successful doing anything like this.
> This way all filesystems (HPFS, NTFS or other)
> can be backuped. There is no need for support
> for this filesystem in the kernel.
Point.
> With netcat and an linux box connected to the net
> this creating process must be possible.
As it turns out, it's almost trivial. (Although you need to run
netcat at both ends of the link... getting it going on a remote server
is a small logistical problem that isn't too difficult to overcome).
Enough of my rantings and ravings.... :)
Cheers
Tony
