Bug 151223 - After installation, /etc/inittab does not exist
After installation, /etc/inittab does not exist
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2005-03-15 22:47 EST by Zlatin Balevsky
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-17 10:11:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Zlatin Balevsky 2005-03-15 22:47:37 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
Gecko/20050302 Firefox/1.0.1 Fedora/1.0.1-1.3.2

Description of problem:
This is a fresh installation of fc4t1.  The bootloader is on the MBR;
there is a working fc3 installation on /dev/hda1.  FC4t1 was installed
on a newly created partition on /dev/hdc3, with reiserfs as filesystem.

Before installation, the sha1 of the iso verified properly. During the
installation everything seemed to go ok.

At the first boot attempt, After starting nash, INIT claimed that it
cannot find /etc/inittab and asked me to enter the runlevel. 
Regardless of which runlevel I'd enter, it'd say "no more processes in

Version-Release number of selected component (if applicable):

How reproducible:
Didn't try

Steps to Reproduce:
 Install fc4t1 on a partition on a different disk than the bootloader,
attempt to boot.

Actual Results:  At the first boot attempt, After starting nash, INIT
claimed that it cannot find /etc/inittab and asked me to enter the
runlevel.  Regardless of which runlevel I'd enter, it'd say "no more
processes in runlevel".

Expected Results:  Normal bootup loading sequence at the default runlevel.

Additional info:

If the kernel parameter root=/dev/hda1 is passed (and /lib/modules/...
is symlinked properly), the old system boots normally even with the
new kernel.  (that's what I'm using to submit this report).

After loading the system this way and inspecting the fc4 partition,
/etc/inittab indeed was missing.
Comment 1 Zlatin Balevsky 2005-03-16 00:40:33 EST
Note:  this installation was made from an i386 DVD that did not pass the
self-check.  However, people on various forums and mailing lists have said that
all isos fail the self-check, so take this report with a grain of salt.  

Once isos that pass the self-check are made available, I'll try to reproduce.
Comment 2 Chris Lumens 2005-03-16 16:15:04 EST
What package selections did you make while installing?  What does your
bootloader config look like?  I'm unable to reproduce this here with a straight
rawhide install.
Comment 3 Bryan Christ 2005-03-16 18:10:11 EST
I have this problem too.  My sha1sum pass on the ISO images but the disc fails 
the Media Check.  Considering Comment #1 I am disregarding the Media Check.

I had an fc3 installation, but I chose to format my /boot partition (ext2) and 
my root partiton (reiserfs) and do a fresh installation.  I chose the 
Workstation selection of packages.  Upon reboot I was greeted with the missing 
inittab.  My experience was the same as the author of this bugzilla.

I am now going to try to install fc3 and upgrade to fc4 and see if that behaves 
Comment 4 Zlatin Balevsky 2005-03-16 23:39:57 EST
based on my experiences with bug 151344 I decided to repeat the installation on
an ext3 partition and everything worked fine.  It seems that reiserfs is the
Comment 5 Chris Lumens 2005-03-17 10:11:33 EST
Reiserfs is completely unsupported.  Please repoen if you see these same
problems installing to an ext3 filesystem.
Comment 6 Bryan Christ 2005-03-17 10:16:44 EST
Upgrading from fc3 to fc4-test1 produced a (somewhat) working installation 
(inittab not missing).  Will retry with ext3 instead.

Note You need to log in before you can comment on or make changes to this bug.