experchange > sun

Chris (09-01-18, 04:15 PM)
Hi,

Still working on ideas for a universal boot server, hosted on
a Solaris 10 machine. So far, Solaris 8, 9 and 10 working, but
would like to have Sunos 4 as an option as well, to test
Sun 3-50, 3-60 and a 3-150. Have these all more or less
working as a diskless clients, but it would be good to have a
remote install option for these machines. The approach so far
has been to install 8 and 9 on another machine, then use the
add client mechanism to create a client, transfer the file trees
to the sol10 machine, setup tftp, bootparams and nfs to suit.
Seems to work ok at that level, but sun 3 seems a bit more
difficult.

Have a set of 4.1.1 distro tapes for sun3 and have installed
a miniroot on a local disk, via qic drive, but haven't been
able to do a full install as the tapes won't read past a few
of the tar files. Fitted new tension bands to the tapes from
donor unused tapes, but either the tapes are flaky, or the qic
drive is out of adjustment, so no install via that route.

Ideally, the Sol 10 box would serve the tape files, which are
on the web, but miniroot on partition b is still needed. Did
try moving the miniroot drive to another machine and doing a
ufsdump, but when restored to a disk, miniroot won't boot. Assume
it needs a boot block, but can't find any info relating to that
either, so another dead end.

Did find a reference to Sunos 4 having a "remote install server"
capability. No further info on that, but Sun must have
had that capability in house for production so how did they do
it ?.

Any ideas or pointers to a way forward would be appreciated...

Chris
DoN. Nichols (09-02-18, 03:41 AM)
On 2018-09-01, Chris <xxx.syseng.yyy> wrote:
[..]
> to the sol10 machine, setup tftp, bootparams and nfs to suit.
> Seems to work ok at that level, but sun 3 seems a bit more
> difficult.


I think that it is the lack of the OpenBoot firmware which makes
installation of SPARC systems easier.

> Have a set of 4.1.1 distro tapes for sun3 and have installed
> a miniroot on a local disk, via qic drive, but haven't been
> able to do a full install as the tapes won't read past a few
> of the tar files. Fitted new tension bands to the tapes from
> donor unused tapes, but either the tapes are flaky, or the qic
> drive is out of adjustment, so no install via that route.


Hmm ... have you found "tprobe" yet? It is a program designed
to scan a tape and make it into a single file which can be used for
making more tape copies. It was written for the purpose of keeping
Sun-3 tapes available. Hmm ... there is a different program with the
same name for testing USB serial communications. I have the tar file of
the original program -- all of 96K in size.

Beware that my e-mail is munged in the headers. Take off the
"BP" at the beginning and end of the username.

I won't send the file unless you tell me that you want it. Here
is part of the README file in it:

================================================== ====================
@(#)README V1.0, 12-Feb-1992, Thad Floryan [ thad ]

tprobe is a utility which succeeds duplicating boot/install tapes that are not
easily copied by other means. One of its features is operation over a pipeline
utilizing multiple tape drives whereever they exist on a network or a system.

tprobe can also (indirectly) perform media conversions, though the only
verified conversions have been from QIC-120 and QIC-150 to QIC-24 and vice
versa; there is no inherent limitation, so other conversions are definitely
possible.
================================================== ====================

Note that you not only want the SunOs 4.1.1 tape, but also the
SunOs 4.1.1-U1 patch tape, which will give you the last version of SunOs
for the Sun3 machines.

Also -- something else to watch out for. Avoid any drives
larger than 1 GB. There is a problem in the SCSI driver. In
particular, it is in the part which handles bad block replacement.
Normally the replacements are taken from a reserved space near the end
of the drive, but if it is taken from a point past the 1 GB point, a
version of the SCSI command set is used which limits the block count, so
a reference to a sector beyond the 1GB point actually references a
sector near the start of the drive (depending on how far past the 1GB
point the drive allows). This results in any use of the "replaced"
sectors to overwrite ones near the start of the drive -- where the OS
was installed. So as it is used, it gets sicker and sicker. Usually,
after the drive is initally formatted, there is no use of the bad block
replacments, but as the drive ages more and more get used. (You could
lie to the system when you format the drive, and only use the first 1GB,
since smaller drives are harder and harder to find these days. This
problem was fixed in SunOS 4.1.1 for the SPARC machines, but not for the
Sun-3 machines -- at a guess to encourage people to move to the SPARC
machines. :-)

Oh yes -- another thing to watch out for on the Sun-3 machines.
*don't* enable the parity checking jumper. The drive is easy to access
during the installation booted from the tape, but it can't be read when
you try to boot from the just installed disk. (I've beat my head
against the wall for quite a while with that problem. :-)

> Ideally, the Sol 10 box would serve the tape files, which are
> on the web, but miniroot on partition b is still needed. Did
> try moving the miniroot drive to another machine and doing a
> ufsdump, but when restored to a disk, miniroot won't boot. Assume
> it needs a boot block, but can't find any info relating to that
> either, so another dead end.


Part of what is handled by the booting from the tape. Check the
"installboot" command in the manuals. Looking at an older version will
probably be better, since the newer one knows about zfs which you can't
support on the Sun-3 machines.
[..]
YTC#1 (09-02-18, 10:38 AM)
On 01/09/2018 15:15, Chris wrote:
[..]
> had that capability in house for production so how did they do
> it ?.
> Any ideas or pointers to a way forward would be appreciated...


Hmm, interesting.

A small thread from back in 1998 suggests that it can be done.



Add the compatibility as suggested by Casper.

I'd then add JET (Jumpstart Enterprise Toolkit) , write the scripts
suggested and call them via the custom module.

This,

not this
Chris (09-08-18, 12:21 AM)
On 09/01/18 15:15, Chris wrote:
> Hi,
> Still working on ideas for a universal boot server, hosted on

....
Thanks for the replies. As I said, can't read past the first few
tar files on the tape doing a regular install. Could be the tape
drive, but tried he only other qic drive here and it won't even boot
from that, so the tar files look like the only answer. A cd install
was around at the time, but not easy to find, though someone may
have an iso image somewhere.

Trying s different track, listed the contents of all the tar files
to see where they are installed, then wrote a script to unpack those
into root an usr trees. Various issues and not quite there yet. for
example, /sbin doesn't get files loaded from tar, jut the directory
is created, so the script copies those from elsewhere. /dev doesn't
get populated either, so nfs mounted the dev directory to another
sun machine, then run makedev std from that. Seems to work ok, but
is there a way to copy /dev files ?. ufs dump must do it, so will
try that perhaps.

Various other issues but setting up for diskless boot and it it does
work, though a few issues to fix. Creating the trees from the tar
files takes less than 15 seconds, somewhat faster than a tape
install for sure.

A bit of a labour of love, but an interesting task...

Chris
DoN. Nichols (09-08-18, 01:16 AM)
On 2018-09-07, Chris <xxx.syseng.yyy> wrote:
[..]
> sun machine, then run makedev std from that. Seems to work ok, but
> is there a way to copy /dev files ?. ufs dump must do it, so will
> try that perhaps.


O.K. It has been a while since I ran 4.1.1, so I don't remember
what was in /sbin.

As for /dev, the install script runs makedev in the /dev
directory (normal for BSD flavored systems like SunOs 4.1.1, but not for
SysV based systems (e.g. SunOs 5.*)). The script stays there to be run
if you need to make more /dev entries.

So -- if you can find a MAKEDEV from a similar vintage of the
OS, copy it into /dev, and run "./MAKEDEV all". (Based on looking at an
OpenBSD system which I am still running, not a SunOs 4.1.1 .) You need
to have "mknod" somewhere in your path. On OpenBSD, that is in /sbin.

> Various other issues but setting up for diskless boot and it it does
> work, though a few issues to fix. Creating the trees from the tar
> files takes less than 15 seconds, somewhat faster than a tape
> install for sure.


You do have other Sun3 systems around to get your NFS from,
apparently. Same version of SunOs?

> A bit of a labour of love, but an interesting task...
> Chris


Understood. My first Sun was a Sun2/140 IIRC, and a similar
learning curve. IIRC, that was some version of SunOs 2.*.*

Good Luck,
DoN.
Chris (09-09-18, 01:22 AM)
On 09/08/18 00:16, DoN. Nichols wrote:

> O.K. It has been a while since I ran 4.1.1, so I don't remember
> what was in /sbin.


About 6 files, but they are copies, not links, from other places. Most
likely because they are needed before /usr gets mounted.

> So -- if you can find a MAKEDEV from a similar vintage of the
> OS, copy it into /dev, and run "./MAKEDEV all". (Based on looking at an
> OpenBSD system which I am still running, not a SunOs 4.1.1 .) You need
> to have "mknod" somewhere in your path. On OpenBSD, that is in /sbin.
> You do have other Sun3 systems around to get your NFS from,
> apparently. Same version of SunOs?


Pulled the 3/60 out from store in 2016 and imaged all the
partitions to dump files. The system disk failed later, but was
able to recover from that, so still have a working system for
reference. version is 4.1.1 or 3 from memory and things like
networking and nfs all work as expected.

Running sun3 makedev under Sol 10 fails,
complaining about group errors, so nfs mounted the Sol 10 directory
on a Solaris 2.6 Sparc box and ran makedev from there. Unlike the
suninstall program, makedev is a script rather than a binary.

Working as diskless client so far, but copied all the files to a
disk today and after the usual scsi issues, it does boot, but fails
on the fdisk stuff and ends up in single user mode, so still some work
to do.

> Understood. My first Sun was a Sun2/140 IIRC, and a similar
> learning curve. IIRC, that was some version of SunOs 2.*.*
> Good Luck,
> DoN.


Do yo still have the Sun 2 box ?. Would be an interesting project to
restore and they are not exactly thick on the ground.

Picked up a couple of books this week, the 2001 issue Solaris Internals
and Automating Solaris Installations, from 1995. Both have quite a
bit of info on the boot process and initialisation

It's just a fun project, but helps to keep the brain cells active,
as we inevitably get older and greyer. Perhaps a bit of reversion
to type, as the 3/60 was the first serious unix box here, circa 1993,
complete with a 105mb disk to start with. As the song goes:
"The bus came by and I got on. That's where it all began" :-)...

Chris
DoN. Nichols (09-09-18, 03:24 AM)
On 2018-09-08, Chris <xxx.syseng.yyy> wrote:
> On 09/08/18 00:16, DoN. Nichols wrote:
>> O.K. It has been a while since I ran 4.1.1, so I don't remember
>> what was in /sbin.

> About 6 files, but they are copies, not links, from other places. Most
> likely because they are needed before /usr gets mounted.


O.K. That makes sense.

> Pulled the 3/60 out from store in 2016 and imaged all the
> partitions to dump files. The system disk failed later, but was
> able to recover from that, so still have a working system for
> reference. version is 4.1.1 or 3 from memory and things like
> networking and nfs all work as expected.


O.K. That should have compatible programs -- unless you are
running SunOs 3.? on it instead of 4.1.1. (While 4.1 made its way up to
4.1.4 in the SPARC world, it stopped at 4.1.1 for the Sun3 (68020) and
the Sun3x (68030 IIRC)

> Running sun3 makedev under Sol 10 fails,


It would. Devs are made rather differently in Solaris (even
Solaris 2.6). MAKEDEV calls mknod IIRC in SunOS 4.1.? and earlier.
Groups are quite different between the two as well. Among other things,
there is the wheel group in SunOs 4.1.x and earlier (and in OpenBSD,
FWIW). You can "su" to root only if you are a member of group wheel,
and a lot of important things are made group wheel, including a lot of
devices which MAKEDEV produces.

> complaining about group errors, so nfs mounted the Sol 10 directory
> on a Solaris 2.6 Sparc box and ran makedev from there. Unlike the
> suninstall program, makedev is a script rather than a binary.


It is a script, but it calls binaries such as mknod, and I'm not
sure how trustworthy the product of a sparc version of mknod would be on
a Sun-3 system.

> Working as diskless client so far, but copied all the files to a
> disk today and after the usual scsi issues, it does boot, but fails
> on the fdisk stuff and ends up in single user mode, so still some work
> to do.


Not sure how different the filesystems are between SunOs 4.1.1
and Solaris 2.6, but you may need to mount the disk on your Sun 3/60 and
rebuild the filesystem with format, label it all, and then run newfs on
the Sun 3/60 and rebuild the various file systems there from your tar
files. (And don't just copy the /dev tree from the 3/80. There may be
some difference in device numbers between the two vintages.

>> Understood. My first Sun was a Sun2/140 IIRC, and a similar
>> learning curve. IIRC, that was some version of SunOs 2.*.*
>> Good Luck,
>> DoN.

> Do yo still have the Sun 2 box ?. Would be an interesting project to
> restore and they are not exactly thick on the ground.


I still have it -- but I really want to keep it. Also, it is a
heavy beastie, and shipping it across the Atlantic to you would be
quite expensive.

> Picked up a couple of books this week, the 2001 issue Solaris Internals
> and Automating Solaris Installations, from 1995. Both have quite a
> bit of info on the boot process and initialisation


O.K. But different from Sun3 -- Solaris is SysV flavored,
Sun3's SunOS 4.1.1 is BSD flavored.

And your last word in your paragraph above verifies that the .uk
in your address is reasonable, as you spelled the word the UK way
instead of the US way. :-)

> It's just a fun project, but helps to keep the brain cells active,
> as we inevitably get older and greyer. Perhaps a bit of reversion
> to type, as the 3/60 was the first serious unix box here, circa 1993,
> complete with a 105mb disk to start with. As the song goes:
> "The bus came by and I got on. That's where it all began" :-)...


My first unix box was a Cosmos CMS/UNX based on the Motorola
MC-60000. (The 68000 doesn't have the necessary instructions to support
virtual memory, so it had to be v7 unix, not either SysV nor BSD.) It
was slow (a poor implementation of the C compiler, based on comparing
the assembly language output for the same function on that and on a AT&T
Unix-PC (4300/3B1) (68010 based). As far as I could tell, the v7
compiler pretty much ignored instructions in the 68000 which were not
also in the PDP-11, with the exception of the LNK and ULNK instructions,
used to build stack frames and to destroy them when no longer needed. I
discovered this when I saw how slow it was compared to the Unix-PD when
I was trying to crack a password in a Tektronix 6130 (yet another BSD
unix box). That one had died in a class, apparently, and was sold
surplus intact, with the whole OS installation. What was wrong was a
fuse inside the power supply which had failed. Replace that and it
worked fine, and had a guest account which worked so I could see the
passwd file (before the days of /etc/shadow). It turned out that the
root password was "gnome" -- which was in the spelling checker
dictionary. :-)

Presumably, they had multiple systems for the class, including
spares, so they just pulled out another one for the student.

> Chris


Enjoy,
DoN.
Chris (09-09-18, 11:01 PM)
On 09/09/18 02:24, DoN. Nichols wrote:

[..]
> spares, so they just pulled out another one for the student.
> Enjoy,
> DoN.


The 3/60 was the first *serious* unix box, but did install 4.3 from
tape to a Vax 730 at one stage. A whole 3 mbytes memory, with the
kernel taking 3 or 4 days to rebuild and me praying that we didn't
have a power cut. Take so much for granted now, but just doing an
install could be seriously hard work back then.

One of the odd glitches trying to export a large raidz array
to a Sun 3 system, is the fact that the latter being 32 bit, you get
strange results from df, large numbers, some of them negative.
Thinking about it, 32 bits gives 4Gb using unsigned arithmetic,
but it was quite common to use char, int, long etc in the old C
programming days, which of course are signed values. Perhaps
explains the 2gbyte limit for the disk partitions. Having started
in computing programming asm on micros, using signed branches
can get you into serious trouble when the sign bit flips :-)...

Chris
Chris (09-14-18, 12:16 AM)
On 09/09/18 22:01, Chris wrote:
> On 09/09/18 02:24, DoN. Nichols wrote:


Still issues with this setup. The script builds root and usr and the
system does load/run the kernel from sd0a, but at the end of device
probing, we get a revarp to the network, and not the usual root and
user device identification, prior to doing an fsck. What this seems to
mean is that the kernel thinks it's doing a network boot, when it's
just booted from sd0a ?.

Tried to mimick the working system disk on the build disk, fstab,
hostname etc, with all files and sizes looking ok, so must be missing
something obvious, or there's some magic rune in the Sun install
program.

Any ideas to fix this appreciated, as can find no in depth info on
the timeline stages for a Sun 3 boot...

Chris
DoN. Nichols (09-20-18, 03:45 AM)
On 2018-09-13, Chris <xxx.syseng.yyy> wrote:

[ ... ]

[..]
> program.
> Any ideas to fix this appreciated, as can find no in depth info on
> the timeline stages for a Sun 3 boot...


Hmm ... again -- it has been a long time since I booted a Sun-3
system, so I can't be sure -- but try (from the un-booted system)
typing:

================================================== ====================
printenv boot-device
================================================== ====================

and see what it says. On my systems (all SPARC and UltraSPARC these
days) it says:

================================================== ====================
boot-device=disk0
================================================== ====================

or in some cases, it may show a special name for using a zfs filesystem
as the boot device. If there is a space and "net" in the list of
boot-device options, it will try booting from the net -- and *I* never
want it to do so, so I change that with "setenv" from an un-booted
system, or "eeprom" from a booted system.

Good Luck,
DoN.
Chris (09-21-18, 01:29 PM)
On 09/20/18 02:45, DoN. Nichols wrote:

[..]
> system, or "eeprom" from a booted system.
> Good Luck,
> DoN.


Thanks, I guess the real problem is that there seems to be very little
in depth info on the overall boot process. ie: after booting vmunix
and running it, what happens next etc ?. Already have a second edition,
but bought a copy of the Solaris Internals first edition recently and
that has some info on the disk boot block format, but the rest is
very Sparc oriented and lacks in depth detail on the boot internals
for Sun 3. Have scoured the web, but there must be some Sun 3 docs or
whitepapers on this somewhere out there.

The other issue is writing the bootblock. Apparently, suninstall uses
dd to write the boot block on the first few sectors and had an initial
stab at that by dd'ing sectors 1-15 to and from a disk. It sortof
partially works, but complains about checksum error, and "trying to
boot anyway" message, but then stops with an exception. Perhaps the
checksum also includes sector 0, the vtoc / partition map, but haven't
looked into that more, as yet. Of course, suninstall is a binary,
whereas it would be much easier to reverse engineer if it were a
script. Did quite a bit of 68k asm years ago, so dissasembly might
be the only way in extremis, though the original will of course be
compiled C.

This is all a bit exhuming the entrails of a long dead system, but it
could be useful to others trying to restore old Sun kit. One thing I
did find last week was a Sun faq from 1998, which describes what i'm
trying to do in faq no 80, "Installing Sunos by hand". Not giving up
on this though, so perhaps regroup, review and start again :-)...

Chris
Similar Threads