On 05/28/09 00:36, Martin Bochnig 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). >
Yes, we only use the first 2TB currently and we are working on getting all pieces together to allow for booting (and installing) on to an EFI labeled disk. However this particular problem 6843138, happens even with a limited to 2TB vtoc on the disk as grub is checking I/O limit against capacity and the capacity is not only not correctly reported by BIOS but also grub has a bug where it chops the capacity to lower 32 bit value of what BIOS reports. About the other comment on 6775732, that bug is already fixed and since it went to build 109 of snv, Opensolaris 0906 should already have the fix. This problem should not cause any issues during boot anyway as far as I know. Please let me know if I can provide further info Thanks --shidokht > 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 >
