On Thu, May 28, 2009 at 9:36 AM, Martin Bochnig <martin at martux.org> wrote: > On Thu, May 28, 2009 at 9:29 AM, Jan Damborsky <Jan.Damborsky at sun.com> > wrote: >> Hi Shidokht, >> >> >> Shidokht Yadegari wrote: >>> >>> On 05/27/09 10:36, Jan Damborsky wrote: >>>> >>>> Hi Pallavi, >>>> >>>> could you please add release notes for bugs 9026 >>>> and 6843138 to OpenSolaris 2009.06 release notes ? >>>> >>>> Shidokht, could you please take a look to verify if >>>> the information captured below is correct and provide >>>> workaround for 6843138 if one exists ? >>>> >>> ... >>>> >>>> >>>> ================================================================================== >>>> bugid: 6843138 >>>> synopsis: can not boot off a 2.2TB and zfs root >>>> >>>> Platforms affected: >>>> x86 >>>> >>>> Description: >>>> Due to the limitation in current implementation of GRUB which OpenSolaris >>>> uses as boot >>>> loader on x86 platform, OpenSolaris operating system can't be booted from >>>> disk which >>>> capacity exceeds 2^32 sectors or 2TB (assuming that sector size is 512 >>>> bytes). >>> >>> Hi, >>> >>> Since the problem depends on whether the needed data for booting falls in >>> the region >>> defined by the lower 32bits of capacity, ?I'd suggest rewording "can't be >>> booted" >>> to "may not be booted" >> >> ok. >> >>> >>> >>> I don't have a great workaround here. For a warm reboot, if we do a >>> modunload -i 0 >>> and then do reboot, fastreboot would have a chance in rebooting the system >>> bypassing >>> grub if all loaded drivers support quiesce. >> >> If my understanding of the problem is correct, if we make sure that slice >> which root pool resides in doesn't exceed 2TB boundary, GRUB will be >> always able to locate all necessary pieces even on >2TB disk ? >> >> Thinking about this more, I am a little bit confused. I was assuming >> that it is not possible to utilize space after 2TB, as fdisk >> partition table also uses 32 bits for defining sector partition geometry, >> so it would be always assured that all necessary data are stored >> within first 2TB ? >> >> Thank you, >> Jan > > > > Jan, as far as I can tell, you are correct with this. > > Current workaround: Only access first 2TB of physical hdd due to 32bit VTOC. > Or, alternativel, use disk not as boot-device and EFI-label it (which > was't the question). > > Two long-term solutions: > > A) Grub 2 and EFI label > B) Taking relevant bits out of Grub 2 and backporting them to 0.97 as > currently shipping. > Both are technically doable. And some guys are working on this and > have it already working. > > Please ask Jan Setje-Eilers. > > Martin >
I just googled a bit, more links might follow later on. See this: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6775732 Commit to Fix snv_109 Fixed In snv_109 Release Fixed Related Bugs 4944410 , 6708609 Submit Date 24-November-2008 Last Update Date 10-February-2009 Description With the plus1tb project we now support VTOC on disks larger than 2TB. On such a disk on x86, s8-s15 minor nodes are not being created.
