On Thu, May 28, 2009 at 9:40 AM, Martin Bochnig <martin at martux.org> wrote: > 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. >
http://opensolaris.org/os/community/on/flag-days/pages/2008091102/ http://arc.opensolaris.org/caselog/PSARC/2008/336/20080520_shidokht.yadegari
