What happens if you *do* reboot here; are the partitions you created
seen when you boot back into the installer?

The only partitions that appear after rebooting are the root disk (sdm) and the 
first Adaptec disk (sda).

What happens if you try the updates disk at:

  http://people.redhat.com/notting/updates/updates.img

Write this to an LS-120, boot the installer with 'linux updates', insert
the disk when prompted, and *then* try partitioning.

Does this work any better?

Installation still fails on qa0529 with updates disk.  Error message reported 
is identical.

  "The Kernel is unable to read your new partitioning information, probably 
because you modified extended partitions.  While this is not critical, you 
must reboot your machine before proceeding. Insert the Red Hat Boot Disk 
now, and press OK to reboot your system."

and, as you stated before, the partitions you created are *not* there when
you boot back into the installer?

I tried this with a 39150 in slot 1, and a 29xx in slot 2. The system
didn't boot (hung in the BIOS after the Adaptec SCSI bus scans.)

After rebooting, there is only one partition on sda.  All other disks appear 
blank.

If fdisk (in installer) is used to partition the disks, I noticed that the 
devices disappear in /tmp.  If you back up in the installer and select disk 
druid these partitions are not seen but the devices reappear in /tmp.  If fdisk 
is run manually in VT2 these devices do not disappear.

I also noticed that the EFI GPT partition information looked very strange (in 
VT2 I verified that all disks sdb - sdl reported identical information, sda 
still had the single partition I had created on the previous installation 
attempt):
Disk /tmp/sdh:  255 heads, 63 sectors, 1115 cylinders
Units = cylinders of 16065 * 512 bytes


Device       Boot		Start	End		Blocks		Id
	System
/tmp/sdh1		1	267350		2147483647+	ee	EFI GPT
Partition 1 does not end on a cylinder boundary:
	phys=(1023,255,62) should be (1023,254,63)

** I would not mind having 1.05 TB of space on a single disk **

We've reproduced something similar here.

It *looks* like the number/location of controllers is a red herring.

Can you confirm that at least one of the disks that you're partitioning
has an odd number of sectors?

I gave it a shot.  If this isn't quite right, I apologize in advance.
Bill, can you see if this works for you?


diff -burN --exclude=*~ anaconda-7.1/libfdisk/disk_funcs.c anaconda-7.1-
gpt/libfdisk/disk_funcs.c
--- anaconda-7.1/libfdisk/disk_funcs.c	Wed Apr 25 13:09:58 2001
+++ anaconda-7.1-gpt/libfdisk/disk_funcs.c	Thu May 31 15:48:15 2001
@@ -128,6 +128,7 @@
   __off64_t offset;
   ssize_t readcount = 0, thisreadcount=0;
   ssize_t leftreadcount = count;
+  blk_ioctl_parameter p;

   if (!buffer || !count) return 0;
   if (!IsLBAValid(filedes, lba)) return 0;
@@ -135,8 +136,11 @@
   /* If this is the last block of the disk,
      try using ioctl to read.
      Fall back to normal read if that fails */
-  if ( (lba == LastLBA(filedes)) && (count == 512) ){
-    if( ! ioctl(filedes, BLKGETLASTSECT, buffer) )
+  if ( (lba == LastLBA(filedes)) && (count == 512) ) {
+	  p.block = 0;
+	  p.content_length = count;
+	  p.block_contents = buffer;
+	  if( ! ioctl(filedes, BLKGETLASTSECT, &p) )
                return count;
   }

@@ -184,6 +188,7 @@
   __off64_t offset;
   ssize_t writecount = 0, thiswritecount = 0;
   size_t leftwritecount = count;
+  blk_ioctl_parameter p;


   if (!buffer || !count )
@@ -195,7 +200,10 @@
      try using ioctl to read.
      Fall back to normal read if that fails */
   if ( (lba == LastLBA(filedes)) && (count == 512) ){
-    if( ! ioctl(filedes, BLKSETLASTSECT, buffer) )
+	  p.block = 0;
+	  p.content_length = count;
+	  p.block_contents = buffer;
+	  if( ! ioctl(filedes, BLKSETLASTSECT, &p) )
        return count;
   }

diff -burN --exclude=*~ anaconda-7.1/libfdisk/disk_funcs.h anaconda-7.1-
gpt/libfdisk/disk_funcs.h
--- anaconda-7.1/libfdisk/disk_funcs.h	Tue Apr 24 13:50:28 2001
+++ anaconda-7.1-gpt/libfdisk/disk_funcs.h	Thu May 31 15:46:05 2001
@@ -13,4 +13,11 @@

 off_t GetDeviceBlockSize( int filedes );

+typedef struct {
+	unsigned int block;
+	size_t content_length;
+	char *block_contents;
+} blk_ioctl_parameter;
+
+
 #endif /* _DISK_FUNCS_H */

OK, after using the fixed partitioning code, another error is received

(from other e-mail)

>       It does appear that we are getting a little closer.  The boot disk
> formatted correctly (sdm) this time.  Then the installer failed with "An
> error occurred trying to format /fs1:  This problem is serious, and the
> install cannot continue.  Press Enter to reboot your system.",  /fs1 is sda.
> I took a look on VT5 and found the following error "/usr/sbin/mke2fs: No
> such device or address while trying to determine filesystem size".  There
> was not messages printed out to VT1 this time.

RH has yet to reproduce this failure in-house.

If you use switch to VT2, and run fdisk /dev/sda, see sda1 is type 6 (FAT16), 
not type ee (protective MBR for GPT).  Run parted /dev/sda and see that the GPT 
partitions are there, but since the PMBR has type 6 there (not type EE), the 
kernel now thinks the disk is MBR not GPT...  Using fdisk to switch sda1 from 6 
to ee, write it out, and exit, and see the kernel now gets it right.

Not sure why /dev/sda1 is getting the type set to 6 (and not ee).

This is fixed in anaconda-7.1-15 or later.