Red Hat Bugzilla – Bug 71438
kickstart located on webserver does not work!
Last modified: 2007-04-18 12:45:29 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020606 Description of problem: When booting 'linux ks=http://hostname/~user/path/ks.cfg', the anaconda or kickstart portion of anaconda *mangles* the URL and cannot fetch the ks.cfg kickstart script. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Make bootnet.img install floppy 2. mount /mnt/floppy and edit syslinux.cfg to change the 'ks' boot method to be the default and change the append line to use include ks=http://ipnumber/~user/path/ks.cfg 3. umount /mnt/floppy...waiting for light to turn off before removing floppy 4. Stick floppy in server and boot machine 5. Install process hangs on Blue screen ("welcome to red hat linux") 6. Looking at alt-f3 screen, I see: ks location: http:/ipnumber/~user/path/ks.cfg transferring http://ipnumber//~user/path/ks.cfg ...(and after much waiting)... failed to retrieve http:/ipnumber//~user/path/ks.cfg NOTE: the http:/ (not //) and //~user (not /~user) are EXACTLY as they are seen on the screen and not typos. Checking the web server logs, I have found in error_log: [Tue Aug 13 13:34:26 2002] [error] [client ipnumber] File does not exist: /var/www/html//~user/path/ks.cfg Why is it getting mangled? Shouldn't apache be able to deal with an extra leading / ? ~user does work for other things so it's not a lack of public_html being defined in the httpd.conf file.
An additional side note: If, instead of specifying the complete URL, I specify the server name and path...then automagically generated URL works. For example, ks=http://ipnumber/~user/path/ succesfully grabs the ip.of.install.machine-kickstart file from that URL. Strange... this (working) option of basing the kickstart filename based on IP name is not desirable for my setup (since I don't control the DHCP server) and so I'd like the problem of fully specifying the URL fixed.
Sorry to make a fuss...apparently, some bizarre interaction with a firewall was occurring between the two machines. When the http server and install box were put on the same network, the problem went away (first diagnosed by using a crossover cable). I feel like a putz. Mea Culpa.