diff options
| -rw-r--r-- | distrib/notes/sparc64/contents | 58 | ||||
| -rw-r--r-- | distrib/notes/sparc64/hardware | 38 | ||||
| -rw-r--r-- | distrib/notes/sparc64/install | 550 | ||||
| -rw-r--r-- | distrib/notes/sparc64/prep | 62 | ||||
| -rw-r--r-- | distrib/notes/sparc64/upgrade | 1 | ||||
| -rw-r--r-- | distrib/notes/sparc64/whatis | 5 | ||||
| -rw-r--r-- | distrib/notes/sparc64/xfer | 302 |
7 files changed, 1016 insertions, 0 deletions
diff --git a/distrib/notes/sparc64/contents b/distrib/notes/sparc64/contents new file mode 100644 index 00000000000..d764e72cd13 --- /dev/null +++ b/distrib/notes/sparc64/contents @@ -0,0 +1,58 @@ +TopPart + +OpenBSDdistsets + +OpenBSDbsd + +OpenBSDrd + + installboot The OpenBSD/sparc64 boot loader installation + program + bootxx The OpenBSD/sparc64 boot block + boot The OpenBSD/sparc64 secondary boot loader + boot.net The OpenBSD/sparc64 network boot loader + + +Please note that there are multiple bootable images and kernels, intended +to allow installing OpenBSD/sparc64 in a variety of situations without +requiring a pre-existing working operating system. + +The "miniroot{:--:}OSrev.fs" is a small bootable root filesystem that can be used +for installation or upgrade where there is some means to copy the miniroot +image into a swap or unused partition on the system, and also for diskless +or net booting. This can be convenient if you have a existing installation +of OpenBSD, NetBSD, SunOS, or Solaris and wish to test or upgrade the +existing system to OpenBSD. + +These bootable images are also useful as "failsafe" boots for system +maintenance and disaster recovery. + +The kernel and boot images are provided for net booting installations. +While the OpenBSD bootblocks will work with the provided miniroot images, +Sun bootblocks require a separate kernel image and root filesystem. + + +Bootable installation images: + +DistributionDescription(ten) + +OpenBSDbase(18.4M,56.4M) + +OpenBSDcomp(12.1M,39.7M) + +OpenBSDetc(165.2K,740.0K) + +OpenBSDgame(2.7M,6.7M) + +OpenBSDman(3.4M,13.1M) + +OpenBSDmisc(1.6M,5.4M) + +OpenBSDxbase(4.6M,12.9M) + +OpenBSDxshare(1.4M,8.3M) + +OpenBSDxfont(6.0M,7.3M) + +OpenBSDxserv(5.4M,14.6M) + diff --git a/distrib/notes/sparc64/hardware b/distrib/notes/sparc64/hardware new file mode 100644 index 00000000000..b142f0e3697 --- /dev/null +++ b/distrib/notes/sparc64/hardware @@ -0,0 +1,38 @@ +OpenBSD/sparc64 OSREV runs on the following classes of machines: + - SBUS based workstations: + Ultra 1 + - PCI based workstations: + Ultra 5 + - faithful clones of the above Sun systems. + +OpenBSD/sparc64 OSREV does NOT run on these machines (yet): + - Sun Blade 100 + +The minimal configuration requires 32M of RAM and ~120M of disk space. +To install the entire system requires much more disk space, and to run +X or compile the system, more RAM is recommended. + +Supported devices {:-include-:}: + serial ports: + Zilog ttya and ttyb (can be used as console if needed), + + ethernet: + on-board AMD Lance ethernet ("le0"), + SBus AMD Lance ethernet cards, + PCI/SBus SunSwift and Quad FastEthernet cards (hme, qfe) + SBus FastEthernet cards (qec+be) + SBus QuadEthernet cards (qec+qe) + + SCSI: + on-board "esp" SCSI controller + SBus "esp" SCSI controller (including 3rd party compatibles), + +Hardware the we do NOT currently support, but get many questions about: + Multiprocessor machines + Audio drivers + Floppy driver + SBus cgeight framebuffers + SBus GS framebuffer (aka cgtwelve) + SBus GT framebuffer ("Graphics Tower") + SBus ZX framebuffer (aka Leo) + diff --git a/distrib/notes/sparc64/install b/distrib/notes/sparc64/install new file mode 100644 index 00000000000..e741c90a244 --- /dev/null +++ b/distrib/notes/sparc64/install @@ -0,0 +1,550 @@ +OpenBSDInstallPrelude + +There are several ways to install OpenBSD onto a disk. The easiest way +in terms of preliminary setup is to use the OpenBSD miniroot that can +be booted off your local disk's swap partition. The normal way is to +use the OpenBSD installation floppy, or an installation tape. + +If your Sparc is hooked up in a network and you can find a server to +arrange for a diskless setup, which is a convenient way to install on a +machine whose disk does not currently hold a usable operating system. +This is difficult to get set up correctly the first time, but easy to +use afterwards. (see ``Installing using a diskless setup'' below). + +It is also possible to install OpenBSD "manually" from a running SunOS +system, using SunOS tools and gnu tar and gunzip (see ``Installing from +SunOS'' below). + + +Booting from the Installation Media: + +Prior to attempting an installation, you should make sure that everything +of value on the target system has been backed up. While installing OpenBSD +does not necessarily wipe out all the partitions on the hard disk, errors +during the install process can have unforeseen consequences and you will +probably render the system unbootable if you start, but do not complete +the installation. Having the installation media for the prior installation, +be it a SunOS or OpenBSD CD-ROM or OpenBSD install diskettes is good +insurance if you want to be able to "go back" for some reason. + +After taking care of all that, bring your system down gracefully using +the shutdown(8) and/or halt(8) commands. This will get you to the monitor +prompt. Sun PROM monitor commands and setup differ considerably depending +on the system architecture and age, you may needed to reference the PROM +monitor manual for your system for details. + +There are four main cases: + + sun4 (older servers, deskside workstations): + prompt is a ">", boot command is "b", uses sd(c,s,p) syntax + with s defined as scsi-unit*8+lun in hex + OpenBoot Version 1 (newer servers, desktop workstations): + prompt is "ok", boot command is "boot" uses sd(c,s,p) syntax + with s defined as scsi-unit. + OpenBoot Version 2 (newer servers, desktop workstations): + prompt is "ok", boot command is "boot" uses diskn:p syntax. + OpenBoot Version 2 (certain newer desktop workstations): + prompt is "ok", boot command is "boot" uses diskn syntax + unless booting from a non-standard partition, in which case: + boot /sbus/esp/sd@t,0:p bsd (where "t" is the scsi target, + and "p" is the partition. examples would be t="3" and p="b") + + +If you expect your workstation to have an OpenBoot Prom but get a ">", +enter then "n" command to enter the "new command mode". You can set this +as the default by doing a "setenv sunmon-compat? false" command, followed +by a "reset" command. + +Note that OpenBoot Proms also do the Sun SCSI-ID shuffle for disks, this +is described elsewhere in some detail. For the purposes of this section, +drive 0 refers to the internal or first SCSI drive, which usually has a +SCSI-ID of 3. + + +Booting from Floppy Disk installation media: + + ok boot fd()bsd # for version 1 OpenBOOT ROMs + ok boot floppy bsd # for version 2 OpenBOOT ROMs + +This will cause the kernel contained in the floppy to be booted. + +After the initial device probe messages you'll asked to start the +install or upgrade procedure. Proceed to the section ``Running the +installation scripts'' below. + + +Booting From CD-ROM installation media: + + > b sd(,30,0)OSREV/sparc/bsd.rd # for Sun4 monitors* + # (not working currently) + ok boot sd(,6,0)OSREV/sparc/bsd.rd # for version 1 OpenBOOT ROMs + ok boot cdrom OSREV/sparc/bsd.rd # for version 2 OpenBOOT ROMs + +If the boot is successful, you will get a loader version message, +executable sizes and then the Kernel copyright and device probe +messages. Boot failure modes are typically a lot of CD-ROM drive +activity, but no messages or complaints about magic numbers, +checksums or formats. + +Not all sparc systems support bootable CDROMS and the current +boot image is only known to work on sun4c and sun4m architectures. +If it does not work, you'll have to create a boot floppy or bootable +hard disk using the instructions under preparing boot media. + +After the initial device probe messages you'll asked to start the +install or upgrade procedure. Proceed to the section ``Running the +installation scripts'' below. + + +Booting from SCSI disk (miniroot or floppy image): + +Boot the miniroot by typing the appropriate command at the PROM: + + > b sd(,,1)bsd # for sun4 monitors* + ok boot sd(,,1)bsd # for version 1 OpenBOOT ROMs + ok boot disk:b bsd # for version 2 OpenBOOT ROMs + ok boot /sbus/esp/sd@3,0:b bsd # for version 2 OpenBOOT ROMs + # that won't take disk:p syntax. + +If you've loaded the miniroot onto some other disk than the default +drive 0, modify the boot specifier accordingly, keeping in mind the +drive vs. scsi-id shuffling and partition a=0, b=1... + + > b sd(0,10,1)bsd # example - scsi target 2 on sun4 monitors* + ok boot sd(0,3,1)bsd # example - scsi target 0 on v1 OpenBOOT ROM + ok boot disk3:b bsd # example - scsi target 0 on v2 OpenBOOT ROM + ok boot /sbus/esp/sd@0,0:b bsd # example - scsi target 0 on v2 + # OpenBOOT ROM that won't take + # disk:p syntax. + +(*) for sun4 this is scsi-target*8+scsi-lun (usually 0) expressed in hex... + +This will cause the kernel contained in the miniroot to be booted. +After the initial device probe messages you'll asked to start the +install or upgrade procedure. Proceed to the section ``Running the +installation scripts'' below. + + +Booting from SCSI tape: + +Boot the miniroot by typing the appropriate command at the PROM: + + > b st(,,1) # for sun4 monitors + # (not working currently) + ok boot st(,,1) # for version 1 OpenBOOT ROMs + ok boot tape:1 # for version 2 OpenBOOT ROMs + ok boot /sbus/esp/st@4,0:1 # for version 2 OpenBOOT ROMs + # that won't take tape:n syntax. + +The above instructions assume your tape drive is the default tape drive +using SCSI id 4. If your drive uses id 5, modify the boot command +accordingly: + + > b st(,28,1) # example - 2nd tape drive on sun4 monitors + ok boot st(,5,1) # example - 2nd tape drive on v1 OpenBOOT ROM + ok boot tape1:1 # example - 2nd tape drive on v2 OpenBOOT ROM + ok boot /sbus/esp/st@5,0:1 # example - 2nd tape drive on v2 + # OpenBOOT ROM that won't take + # tape:n syntax + +This will cause the kernel contained in the miniroot to be booted. +After the initial device probe messages you'll be asked to start the +install or upgrade procedure. Proceed to the section ``Running the +installation scripts'' below. + + +Installing using a diskless setup: + +First, you must setup a diskless client configuration on a server. If +you are using a OpenBSD system as the boot-server, have a look at the +diskless(8) manual page for guidelines on how to proceed with this. +If the server runs another operating system, you'll have to consult +documentation that came with it (on SunOS systems, add_client(8) and +the Sun System/Networks administrators guide constitute a good start). + + +Boot your workstation from the server by entering the appropriate `boot' +command at the monitor prompt. Depending on the PROM version in your machine, +this command takes one of the following forms: + + > b le()bsd.rd # for sun4 monitors + ok boot le()bsd.rd # for version 1 OpenBOOT ROMs + ok boot net bsd.rd # for version 2 OpenBOOT ROMs + +This will cause the kernel provided by the diskless setup to be booted. +After the initial probe messages you'll asked to start the install +or upgrade procedure. Proceed to the section ``Running the installation +scripts'' below. + + +Installing using the Floppy, CD-ROM, tape, miniroot or netboot procedure: + +OpenBSDInstallPart2 + + Boot your machine from the installation media as described above. + + It will take a while to load the kernel especially from a floppy + or slow network connection, most likely more than a minute. If + some action doesn't eventually happen, or the spinning cursor has + stopped and nothing further has happened, either your boot media + is bad, your diskless setup isn't correct, or you may have + a hardware or configuration problem. + +OpenBSDBootMsgs + + While booting, you will probably see several warnings. You + may be warned that the kernel can't figure out what device + it booted from and that no swap space is present. Do not be + alarmed, these are completely normal. The first warning + occurs because while OpenBSD/sparc can boot from the floppy + drive, the kernel itself lacks a floppy driver for some + architectures. + + Next there will be a prompt asking you for a shell name, just + hit return to start executing the installation setup script. + + You will next be asked for your terminal type. If you are + installing from a keyboard/monitor console, the default of + "sun" if correct. If you are installing from a serial console + you should choose the terminal type from amongst those listed. + (If your terminal type is xterm, just use vt100). + + After entering the terminal type you will be greeted by a + welcome message and asked if you really want to continue. + Assuming you answered yes, the install program will then tell + you which disks of that type it can install on, and ask you + which it should use. The name of the disk is typically "sd0". + Reply with the name of your disk. + + Next you will have to edit or create a disklabel for the disk + OpenBSD is being installed on. The installation script will + invoke the text editor allowing you to do this. Note that + partition 'c' inside this disk label should ALWAYS reflect the + entire disk, including any non-OpenBSD portions. The root file + system should be in partition 'a', and swap is usually in partition + 'b'. It is recommended that you create separate partitions for + root and /usr, you may also want to specify /var and /home + partitions. + + The swap partition (usually 'b') should have a type of "swap", all + other native OpenBSD partitions should have a type of "4.2BSD". + Block and fragment sizes are usually 8192 and 1024 bytes, but can + also be 16384 and 2048 bytes. + + The install program will now label your disk and ask which file + systems should be created on which partitions. It will auto- + matically select the 'a' partition to be the root file system. + Next it will ask for which disk and partition you want a file + system created on. This will be the same as the disk name (e.g. + "sd0") with the letter identifying the partition (e.g. "d") + appended (e.g. "sd0d"). Then it will ask where this partition is + to be mounted, e.g. /usr. This process will be repeated until + you type "done". + + At this point you will be asked to confirm that the file system + information you have entered is correct, and given an opportunity + to change the file system table. Next it will create the new file + systems as specified, OVERWRITING ANY EXISTING DATA. This is the + point of no return. + + After all your file systems have been created, the install program + will give you an opportunity to configure the network. The network + configuration you enter (if any) can then be used to do the install + from another system using NFS, HTTP or FTP, and will also be the + configuration used by the system after the installation is complete. + + If you select to configure the network, the install program will + ask you for a name of your system and the DNS domain name to use. + Note that the host name should be without the domain part, and that + the domain name should NOT {:-include-:} the host name part. + + Next the system will give you a list of network interfaces you can + configure. For each network interface you select to configure, it + will ask for the IP address to use, the symbolic host name to use, + the netmask to use and any media flags to set. This is driver + dependent, but for the sparc le(4) driver, the flags usually carry + meaning: + + auto Use existing setting (only setup by netboot) + 10baseT Use UTP (twisted pair) port + 10base5 Use AUI port + +*** IMPORTANT - these are the correct setting for Sparc ethernet cards, + the suggestions shown by the install script are generic + and may or may not be correct... + + After all network interfaces have been configured the install pro- + gram will ask for a default route and IP address of the primary + name server to use. You will also be presented with an opportunity + to edit the host table. + + At this point you will be allowed to edit the file system table + that will be used for the remainder of the installation and that + will be used by the finished system, following which the new file + systems will be mounted to complete the installation. + + After these preparatory steps has been completed, you will be + able to extract the distribution sets onto your system. There + are several install methods supported; FTP, HTTP, tape, CD-ROM, NFS + or a local disk partition. To install from a tape, the distrib- + ution sets must have been written to tape prior to running the + installation program, either as tar images or as gzipped tar + images. Note that installation sets on multiple floppies is not + currently supported. + +OpenBSDFTPInstall + +OpenBSDHTTPInstall + +OpenBSDTAPEInstall + +OpenBSDCDROMInstall + +OpenBSDNFSInstall + +OpenBSDDISKInstall({:-"wdN" or -:},{:-only -:}) + +OpenBSDCommonFS + +OpenBSDCommonURL + +After completing an installation: + +Now try a reboot. (If needed, swap your scsi id's first). Initially +I'd suggest you "boot sd()bsd -bs", then try multiuser after that. +if you boot single-user the OpenBSD incantation to make the root +filesystem writable is + + OpenBSD# mount -u /dev/sd0a / + +The Sun monitor normally tries to load a file called "vmunix". +On OpenBOOT ROM systems you can change it to load OpenBSD instead using +the following commands: + +On version 1 OpenBOOT ROMs: + >n + ok setenv boot-from sd(0,0,0)bsd + ok + +On version 2 OpenBOOT ROMs: + ok setenv boot-file bsd + ok setenv boot-device /sbus/esp/sd@0,0 + +On sun4 systems, you may not need to specify the boot file, as +the OpenBSD boot blocks will look for "bsd" on the boot device by default. + +OpenBSDCongratulations + +If you will be running your OpenBSD system from a serial console, you may +need to edit /etc/ttys and change the terminal type, and getty method from +"sun" and "suncons" to "vt100" and "std.9600" or something similar. Also +when running from a serial console, you may wish to adjust the eeprom +settings for input-device, output-device, screen-#columns, and screen-#rows +as appropriate. + +If you plan on using the extra serial ports on 4/300 systems, +you'll need to make sure you have device nodes for them e.g.: + mknod /dev/ttyc c 12 4 + mknod /dev/ttyd c 12 5 +To use these ports for terminals etc, you will want to add them to +/etc/ttys. + +In order to use 'tip' on OpenBSD/sparc, you'll need to edit /etc/ttys +and add "local" to the end of the tty configuration line, and run +'ttyflags -a' to put your changes into effect. + +If you are unfamiliar with UN*X-like system administration, +it's recommended that you buy a book that discusses it. + + + +Installing from SunOS. + +You need a SunOS machine to install OpenBSD. You also need at +least the following pieces: + + the *.tgz files you want to install (as a minimum, base{:--:}OSrev.tgz and + etc{:--:}OSrev.tgz) + gunzip (GNU gzip) SunOS binary + gtar (GNU tar) SunOS binary + a "/boot" file from a SunOS machine that matches your machine type + (e.g. sun or sun4c) + a kernel, most likely "/bsd" + +All these pieces, except "/boot" and the GNU utilities are supplied in +the OpenBSD/sparc distribution. + +You need to format and partition the disk using SunOS (since +OpenBSD/sparc uses SunOS disk labels.) Give yourself adequate +partition sizes. Here is an example layout: + + partition size offset will be.. + sd0a 80000 0 / + sd0b 256000 80000 swap + sd0c 4165271 0 `whole disk' + sd0d 100000 436000 /var + sd0f 100000 336000 /tmp + sd0g 3229271 936000 /usr + sd0h 400000 536000 /var/tmp + +Use SunOS to newfs the partitions which will have filesystems on them. +(OpenBSD's filesystem format is identical to SunOS). + + sunos# newfs /dev/rsd0a + [... lots of output] + +Repeat for any other partition (in this example, /dev/rsd0d, /dev/rsd0f, +/dev/rsd0g, /dev/rsd0h). + +NOTE: If you are able to, there is a performance benefit from +newfs'ing using OpenBSD. If you newfs using the OpenBSD newfs command, +be sure to use the -O flag for your / partition, so that newfs will +use the 4.3BSD filesystem format, rather than the new 4.4BSD filesystem +format. If you forget, you will not be able to boot -- the SunOS boot +blocks do not understand the extended 4.4BSD filesystem format. + +Mount those partitions in a tree formation, under /mnt; ie: + + sunos# df + Filesystem kbytes used avail capacity Mounted on + [...] + /dev/sd0a 38427 0 38427 0% /mnt + /dev/sd0d 48249 0 48249 0% /mnt/var + /dev/sd0f 48249 0 48249 0% /mnt/tmp + /dev/sd0g 1564024 0 1564024 0% /mnt/usr + /dev/sd0h 193536 0 193536 0% /mnt/var/tmp + +Place a standard SunOS "boot" program in /mnt (your new root +partition), and use the SunOS command "installboot" to make it work. +The installboot man page says to do something like this: + + sunos# cp /usr/mdec/sdboot /mnt/boot + sunos# sync; sync + sunos# /usr/mdec/installboot -vlt /mnt/boot /usr/mdec/bootsd /dev/rsd2a + +You can now extract the provided "*.tgz files onto your disk. + + sunos# ls -FC + base{:--:}OSrev.tgz comp{:--:}OSrev.tgz man{:--:}OSrev.tgz xfont{:--:}OSrev.tgz + bsd etc{:--:}OSrev.tgz misc{:--:}OSrev.tgz xserv{:--:}OSrev.tgz + bsd.scsi3 game{:--:}OSrev.tgz xbase{:--:}OSrev.tgz + sunos{:-#-:} gunzip < base{:--:}OSrev.tgz | (cd /mnt; gtar xvpf -) + [...] for each set + +And finally copy an OpenBSD kernel (either bsd or bsd.scsi3) onto your disk. + + sunos# cp bsd.scsi3 /mnt/bsd + +The GNU gunzip and gtar programs are not distributed as part of SunOS, +but may be present in your /usr/local/bin. If not, you will need to +obtain them from a GNU archive and install before proceeding. The +OpenBSD tar files are in the "new format" that includes directory +information, and the standard SunOS tar will not extract from them +successfully. + +After the files have been extracted, setup /mnt/etc/fstab to match +your actual disk layout. (Minus the "/mnt" component of each path, of +course :-) + +Now proceed to reboot the machine and the customize your installation. + + +Net Boot or Diskless Setup Information: + +The set up is similar to SunOS diskless setup, but not identical, because +the Sun setup assumes that the bootblocks load a kernel image, which then +uses NFS to access the exported root partition, while the OpenBSD bootblocks +use internal NFS routines to load the kernel image directly from the +exported root partition. + +Please understand that no one gets this right the first try, since +there is a lot of setup and all the host daemons must be running and +configured correctly. If you have problems, extract the diskless(8) +manpage, find someone who's been through it before and use the host +syslog and tcpdump(8) to get visibility of what's happening (or not). + +Your Sparcstation expects to be able to download a second stage bootstrap +program via TFTP after having acquired its IP address through RevARP when +instructed to boot "over the net". It will look for a filename composed of +the machine's IP address followed by the machine's architecture, separated +by a period. For example, a sun4c machine which has been assigned IP +address 130.115.144.11, will make an TFTP request for `8273900B.SUN4C'. +Normally, this file is a symbolic link to an appropriate second-stage +boot program, which should be located in a place where the TFTP daemon +can find it (remember, many TFTP daemons run in a chroot'ed environment). + +You can find the boot program in `/usr/mdec/boot' in the OpenBSD/sparc +distribution. Unfortunately, it is necessary to install this file +differently for sun4 and sun4c clients: the sun4 version needs to have its +`a.out' header stripped off (otherwise the machine will crash), while the +sun4c version must retain it (otherwise the PROM will complain). + +Here's an example to illustrate this whole mess: + + server# cd /<client-root-dir>/usr/mdec + if client is a sun4: + server# set SKIP=1 + server# set KARCH=SUN4 + else + server# set SKIP=0 + server# set KARCH=SUN4C + server# dd if=boot of=/tftpboot/boot.sparc.OpenBSD.$KARCH skip=$SKIP bs=32 + server# cd /tftpboot + server# ln -s boot.sparc.OpenBSD.$KARCH 8273900B.$KARCH + + +After the boot program has been loaded into memory and given control by +the PROM, it starts locating the machine's remote root directory through +the BOOTPARAM protocol. First a BOOTPARAM WHOAMI request is broadcast +on the local net. The answer to this request (if it comes in) contains +the client's name. This name is used in next step, a BOOTPARAM GETFILE +request -- sent to the server that responded to the WHOAMI request -- +requesting the name and address of the machine that will serve the client's +root directory, as well as the path of the client's root on that server. + +Finally, this information (if it comes in) is used to issue a REMOTE MOUNT +request to the client's root filesystem server, asking for an NFS file +handle corresponding to the root filesystem. If successful, the boot +program starts reading from the remote root filesystem in search of the +kernel which is then read into memory. + +You will want export the miniroot{:--:}OSrev.fs filesystem to the client. You +can dd this filesystem image to some spare partition, mount and export +that partition or use tar to copy the contents to a more convenient spot. + +Alternatively you can build a bootable partition from the distribution sets +as follows: + +Unpack `base{:--:}OSrev.tgz' and `etc{:--:}OSrev.tgz' on the server in the root directory +for your target machine. If you elect to use a separately NFS-mounted +filesystem for `/usr' with your diskless setup, make sure the "./usr" base +files in base{:--:}OSrev.tgz end up in the correct location. One way to do this is +to temporarily use a loopback mount on the server, re-routing <root>/usr to +your server's exported OpenBSD "/usr" directory. Also put the kernel and +the install/upgrade scripts into the root directory. + +A few configuration files need to be edited: + + <root>/etc/hosts + Add the IP addresses of both server and client. + + <root>/etc/myname + This files contains the client's hostname; use the same + name as in <root>/etc/hosts. + + <root>/etc/fstab + Enter the entries for the remotely mounted filesystems. + For example: + server:/export/root/client / nfs rw 0 0 + server:/export/exec/sun4.OpenBSD /usr nfs rw 0 0 + +Now you must populate the the `/dev' directory for your client. If you server +runs SunOS 4.x, you can simply change your working directory to `<root>/dev' +and run the MAKEDEV script: `sh MAKEDEV all'. + +On SunOS 5.x systems, MAKEDEV can also be used, but there'll be error +messages about unknown user and groups. These errors are inconsequential +for the purpose of installing OpenBSD. However, you may want to correct them +if you plan to the diskless setup regularly. In that case, you may re-run +MAKEDEV on your OpenBSD machine once it has booted. + diff --git a/distrib/notes/sparc64/prep b/distrib/notes/sparc64/prep new file mode 100644 index 00000000000..1589c5233bc --- /dev/null +++ b/distrib/notes/sparc64/prep @@ -0,0 +1,62 @@ + +Your OpenBOOT ROM may need some setup. If you are running OpenBSD on +a sun4c, or sun4m system, the ROM must be set to "new" command mode. +If your sun4c or sun4m machine comes up and gives you a `>' prompt +instead of `ok', type: + + >n + ok setenv sunmon-compat? false + ok + +This is needed because OpenBSD relies on the behaviour of the "new" command +mode. OpenBSD will not boot correctly on sun4c or sun4m systems that +are not running in "new" command mode. The sun4 systems such as the 4/110, +4/200, and 4/300 system do not have a "new" command mode, and will work +fine as-is. + + +Your OpenBOOT ROM may need some setup. You cannot use the security modes +of the sparc OpenBOOT ROM. Make sure that the ROM security modes are +disabled: + + ok setenv security-mode none + + +Please note that while OpenBSD and SunOS have a reasonable degree of +compatibility between disk labels and filesystems there are some problems +to watch out for during initial installation or when trying to maintain +both OpenBSD and SunOS environments on the same system. + + If the OpenBSD fsck(8) utility is used on a SunOS filesystem, it will + set OpenBSD "clean flags" and BSD4.4 summary fields in the superblock. + SunOS does *not* like this and you will have to do a "fsck -b 32" under + SunOS to access an alternate superblock to repair the filesystem. You + should always specify SunOS filesystem with a "pass number" of 0 in + their /etc/fstab entry to prevent this, and preferably mount them "RO". + + If SunOS fsck is used on an OpenBSD filesystem in the default OpenBSD + (4.4BSD) format, it will first complain about the superblock and then + about missing . and .. entries. Do *not* try to "correct" these + problems, as attempting to do so will completely trash the filesystem. + + You should avoid using soft updates (option softdep in /etc/fstab) + on your shared filesystems. + Although untested, it is likely that SunOS would be confused by a + filesystem with soft update flags enabled. + +The OpenBSD "Sun Compatible" disklabel have been extended to support 16 +partitions, which may be compatible with Solaris, but the old SunOS +format(8) utility only sees the first 8 partitions and may "lose" +information about the extended partitions. + +Use SunOS format(8) only with *extreme* caution on drives that contain +OpenBSD partitions. + + +OpenBSD and Sun BSD bootblocks are similar in concept, though implemented +differently. The OpenBSD bootblocks are architecture independent and also +understand the extended disklabels with 16 partitions. You can use SunOS +bootblocks, but remember that OpenBSD bootblocks must be installed with +OpenBSD installboot and SunOS bootblocks with SunOS installboot. + + diff --git a/distrib/notes/sparc64/upgrade b/distrib/notes/sparc64/upgrade new file mode 100644 index 00000000000..b7ee9ee41a7 --- /dev/null +++ b/distrib/notes/sparc64/upgrade @@ -0,0 +1 @@ +OpenBSDUpgrade({:- or the installation floppy-:}) diff --git a/distrib/notes/sparc64/whatis b/distrib/notes/sparc64/whatis new file mode 100644 index 00000000000..8956be0a8a4 --- /dev/null +++ b/distrib/notes/sparc64/whatis @@ -0,0 +1,5 @@ +OpenBSD/sparc64 OSREV is a port to the UltraSPARC processor-based machine, +such as the workstations manufactured by Sun Microsystems. + +This port is in its infancy, so device support is somewhat limited, but +active development is continuing. diff --git a/distrib/notes/sparc64/xfer b/distrib/notes/sparc64/xfer new file mode 100644 index 00000000000..41a53611a28 --- /dev/null +++ b/distrib/notes/sparc64/xfer @@ -0,0 +1,302 @@ +Installation is supported from several media types, including: + + FFS partitions + Tape + Remote NFS partition + CD-ROM + FTP + HTTP + +Not all methods are supported on all Sparc Systems and some of them +work only with the floppy or the miniroot installation. + +If you have the OpenBSD CD-ROM distribution (and a CD-ROM drive), you +may be able boot from it. Not all sparc systems support booting from +CD-ROM and the current boot images is only known to work on sun4c and +some sun4m architecture workstations. If you can boot from the CD-ROM, +you are home free and can proceed to the installation steps. If not, +you will need to do some setup work to prepare a bootable image, either +a floppy, hard drive, or compatible net boot server. + +In addition to the bootable image, you also need to consider how to +access the binary distribution sets to actually install the system. If +you have the OpenBSD CD-ROM distribution you can either access the +CD-ROM directly from the bootable image or remotely mounted on another +system via NFS. + +Although you can access the distribution sets directly from the CD-ROM or +from one of the FTP mirrors over the internet, you may wish to transfer +the sets to a local FTP or NFS server, or copy them to a partition on +the target system's disk or onto a SCSI tape. + +The variety of options listed may seem confusing, but situations vary +widely in terms of what peripherals and what sort of network arrangements +a user has, the intent is to provide some way that will be practical. + + +Creating a bootable floppy disk using DOS/Windows: + + First you need to get access to the OpenBSD Bootable floppy + images. If you can access the CD-ROM distribution under DOS + the bootable disks are in the OSREV/sparc directory, otherwise + you you will have to download them from one of the OpenBSD + ftp or http mirror sites, using ftp or a web-viewer. In either + case, take care to do "binary" transfers, since these are + images files and any DOS cr/lf translations or control/z EOF + interpretations will result in corrupted transfers. + + You will also need to go to the "tools" directory and grab a + copy of the rawrite.exe utility and its documentation. This + program is needed to correctly copy the bootable filesystem + image to the floppy, since it's an image of a unix partition + containing a ffs filesystem, not a MSDOS format diskette. + + Once you have installed rawrite.exe, just run it and specify the + name of the bootable image, such as "floppy.fs" and the name of + the floppy drive, such as "a:". Be sure to use good quality HD + (1.44MB) floppies, formatted on the system you're using. The + image copy and boot process is not especially tolerant of read + errors. + + Note that if you are using NT to write the images to disk, you + will need to use ntrw.exe instead. It is also available in the + "tools" directory. Grab it and run in with the correct + arguments like this "ntrw <image> <drive>:" + + Note that, when installing, the boot floppy can be write-protected + (i.e. read-only). + + +Creating a bootable floppy disk using SunOS or other Un*x-like system: + + First, you will need obtain a local copy of the bootable filesystem + image as described above. If possible use cksum or md5 to verify + the checksums of the images vs. the values in the CKSUM or MD5 + files on the mirror site. + + Next, use the dd(1) utility to copy the file to the floppy drive. + Under SunOS, the command would be: + + dd if=floppy{:--:}OSrev.fs of=/dev/rfd0c bs=36b + + If you are using something other than SunOS, you may have to adapt + this to conform to local naming conventions for the floppy and + options suitable for copying to a "raw" floppy image. The key + issue is that the device name used for the floppy *must* be one + that refers to the whole 2880 block image, not a partition or + compatibility mode, and the copy command needs to be compatible + with the requirement that writes to a raw device must be in + multiples of 512-byte blocks. The variations are endless and + beyond the scope of this document. + + If you're doing this on the system you intend to boot the floppy on, + copying the floppy back to a file and doing a compare or checksum + is a good way to verify that the floppy is readable and free of + read/write errors. + + + +Creating a bootable hard disk using SunOS or other Un*x-like system: + + If you don't have a floppy drive you can copy the single floppy + installation image "floppy{:--:}OSrev.fs" or the mini-root "miniroot{:--:}OSrev.fs" + onto the hard disk you intend to boot on. Traditionally, the + way to do this is to use dd(1) to place the bootable filesystem + image in the "swap" partition of the disk (while running in + single user mode), and then booting from that partition. + + Using the "b" partition allows you to boot without overwriting + any useful parts of the disk, you can also use another partition, + but don't used the "a" or "c" partition without understanding + the disklabel issues described below under "incompatible systems". + + This requires that you be running SunOS, Solaris, OpenBSD or NetBSD + which have a compatible view of SunOS disk labels and partitions. + + Use the dd(1) utility to copy the file to the hard drive. + Under SunOS, the command would be: + + dd if=floppy{:--:}OSrev.fs of=/dev/rsd0b bs=36b + - or - + dd if=miniroot{:--:}OSrev.fs of=/dev/rsd0b bs=36b + + The blocksize is arbitrary as long as it's a multiple of 512-bytes + and within the maximum supported by the driver, i.e. bs=126b may + not work for all cases. Again, device/partition names may vary, + depending on the OS involved. + + If you are preparing the hard drive on an incompatible system or + don't care about the hard disk contents, you can also install the + bootable image starting at the beginning of the disk. This lets + you prepare a bootable hard-drive even if don't have a working + operating system on your Sparc, but it important to understand + that the bootable image installed this way includes a "disk label" + which can wipe out any pre-existing disklabels or partitioning for + the drive. + + The floppy image is used only for booting, and can be placed in + a partition that will be overwritten during the install process, + since it actually runs off a ram-disk image in the kernel. In + contrast the miniroot is a normal unix root filesystem and you + must place in a partition that will not be overwritten until you've + completed the installation process. + + To copy the floppy image to the whole disk, overwriting labels: + + dd if=floppy{:--:}OSrev.fs of=/dev/rsdXc bs=36b + + Two notes - X should be replaced by the unit number of the target + disk, which is most likely *not* the disk/partition that's your + current root partition. Again names may vary depending on the + OS involved. Second, after doing this, the disklabel will be one + that would be appropriate for a floppy, i.e. one partition of 2880 + block, and you'll probably want to change that later on. + + If you're starting with a virgin disk and trying to do this under + SunOS, use format(8) and newfs(8) to set up the partitions and + mark the intended partition as an normal partition type. If you're + using OpenBSD, perhaps on another architecture, OpenBSD will + create a "fictitious label" that will let you access the whole + disk. + + To copy the floppy image to the hard disk, preserving SunOS, + Solaris NetBSD or OpenBSD labels: + + dd if=floppy{:--:}OSrev.fs of=/dev/rsdXc bs=1b skip=1 seek=1 + + You need to be sure that your version of dd(1) supports the + skip and seek operands, otherwise you can try a technique like: + + dd if=/dev/rsdXc of=/tmp/label bs=1b count=1 + dd if=floppy{:--:}OSrev.fs of=/dev/rsdXc bs=36b + dd if=/tmp/label of=/dev/rsdXc bs=1b count=1 + + In either case, you've created a situation where the disklabel + and the filesystem information don't agree about the partition + size and geometry, however the results will be usable. + + +Creating a network bootable setup using SunOS or other Un*x-like system: + + The details of setting up a network bootable environment vary + considerably, depending on the network's host. Extract the + OpenBSD diskless(8) man page from the man{:--:}OSrev.tgz distribution + set or see the copy on the OpenBSD web page. You will also + need to reference the relevant man pages or administrators guide + for the host system. + + Basically, you will need to set up reverse-arp (rarpd) and boot + parameter (bootpd) information and make the OpenBSD bootblock, + kernel/miniroot partition, and a swap file available as required + by the netboot setup. + + + +The steps necessary to prepare the distribution sets for installation +depend on which method of installation you choose. Some methods +require a bit of setup first that is explained below. + +The new single floppy installation allows installing OpenBSD directly +from FTP mirror sites over the internet, however you must consider the +speed and reliability of your internet connection for this option. It +may save much time and frustration to use ftp get/reget to transfer the +distribution sets to a local server or disk and perform the installation +from there, rather than directly on the internet. + + +To install or upgrade OpenBSD using a tape, you need to do the following: + + To install OpenBSD from a tape, you need to make a tape that + contains the distribution set files, each in "tar" format or + in "gzipped tar format". First you will need to transfer the + distribution sets to your local system, using ftp or by mounting + the CD-ROM containing the release. Then you need to make a tape + containing the files. + + If you're making the tape on a UN*X-like system, the easiest way + to do so is make a shell script along the following lines, call it + "/tmp/maketape". + + #! /bin/sh + tape=/dev/nrst0 + mt -f ${tape} rewind + if test $# -lt 1 + then + for file in bsd.rd boot + do + dd if=${file} of=${tape} obs=8k conv=sync + done + fi + for file in base etc comp game man misc xbase xfont xserv xshare + do + dd if=${file}OSrev.tgz of=${tape} obs=8k conv=sync + done + tar cf ${tape} bsd + mt -f ${tape} offline + # end of script + + + And then: + + cd .../OSREV/sparc + sh -x /tmp/maketape + + + Note that this script creates a bootable tape. If you only want to + fetch the OpenBSD files from tape, but want to boot from another + device, you can save time and space creating the tape this way: + + cd .../OSREV/sparc + sh -x /tmp/maketape noboot + + + If you're using a system other than OpenBSD or SunOS, the tape + name and other requirements may change. + + +To install OpenBSD using a remote partition, mounted via +NFS, you must do the following: + + NOTE: This method of installation is recommended only for + those already familiar with using BSD network + configuration and management commands. If you aren't, + this documentation should help, but is not intended to + be all-encompassing. + + Place the OpenBSD distribution sets you wish to install into a + directory on an NFS server, and make that directory mountable + by the machine on which you are installing or upgrading OpenBSD. + This will probably require modifying the /etc/exports file on + of the NFS server and resetting its mount daemon (mountd). + (Both of these actions will probably require superuser + privileges on the server.) + + You need to know the numeric IP address of the NFS server, + and, if the server is not on a network directly connected to + the machine on which you're installing or upgrading OpenBSD, + you need to know the numeric IP address of the router closest + to the OpenBSD machine. Finally, you need to know the numeric + IP address of the OpenBSD machine itself. + + Once the NFS server is set up properly and you have the + information mentioned above, you can proceed to the next step + in the installation or upgrade process. If you're installing + OpenBSD from scratch, go to the section on preparing your hard + disk, below. If you're upgrading an existing installation, go + directly to the section on upgrading. + +If you are upgrading OpenBSD, you also have the option of installing +OpenBSD by putting the new distribution sets somewhere in your existing +file system, and using them from there. To do that, you must do the +following: + + Place the distribution sets you wish to upgrade somewhere in + your current file system tree. At a bare minimum, you must + upgrade the "base" binary distribution, and so must put the + "base{:--:}OSrev" set somewhere in your file system. If you wish, + you can do the other sets, as well, but you should NOT upgrade + the "etc" distribution; the "etc" distribution contains system + configuration files that you should review and update by hand. + + Once you have done this, you can proceed to the next step in + the upgrade process, actually upgrading your system. |