Before you start you might need to consider your disk configuration to sort out a quirk in SCSI-ID to SD-UNIT mapping that exists on Sun SPARCstations. Upon leaving the factory, SunOS and the OpenBOOT ROM map according to this table: SCSI-ID -> SunOS SD-UNIT 0 sd3 1 sd1 2 sd2 3 sd0 4 sd4 5 sd5 6 sd6 Unlike SunOS and the OpenBOOT ROM, a generic OpenBSD kernel numbers SCSI drives sequentially as it finds them. The drive with the lowest SCSI-ID will be called sd0, the next one sd1, etc. This is mostly a non-issue if you have only one drive on your system, but can get confusing if you have multiple drives (unless you choose to use DUIDs to access partitions). If you plan to eliminate SunOS altogether it may be best to correct the SCSI-IDs of your drives, while if you plan to leave SunOS installed, it may be better to install OpenBSD on a drive with SCSI-ID 1 or 0. Older OpenBoot proms (versions 1.x) provide an environment variable, sd-targets, that controls the drive<->SCSI-ID mapping; you can change this to reflect the natural ordering or just set the boot related variables to boot from the correct drive, whatever the numbering. Its default-value is ``31204567'', which means unit 0 and 3 are exchanged. To revert to the ``normal'' behaviour, enter the following command: ok setenv sd-targets 01234567 Your OpenBOOT ROM may need some setup. If you are running OpenBSD on a sun4c, sun4e or sun4m system, the ROM must be set to "new" command mode. If your 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, sun4e 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. Also, 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 To disable automatic boot use the following command: ok setenv auto-boot? false and then to enable it later use: ok setenv auto-boot? true or on an installed system use the eeprom(8) command: # eeprom 'auto-boot?=true' 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 has been extended to support 16 partitions, which may be compatible with Solaris and SunOS, but they will only see the first 8 partitions and you may "lose" information about the extended partitions. OpenBSD and Sun BSD bootblocks are similar in concept, though implemented differently. The OpenBSD bootblocks are architecture independent and also understand the extended disk labels 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.