Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 81220 - upgraded install fails on startup with missing init
upgraded install fails on startup with missing init
Product: Red Hat Public Beta
Classification: Retired
Component: mkinitrd (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Erik Troan
David Lawrence
Depends On:
Blocks: 79578
  Show dependency treegraph
Reported: 2003-01-06 16:04 EST by Benjamin Reed
Modified: 2007-04-18 12:49 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-26 11:17:42 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 Benjamin Reed 2003-01-06 16:04:41 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1)
Gecko/20030105 Chimera/0.6+

Description of problem:
I've upgraded a RedHat 8.0 installation to phoebe, and it appears that init has
somehow gotten messed up.  If I boot from the supplied kernel or from the boot
floppy created during install, I get a kernel panic about a missing init.

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

How reproducible:

Steps to Reproduce:
1. Install RedHat 8.0 (using software raid stripe root, but /boot on a separate
non-raid partition)
2. Upgrade to phoebe
3. Boot

Actual Results:  Kernel panic.  It appears mkrootdev is failing, but it is
unclear why.

Expected Results:  Startup.  =)

Additional info:

The last bits of the kernel startup look like this:

  Creating block devices
  Creating root device
  mkrootdev: mknod failed: 17
  Mounting root filesystem
  mount: error 19 mounting ext3
  pivotroot: pivot_root(/sysroot,/sysroot/initrd) failed: 2
  umount /initrd/proc failed: 2
  Freeing unused kernel memory: 128k freed
  Kernel panic: No init found.  Try passing init=option to kernel.

I've also tried booting from the rescue disk, and then chrooting into the
system.  If I then run "init 5", I get a different, but seemingly related, bug:

  # chroot /mnt/sysimage
  sh-2.05b# su -
  su(pam_unix)[105]: session opened for user root by (uid=0)
  [root@localhost root]# init 5
  init: timeout opening/writing control channel /dev/initctl
  [root@localhost root]#

I'm not convinced it's necessarily SysVinit, but something is definitely wrong
here somewhere early in the init process.
Comment 1 Benjamin Reed 2003-01-06 17:51:12 EST
I'm sorry, I missed this the first time around.  Further up in the startup, I get:

  md: bind<hda3,1>
  md: bind<hdc3,2>
  md: running: <hdc3><hda3>
  md: hdc3's event counter: 00000048
  md: hda3's event counter: 00000048
  md: personality 2 is not loaded!
  md: do_md_run() returned -22
  md: md0 stopped.
  md: unbind<hdc3,1>
  md: export_rdev(hdc3)
  md: unbind<hda3,0>
  md: export_rdev(hda3)
  md: .. autorun DONE.

...which makes it look like it's not loading the raid stuff for some reason. 
Does that help?
Comment 2 Erik Troan 2003-01-14 17:23:49 EST
are you using lilo or grub?
Comment 3 Benjamin Reed 2003-01-14 17:27:08 EST
I'm using the default, I believe, which I guess would be grub.

But I have a hard time believing grub is the problem if I boot the rescue disk
and chroot to the partition and still can't init...

I unfortunately don't have the test system anymore, I needed to format it for
other testing related to work, so I can't give you more specifics, but
bootloader appeared to not be the issue.  I could bypass that by chrooting from
a rescue.
Comment 4 Erik Troan 2003-01-26 11:17:42 EST
there is a known problem in mkinitrd w/ systems using raid that has been fixed
in rawhide -- I'm going to guess that was it since you can't test the fix

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