Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Seeking advice on transferring OS to new drive

5 views
Skip to first unread message

Brian K. Meadows

unread,
Jul 4, 1997, 3:00:00 AM7/4/97
to

I'm getting ready to install a new HD into my Intel box and need some
advice on what tools to use and how I should organize the transfer of
my OS. Right now I have two internal SCSI drives, each partitioned
into Next/Windows. Sd0 has everything except /Local/Apps which
resides on sd1. Without doing a cold install of Next/OpenStep, is
there a good way to migrate onto my new drive. I've got my system
tricked out and it would save a lot of time if I don't have to
reinstall and tweak every application. In addition I've got an
external Jazz drive available.

Any and all advice is appreciated.

Brian Meadows

______________________________________
Brian K. Meadows
Applied Chaos Laboratory
School of Physics
Georgia Institute of Technology
Atlanta, GA 30332-0430
phone: (404) 894-1448
fax: (404) 894-9958
email: bmea...@acl.gatech.edu
WWW: http://acl.gatech.edu
______________________________________

Axel Habermann

unread,
Jul 4, 1997, 3:00:00 AM7/4/97
to

Brian K. Meadows <bmea...@acl.gatech.edu> wrote:
: I'm getting ready to install a new HD into my Intel box and need some

: advice on what tools to use and how I should organize the transfer of
: my OS. Right now I have two internal SCSI drives, each partitioned
: into Next/Windows. Sd0 has everything except /Local/Apps which
: resides on sd1. Without doing a cold install of Next/OpenStep, is
: there a good way to migrate onto my new drive. I've got my system
: tricked out and it would save a lot of time if I don't have to
: reinstall and tweak every application. In addition I've got an
: external Jazz drive available.

This should really go to the FAQ.

Depending on what version of NS/OS you use you might not want to
use possibly buggy GUI Tools like BuildDisk.

I have successfully transferred whole installations using either of
two methods:

Connect the new disk, using a spare ID. If it's smaller than 2GB
and you wnat to use the whole disk for NeXTSTEP, you might let the
Workspace initialize it, else use fdisk and/or a disktab entry
and disk

When the newly created NS partition is mounted, copy the whole
stuff over using

cd /
gnutar -cf - | (cd /newdisk; gnutar -xpf -)

or

cd /newdisk
dump 0f - / | restore rf -

When using dump/restore, be sure you have a working restore
(restore had a bug in 3.3 IIRC, the 3.3patch should be ok)

Depending on what you want to achive, you can repeat
the last step for /LocalApps

After having copied everything, the newdisk is identical
to your old /, so now you could change the id of the
new disk to something lower an boot off it or make a kickdisk
configuration on /.

HTH
--
Axel Habermann
ki...@buran.fb10.tu-berlin.de Fon:+49 30 45478986 Fax:4542296

Die Dateien, in denen die Programmdokumentation enthalten ist,
haben normalerweise die Endung ".c", -- Kristian Koehntopp

Rex Dieter

unread,
Jul 5, 1997, 3:00:00 AM7/5/97
to


Axel Habermann <ki...@buran.fb10.tu-berlin.de> wrote in article
<5pjmsn$8li$2...@brachio.zrz.TU-Berlin.DE>...


> Brian K. Meadows <bmea...@acl.gatech.edu> wrote:
> : I'm getting ready to install a new HD into my Intel box and need some
> : advice on what tools to use and how I should organize the transfer of
> : my OS. Right now I have two internal SCSI drives, each partitioned

> I have successfully transferred whole installations using either of
> two methods:
>

> When the newly created NS partition is mounted, copy the whole
> stuff over using
>
> cd /
> gnutar -cf - | (cd /newdisk; gnutar -xpf -)

Eek... You lose some permissions (like SUID bits) using just tar.

> or
>
> cd /newdisk
> dump 0f - / | restore rf -

better.

Why not just use 'ditto'??

I guess if ditto'ing a WHOLE disk, you'd better be careful not to say:

ditto / /newdisk

(That might get into recursive copying... trying to copy /newdisk into
/newdisk/newdisk, etc...).

OK, then do:

ditto /all /root /dirs /except /newdisk

(You get the idea). (-;

---
Rex Dieter
Computer System Manager
Department of Mathematics and Statistics, UNL
http://www.math.unl.edu/~rdieter/

John Kheit

unread,
Jul 5, 1997, 3:00:00 AM7/5/97
to

"Rex Dieter" <rdi...@math.unl.edu> wrote:
> Axel Habermann <ki...@buran.fb10.tu-berlin.de> wrote in article
> <5pjmsn$8li$2...@brachio.zrz.TU-Berlin.DE>...
> > Brian K. Meadows <bmea...@acl.gatech.edu> wrote: I have

> > successfully transferred whole installations using either of
> > two methods: When the newly created NS partition is mounted,
> > copy the whole stuff over using
> >
> > cd / gnutar -cf - | (cd /newdisk; gnutar -xpf -)

> Eek... You lose some permissions (like SUID bits) using just tar.

Zactly.... "ditto [source] [destination]" works fantastic for
this... I just wish I knew a way to ditto|tar|gz !!! Then I could
make nice perfectly compressed backups and restore gz|tar|ditto
back to the drive...

But for duping a disk, ditto is great.


> ditto / /newdisk
> (That might get into recursive copying... trying to copy /newdisk
> into /newdisk/newdisk, etc...).
> OK, then do:
> ditto /all /root /dirs /except /newdisk
> (You get the idea). (-;

I usually kick off an optical drive and ditto from one or another.
Ditto, for example, cannot copy the swapfile.front file... The
solution I have is a bit hacky but it works... I make a bom file,
then change the swapfile.front file to swapfile.fronz and put an
empty file in the same directory as swapfile.front titled
swapfile.fronz...That way I can do a ditto on the active drive in
its entirety doing a ditto bom [source] [destination]. But rather
than hassel with that I just kick from the optical...
--
Thanks, be well, take care, later, John Kheit; Self expressed...
__________________________________________________________________
monoChrome, Inc. ASCII, MIME, PGP, SUN, & NeXTmail OK
NeXT/OPENSTEP Developer mailto:jkh...@cnj.digex.net
Telepathy, It's coming... http://www.cnj.digex.net/~jkheit
New York Law School You're dangerous because you're honest

John Kheit

unread,
Jul 5, 1997, 3:00:00 AM7/5/97
to

John Kheit <jkh...@cnj.digex.net> wrote:
> I usually kick off an optical drive and ditto from one or another.
> Ditto, for example, cannot copy the swapfile.front file... The
> solution I have is a bit hacky but it works... I make a bom
> file, then change the swapfile.front file to swapfile.fronz and
> put an empty file in the same directory as swapfile.front titled
> swapfile.fronz...That way I can do a ditto on the active drive
> in its entirety doing a ditto bom [source] [destination]. But
> rather than hassel with that I just kick from the optical...

It's late and I ought to be asleep :) BTW, happy 4th to all us
yankees (and all our friends across the pond that are glad to be
rid of us :). Anyway, when I said "change the swapfile.front file"
above...I mean edit the bom file... That's why I just change the
one character in it, b/c bom files are binary and not ascii...and
as a general rule it's a bad idea to edit and then manipulate
binaries like that...

Timothy Luoma

unread,
Jul 6, 1997, 3:00:00 AM7/6/97
to

John Kheit <jkh...@cnj.digex.net> wrote:

>Ditto, for example, cannot copy the swapfile.front file... The
>solution I have is a bit hacky but it works...

Why would you want to?

The swapfile.front file is not a real file, but just a file used in making a
compressed swapfile.

There's no real reason to copy that, or the regular swapfile, for that
matter.

Well, the original swapfile might have value because it can be re-used, and
usually you want a swapfile that is around 16 megs. When you reboot it will
be trimmed back to the LOWAT.

Still, there's no need to copy the swapfile.front

TjL

ps -- Hebrew started as of 2 July, and ends on 22 August, so
please understand if responses are slow. I am taking a 2
semester class in 8 weeks for 6 credits

--
TjL <luo...@peak.org>

John Kheit

unread,
Jul 6, 1997, 3:00:00 AM7/6/97
to

Timothy Luoma <luo...@peak.org> wrote:
> John Kheit <jkh...@cnj.digex.net> wrote:
> >Ditto, for example, cannot copy the swapfile.front file... The
> >solution I have is a bit hacky but it works...
> Why would you want to?

I dont, but ditto does...


> The swapfile.front file is not a real file, but just a file used
> in making a compressed swapfile.

> There's no real reason to copy that, or the regular swapfile,
> for that matter.

> Well, the original swapfile might have value because it can be
> re-used, and usually you want a swapfile that is around 16 megs.
> When you reboot it will be trimmed back to the LOWAT.

> Still, there's no need to copy the swapfile.front


Righto. The problem is if you try to ditto your root (i.e. "/")
to another drive, say "/myDrive"...by doing a "ditto / /myDrive"
then ditto TRYS to copy swapfile.front, and fails b/c it cant (for
just the reasons you state above)... that hack I showed in the
previous post get's around this problem if you don't have an extra
drive to boot off to do a safer ditto...(hope I was a little more
clear...)

(BTW Tim, I've been trying to send you email, but they keep
bouncing...seems that my ISP set up a new spam filter system that
filters some of my outgoing email to certain domains--arg--so I
wasn't able to respond directly to some of your posts...but hopefully
you saw them posted...weird thing is that I can GET email from just
about anyone so go figure what the heck they have going on w/ them
spam filters...)

Axel Habermann

unread,
Jul 6, 1997, 3:00:00 AM7/6/97
to

Charles William Swiger <cs...@andrew.cmu.edu> wrote:
: Excerpts from netnews.comp.sys.next.sysadmin: 5-Jul-97 Re: Seeking
: advice on trans.. by "Rex Dieter"@math.unl.ed
: >> When the newly created NS partition is mounted, copy the whole
: >> stuff over using
: >>
: >> cd /
: >> gnutar -cf - | (cd /newdisk; gnutar -xpf -)
: >
: > Eek... You lose some permissions (like SUID bits) using just tar.

: That's what the 'p' option is for. From 'man tar':

: p This modifier says to restore files to their ori-
: ginal modes, ignoring the present umask(2).
: Setuid and sticky information will also be
: restored to the super-user.

Thanks Chuck,

but there's still something to desire...

So being root, do the following:

cd /
gnutar -clf - | (cd /newdisk; gnutar -xpf -)

The l pretends gnutar from entering other filesystems mounted somewhere.

Timothy J. Luoma

unread,
Jul 6, 1997, 3:00:00 AM7/6/97
to

In <5po13u$b9h$1...@brachio.zrz.TU-Berlin.DE> Axel Habermann wrote:
> Charles William Swiger <cs...@andrew.cmu.edu> wrote:
> : Excerpts from netnews.comp.sys.next.sysadmin: 5-Jul-97 Re: Seeking
> : advice on trans.. by "Rex Dieter"@math.unl.ed
> : >> When the newly created NS partition is mounted, copy the whole
> : >> stuff over using
> : >>
> : >> cd /
> : >> gnutar -cf - | (cd /newdisk; gnutar -xpf -)
> : >
> : > Eek... You lose some permissions (like SUID bits) using just tar.
>
> : That's what the 'p' option is for. From 'man tar':
>
> : p This modifier says to restore files to their ori-
> : ginal modes, ignoring the present umask(2).
> : Setuid and sticky information will also be
> : restored to the super-user.

[snip]


> cd /
> gnutar -clf - | (cd /newdisk; gnutar -xpf -)
>
> The l pretends gnutar from entering other filesystems mounted somewhere.

I'm pretty sure you meant 'prevent' rather than 'pretend'.

Would you need to specify the 'p' flag when you make the archive as well as
when you un-archive?

gnutar -clfp - | (cd /newdisk; gnutar -xpf -)

Charles William Swiger

unread,
Jul 7, 1997, 3:00:00 AM7/7/97
to

Excerpts from netnews.comp.sys.next.sysadmin: 6-Jul-97 Re: Seeking
advice on trans.. by Timothy J. Lu...@peak.or
> Would you need to specify the 'p' flag when you make the archive as well as
> when you un-archive?

No-- it wouldn't make any difference.

When making an archive, tar and gnutar preserve the same information
regardless of whether the 'p' flag is specified. The 'p' flag only
controls whether the program ignores the umask when extracting files
from an archive.

-Chuck


Charles Swiger | cs...@andrew.cmu.edu | standard disclaimer
----------------+---------------------+---------------------
I know you're an optimist if you think I'm a pessimist.


Daniel Boehringer

unread,
Jul 7, 1997, 3:00:00 AM7/7/97
to

John Kheit <jkh...@cnj.digex.net> wrote:

> Ditto, for example, cannot copy the swapfile.front file... The
> solution I have is a bit hacky but it works...

solution: unmount the swapfile.front file before dittoing. (this worked for
me).


daniel

Timothy Luoma

unread,
Jul 7, 1997, 3:00:00 AM7/7/97
to Daniel Boehringer

This strikes me as a bad idea, or at least a dangerous one, because the
.front file is used to make the compressed swapfile.

As I said earlier, there's no real reason to want to copy it via ditto, so
the fact that it fails is unimportant, unless it breaks ditto altogether.

swapfile.front is not a real file. It is a necessary file, however,
at least if you want a compressed swapfile.

TjL

Sigthor Hrafnsson

unread,
Jul 7, 1997, 3:00:00 AM7/7/97
to

Timothy Luoma wrote:
>
> John Kheit <jkh...@cnj.digex.net> wrote:
>
> >Ditto, for example, cannot copy the swapfile.front file... The
> >solution I have is a bit hacky but it works...
>
> Why would you want to?
>
> The swapfile.front file is not a real file, but just a file used in making a
> compressed swapfile.
>
> There's no real reason to copy that, or the regular swapfile, for that
> matter.
>
> Well, the original swapfile might have value because it can be re-used, and
> usually you want a swapfile that is around 16 megs. When you reboot it will
> be trimmed back to the LOWAT.
>
> Still, there's no need to copy the swapfile.front
>
> TjL
>
> ps -- Hebrew started as of 2 July, and ends on 22 August, so
> please understand if responses are slow. I am taking a 2
> semester class in 8 weeks for 6 credits
>
> --
> TjL <luo...@peak.org>
Hi

ditto worked great for me!

si...@treknet.is

John Kheit

unread,
Jul 8, 1997, 3:00:00 AM7/8/97
to

Timothy Luoma <luo...@peak.org> wrote:
> On 7 Jul 1997, Daniel Boehringer wrote:

> > John Kheit <jkh...@cnj.digex.net> wrote: solution: unmount


> > the swapfile.front file before dittoing. (this worked for me).

> This strikes me as a bad idea, or at least a dangerous one,
> because the .front file is used to make the compressed swapfile.

> As I said earlier, there's no real reason to want to copy it via
> ditto, so the fact that it fails is unimportant, unless it breaks
> ditto altogether.

> swapfile.front is not a real file. It is a necessary file,
> however, at least if you want a compressed swapfile.

Hmmm, i'm failing rather severly at expressing this...

Ok, lets try this. If log in as root, and mount a blank 2Gb drive
on your root called /myBlank. Then you want to ditto your current
root to the blank, so you do the following:

ditto / /myBlank

After doing that, ditto will FAIL when it gets to swapfile.front
because it's not a real file. I.e. making it impossible or difficult
to ditto your root to another drive. So in essence you want ditto
to copy everything BUT swapfile.front...but there is no easy way
to tell ditto this...sooooo...

What you do is make a BOM file, in effect remove swapfile.front
from the BOM file, and then do this:

ditto -bom myBomFile / /myBlank

Now, the ditto will work since your modified myBomFile has a listing
of every file on your hard drive EXCEPT the swapfile.front file
which ditto is incapable of copying...

Hope that was a little better...

Timothy Luoma

unread,
Jul 8, 1997, 3:00:00 AM7/8/97
to John Kheit

On 8 Jul 1997, John Kheit wrote:
> After doing that, ditto will FAIL when it gets to swapfile.front
> because it's not a real file. I.e. making it impossible or difficult
> to ditto your root to another drive. So in essence you want ditto
> to copy everything BUT swapfile.front...but there is no easy way
> to tell ditto this...sooooo...

Ah... I see... ditto is one of those programs that decides to shoot itself
in the head when it gets a hangnail....

Sure I can see why it might think it is important to notify you that a
file wasn't transferred, but couldn't it just log it and continue?

I suppose I couldn't just use (as root):

/usr/local/gnu/bin/cp --one-file-system --verbose --recursive \
--preserve --no-dereference / /NewDisk/

I'm not sure how '--preserve' does at special files, etc

TjL

ps -- does anything special have to be done when using these comands to
make the disk 'bootable' or is any HD under Unix bootable by default?
I've had to deal with some dumb operating systems that had two types of
disks, bootable and nonbootable

John Kheit

unread,
Jul 9, 1997, 3:00:00 AM7/9/97
to

Timothy Luoma <luo...@peak.org> wrote:
> Ah... I see... ditto is one of those programs that decides to
> shoot itself in the head when it gets a hangnail....

> Sure I can see why it might think it is important to notify you
> that a file wasn't transferred, but couldn't it just log it and
> continue?

I'm not sure what it's supposed to do...just that it fails at that
spot :( And I used that hack/brute force method to get around
it... But now others showed that tar can do similiar things...now
if someone could show me how to use gnutar to do a ditto like
backup, and pipe that through gz...and for the entire thing to
write in say 200Mb chunks that can be used and rejoined off of
opticals...that would be neet :)

Matthew Seaman

unread,
Jul 10, 1997, 3:00:00 AM7/10/97
to

In <5pv0cq$eep$1...@news2.digex.net> John Kheit wrote:
> ...now if someone could show me how to use gnutar to do a ditto like
> backup, and pipe that through gz...and for the entire thing to write in say
> 200Mb chunks that can be used and rejoined off of opticals...that would be
> neet :)

i) Install gnu textutils

ii) gnutar -zcvf - /some-dir | split --bytes=200m - backup.

Which will write a series of files backup.aa, backup.ab, ...

To extract:

cat backup.* | gnutar -zxvpf -

Matthew
--
Certe, Toto, sentio nos in Kansate nin iam adesse.

Matthew Seaman P&L Systems, 12 The Broadway, Amersham, Bucks., HP7 0HP, UK
Tel: +44 1494 432422 Fax: +44 1494 432478


Chris Douty

unread,
Jul 11, 1997, 3:00:00 AM7/11/97
to

In article <5pmt6p$j3e$1...@ha2.rdc1.nj.home.com>,

Timothy Luoma <luo...@peak.org> wrote:
>John Kheit <jkh...@cnj.digex.net> wrote:
>
>>Ditto, for example, cannot copy the swapfile.front file... The
>>solution I have is a bit hacky but it works...
>
>Why would you want to?

I dunno? Why, or is that a trick question?

I recommend "ditto" like several other have. I actually built the system
I'm running now via ditto -bom <stuff> from the NS CD-ROMs. I didn't
want to use builddisk for various reasons (mostly I couldn't remember how
to keep it from formatting my drive or at least to use my special
disktab). I ran into a snag when attempting to boot the new OS for the
first time. loginwindow.app came up in "install" mode and required some
soothing to get into normal operation.

My memory is a little fuzzy as to the details; this was several months
ago. I think that it came up to the point where the install process asks
which optional packages you want to install. I finally selected no
additional packages and pressed "Continue." This flipped whatever
semaphore loginwindow.app looks for to determine which mode to use and
everything orked fine from then on. I do believe that it looks for a
file like "first time" or something obvious which the normal CD install
coppies on the the root directory. Just delete it and you can probably
avoid the while mess.

Someone also asked about what you need to do to make the disk bootable.
The normal format with "disk" should install the boot block. I'm not too
sure about interaction with Intel machine though. I did all my tricks on
real black hw.

One other thing to look out for using ditto though. If you use the BOM
mode to copy files from the CD-ROM you will get a FAT install of the
whole OS. I didn't quite realize this until I upgraded the machine I
built using ditto and realized that everything is FAT. Now I have to
lipo my whole disk! There is an option to ditto to thin the files on the
way though, make sure to use it. I just realized what happened. I did
use the -arch flag when building the disk, but my BaseSystem.bom listed
everything as fat. You'll have to play arround with mkbom, lsbom and
friends to fix up your BOM files after the copy.

Good luck,
Chris

--
Christopher Douty - Rogue Engineer trapped in a land of software
cdo...@netcom.com
"Frequently the messages have meaning; that is they refer to or are correlated
according to some system with physical or conceptual entities. These semantic
aspects of communication are irrelevant to the engineering problem." -Shannon

0 new messages