Having got PXE-based network installation of SLES9 working some time ago, I was surprised recently to find that the corresponding rescue-mode boot configuration failed (just when I needed it, having made a change that caused booting to fail). I think that's a consequence of having added SP1 & SP2 to the installation source; I'm fairly sure rescue mode "just worked" when I first set it up, using only the original SLES9 CDs. I've found some workarounds, but having set up the installation source using YaST, it seems strange that it doesn't "just work", and there may be better solutions than the ones I've found. The problem arises with an (HTTP) installation source set up using YaST (from ISO images of the original SLES9 release plus SP1 and SP2). All of the symlinks in the top-level SLES9 install source directory point at the original SLES9 release's directories, except for the driverupdate symlink which points into an SP2 directory. The TFTP directory used to get installation or whatever started is configured with copies of the linux and initrd files from the boot/loader directory on SP2's CD1. While installation works just fine (and breaks if I try using the linux and initrd files from the original SLES9 CD1), rescue mode boots OK but is totally useless because its /lib/modules directory contains only modules for the installation kernel version from the original SLES9 release, rather than for the SP2 kernel that it's actually running. In consequence, it can't access e.g. ext3 or ReiserFS partitions on the system's hard drives, and is useless for rescuing the system. Some experimentation revealed that * Replacing the "rescue" symlink in the boot directory of the original SLES9 CD1 directory with a symlink pointing at the SP2 equivalent worked * Alternatively, specifying a URL in the rescue= kernel option (instead of rescue=1) works, though not as I originally expected. The catch there is that it does NOT use the URL I supply, it adds /boot/rescue to the end of the URL. I'd set up a "rescue" symlink in the top level SLES9 installation source directory and tried a URL pointing at that, but it got a 404 (not found) error. The only way to get it to work was to use a URL pointing at the SLES9 SP2 CD1 directory so it would find /boot/rescue there. I don't really like that solution, as it seems far more likely to get overlooked after e.g. adding SP3 than if it were a symlink in the installation source directory. I had previously tried simply replacing the "boot" symlink with one pointing at the SP2 CD1 "boot" directory, and rescue mode then worked but autoinstallation failed, presumably because it needed other files from the original SLES9 "boot" directory. Questions: (1) Why doesn't YaST set up the installation source so that rescue mode will "just work", when service packs are added? Bug or oversight? (2) Is there a better solution than either of the ones that I've found and described above? [My primary source of information for setting up PXE installation etc., was http://www.suse.de/~nashif/autoinstallation/9.1/autoyast.pdf . Unlike the official SLES9 version (which scarcely mentions PXE), it includes most of the important details for setting up PXE booting/installation. However, a lot of the "fine details" are left unstated, and with regard to the rescue= setting, it just says "the URL variant specifies the location of the rescue image explicitly". That's misleading, since the URL you specify is NOT what is actually used - /boot/rescue gets appended.] John Line -- John Line - web & news development, University of Cambridge Computing Service