Bug 81220 - upgraded install fails on startup with missing init
Summary: upgraded install fails on startup with missing init
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: mkinitrd
Version: phoebe
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Erik Troan
QA Contact: David Lawrence
Depends On:
Blocks: 79578
TreeView+ depends on / blocked
Reported: 2003-01-06 21:04 UTC by Benjamin Reed
Modified: 2007-04-18 16:49 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-01-26 16:17:42 UTC

Attachments (Terms of Use)

Description Benjamin Reed 2003-01-06 21:04:41 UTC
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 22:51:12 UTC
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 22:23:49 UTC
are you using lilo or grub?

Comment 3 Benjamin Reed 2003-01-14 22:27:08 UTC
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 16:17:42 UTC
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.