Bug 427527 - Kdump kernel doesn't boot after triggering a crashdump
Summary: Kdump kernel doesn't boot after triggering a crashdump
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd
Version: 8
Hardware: ppc64
OS: All
low
high
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL: ARRAY(0x8bcb30)
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-01-04 13:25 UTC by IBM Bug Proxy
Modified: 2009-01-09 05:42 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-09 05:42:07 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
mkdumprd patch (572 bytes, text/plain)
2008-01-04 13:25 UTC, IBM Bug Proxy
no flags Details


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 41352 0 None None None Never

Description IBM Bug Proxy 2008-01-04 13:25:19 UTC
=Comment: #0=================================================
Mohammed Omar <mohd.omar.com> - 2008-01-02 07:16 EDT
---Problem description:---
Kdump kernel is not working after triggering the crashdump (echo "c" >
/proc/sysrq-trigger ) with Fedora 8 on Power5.It stops booting and dropped to
shell saying that...

Fedora release 8 (Werewolf)
Kernel 2.6.23.1-42.fc8 on an ppc64

p520b.in.ibm.com login: SysRq : Trigger a crashdump
Sending IPI to other cpus...
Partition configured for 2 cpus.
Starting Linux PPC64 #1 SMP Tue Oct 30 13:29:14 EDT 2007
-----------------------------------------------------
ppc64_pft_size                = 0x19
physicalMemorySize            = 0xa000000
ppc64_caches.dcache_line_size = 0x80
ppc64_caches.icache_line_size = 0x80
htab_address                  = 0x0000000000000000
htab_hash_mask                = 0x3ffff
physical_start                = 0x2000000
-----------------------------------------------------
Linux version 2.6.23.1-42.fc8kdump (kojibuilder.phx.redhat.com) (gcc
version 4.1.2 20070925 (Red Hat 4.1.2-33)) #1 SMP Tue Oct 30 13:29:14 EDT 2007
[boot]0012 Setup Arch
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 7168 bytes
Zone PFN ranges:
  DMA             0 ->    40960
  Normal      40960 ->    40960
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->    40960
[boot]0015 Setup Done
Built 1 zonelists in Node order.  Total pages: 40400
Policy zone: DMA
Kernel command line: root=/dev/VolGroup00/LogVol00 ro console=hvc0 rhgb quiet 
irqpoll maxcpus=1 noirqdistrib elfcorehdr=41160K savemaxmem=1840M 
scan-log-dump not implemented on this system
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Loading scsi_mod.ko module
Loading sd_mod.ko module
Loading libata.ko module
Loading pata_pdc2027x.ko module
Loading ipr.ko module
Loading jbd.ko module
Loading mbcache.ko module
Loading ext3.ko module
Loading dm-mod.ko module
Loading dm-mirror.ko module
Loading dm-zero.ko module
Loading dm-snapshot.ko module
Creating Block Devices
Creating block device ram0
Creating block device ram1
Creating block device ram10
Creating block device ram11
Creating block device ram12
Creating block device ram13
Creating block device ram14
Creating block device ram15
Creating block device ram2
Creating block device ram3
Creating block device ram4
Creating block device ram5
Creating block device ram6
Creating block device ram7
Creating block device ram8
Creating block device ram9
Creating block device sda
Creating block device sdb
Making device-mapper control node
Scanning logical volumes
  Reading all physical volumes.  This may take a while...
  Found volume group "rootvg" using metadata type lvm2
  Found volume group "VolGroup00" using metadata type lvm2
Activating logical volumes
  1 logical volume(s) in volume group "rootvg" now active
  2 logical volume(s) in volume group "VolGroup00" now active
File descriptor 10 left open
File descriptor 10 left open
File descriptor 10 left open
File descriptor 10 left open
/sbin/dmsetup.static: not found
Creating root device.
Checking root filesystem.
fsck (busybox 1.8.2, 2007-12-03 05:54:59 EST)
fsck: /etc/fstab: No such file or directory
fsck: fsck.auto: No such file or directory
fsck: wait: no more child process?!?
Mounting root filesystem.
fsck: /etc/fstab: No such file or directory
fsck (busybox 1.8.2, 2007-12-03 05:54:59 EST)
fsck: /etc/fstab: No such file or directory
mount -t /dev/VolGroup00/LogVol00 /sysroot
mount: cannot read /etc/fstab: No such file or directory
unable to mount rootfs. Dropping to shell
# 

......................................here it stopped.

----rpm packages used:----

kernel-kdump:   kernel-kdump-2.6.23.1-42.fc8
kexec-tools:    kexec-tools-1.102pre-2.fc8 +                                   
          (kexec)kexec-tools-testing-20071017-rc.tar.gz 
device-mapper:  device-mapper-1.02.22-1.fc8
busybox:        busybox-1.8.2-1.fc9 (busybox-1.6.1-2.fc8.ppc64.rpm has some issue)

-----uname -a----------
Linux p520b.in.ibm.com 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:05:49 EDT 2007 ppc64
ppc64 ppc64 GNU/Linux


------Hardware Environment--------
    Machine type : p520
    Cpu type : Power5
    
---Is this reproducible?----
YES
---- Describe the steps:----

Step1: Install above mentioned rpms on F8 on ppc64 machine.
Step2: chkconfig kdump on
Step3: depmod -a 2.6.23.1-42.fc8kdump
Step4: mkdumprd /boot/initrd-2.6.23.1-42.fc8kdump.img 2.6.23.1-42.fc8kdump
Step5: service kdump start
Step6: echo "c" > /proc/sysrq-trigger

Will generate above pasted log messages on hmc console....
And Step 3 & 4 needs to perform as some "modules version mismatch" error was coming.

----Additional information:-----

Used latest kexec binary as kexec binary in F8 rpm(kexec-tools-1.102pre-2.fc8)
has some issues.
For clarification check ...
https://bugzilla.linux.ibm.com/show_bug.cgi?id=41345 ( RH427201 )
https://bugzilla.linux.ibm.com/show_bug.cgi?id=41346 ( buffer overflow detected while starting kdump
service)

Busybox of F8 (busybox-1.6.1-2.fc8.ppc64.rpm) is not able to create nodes while
kdump kernel boots up. So used latest package(busybox-1.8.2-1.fc9)


=Comment: #2=================================================
Mohammed Omar <mohd.omar.com> - 2008-01-03 06:13 EDT
Hi,

I verified kdump against F7 on ppc64. It gives same output.I used the following
packages:

busybox-1.8.2-1.fc9.ppc.rpm 
kernel-kdump-2.6.21-1.3194.fc7.ppc64.rpm
kexec-tools-1.101-69.fc7.ppc64.rpm

----uname -a--------
Linux p55lp5.in.ibm.com 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:13:52 EDT 2007
ppc64 ppc64 ppc64 GNU/Linux



--thanks
   Omar

=Comment: #3=================================================
Chandru Siddalingappa <chandru.s.com> - 2008-01-03 06:34 EDT
I edited the init script in initrd-2.6.23.1-42.fc8kdump.img  file and added a line 
'mount -o defaults --ro -t ext3 /dev/VolGroup00/LogVol00 /sysroot'  just before
dropping in to shell.  The system now boots in to kdump kernel and saves a
vmcore on the local filesystem. 


=Comment: #4=================================================
Chandru Siddalingappa <chandru.s.com> - 2008-01-04 06:14 EDT

mkdumprd patch

The expression in mkdumprd 

FSTYPE=\`fsck -N \$ROOTDEV | awk '/.*sbin.*/ {print \$1}' 

assigns a null value to FSTYPE when run with the fsck available in the
initrd-kdump.img file.
The /sbin/fsck gives the following output 

# /sbin/fsck -N /dev/VolGroup00/LogVol00
fsck 1.40.2 (12-Jul-2007)
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 /dev/VolGroup00/LogVol00 


The fsck from initrd image file ...
# /tmp/kdumpinit/bin/fsck -N /dev/VolGroup00/LogVol00
fsck (busybox 1.8.2, 2007-12-03 05:54:59 EST)
[fsck.ext3 (1) -- /] fsck.ext3 /dev/VolGroup00/LogVol00

Attached is a small change that helps overcome this problem.

Comment 1 IBM Bug Proxy 2008-01-04 13:25:22 UTC
Created attachment 290845 [details]
mkdumprd patch

Comment 2 IBM Bug Proxy 2008-02-21 10:56:43 UTC
------- Comment From mohd.omar.com 2008-02-21 05:49 EDT-------
This issue persists in F9Alpha.
Kernel: 2.6.24-2.fc9
Kexec-tools: kexec-tools-1.102pre-3.fc9.ppc64.rpm

After applying the patch from
https://bugzilla.linux.ibm.com/show_bug.cgi?id=41346#c22, It is reproducible.

--Regards
Omar

Comment 3 IBM Bug Proxy 2008-03-04 08:48:43 UTC
------- Comment From deepakraj.com 2008-03-04 03:41 EDT-------
Omar, could you recheck on latest release

Comment 4 IBM Bug Proxy 2008-03-06 06:00:53 UTC
------- Comment From mohd.omar.com 2008-03-06 00:59 EDT-------
Deepak,
F9 Beta (next release) suppose to land on 20th March 2008.

Comment 5 IBM Bug Proxy 2008-05-29 11:16:34 UTC
------- Comment From IndhuDurai.com 2008-05-29 07:11 EDT-------
Hi,

Will check this bug, once bug#45199 gets closed.

Thanks,
Indhu D

Comment 6 Bug Zapper 2008-11-26 09:17:31 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 7 Bug Zapper 2009-01-09 05:42:07 UTC
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


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