Red Hat Bugzilla – Bug 147284
Exited and left only some directories and files
Last modified: 2007-11-30 17:10:59 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
When attempting an installation on Feb 05, 2005, the following
problems were encountered.
could not see lvm installs in text installation, could see the
installation using the graphical installer.
Inode creation during filesystem formatting seemed very slow and
almost stalled. The process was slow for all partitions, but /dev/sda2
that was designated as the home partition was the longest in lagging.
All that was left after the installation was a very small directory
structure. The directory structure and files created were smalle
enough to gzip. I will submit the whole filesystem stub since the
residue creation was so small in size. There was a lost-found
directory within boot, but no grub subdirectory or kernels.
The zip file shows the resulting system.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. pick FTP site to install rawhide from
2. attempt installation on several computers.
3. Experience long delays during formatting of filesystem and then
installer failure during the installation.
Actual Results: A stub filesystem structure that is small enough to
gzip and email.
Expected Results: Installation of a complete filesystem and no
failures with the GUI or during program installation. A working system
with no bugs
The installation was tried from the same mirror and on two different
computer types. Similar lagging of filesystem creation was exhibited
on both attempts. EXT3 filesystems and swap were the filesystem types
Created attachment 110698 [details]
complete directory structure from faled installation
This was so small and included fstab, modprobe.conf and other files in /etc and
around the systen. This is why the filesystem was zipped for the information.
What were the symptoms of the failure? Traceback about not being able
to mount some filesystems? If so, should be fixed in CVS (and current
rawhide), but current trees are almost certainly broken in new and
different ways ;)
When I tried to fresh install, I was able to make it through selecting
packages and setting up the desired partitions for the new
installation. sda1 was /boot and was to be 101 mb, sda2 was set to
/home and was designated at 20 gig, swap was designated for sda3 at 1
gb, sda4 was extended and contained sda5 which was / at 17 mb+. The
attachment with mtab, fstab probably already reveal that inforation.
When trying to do the installation the first time, sda2 hung for quite
a while trying to create the 54th inode. After it was created, though
with errors, the other partitions were created and formatted. The
creations of the other partitions seemed to be a slow process also.
After this failure, I decided to try the installation again, I decided
to bypass the usage of sda2 as home and used the same scheme as
mentioned above. (sda2 not used at all).
Since the partitions were formatted already, I skipped reformatting
the partitions again. When the installation ceased, I tried to recover
the information from screen 2 shell. Whatever I tried to copy turned
out to be 16 mb of binary data. I did not get the information that was
displayed on in the terminal.
Post-failure, I booted up one of my working installations and expected
to be able to retrieve information in the /root directory from
anaconda. There was only what is in the zip above.
Checking the partitions that were created from the installer, sda2 was
indeed corrupted fsck stated that the reported size was larger than
the available size. the other partitions seemed to fsck alright.
(didn't check swap).
After mkfs -j /dev/sda2 was performed using a working installation on
the same computer, the disk formatted and there was no long delays
during formatting. I copied some files to the reformatted sda2
partition as well as the sda1 and sda5 partitions and they seemed to
Sorry I could not capture the logs or messages from this installation
I expect to encounter broken in different ways. :-)
correction, sda5 was designated as 17 gb, not mb for /
Also, i noted that using the fileroller in the GUI did not show what
is in the gz file in its entirety. The gz was created using mc
(midnight commaander) utilities available from the F2 menu. When using
mc to view the gz, it mirrors what was shown on the actual disk. (sda5)
*** Bug 151877 has been marked as a duplicate of this bug. ***
From Rawhide through FC4T1 the installer seemed to want to bail out when
attempting to complete a fresh install. I had 256MB/233 MHz of memory and the
installer would bail out. I replaced the module with a 512MB/333 MHZ module and
I did not get the same dropout from anaconda.
A symptom in the shell would be that all processes seemed to be waiting and
erratically, running ls would occasionally give segfaults. The installer would
allow you to select packages, then would bailout on the second or third package
that was being installed. Text mode would also exhibit the same symptom of
getting to the second or third package before the program bailed out.
When the rawhide version bailed out, it exhibited the above listed symptoms
described. The FC4T1 just seemed to exit and did not lockup the system. An
install image was also created in /home of around 60 MB (rhinstall-stage2.img)
The remaining filesystem and logs is probably around 9MB with all the remaining
directories installed before failure.
I still have the zipped filestructure handy (60MB)and the 256MB module which
exhibited the error reported in bug 151877 and this earlier bug.
This failure seems to only effect new installs. Upgrades seemed to be alright.
With the kernel debugging turned off, this should be better. Can you try again
I assume you mean to try this with only 256 MB installed and attempting a fresh
install. I will give test3 a try to see how things proceed.
The installation did not exit while installing fresh with the FC4T3 installation
discs. The install tried was an everything install and nothing bombed out.