Hi "unix support" - I'm not exactly sure where you are at in the troubleshooting process (hard to see which posts were last when they are replies ;-)

If I was in this particular situation (and I have been) - I would do a basic system installation from DVD (no kickstart), identify your drives/partitions/volumes... and then once you have finished the install, you will have a /root/anaconda-ks.cfg that you can retrieve the drive information from.

One of the threads in here reminded me of another situation I found myself in with the IBM server - I had installed RHEV, then VMware ESXi ... and somewhere along the way I could no longer boot the system and could not put an OS on the drives. I don't exactly know what the issue was, but I resolved it by booting with a Knoppix CD and wiping the drive information and then re-installing a GPT disk label.

My opinion is that UEFI is the better option, IF... you can make it work (obviously). Like I mentioned earlier - I suspect you are having issues with Legacy vs UEFI boot, GPT vs MSDOS boot label, or the quirky issue with the MBR I just mentioned.

Good luck!

IBM is typically very good at identifying oddities with their systems, and I don't really see any mention of strange configurations options, etc... for the install.
http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=MIGR-5087593

Ketan,
I agree with James - if you CAN get UEFI to work, use it!!!

It just seemed from that Red Hat article it recommended not using it. That --does not-- mean it won't work, you just might have to do a "Louis and Clark" expedition to make it work.

updated
Hi Ketan,

I remembered posting this from yesterday. This is from centos - but no one ever replied it it worked or not. This is worth a try to make UEFI work - centos.org forum UEFI boot partition line for kickstart, especially the portion where you see what is in the code block below...

Try this (and use UEFI, not the legacy bit) in your kickstart file... not sure if it will work (the centos forum link above never had an update if that worked, it is worth a shot)

part /boot/efi --fstype="EFI System Partition" --size=500 --ondisk=sda

See what James wrote above (thanks James)

I'll be tied up the rest of the day most likely.

Kind Regards,
Remmele

update - I thought another person (James) had posted here - if you --can-- get UEFI to work, it would be better (he mentioned that and I agree). I saw this morning at IBM's website that they believed UEFI support for RHEL 6 was resolved at RHEL 6.2 and you're using RHEL 6.4.

I do have a few dell servers running RHEL 6.5 with .5TB of RAM not using UEFI working fine, but if you can get UEFI to work, awesome.

Apologies for the clutter of links within the replies, there are some links I gave going to IBM's website and they have generally some very good documentation. One of the links I provided is specific to your server (today).

Try that bit in this post for your kickstart file, hope it works.

kind Regards,
Remmele

Hi Ketan, it seems my replies may not be populating here.

My replies have not been populating here...

Try this in the kickstart file, booting --with UEFI-- enabled!

part /boot/efi --fstype="EFI System Partition" --size=500 --ondisk=sda

I found this on a centos forum (posted it earlier in this discussion). If you can use EUFI, do so.

Hi Ketan,

Not sure if my posts will make it here in this discussion

Try entering the following into your kickstart file. I found this in a centos.org forum (mentioned earlier in this discussion).

• Use UEFI with this bit below, not the legacy boot!

part /boot/efi --fstype="EFI System Partition" --size=500 --ondisk=sda

• I mentioned earlier in this discussion regarding the problem when you enter a kickstart you land in grub... format the disk (if needed with a raid bios utility or using anaconda).

• **It seems until the disk is reformatted, the kickstart will land in grub (i've seen this before, mentioned previously a possible resolution). (mentioned previously on 6 May)

• Use 'zerombr' in the kickstart file and use the clearpart directive (constrain to your sda drive unless all raid arrays can be wiped). clearpart --ondrive=sda (mentioned previously on 6 May)

I hope this post makes it into the discussion, been trying to fix my own computer here where I am currently at.

Ketan, a recap

It seems this is the situation you have...

Based on the context of all we've discussed here's what I suspect you likely have to do next

1) Before anything else, first of all - Format the drive that is your /dev/sda drive either with a raid bios function (your IBM server may have some nice tool built in for this as well), or using anaconda to format your drive that is /dev/sda. IMPACT: Until this is done, it seems any attempt to kickstart will land you into grub (I've seen this in my environment a few times and formatting the drive seems to fix the issue.

2) After formatting the /dev/sda drive above, -- Yes, use vfat in the kickstart (2 sources)
a. REFERENCE this link, and also
b. and this link.

Verify & place this bit below into your kickstart (note, The --initlabel option has been deprecated.)

zerombr
ignoredisk --only-use=sda
bootloader --location=mbr
clearpart --all --drives=sda 
part /boot/efi --asprimary --fstype=vfat --size=500 --label=EFI --ondisk=sda
[remainder of partitioning goes here in subsequent lines]

NOTE: I've found differing documentation regarding vfat and ext3 on RHEL 6 with the /boot/efi partition. this source, paragraph 9.15.5.1.1. Advice on Partitions says " UEFI systems should contain a 50-150MB /boot/efi partition with an EFI System Partition filesystem" (I would never make a /boot partition less than 500MB myself)

3) AFTER editing the kickstart, Try the kickstart using UEFI --not the legacy boot--
- James is correct, and the non-UEFI method would be better, and only use the non-UEFI method if it simply is impossible. I saw that Red Hat article posted earlier on this, however that doesn't mean UEFI will not work necessarily.

• If vfat does not work, try this instead in the kickstart file:

part /boot/efi --asprimary --fstype="EFI System Partition" --size=500 --label=boot --ondisk=sda

4) If UEFI will not work, reengage here and someone here hopefully can help, or perhaps try what was listed in that Red Hat Solution that said to use the Legacy method for your server.

Hope this helps, sorry for the scattered posts and repetitive posts (my browser on my other computer is broken, will dump it).

Kind Regards,
Remmele

Hi Ketan,

Very glad the server is installed... That looks like a rather small drive.

In your kickstart file, were there two lines for /boot (one for /boot and the other for /boot/efi)? That could be why you have multiple partitions.

How big is the /sda drive (total, before all formatting)? Did any other partitions get created as you wish or do you only have those partitions above? That's a small drive. Is the drive you loaded this on really only about 2GB total?

What is the output of these commands:
df -PhT /boot/efi
and
fdisk -l

Gotta run to an appointment,

Kind Regards,
Remmele

Ketan, along with the above commands in the last post I made, run
df -PhT
as well - thanks

Ketan,

The '/' partition is terribly small - it looks like it is 1GB.

Sorry - perhaps should have specified, when you used the /boot/efi - I believe you did not need the additional partition of /boot/ I think in the example I gave, it only had /boot/efi

Also, your LVM volumes do not total out to the entirety of your 146GB drive. I'd recommend a --grow with your "/" partition, and larger sizes for the remainder for your partitons.

Ketan, it looks like your entire drive /dev/sda is not fully used.
I noticed a GPT partition.

I'm late for an appointment that will take most of the morning - and will be tied up this afternoon.

It seems your partitions are not very generous (understatement TM) for a 146GB drive.

Did you get this partitioning as a mandate from some vendor or someone? I'd recommend a more generous partitioning scheme where the full use of your 146gb drive is taken.

The /boot and /boot/efi also seems like overkill.

Sorry I have to go to my appointment

Kind Regards,
Remmele

Hi Ketan,

• I noticed the GPT partition and it seems to be preventing you from using the entire disk. See next bit in the next line...
  • I believe this Red Hat Solution will help you remove the GPT partition from your sda drive (look at the output you provided above). If you want to remove the GPT partition on your /dev/sdb drive, that procedure should help as well.

NOTE: I'd recommend doing the above first before re-kickstarting your system...

Next...

• I greatly suspect that the /boot/efi partition you have with 'vfat' seems to have taken the needed EFI partition, in which case you would not need to define a extra /boot partition. I believe you just need to remove the /boot line from your kickstart and use the one (you used before) for /boot/efi.

• NOTE: the "--initlabel" bit is deprecated (mentioned May 9th, see previous posts), however it seemed to get you initially going.

quote from above link:

The --initlabel option has been deprecated. To 
initialize disks with invalid partition tables 
and clear their contents, use the zerombr command. 

A few questions...

• Do you have any other systems such as this one you could look at the partitioning to see if the partitioning is sufficient?

  • If you do have another like system, have you had any of those partitions fill up?

• I have no idea what role/service(s) your server will fulfill. It seems the partitions are terribly small especially since you would want to use the entire 146GB drive, and right now the GPT partition seems to be preventing you from doing so (see first paragraph).

• I would highly recommend:
  1) Reviewing the role of your server and defining something larger for your partitions (especially "/", "/tmp", "/usr", "/var" and maybe "/home". If needed, confer with your co-workers or whoever is asking for you to create the server.

  • I noticed you have a "/logs" directory, do you have a requirement to put some atypical logs under "/logs"?
  • The typical location for logs is "/var/log" and I typically make my logs go there.
  • Did you have some requirement for a "/logs" directory?
  • Is there a reason you could not use "/var/log" instead of "/logs"? This is your choice, but just something to consider.

• The remaining directories you have defined, I can not tell you if they are sufficient but recommend you research so that later the system doesn't have full partitions and crash.

• Again, I'd highly recommend reviewing your system for the partitions you have to see how you can use the entire 146GB after removing that GPT partition.

This next line in your kickstart would make your bootloader go on sda (and sdb would be not considered for the bootloader)

bootloader --location=mbr --driveorder=sda --append="crashkernel=auto rhgb quiet"

• This would clear the partitions, and if you wished, you could replace the "bootloader" below with the one just above.

clearpart --drives=sda,sdb --all
zerombr
bootloader --location=mbr
clearpart --all --drives=sda 
part /boot/efi --asprimary --fstype=vfat --size=500 --label=EFI --ondisk=sda
part pv.13 --size=1 --grow --ondisk=sda
volgroup rootvg --pesize=32768 pv.13
[remainder of partitioning you define goes here in subsequent lines]

Ketan, Remember to clear the GPT partition on at least your sda drive (see first lines in this post).

Kind Regards,
Remmele

Hi Ketan,

Understood... Do you typically use vmware?

I brought up the removal of the GPT partition because you have a 146GB drive and it seems from all your output you certainly not using all of it. I recognize now that your partitioning is a reflection of what you use in your virtual world. If you DO wish to use the entire 146GB drive, you'll still need to remove that GPT partition.

I think your IBM physical system is what caused the need for the /boot/efi partition.

• I believe you need to keep the /boot/efi partition to what you used very recently when the kickstart finally worked. I just think it is overkill to have both /boot and /boot/efi in your kickstart file when /boot/efi seems to be what you needed.
  • (see previous comments and sources I provided leading to various links for references).

As far as the other systems, if they are operational/running, they probably should be left alone.

Does that small amount of partitioning provide enough space on your systems in general so that your partitions do not fill up? Generally, it is bad when a partition fills up and can cause issues based on whatever partition actually fills up.

See the previous posts, and especially the references/links regarding the /boot/efi partition.

Kind Regards,
Remmele

All,

I have been following this discussion and see that you come to a point where I think I have to add my point of view.

/boot
and
/boot/efi

are both needed on server that supports EFI.

/boot can be ext2, ext3 or ext4 (perferred ext4) on RHEL 6.4+

/boot/efi needs to be vfat.

Sorry Ketan, I do not see a way to keep this VMware compatible. Maybe Red Hat support knows a way to avoid EFI compatiblity.

Kind regards,

Jan Gerrit Kootstra

Hi Ketan,

I can't answer that last question, I suspect the gpt partition may have preceded the fun/events we have entertained maybe. In any case, the procedure I posted yesterday would eliminate the GPT partition.

I'll be unavailable today, tied up.

Kind Regards,
Remmele

Ketan, please -disregard- the last post (2014-05-13T), I was using my broken browser...

Ketan, regarding your question on the gpt label, I have no idea how it got there either. If you wanted to use the remainder of the disk, you could remove it with the parted commands.

Jan, thanks again, see post just above this, thanks.

Kind Regards,
Remmele

Ketan,

I think Jan is right regarding what he mentioned on calling Red Hat Support regarding what he addressed on EFI compatibility.

Thanks