@rcberwick/bobo68: problem is that so far what I could restore seems to be broken at some level, since binary data is there but, for example, applications are displayed with a generic icon with a question mark on it and when I try to launch them they either output "Cannot exec ... (not a valid program)" or "Bad executable".

I had this once with the "Configure" application. It is an Intel binary which would not run on 68k of course. The drive / image itself is obviously ok otherweise the data would be so scrambled that you could not boot from it or see files.

Does this happen on the 030 Cube?

paolo.bertolo wrote:

Could it be that there's some kind of mismatch between the format of the source disk and the virtual partition on the SCSI2SD device?

The format of the source does not really matter. A dd file is just a file with blocks from a drive. Also the virtual partition (I guess you mean the SCSI devices that SCSI2SD emulates!?) does not really matter because when you put the sd card in your Mac it is just a device with blocks. That said you can of course easily write across SCSI device boundaries with your Mac because they only exist in SCSI2SD's config.

I had this once with the "Configure" application. It is an Intel binary which would not run on 68k of course. The drive / image itself is obviously ok otherweise the data would be so scrambled that you could not boot from it or see files.

Does this happen on the 030 Cube?

I don't think it's an intel binary, at the time of version 1.0 everything was for 68k only. For example, I'm sure version 1.0 of Mathematica is a 68k binary.

I have the feeling that something gets messed up in the process of archiving, moving, expanding and restoring across different file systems.
In the past I've seen 7z / tar archives being quite critical, since I had to deflate them on my Mac before moving to the NeXT... e.g. if I expand the 7z archive, untar it on my Mac and then move it to the NeXT, I have basically the same issue: binary data is there but cannot be executed. When I just unzip and move the tar file to the NeXT and untar it locally, everything is OK...
Is there any 7z utility for NeXTStep?

He's absolutely correct. As he said better than I did in the previous post, you have to use a method that copies disk blocks, exactly. i.e., dd.
Tar and other archive methods won't work here. Neither will dump/restore. That is used to restore once you have a NeXTstep formatted partition to restore to; if it's to be bootable, it has to have the boot blocks already in place and these aren't part of the dump/restore.

Once you have a single image file produced by dd you can, of course, compress it using e.g., gzip. But that is something else. There are lots of these around. That one the way I've archived my running systems.
You can even use dd along with ssh to dd a bootable partition from a NeXT machine to a Mac or Linux or PC; that is one way to make the dd images in the first place.

bobo68 wrote:

But we are not handling archives of single files here. We have a binary image of a whole drive. No tar involved. And compression tools should not alter the binary image file.

Under which configuration do you try to start the applications? On the 030 Cube with ROM ??? and NS ???.

This is very helpful because these are close to all the required steps...but...
I agree with you: you don't want to do the disk initialization using the NeXTOS-- because in all likelihood it conflicts with the simulated 'disk geometry' and partitioning scheme already set up by the scsi2sd xml file OR else the dd image you have was set up for a drive geometry that doesn't match up. When you use the NeXT command "disk -i ...." it makes assumptions using /etc/disktab, plus guessing. Not clear what it will do, but it does not seem to work.

If you have a Mac or a linux box at hand, then I would suggest doing everything on that first, using dd there to write out the block by block copy to the sd card, and then simply moving the resulting sd card to the scsi2sd adaptor. I have done this with dozens of 030 and 040 machines, without any difficulties.

The steps would be nearly exactly as you have (correctly) done them, though with a few differences because you would be operating on the Mac or linux box and writing to the sd card there:

1. unzip the *.dd.zip file [much, much faster than on the NeXT.... let's say this is "nextimage.dd"]
2. insert an SD card, and then, if it's mounted automatically, unmount it [on a Mac --]
(i) diskutil list [to get the list of devices and find out which one corresponds to the sd card. Say it's disk4]
(ii) sudo diskutil unmountDisk disk4
3. sudo dd if=nextimage.dd of=/dev/rdisk4 bs=1m
4. sudo diskutil unmountDisk disk4 [on a Mac]
5. Remove the sd card and put it into the scsi2sd adaptor, try to boot.

Basically the same steps on a linux box.
You of course want to be very careful to make sure you have the right disk number when you start the dd so that you do not blow away your local machine's drive...

xml files with suitable geometries have been posted on the forum. FWIW, if you are doing four 2gb partitions, you need > 8gb card, to accommodate.
I have not done this for an MO drive image, however, and I'm not sure how that would match up.

The above is what has worked for me - hope this is of some help. Post your xml file in full - I can repost one I use for 4 x 2gb partitions (eventually written to a 16gb sd card)

paolo.bertolo wrote:

So, here's what I'm trying to do. Unsuccessfully, so far.

- Downloaded the file "NS10a_1GB_V4_incl_Business-Land_Demos.dd.zip", linked many times in this forum and available out there...

- moved via FTP to my NeXT Station mono; the machine is equipped with NeXTStep 3.3 and is equipped with a SCSI2SD with 8 Gb SD card split into 4 drives, each of them 2 Gb

I suspect the binary data written by dd is not consistent with the initialisation scheme and this is messing everything up...

Any advise?

If you write a dd image to a raw scsi device (which you do) there is no initialization scheme left from before. Where should it be stored? You overwrite all disk blocks with the image blocks (or at least everything from block 0 to the length of the image). The image contains everything: boot blocks, partition scheme, inodes, data. Therefore the initialization step is not necessary.

1. unzip the *.dd.zip file [much, much faster than on the NeXT.... let's say this is "nextimage.dd"]
2. insert an SD card, and then, if it's mounted automatically, unmount it [on a Mac --]
(i) diskutil list [to get the list of devices and find out which one corresponds to the sd card. Say it's disk4]
(ii) sudo diskutil unmountDisk disk4
3. sudo dd if=nextimage.dd of=/dev/rdisk4 bs=1m
4. sudo diskutil unmountDisk disk4 [on a Mac]
5. Remove the sd card and put it into the scsi2sd adaptor, try to boot.

All right, some positive progress to report: when everything is done on a Mac, it seems as though things are prone to work.
Unfortunately, I had to give up on getting to the same result by working directly on a NeXT, I could not make any progress, blocks written by dd were apparently somehow not consistent and the partition could not even be mounted.

I'm adding a couple of lines to the above mentioned steps.

Start on a Mac...

0. using scsi2sd-util reset the SCSI2SD adaptor (whose set up is independent from the specific content of the SD card) and load the default settings [one single SCSI device, 2 Gb, SCSI address 0]

1. unzip the *.dd.zip file [much, much faster than on the NeXT.... let's say this is "nextimage.dd"]

Hello: Does anyone have clean versions NeXTSTEP .8 and NeXTSTEP .9 images that they can put on drop box for me or point me to a clean download site , the first is preferable.
I tried one of the download sites
DO NOT USE THIS http://vetusware.com and it is obviously a phishing virus site as it came up with a warning unless I called an 800 number they would delete my harddrive .

Appreciate your help , I have a 1.0 , my .9 master drive just croaked and am looking for to trying .8 , also any tips appreciated if there are any gotchas installing images to micro sd ._________________Rob Blessin President computerpowwow ebay sales@blackholeinc.comhttp://www.blackholeinc.com
303-741-9998 Serving the NeXT Community since 2/9/93

we have been able to confirm the compatibility of almost every release of NeXTSTEP with the NeXT emulator Previous. what we're still missing is NeXTSTEP Release 0.8 or 0.8a. please contact me or andreas_g if you have a working copy. some releases have "special needs" (like we have seen with Release 2.0 which refused to boot). now that 2.0 is running, we would like to check if 0.8 works in Previous or not... thank you!