I was going to ask for a screenshot of the hung state and ask you to check the server was configured to boot from the network first, then look at your http connection to the pxe server, but... I see from your case #17331, and the related case #17241 that you've probably had all that from support already, and you're having a serious issue with the %POST section of your kickstart file.

Have you tried pasting the whole of your original kickstart file into the space for additional kickstart options? Anything placed in there overrides the GUI portion of the system package.

Fair enough.

I'm afraid I haven't come across issues with the grub loader as you describe.

It seems to me that you could do with a way of replacing the generated kickstart file with your own kickstart file.

There is a place that you can put commands early enough in the process to do this, but I can't remember where it is.

About two years ago I had to replace a section of the config file that is passed to the pxe client so that it had the correct address to access the appserver from the subnet it was in.

I'll try to find that for you, but maybe someone else reading this can chip in if they know it.

I've searched through my old tickets and I can't find the answer in there. It must have been given by phone.

When Dan Fitzpatrick gets in he should be able to tell you how to do this.

did this box have an os on it before you provisioned it?

you might need to wipe the MBR on the drives - if our install of redhat puts grub on a drive partition and not the MBR, and there is an old grub installed on the mbr this might happen.

wiping the MBR in this case will not help. what olivier is hitting is a functionality issue with how we do the "%post" section of the post os install script. we create a script that gets executed during the boot process that happens immediately following the OS install. additionally, the customer provides two post sections in their typical system package, one which is a regular "%post" and another which is "%post --nochroot". the nochroot one can be forced into the package by inserting the "%post --nochroot" into the post os install script at the end. this will result in two "%post" sections being created. he needs this to run, however, before the system reboots and not during the startup process. this is where the enhancement requests have to come into play...

oh...that's interesting... the %post --no-chroot runs outside the /mnt/sysimage ? that's useful actually.

for more information:

https://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/sysadmin-guide/s1-redhat-config-kickstart-postinstall.html

https://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/sysadmin-guide/s1-kickstart2-postinstallconfig.html

I have provisioned RHEL4U3 successfully on my demo drive many times - not w/ the options your client is using though.

Hello,

I have provisioned Red Hat 4 update 2 without problem on DL380 G5. In fact the problem depends of the hardware. For IBM x3350 I need a Red Hat 4 update 7.

For each different hardware you have to validate the network install.

Regards,

Nicolas