Bug 75365
Summary: | LTC1368 - Installer fails to format / on automatic partition selection | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux Beta | Reporter: | Keith Cooper <klc> |
Component: | kernel | Assignee: | Guy Streeter <streeter> |
Status: | CLOSED DEFERRED | QA Contact: | Brock Organ <borgan> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | RC1 | CC: | 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
------- 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 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. 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. ------- 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. ------- 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 ------- 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 ------- 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.... ------- 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). ------- 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.... ------- 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." ------- 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). ------- 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? 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. ------- 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"? # 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 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. Any partition smaller than 487MB fails. It doesn't appear to be a problem on 4GB virtual disks. urk. user error. It fails the same way with a 4GB disk as it does with a 2GB disk. ------- 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. *** Bug 77536 has been marked as a duplicate of this bug. *** ------- 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. ------- Additional Comment #26 From Mike Ranweiler(mranweil.com) 2002-11-15 17:30 ------- This has been documented. Closing IBMs bug entry. |