AFAIK legacy grub can't handle GPT partitions.

But there seems to be a workaround for that: http://www.wensley.org.uk/gpt

CC: (none) => sander.lepik

fair enough, but why does the installer keep the GPT and/or install grub with that if it can't handle it?

adjusted to installer as I think it is an installer issue.

Component: RPM Packages => Installer

Could you provide the file /root/drakx/report.bug.gz as an attachment ?
I you don't have the file, you can switch to console 2 (by pressing 'Ctrl-Alt-F2') during installation, put a floppy in floppy drive or plug a USB key/stick and type: bug then press Enter. It will put report.bug on the floppy/key.

Grub legacy is supposed to support GPT. At least, we have a patch for this :
http://svnweb.mageia.org/packages/updates/1/grub/current/SOURCES/grub-gpt.diff?revision=101464&view=markup

CC: (none) => boklm

I installed today a server with 4TB GPT partitions on Mageia 1, and it works fine.

The installer does not support creating GPT partitions, however it can install on GPT partitions if the partitions are already created. So I first install Mageia using old dos partition table, then installed gdisk, created the GPT partitions using gdisk, rebooted and installed Mageia again.

(In reply to comment #5)
> I installed today a server with 4TB GPT partitions on Mageia 1, and it works
> fine.
> 
> The installer does not support creating GPT partitions, however it can install
> on GPT partitions if the partitions are already created. So I first install
> Mageia using old dos partition table, then installed gdisk, created the GPT
> partitions using gdisk, rebooted and installed Mageia again.

So I suppose there should be a message about this in installer, and in the wiki too

first cc'ing doc team, then assigning to maintainer

Keywords: (none) => USABILITY
CC: (none) => doc-bugs, marja11

because of the obvious confusion (and the big success last time :), I prepared two screen captures showing two different emanations of the same bug when installing to a gpt partitioned disk (after modifying the partition table)

the example disk image can be created like this (for simulation):
# dd if=/dev/zero of=disk_1T_sparse.img bs=1k seek=1023M count=1
# gdisk disk_1T_sparse.img
| Command (? for help): r
| Recovery/transformation command (? for help): l
| Enter backup filename to load: disk_1T_250_250_20.gpt
| Recovery/transformation command (? for help): w
| ...
| Do you want to proceed, possibly destroying your data? (Y/N): y

http://vserver.13thfloor.at/Stuff/MAGEIA/BUGS/gpt.flv.xz
http://vserver.13thfloor.at/Stuff/MAGEIA/BUGS/gpt2.flv.xz
http://vserver.13thfloor.at/Stuff/MAGEIA/BUGS/disk_1T_250_250_20.gpt

Version: 1 => Cauldron
Target Milestone: --- => Mageia 2

just verified, issue is still present in Mageia2 Beta1

CC: (none) => herbert

As far as I know the installer can create GPT partitions, it can not however create a GPT partition table on a new empty disk.

please be so kind and take the time to actually _read_ the bug report and if it is still unclear, _watch_ the screen captures ...

thanks!

Please find someone else to fix your bug.

Assignee: pterjan => bugsquad

So, removing first partition and created a new one, it gets numbered n+1, 7 in my case, 4 in the report.

* tell kernel del (sda 1  ) force_reboot= rebootNeeded=
* tell kernel add (sda 7 2048 17784833) force_reboot= rebootNeeded=

And then bootloader config is totally wrong

CC: (none) => pterjan

I just committed a fix in svn

A stage2 containing the fix for GPT partitions numbering was uploaded (Version 14.3)

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

(In reply to comment #14)
> A stage2 containing the fix for GPT partitions numbering was uploaded (Version
> 14.3)

@ Pascal

So this bug is fixed, or were you leaving it open for Herbert to confirm it is?

(In reply to comment #16)
> (In reply to comment #14)
> > A stage2 containing the fix for GPT partitions numbering was uploaded (Version
> > 14.3)
> 
> @ Pascal
> 
> So this bug is fixed, or were you leaving it open for Herbert to confirm it is?

ping?

Yes it should be fixed, closing

Status: NEW => RESOLVED
Resolution: (none) => FIXED