I never expected this process to such a tough slog, but I'm almost there. OSCAR 5.1rc1 install on Fedora 9. Eventually clawed through various issues (including discovering that specifying a non-zero(default) "padding" in the OSCAR GUI is broken; bug report pending), I got to the point where my 16 PXE-booting nodes would successfully be given IPs ala DHCP from the master, but time-out when TFTP tried to pull over images to start the node installs. Yes, I've specified UYOK. I double-checked that all the things needed for a PXE boot were present and functional; a tftpd installed, xinetd running and /etc/xinet.d/tftp containing "disable = no" and not yes, etc. (An independent reference I used for this was http://jeffkrimmel.com/pxe-boot/ This is not a plug; I simply found it concise and helpful)
There was a recent long thread on this TFTP timeout under Centos. In my case, Fedora 9, it was simply due to firewalling, even after apparently/repeatedly disabling any and all firewalling in the appropriate Fedora admin GUI. For the interest of others, in the case of Fedora 9, turning off the firewall in the admin GUI is NOT ENOUGH; checking with "iptables -L" afterwards still shows a couple of REJECT rules, one in each of the INPUT and FORWARD chain. Remove these by hand with, e.g, "iptables -D INPUT 5" (if the REJECT rule was line #5 in the INPUT chain). Magically, upon node reset the TFTP boot then started and all seemed wonderful again. And then the next problem happened: after five minutes of disk partitioning, filesystem making, image copying, etc., the installation process failed. SystemImager claimed it wanted DEFAULTBOOT specified, specifically (in the messages to the console for the node booting), "DEFAULTBOOT must be specified at /usr/lib/systemconfig/Boot.pm, line 69" (This refers, I presume, to the master's Boot.pm file) The node was alive (in ramdisk), I was in a shell, and so I looked around while the console was still connected to the node (kvm); in fact, it did look practically all set-up with OSCAR installed. Though it looked like it tried to install all known boot methods, it had a /boot/grub directory (though in the new system disk partition /a, of course), populated with what one might expect to find (in my case, System.map-2.6.25-14.fc9.x86_64, config-2.6..., initrd-2.6..., vmlinux-2.6..., lost&found, a grub dir (though only containing splash.xpm.gz). There was no "menu.1st" or "grub.conf" anywhere, and I doubt it got to writing an MBR to disk (confirmed, because a reset didn't know what to do). It's easy to force the node to re-setup over PXE (BIOS boot order forced to ethernet), to arrive at exactly the same point another five minutes later. I'm looking into this - perhaps it's as easy as hauling out all the other boot methods in Boot.pm (I like grub, personally) - but find it surprising that yet again this is something I'd have to tinker with. If anyone has any feedback while I address this, I'm all ears. I'd also be interested in knowing if anyone has done a truly "diskless node" OSCAR install, and how (if straight-forward). Chris ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Oscar-users mailing list Oscar-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-users
