| Depan | Profil | Galeri | Artikel | Tutorial | Humor | Berita Terkini | Info Lowongan Kerja | Cara Cari Uang |
-----------------------------------------------------------------
"Tujuan yang besar memberikan hasil yang besar. Tidak ada tujuan tidak ada hasil apapun, atau menghasilkan tujuan orang lain" (Mark Victor Hansen)

Sep 2, 2008

12 - Common installation problems

12.1 - My Compaq only recognizes 16M RAM

Some Compaq systems have an issue where the full system RAM is not detected by the OpenBSD second stage boot loader properly, and only 16M may be detected and used by OpenBSD. This can be corrected either by creating/editing /etc/boot.conf file, or by entering commands at the "boot>" prompt before OpenBSD loads. If you had a machine with 64M RAM, but OpenBSD was only detecting the first 16M, the command you would use would be:
machine mem +0x3000000@0x1000000
to add 48M (0x3000000) after the first 16M (0x1000000). Typically, if you had a machine with this problem, you would enter the above command first at the install floppy/CD-ROM's boot> prompt, load the system, reboot, and create an /etc/boot.conf file with the above line in it so all future bootings will recognize all available RAM.
It has also been reported that a ROM update will fix this on some systems.

12.2 - My i386 won't boot after install

Your install seemed to go fine, but on first boot, you see no sign of OpenBSD attempting to boot. There are a few common reasons for this problem:
• No partition was flagged active in fdisk(8). To fix this, reboot the machine using the boot floppy or media, and "flag" a partition as "active" (bootable). See here and here.
• No valid boot loader was ever put on the disk. If you answer "Y" to the "Use entire disk for OpenBSD?" question during the install, or use the "reinit" option of fdisk(8), the OpenBSD boot record is installed on the Master Boot Record of the disk; otherwise, the existing master boot code is untouched. This will be a problem if no other boot record existed. One solution is to boot the install media again, drop to the shell and invoke fdisk(8) to update the MBR code from the command line:
• # fdisk -u wd0
Note: the "update" option within the interactive ("-e") mode of fdisk will not write the signature bytes required to make the disk bootable.
• In some rare occasions, something may go wrong with the second stage boot loader install. Reinstalling the second stage boot loader is discussed here.

12.3 - My (older, slower) machine booted, but hung at the ssh-keygen steps

It is very likely your machine is running fine, just taking a while to do the ssh key generation process. A SPARCStation2 or a Macintosh Quadra may take several hours to complete the three ssh-keygen(1) steps. Just let it finish; it is only done once per install.
Note that the default key size was increased for OpenBSD 3.8, so the generation times are much longer than they used to be. Users of very slow machines may wish to generate their keys on another computer, place them in a site41.tgz file, and install them with the rest of the file sets.

12.4 - I got the message "Failed to change directory" when doing an install

When doing an FTP install of a snapshot during the -beta stage of the OpenBSD development cycle, you may see this:

Do you want to see a list of potential FTP servers? [yes] Enter
Getting the list from 192.128.5.191 (ftp.openbsd.org)... FAILED
Failed to change directory.
Server IP address or hostname?
This is normal and expected behavior during this pre-release part of the cycle. The install program looks for the FTP list on the primary FTP server in a directory that won't be available until the release date, so you get the above message.
Simply use the FTP mirror list to find your favorite FTP mirror, and manually enter its name when prompted.
Note: You should not see this if you are installing -release or from CD-ROM.

12.5 - My fdisk partition table is trashed or blank!

Occasionally, a user will find a system will work, but when doing an fdisk wd0, they see a completely blank (or sometimes, garbage) partition table. This is usually caused by having created a partition in fdisk(8) which had an offset of zero sectors, rather than the one track offset it should have (note: this is assuming the i386 or amd64 platform. Other platforms have different offset requirements, some need NO offset). The system then boots using the PBR, not using the MBR.
While this configuration can work, it can be a maintenance problem and should be fixed. To fix this, the disk's file systems must generally be recreated from scratch (though if you REALLY know what you are doing, you may be able to recreate just your disklabel and MBR, and only lose and have to rebuild the first OpenBSD partition on the disk).


No comments: