Hi, I'm having trouble building isos that can be read by NS3.3 on Intel hardware. I can read and mount the CD ok on VirtualBox with NS3.3 and it also show's the volume name.
On real hardware it says it has a invalid label and can not be read or mounted but the normal NS3.3 User or Developer CD can be read and mounted in single user mode.
I can only mount on single user mode as I have to boot the driver CD which has EIDE v3.35 (Dual EIDE/ATAPI driver) on it, after selecting the SCSI Adaptec driver first.
These are the command lines I'm using to build the CDs.
I use this one when I just files only on the CD.
# mkisofs -R -iso-level 4 -hide-joliet-trans-tbl -hide-rr-moved -V NeXTstuff -o NeXTstuff.iso NeXT/
I use this one when I want to put the 2.88MB floppy disk at the start of the CD with the drivers on it so I can start the installation.
# mkisofs -r -b 4.2_YOUR_SPECIFIC.floppyimage -c boot.catalog -o cdname.iso .
There is nothing fancy in the Volume name, i.e NSDRIVERS, EOF1_1, less than 12 chars, no fancy ASCII characters (maybe underscore).
Thanks
Just some ideas - are the CDs that can be mounted on your physical machine also CD-Rs or mass-produced ("pressed") ones? Old CD-ROM drives sometimes have trouble reading CD-Rs.
Also, you need to make sure the CD-R is finalized after writing the image, but I would assume that most CD-R writing software does this automatically.
Quote from: cuby on February 02, 2025, 05:19:45 AMJust some ideas - are the CDs that can be mounted on your physical machine also CD-Rs or mass-produced ("pressed") ones? Old CD-ROM drives sometimes have trouble reading CD-Rs.
Also, you need to make sure the CD-R is finalized after writing the image, but I would assume that most CD-R writing software does this automatically.
The burnt OpenStep 4.2 User ISO can be read and mounted, and also both all 3 CDs that have the 2.88MB bootable floppy disk image at the start can be read and booted to select drivers. A Windows XP home iso that I have burnt can also be read and boots.
This is on the IBM Thinkpad T43 which is 2005.
I may have a solution for this—there's a version of mkisofs that actually runs on NeXTSTEP. Vintage: 1997!
Get mkisofs.1.11.NIHS.bs.tar.gz from here: ******************/archive/apps/utils/cdrom/
The command I was able to use to make a nice Rock Ridge image with it was:
mkisofs -L -N -r -v -l -m '*.wmd' -V "<label>" -o <destination>.iso <source-directory>
This is NeXT-y enough that I can even write .dir.tiff images with it successfully.
I don't have any real hardware to test it on, but maybe this will work out better for you.
Additionally, there are several other esoteric options for manipulating the volume header described in the mkisofs(8) manpage.
Quote from: Rhetorica on March 08, 2025, 02:08:27 AMI may have a solution for this—there's a version of mkisofs that actually runs on NeXTSTEP. Vintage: 1997!
Get mkisofs.1.11.NIHS.bs.tar.gz from here: ******************/archive/apps/utils/cdrom/
The command I was able to use to make a nice Rock Ridge image with it was:
mkisofs -L -N -r -v -l -m '*.wmd' -V "<label>" -o <destination>.iso <source-directory>
This is NeXT-y enough that I can even write .dir.tiff images with it successfully.
I don't have any real hardware to test it on, but maybe this will work out better for you.
Additionally, there are several other esoteric options for manipulating the volume header described in the mkisofs(8) manpage.
Thanks will give it a go. I see this site has mkisofs.1.12b5.NIHS.b.tar.gz (
https://www.nextcomputers.org/NeXTfiles/Software/NEXTSTEP/Apps/CDRom/mkisofs.1.12b5.NIHS.b.tar.gz). It says in your Readme you only need the POSIX library for compiling?!
Hah, not mine; oh god! I've barely gotten hello world to compile. That's a mirror of PEAK that I saved from oldcomputers-archive.fr before it (predictably) vanished into the ether again. It's a slightly later snapshot than the z80.org mirror—notably it has the experimental USB drivers.
For whatever reason it seems like the absence of libposix.a from everything but NS3.3 is a pretty big deal. (perl 5.004 also mentions it.) I'm starting to wonder if this could also be why the newer gcc produces bad binaries under OS4.2...