OpenSolaris

Category
   utility
Sub-Category
   fdisk
Description
   fdisk(1M) behavior when used with -F option has a problem that does not appear to happen when used interactively - it refuses to modify the partition table if the last partition exceeds the disk size Solaris can see, even if other systems see more space.
So when another operating system (Windows or Linux) writes a partition table entry that *it* thinks is valid, Solaris fdisk(1M) when run with -F is unable to modify *any* entries in that partition table.
What is frustrating is that even if the partition entry that fdisk(1M) is being asked to modify is *not* the partition that it is complaining about, it error exits anyway, without making the modification.
It seems that fdisk(1M) should be more tolerant in cases when a partition entry that was previously created by another system and is left unmodified just happens to not comply with what Solaris sees as the capacity of the drive. As noted, it appears that when run interactively, this is already the case.  The problems seems to only be when run with -F.
For more details, see: http://defect.opensolaris.org/bz/show_bug.cgi?id=2133
Frequency
   Always
Regression
   No
Steps to Reproduce
   
See http://defect.opensolaris.org/bz/show_bug.cgi?id=2133
Expected Result
   
That the partition table entry would be modified.
Actual Result
   jack@opensolaris:~$ pfexec fdisk -F /tmp/fd c6d0p0
fdisk: Partition table exceeds the size of the disk.
fdisk: Error on entry "  15    0    254    63     1023    254    63     1023   
293507612 97214356".
See http://defect.opensolaris.org/bz/show_bug.cgi?id=2133 for more details.
Error Message(s)
   
Test Case
   
Workaround
   
Submitter wants to work on bug
   No
Additional configuration information
   Output from iostat -En
gs145266@opensolaris-08.05-gs:~$ iostat -En
c5d0             Soft Errors: 0 Hard Errors: 0 Transport Errors: 0 
Model: Hitachi HTS7220 Revision:  Serial No: 070719DP0400DTG Size: 200.05GB
<200047067136 bytes>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0 
Illegal Request: 0 
c4t0d0           Soft Errors: 0 Hard Errors: 6 Transport Errors: 0 
Vendor: MATSHITA Product: DVD-RAM UJ-852S  Revision: 1.01 Serial No:  
Size: 0.00GB <0 bytes>
Media Error: 0 Device Not Ready: 6 No Device: 0 Recoverable: 0 
Illegal Request: 0 Predictive Failure Analysis: 0

N/A

Following Bugzilla bugs were closed as duplicate of this bug:

2133 Could not install - "fdisk(1M) -F" fails in some scenarios
http://defect.opensolaris.org/bz/show_bug.cgi?id=2133

4831 OpenSolaris 101aRC1b can not create a single fdisk partition as a multi-boot configuration
http://defect.opensolaris.org/bz/show_bug.cgi?id=4831
It seems that the bug has been seen on OpenSolaris 2009.06 which is based on build 111.
Following bugzilla bug was filed for that issue:

9382 fdisk problems during install
http://defect.opensolaris.org/bz/show_bug.cgi?id=9382

From Jürgen Keil:
...
The fix for 6711786 has added a new function entry_from_old_table(),
that is supposed to detect unchanged fdisk entries, that need no
validation.

But the entry_from_old_table() is looking at fdisk entries 1..3 only,
fdisk entry 4 is ignored?  Off-by-one error?


diff --git a/usr/src/cmd/fdisk/fdisk.c b/usr/src/cmd/fdisk/fdisk.c
--- a/usr/src/cmd/fdisk/fdisk.c
+++ b/usr/src/cmd/fdisk/fdisk.c
@@ -1725,7 +1725,7 @@ entry_from_old_table(

        if (id == SUNIXOS || id == SUNIXOS2)
                return (0);
-       for (i = 0; i < FD_NUMPART - 1; i++) {
+       for (i = 0; i < FD_NUMPART; i++) {
                if (Old_Table[i].systid == id &&
                    Old_Table[i].bootid == act &&
                    Old_Table[i].beghead == bhead &&
...

Based on this information, reopening this CR for evaluation.