Bug 179499
| Summary: | initrd panics the kernel when using "init 1" on the grub command line | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Don Zickus <dzickus> |
| Component: | mkinitrd | Assignee: | Peter Jones <pjones> |
| Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-02-03 23:10:56 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. |
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} <ffffffff8100a58e>{system_call+126} Version-Release number of selected component (if applicable): mkinitrd-5.0.17-1 How reproducible: Always 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.