Bug 75365

Summary: LTC1368 - Installer fails to format / on automatic partition selection
Product: [Retired] Red Hat Linux Beta Reporter: Keith Cooper <klc>
Component: kernelAssignee: Guy Streeter <streeter>
Status: CLOSED DEFERRED QA Contact: Brock Organ <borgan>
Severity: low Docs Contact:
Priority: low    
Version: RC1CC: nobody
Target Milestone: ---   
Target Release: ---   
Hardware: powerpc   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-11-16 18:26:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Keith Cooper 2002-10-07 18:19:38 UTC
Description of Problem:
 Installer fails to format / on automatic partition selection

Version-Release number of selected component (if applicable):
* 7.1-iSeries product
* tree: iSeries-0917

Hardware Environment:

Four (4) virtual disks are allocated to the partition and previously configured 
as follows:

vda1            258M      Linux Native
vda2             15M      Prep Boot
vda5            894M      Linux Native
vda6            878M      Linux Native
vdd1           1788M      Linux swap
vdd2            258M      Linux Native


How Reproducible:


Steps to Reproduce:
1.  Start an NFS based install
2.  Select 'Continue' when prompted for 'Automatic Partitioning'
3.

Actual Results:

After package selection, and information diagnostic concerning creation of 
install log, the following error is displayed.

An error occured trying to format /.  This problem 
is serious, and the installation cannot continue.

Press Enter to reboot your system.

Expected Results:

Installer should successfully remove existing partitions and create partitions 
needed for redhat installatoin.

Additional Information:

The four network storage areas linked to the partition are:

DATA       200M        2       *DYN     *UPDATE
DATA2      200M        3       *DYN     *SHRUPD
ERWIN     2048M        4       *DYN     *SHRUPD  (*)
LSAM1     2048         1       *OPEN    *UPDATE

* The network storage area ERWIN is dynamically linked to a second partition;
  however, that partition is varied off during the test.

------- Additional Comments From earleye.com 2002-10-07 13:20 -------

Interestingly enough, if I unlink the fourth virtual disk (vddd, the disk that 
was dynamically linked to two partitions) I no longer get the option to 
automatically partition the disks.  Please explain what the installer looks for 
when determinig if automatic partitioning is a valid option.



------- Additional Comments From earleye.com 2002-10-07 13:38 -------

Managed to recreate this problem on a second partition.  This partition had two 
virtual disks linked as follows:

ERWIN   2048   2  *DYN  *OPEN  *SHRUPD
LSAM2   2048   1  *DYN  *OPEN  *UPDATE

NOTE that neither virtual disk was linked to any other partition at the time 
that the install was attempted. 

Thinking that it might have something to do with the *SHRUPD state of the 
virtual disk, I trked to link a single virtual disk in with *SHRUPD... This 
worked as expected.

Comment 1 Keith Cooper 2002-10-09 14:03:34 UTC
------- Additional Comments From Jay S. Bryant(jsbryant.com) 2002-10-08 17:45 -------

I saw this same problem on a V5R1 system.  I had two virtual disks linked in 
that had been used for testing previously.

I am going to try doing a fresh install with a different distro on those NWSSTGs 
and then try installing Red Hat.  That should recreate the situation where I saw 
this failure and see if the failure recreates.

The other possibility is that the partition tables were corrupted by my previous 
testing. Still, I wouldn't expect that to cause a failure with Red Hat's 
installer.

------- Additional Comments From Jay S. Bryant(jsbryant.com) 2002-10-08 17:56 -------

Ok, I was able to at least get booted to a point where I could see what 
partitions were on the two existing NWSSTGs mentioned in the bug entry above.  
They were configured as follows:

NWSSTG 1: 3.9 Gb total.
   Part 1 - 258.8 Mb / Linux native
   Part 2 - 15.7 Mb / PPC PReP Boot
   Part 3 - 3.6 Gb / Extended
   Part 5 - 1.7 Gb / Linux native
   Part 6 - 258.8 Mb / Linux native
   Part 7 - 196.0 Mb / Linux swap

NWSSTG 2: 1.9 Gb total.
   Part 1 - 1.y Gb Linux native

Comment 2 Guy Streeter 2002-10-09 21:44:39 UTC
an answer to one of the tangential questions: The installer will not offer to
autmatically configure partition is if doesn't find as much space as it thinks
it needs. 'Enough' is a moving target, and I'm not sure what the current value is.

Comment 3 Guy Streeter 2002-10-09 22:22:00 UTC
Here's how you can help us debug this problem:
Reproduce the error, then vary off the lpar and move the virtual disk to another
lpar that has our refresh distro succesfully installed. From that lpar, try to
run the mke2fs command on the partition that failed during the install. Let us
know the results.


Comment 4 Keith Cooper 2002-10-28 18:09:53 UTC
------- Additional Comment #8 From Jay S. Bryant(jsbryant.com) 2002-10-25 18:47 ------- 

Keith, I was able to recreate the failure on the partition I had seen it on 
before.  The problem is that this information isn't very interesting as we 
still don't know which disk partition (or other variable ) is causing the 
failure.

I think, based on failures that I have seen with other distros that the failure 
may actually be caused by a messed up swap partition on one of the NWSSTGs or 
by a damaged filesystem on one of the NWSSTGs.

I have determined that it isn't a case of the filesystem not being able to be 
read on an existing partition.  I tried installing over a partition with the 
reiser format on it and this didn't cause troubles for Red Hat.

Long story short:  I haven't been able to narrow down this failure to one 
variable.  I am limited on bandwidth and would appreciate it if Erwin could 
make some more time to recreate this failure.



Comment 5 Keith Cooper 2002-10-29 19:07:36 UTC
------- Additional Comment #9 From earleye.com(earleye.com) 2002-10-29 14:01 ------- 

This problem is likely due to installing over virtual storage that has been 
previously formatted with filesystems not supportd by the distribution (i.e., 
reiserfs)....  Testing will attempt the following two scenarios to narrow down 
the problem:

1.  Install a Linux distribution using reiserfs and then attempt to install 
RedHat 7.1

2.  Install a Linux distriubution using ext2 and then attempt to install RedHat 
7.1

Results will be posted in this bugzilla entry



Comment 6 Keith Cooper 2002-10-31 19:22:07 UTC
------- Additional Comment #10 From Pamela Morris(pbowen.com) 2002-10-31 13:33 ------- 

Results of the above test:
Installing Red Hat over SuSE with Reiser or ext2 produced the same result: no 
choice of automatic installation was given. I went into Disk Druid, and the 
partitions were displayed OK there. Selected mount point and installation was 
successful from there.
-PLM

Comment 7 Keith Cooper 2002-11-01 18:01:40 UTC
------- Additional Comment #11 From Mike Ranweiler(mranweil.com) 2002-11-01 12:31 ------- 

I didn't get the option to do an Automatic Partition on an 8 gig nwsstg, so I
couldn't check this out....

Comment 8 Keith Cooper 2002-11-01 20:07:02 UTC
------- Additional Comment #12 From Mike Ranweiler(mranweil.com) 2002-11-01 15:04 ------- 

Ok, I recreated this problem on the 10/31 drop with two nwsstg's:  a 25 gig and
a 8 gig.  Same error:

An error occured trying to format /.  This problem 
is serious, and the installation cannot continue.

From a different bug (77065), it sounds like a server class install just needs
two nwsstgs to get automatic partitioning...  assume at least a few gigs of
space.  Will try mkfs like Guy Streeter asked, and print out the partition table
(but have to create a new nwsstg and install on that first).

Comment 9 Keith Cooper 2002-11-01 21:07:56 UTC
------- Additional Comment #13 From Mike Ranweiler(mranweil.com) 2002-11-01 16:02 ------- 

Ok, I recreated this problem on the 10/31 drop with two nwsstg's:  a 25 gig and
a 8 gig.  Same error:

An error occured trying to format /.  This problem 
is serious, and the installation cannot continue.

From a different bug (77065), it sounds like a server class install just needs
two nwsstgs to get automatic partitioning...  assume at least a few gigs of
space.  Linked them as disk 2 and disk3 booting a different nwsstg and took a look:

[root@localhost /root]# fdisk -l
 
Disk /dev/iseries/vda: 255 heads, 63 sectors, 1020 cylinders
Units = cylinders of 16065 * 512 bytes
 
           Device Boot    Start       End    Blocks   Id  System
/dev/iseries/vda1   *         1         3     24066   41  PPC PReP Boot
/dev/iseries/vda2             4       100    779152+  82  Linux swap
/dev/iseries/vda3           101      1020   7389900   83  Linux
 
Disk /dev/iseries/vdb: 255 heads, 63 sectors, 3187 cylinders
Units = cylinders of 16065 * 512 bytes
 
           Device Boot    Start       End    Blocks   Id  System
/dev/iseries/vdb1             1        33    265041   83  Linux
/dev/iseries/vdb2   *        34        35     16065   41  PPC PReP Boot
/dev/iseries/vdb3            36      3187  25318440    5  Extended
/dev/iseries/vdb5            36       290   2048256   82  Linux swap
/dev/iseries/vdb6           291      1091   6434001   83  Linux
/dev/iseries/vdb7          1092      1892   6434001   83  Linux
 
Disk /dev/iseries/vdc: 255 heads, 63 sectors, 1020 cylinders
Units = cylinders of 16065 * 512 bytes
 
           Device Boot    Start       End    Blocks   Id  System
/dev/iseries/vdc1   *         1        33    265041   83  Linux
[root@localhost /root]#  

None of the partitions on vdb or vdc where mountable (type ext2).  I was able to
successfully create ext2 filesystems on vdb1, vdb6, vdb7, and vdc1, and then all
of them were mountable.

As an aside, I don't think vdc1 needs to be bootable....

Comment 10 Keith Cooper 2002-11-01 21:37:23 UTC
------- Additional Comment #14 From earleye.com(earleye.com) 2002-11-01 16:28 ------- 

We have been unable to determine an exact configuration/steps to re-create this 
problem....  Since RedHat 7.1 does not support an upgrade path, it may be 
acceptable to add a comment to the readme to reflect the following:

"In certain situations, it is possible that the automatic partitioning option 
in the installer will report that the installation was unable to format the 
root (/) partition.  In this case, re-start the installation and use the expert 
partitioning tools to remove all exisitng partiitons and then create new 
partitions for the RedHat installation."

Comment 11 Keith Cooper 2002-11-01 21:38:18 UTC
------- Additional Comment #15 From Mike Ranweiler(mranweil.com) 2002-11-01 16:37 ------- 

Umm... I think you missed my last update.  ;)  Recreation scenario involves
having two nwsstg's, probably at least 4-5 gig between them (I went for the
overkill).

Comment 12 Keith Cooper 2002-11-01 21:54:24 UTC
------- Additional Comment #16 From Mike Ranweiler(mranweil.com) 2002-11-01 16:43 ------- 

Alternatively to Erwin's readme update, would it be easy just to disable auto
partitioning for a server install for this release?

Comment 13 Guy Streeter 2002-11-05 20:02:48 UTC
I have reproduced this failure. This is the output of the failed command:

# /usr/sbin/mke2fs /tmp/vda1 -L /
mke2fs 1.26 (3-Feb-2002)
Filesystem label=/
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
66264 inodes, 265041 blocks
13252 blocks (5.00%) reserved for the super user
First data block=1
33 block groups
8192 blocks per group, 8192 fragments per group
2008 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729, 204801, 221185

Writing inode tables:  0/33
Could not write 8 blocks in inode table starting at 6: Attempt to write block
from filesystem resulted in short write

I don't yet have any idea what this means. If it means something to you, please
let me know.

Comment 14 Keith Cooper 2002-11-05 20:34:45 UTC
------- Additional Comment #18 From Jay S. Bryant(jsbryant.com) 2002-11-05 15:23 ------- 

Guy Streeter: Could you provide the results of doing an "fdisk -l"?

Comment 15 Guy Streeter 2002-11-05 20:46:02 UTC
# fdisk -l /tmp/vda

Disk /tmp/vda: 255 heads, 63 sectors, 261 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/tmp/vda1             1        33    265041   83  Linux
/tmp/vda2   *        34        35     16065   41  PPC PReP Boot
/tmp/vda3            36       261   1815345    5  Extended
/tmp/vda5            36        68    265041   83  Linux
/tmp/vda6            69       130    497983+  82  Linux swap

# cat /proc/partitions
major minor  #blocks  name     rio rmerge rsect ruse wio wmerge wsect wuse
running use aveq

 112     0    2096482 iseries/vda 30 0 240 50 12 54 528 80 0 80 130
 112     1     265041 iseries/vda1 3 0 24 10 9 54 504 50 0 30 60
 112     2      16065 iseries/vda2 1 0 8 10 0 0 0 0 0 10 10
 112     3          1 iseries/vda3 4 0 32 0 0 0 0 0 0 0 0
 112     5     265041 iseries/vda5 0 0 0 0 0 0 0 0 0 0 0
 112     6     497983 iseries/vda6 4 0 32 0 0 0 0 0 0 0 0
 112     8    4192965 iseries/vdb 5 0 40 0 1 0 8 0 0 0 0
 112     9    1598436 iseries/vdb1 0 0 0 0 0 0 0 0 0 0 0
 112    10    1598467 iseries/vdb2 0 0 0 0 0 0 0 0 0 0 0

Comment 16 Guy Streeter 2002-11-06 19:28:21 UTC
I can reproduce this problem outside the installer. If I add a new 2GB virtual
disk to a successful install, and use fdisk to create just one primary 256MB
partition, I get the error from mke2fs.


Comment 17 Guy Streeter 2002-11-06 19:50:58 UTC
Any partition smaller than 487MB fails.

Comment 18 Guy Streeter 2002-11-06 23:13:14 UTC
It doesn't appear to be a problem on 4GB virtual disks.

Comment 19 Guy Streeter 2002-11-06 23:21:19 UTC
urk. user error. It fails the same way with a 4GB disk as it does with a 2GB disk.

Comment 20 Keith Cooper 2002-11-07 15:26:45 UTC
------- Additional Comment #23 From Colin DeVilbiss(devilbis.com) 2002-11-07 10:25 ------- 

Recreated here.

The relevant part of an strace with a partition of size 384M:
lseek(4, 403005440, SEEK_SET)           = 403005440
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = -1 ENOSPC (No space left on device)
write(1, "\nCould not write 8 blocks in ino"..., 119
Could not write 8 blocks in inode table starting at 6: Attempt to write block from filesystem resulted in short write
) = 119

and fdisk -l:
Disk /dev/iseries/vdb: 255 heads, 63 sectors, 261 cylinders
Units = cylinders of 16065 * 512 bytes

           Device Boot    Start       End    Blocks   Id  System
/dev/iseries/vdb1             1        49    393561   83  Linux

and `expr 393561 '*' 1024 - 403005440`:
1024

That is, they are trying to write exactly the last 1024 bytes of the partition, and somebody is telling them ``you're past the end of the device.''  However, they aren't 
getting all the way into our code, since we never return ENOSPC; more code inspection is necessary.

Apparently, a 512MB partition doesn't need that 1024-byte block written at its end.  Writing a testcase to verify that writing the last 1024 bytes of a partition always 
fails.



Comment 21 David Lehman 2002-11-11 17:58:27 UTC
*** Bug 77536 has been marked as a duplicate of this bug. ***

Comment 22 Keith Cooper 2002-11-12 17:22:37 UTC
------- Additional Comment #25 From Pamela Morris(pbowen.com) 2002-11-12 11:53 ------- 

This will be added to the README in GM2 as a documented workaround.

Comment 23 Keith Cooper 2002-11-16 18:26:25 UTC
------- Additional Comment #26 From Mike Ranweiler(mranweil.com) 2002-11-15 17:30 ------- 

This has been documented.  Closing IBMs bug entry.