Description of problem: Anaconda loops on a system with SATA Raid (dmraid) and disk label GPT last action is entering the license code for rhel Version-Release number of selected component (if applicable): rhel 5.3 alpha How reproducible: always Steps to Reproduce: 1. have a disk with GPT 2. have SATA RAID activated 3. start installation Actual results: installation does not work Expected results: successful installation Additional info: On the same system fedora 10 beta was installed successfully
*** Bug 467857 has been marked as a duplicate of this bug. ***
dmraid doesn't handle GPT at all and it shouldn't, it just activates mappings for the whole drives involved in a RAID set and any activation of discovered GPT partitions is subject to kpartx. Any insight what causes anaconda to loop ?
(In reply to comment #0) > Description of problem: > > Anaconda loops on a system with SATA Raid (dmraid) and disk label GPT > last action is entering the license code for rhel > Can you please switch to virtual terminal 3, 4 and 5 and see what messages are there? Either write them down or take photo's with a digital camera and attach those, thanks! You can switch to virtual terminal 5 from the graphical installer by pressing CTRL + ALT + F5, likewise you can switch to terminal 4 by pressing CTRL + ALT + F4, etc.
Digging further, I believe that this is fixed in snapshot 3, can you please retest this with snapshot3 (not the 53 beta release, but snapshot3 released at the end of last week). snapshot3 has a few dmraid bugs fixed including one causing a hang at exactly the point you are seeing. I think this is unrelated to the use of GPT and just a generic dmraid issue we have been seeing in several cases. If you still experience the hang with snapshot3, then please provide the information as requested in comment 3.
Hi, Snap3 changed things but did not improve dmraid on ESB2 LSI firmware. Now installation starts, but rhel5 refuses to install on disk with GPT - claims system does not support GPT, which no other linux distribution tells me ( including fedora ). Have a nice evening, Winfrid
Ok, updating summary to match the new info.
Question is this an Itanium (ia64) system or just a regular i386 or x86_64 system? In RHEL5.x We only support booting using EFI (which is a requirement for using GPT) on ia64 systems.
Hello Hans, I thought already that this would be the "RedHat" answer. Even the tested system is not a system with EFI, I have at home an 3 year old Intel x86 server with EFI. But EFI should not be the restriction for support of GPT. So disks are offering much more capacity you will run very soon into the limits of a msdos partition table ( 2 TB, not more than 15 partitions with a present unmodified kernel ). And fedora already supports GPT, so my question, when will you remove the restriction concerning GPT in RHEL 5. For rhel6 FSC already asked for support of gpt. And just a small correction, not GPT requires EFI - it is the other way around.
(In reply to comment #8) > But EFI should not be the restriction for support of GPT. I'm not very familiar with EFI / GPT myself, but I've been told that having an EFI capable BIOS is required to be able to boot from GPT, which is why we do not support GPT on systems where we don't support EFI. So we do not consider what you are seeing a bug, and as you've already stated yourself a feature request for what you want has already been created.
For anybody stumbling on this bug, you can work around this by wiping the GPT in %pre section. This won't allow you to use GPT but it will allow you to install with msdos style partition table on a system that previously had a GPT: %pre --interpreter /bin/bash # blank out GPT to work around https://bugzilla.redhat.com/show_bug.cgi?id=467848 dd if=/dev/zero of=/dev/sda bs=512 count=2 dd if=/dev/zero of=/dev/sda bs=512 count=2 seek=$(($(blockdev --getsz /dev/sda) - 2))