Copyright © 2002 by Progeny Linux Systems, Inc.
PGI is pronounced identically to the English word "piggy".
These are actually two different questions.
Because PGI is an installer creation system as well as an installer, how PGI works for you is largely determined by the vendor of your PGI-based installation disc.
Your first contact should be your installer vendor. You can find this information at the top of the /var/log/installer.log file.
# head /var/log/installer.log PGI 0.9.7 Architecture: i386 Vendor: Example Penguin Unix Systems Inc. Product: Herring GNU/Linux Version: 1.0beta2 Based on Debian release: 3.0 Built by: Emperor Tux III <emperor_tux@example.com> Command line: /usr/bin/pgi-build --codename=herring PATH is "/sbin:/bin". LD_LIBRARY_PATH is "/lib". |
PGI creates four log files during the installation procedure; you will likely need to be able to give these files to your vendor's technical support representative so that they can diagnose your problem and provide you with a solution. The log files are:
/var/log/installer.log
/var/log/installer.syslog
/var/log/installer.ident
/var/log/installer.dmesg
Note: These files are preserved after installation in the system's /var/log directory, having been copied from the installation environment.
If you do not have the installing system's network configured, the install will not complete, and you need to preserve the logfiles, simply use the pgilogs2disk, available in the installer environment.
pgilogs2disk will copy these log files into a DOS-formatted floppy. From there, the files can be accessed from any computer with the floppy drive, using any operating system that understands the DOS disk format.
Finally, if you have discovered a bug in PGI itself, and (if applicable) confirmed this fact with your installer vendor, you may report the problem to the Debian Bug Tracking System. Ony highly-recommended utility for automating Debian bug reporting procedures is reportbug.
The initial RAM disk used by the installer for a root filesystem is a Second Extended filesystem ("ext2"); support for this filesystem type must be built into the kernel used by PGI. See the kernel configuration chapter of the PGI vendor's manual for more information.
This problem is usually encountered by people testing PGI installers that they just created; if this happens with a PGI disc you received from someone else, either something highly unusual is afoot, or the installer vendor made an error when producing the PGI ISO image.
There are a few possibilities.
The PGI installer X client does not have permission to run on the remote X server. As a matter of security, by default in the X Window System, clients must possess an authentication token before they are permitted to run on an X server. This is what the .Xauthority file in the home directory of the user running the X server is for.
One way to resolve this problem is to copy the X server's authorization token to the machine where the PGI installer is running (this works for MIT-MAGIC-COOKIE-1 and XDM-AUTHORIZATION-1 tokens; it is untested for other authorization mechanisms). One means of doing this is by using scp on the installing system to fetch the .Xauthority from the user home directory of the machine running the X server.
Another way to resolve this problem is to use the xhost command on the machine and under the user account running the X server to grant all clients from a given machine permission to access the X server.
No matter which method you choose, you'll probably want to undo it once the install is finished, for peace of mind with respect to security.
The remote X server is not listening on a TCP port. The X server to which you wish to connect must be listening on a TCP port to receive the PGI installer X client's requests to be displayed. The X server will run on port number 6000 + server number. In other words, server 0 listens on port 6000, server 1 on port 6001, and so forth.
Note: Many distributions of the X Window System these days have TCP port listening turned off by default for security reasons. In most versions of the X Window System, TCP port listening can be re-enabled by omitting the -nolisten tcp argument from the X server's command line.
The network interface is not configured (correctly) on one or both of the machines. See Using the PGI Installer for more information on configuring the network interface on the system being installed. You can use the ifconfig and route commands to confirm that the interface is up (configured) and that a default route is established. Consult your operating system's documentation for information on configuring the network interface on the system running the X server.
The machine running the X server is not reachable via the network. You can use the ping and traceroute commands to do some basic network troubleshooting from the system being installed. Network outages between the installing system and the machine running the X server may be beyond your power to fix.
Some systems — particularly rackmount servers — have a BIOS feature called "console redirection". Some device-probing operations can trick the machine into thinking it should transfer the console to a serial port. Needless to say, if no terminal is connected to the serial port, this can be bewildering.
Experiments at Progeny have established that it is not the discover hardware-detection tool that causes this. We recommend turning off console redirection in your machine's BIOS if it supports this feature and you are experiencing this problem. Console redirection can be re-established after the installation, if you desire.
Ensure that your machine's BIOS is configured to boot from the drive that you installed the boot loader to. On the Intel IA-32 (a.k.a. i386) architecture, the boot loader is GNU GRUB.
If you chose not to install a boot loader, you will need an alternative means of booting the system. If the kernel used by PGI supports your disk hardware directly (i.e., with the drivers compiled into the kernel binary instead of as loadable modules), you can use the PGI installer disk as a boot disk. See Using the PGI Installer for more information.
The PGI installer establishes an initial RAM disk (initrd) for use by the installed system, similar to the one used by PGI itself. The purpose of this initrd is to run the discover command and load device drivers for your system's hardware.
The initial RAM disk is a Second Extended filesystem ("ext2"); support for this filesystem type must be built into the kernel used by PGI. See the kernel configuration chapter of the PGI vendor's manual for more information.
This problem is usually encountered by people testing PGI installers that they just created; if this happens with a PGI disc you received from someone else, either something highly unusual is afoot, or the installer vendor made an error when producing the PGI ISO image.