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
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...
Hi,...
Still working on ideas for a universal boot server, hosted on
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
O.K. It has been a while since I ran 4.1.1, so I don't remember
what was in /sbin.
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?
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.
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.
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?
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
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.
On 09/09/18 02:24, DoN. Nichols wrote:
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.
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...
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 56:39:50 |
| Calls: | 6,652 |
| Calls today: | 4 |
| Files: | 12,200 |
| Messages: | 5,330,879 |