Bug 179499 - initrd panics the kernel when using "init 1" on the grub command line
initrd panics the kernel when using "init 1" on the grub command line
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2006-01-31 16:09 EST by Don Zickus
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-03 18:10:56 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 Don Zickus 2006-01-31 16:09:12 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:

This line fails:
title Fedora Core (2.6.15-1.1871_FC5_dz)
        root (hd0,1)
        kernel /vmlinuz-2.6.15-1.1871_FC5_dz ro root=LABEL=/ init 1 console=ttys console=ttyS0,115200 crashkernel=64M@16M

It works if I take out "init 1"

Red Hat nash version 5.0.17 starting
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Setting up hotplug.
Creating block device nodes.
Loading scsi_mod.ko module
SCSI subsystem initialized
Loading sd_mod.ko module
Loading libata.ko module
Loading ata_piix.ko module
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 177
ata1: SATA max UDMA/133 cmd 0xFE00 ctl 0xFE12 bmdma 0xFEA0 irq 177
ata2: SATA max UDMA/133 cmd 0xFE20 ctl 0xFE32 bmdma 0xFEA8 irq 177
ata1: dev 0 ATA-7, max UDMA/133, 156250000 sectors: LBA48
ata1: dev 0 configured for UDMA/133
scsi0 : ata_piix
ata2: SATA port has no device.
scsi1 : ata_piix
  Vendor: ATA       Model: Maxtor 6L080M0    Rev: BANC
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 156250000 512-byte hdwr sectors (80000 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write back w/ FUA
SCSI device sda: 156250000 512-byte hdwr sectors (80000 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write back w/ FUA
 sda: sda1 sda2 sda3 sda4 < sda5 >
sd 0:0:0:0: Attached scsi disk sda
Loading jbd.ko module
Loading ext3.ko module
Trying to resume from LABEL=SWAP-sda5
label SWAP-sda5 EXT3-fs: INFO: recovery required on readonly filesystem.
not found
UnablEXT3-fs: write access will be enabled during recovery.
e to access resume device (LABEL=SWAP-sda5)
Creating root device.
Mounting root filesystem.
input: ImPS/2 Generic Wheel Mouse as /class/input/input1
kjournald starting.  Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
Setting up other filesystems.
Setting up new root fs
no fstab.sys, mounting internal defaults
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
WARNING: can't access
exec of init () failed!!!: No such file or directory
Kernel panic - not syncing: Attempted to kill init!

Call Trace: <ffffffff81027a82>{panic+134} <ffffffff81225356>{_spin_unlock_irq+9}
       <ffffffff81224d1b>{__down_read+52} <ffffffff8105b8a2>{remove_vma+93}
       <ffffffff81225399>{_spin_lock_irqsave+9} <ffffffff810ee3c2>{__up_read+19}
       <ffffffff8102abd1>{do_exit+140} <ffffffff8102b440>{sys_exit_group+0}

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

How reproducible:

Steps to Reproduce:
1. add "init 1" to the grub line
2. boot
3. frown

Actual Results:  
it crashes as shown above

Expected Results:  
to boot fine

Additional info:

This bug is important because when using the kexec/kdump tools upon a kernel crash a second mini-kernel is booted.  The mini-kernel needs to minimal boot (thus the init 1) to collect info as we don't really know why the original kernel crashed.
Comment 1 Peter Jones 2006-02-03 18:10:56 EST
This is use error -- use "1" not "init 1", (and it probably needs to be at the
very end of the command line.)

But we've discussed what we're doing here and I think you'll be loading a
different initrd for that kernel, so I don't think that's going to matter anyway.

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