Bugzilla – Bug 9026
vtoc partition size is not cylinder size adjusted on disk bigger than 1.96TB
Last modified: 2009-07-10 05:47:29 UTC
You need to log in before you can comment on or make changes to this bug.
I installed osol 2009.06 111b2 on a 2.2 TB raid array. Install went ok. Upon reboot, running format and choosing the boot drive, format thinks the disk is not labeled. Looking at caiman source the problem might be idm_adjust_vtoc()'s second arg nsecs is defined as uint16_t. idm_create_vtoc() is calling it with an uint32_t. On a larger than 1.96TB disk indeed the nsecs will overflow uint16_t. prtvtoc output: * /dev/rdsk/c10t0d0s2 partition map * * Dimensions: * 512 bytes/sector * 315 sectors/track * 255 tracks/cylinder * 80325 sectors/cylinder * 53468 cylinders * 53466 accessible cylinders * * Flags: * 1: unmountable * 10: read-only * * Unallocated space: * First Sector Last * Sector Count Sector * 0 80325 80324 * * First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 0 2 00 80325 4294562921 4294643245 2 5 01 0 4294656450 4294656449 8 1 01 0 80325 80324 4294562921/80325 = 53464.83561780267662620603 0t80325 = 0x139c5 4294562921/0x39c5 = 290389.00000000000000000000
Shidokht, you are right - good catch ! Just to understand the impact of the bug and obtain more data for determining the severity of the issue - installed system booted fine or is it unusable ?
After install, took the DVD out, and booted from hard disk. Worked fine. However while booted from hard disk, doing a reboot takes me to grub menu. Reinstalled just to double check, same behavior. I had a couple of ide disks in my machine. I removed them and reinstalled osol 200906 on the same 2.2 TB raid array (I have a 300GB array on same controller btw). Problem persists and the second reboot from hard disk is taking me to grub menu. Doing a findroot (pool_rpool,0,a) I get: zio_read_data failed Error 15: File not found. Trying snv_114, I am getting ata reset warnings. Looking into that.
A minor correction to my previous comment. Upon second reboot I am getting the grub prompt, not the menu. That was a typo on my part.
Filed bugster CR 6843138 for the boot issue which I could reproduce with snv_114.
Thank you for the update. At this point I assume that the installation was done on x86 platform using GUI installer - is it correct ? That said, based on the location of the problem, the same issue likely affects AI installer for both platforms (x86 & Sparc). I am thinking about following workarounds: [1] GUI x86 Install into Solaris2 partition which is smaller then critical size, so that overflow doesn't occur - reported as 1.96 TB in Description. [2a] AI Sparc create VTOC outside the installer and install into preexisting slice [2b] AI x86 create Solaris2 partition and VTOC outside the installer and install into preexisting slice or make sure that partition created by the AI is smaller then critical size. Shidokth, you are mentioning in Description that the issue is hit for disks larger than 1.96TB. Is it always assured that for smaller disks (or Solaris2 partition) the overflow doesn't occur ? Do you happen to know, how is 'nsecs' determined by Solaris from disk/partition size ? Also, if you install in smaller partition/on smaller disk, can you still see the problem with ending up in GRUB after second reboot ? I am asking trying to determine if this might be separate or related issue.
Installation was done using GUI installer from DVD. For x86 by default for > 8G we do the following in cmlb (common labeling module that most target drivers use) nhead = 255, nsect calculated to be the smallest multiple of 63 based on capacity: nsect = = ((capacity + (UINT16_MAX * 255 * 63) - 1) / (UINT16_MAX * 255 * 63)) * 63; 4211279100 blocks is the cut off from 255 x 252 to 255 x 315. I need to double check but for sparc but I believe we use the same algorithm there in format. We have 6843138 also which I am looking into. Creating a smaller VTOC/fdisk partition may workaround 9026 on x86 but may not be a workaround for 6843138. One problem there is capacity of the drive is not determined correctly in grub.
BTW, please note that the geometry calculation for x86 is based on capacity of the drive not size of Solaris fdisk partition. So I don't think that the possible workarounds to create smaller fdisk partitions for caiman would work.
(In reply to comment #7) > BTW, please note that the geometry calculation for x86 is based on capacity > of the drive not size of Solaris fdisk partition. So I don't think that > the possible workarounds to create smaller fdisk partitions for caiman > would work. Shidokht, you are right - thank you very much for pointing this out.
suggested fix: modify idm_adjust_vtoc(), so that it uses uint32_t data type for 'number of sectors per cylinder' information in order to avoid overflow for disks >1.96TB.
While there, changing also types of idm_ajust_vtoc() local variables holding slice geometry (start sector & sector size) from uint32_t to diskaddr_t - diskaddr_t is used for slice geometry in extvtoc structure introduced by +1tb project.
fixed in changeset: 229231b744a2062ce6810cbab433679b0b733c50