Grub 0.97 does not include support for GPT partition tables and upstream has stated that they have no intention of adding this support as it is a Grub "2" feature. Perhaps this is a pessimistic view point but I don't believe we'll be seeing a stable Grub "2" release for some time. This going to become a serious problem for many users in the near future as storage devices in excess of 2TB are becoming more and more common. We're likely just few years away from seeing single disks in this size range. In my case, I've encountered this issue already with 10TB RAID sets that I'd like to be able to boot from. I've been able to work around this limitation in two ways. 1) cutting the RAID set up into multiple volumes with first one being smaller than 2TB so it can host a msdos partition table or 2) building my own liveCD with a patched version of grub that supports GPT partition tables and using a portage overlay with the same patched version of grub. It is my belief that fix #2 is the more elegant solution. Therefore I'd like to propose that Gentoo patches grub to support GPT partitions. The patch that I pulled from the grub mailing lists to add this support is attached and I can attest that it is functional in a production environment. Reproducible: Always
Created attachment 119309 [details] 0.97-r3 ebuild modified to apply gpt patch
Created attachment 119311 [details] grub gpt patch from: http://www.mail-archive.com/bug-grub@gnu.org/msg10632.html
Is this patch to be pushed in quite soon ? if not how could I do it ? I've tried replacing 0.97-r3.ebuild (v1.10) with the one here, but then emerge complains because of Manifest signatures incorrect and so I reverted ... Is there trouble with GPT for lilo too ? while elilo is masked for amd64....
Coornaert David - you need to rebuild the digest for the ebuild Is there any interest or even hope of a response on this issue from the grub ebuild maintainer?
(In reply to comment #4) > Coornaert David - you need to rebuild the digest for the ebuild > > Is there any interest or even hope of a response on this issue from the grub > ebuild maintainer? > back from holidays, sorry for late reaction, Indeed I figured that I had to fiddle the digest, but I never did this kind of stuff, I'd really appreciate directions/howtos for this case in all cases, +2Tera disks are more and more common, hence I'd advocate for this patch to reach the standard grub ebuild who's in charge of this ?
This patch works for us on amd64 and we need it badly for our 4tb systems. Could this be integrated in the default grub-0.97 ebuild ?
We've been using this patch in our internal portage_overlay tree for months and months and both x86 and amd64. There have been zero problems.
I'm just testing, and will commit this probably on Sunday.
Ok, it works in both non-GPT and GPT disks fine. For non-GPT, I did my laptop, and for GPT I did my new 1U server (/dev/sda is >2Tb as it's a nice 3ware array). I've put it in the tree now, I'll blog about using it so that the Planet feeds pick it up.
Great, thanx
thanks
I'm using a gentoo based system embedded in an initrd as a platform installer. The linux kernel is booted from PXE and operates the following: - partitions the HDDs - installs grub (built from portage) - installs other OS and soft Then the platform restarts and boots the other OS via grub. When using grub-0.97-r3 everything goes well. When just emerging grub-0.97-r4, something goes wrong. When the platform restarts at the end of the install, it tries to boot on the HDD which MBR contains grub stage-1 and suddenly restart again (over and over as long as this HDD is the first boot device). What is the preferred way to diagnosis this problem ?
thild: please open a new bug, and include if you see any grub letters in the output (use a grub config that outputs to a serial port). In that bug, please also include details about your setup.
Robin, I've logged a new bug here: http://bugs.gentoo.org/show_bug.cgi?id=212165 I need to check with a serial line on spare time...
