Bug 238768

can you please post the contents of your /etc/sysconfig/kdump file, and do you
by any chance know the last kernel that kexec-tools-1.101-51 did happen to work
with?

no problem.  all the vars in /etc/sysconfig/kdump were empty:

KDUMP_KERNELVER=""
KDUMP_COMMANDLINE=""
KEXEC_ARGS=""

the kdump kernels available to me to test with were:

kernel-kdump-2.6.20-1.2948.fc6
kernel-kdump-2.6.20-1.2944.fc6
kernel-kdump-2.6.20-1.2933.fc6
kernel-kdump-2.6.18-1.2798.fc6

I tested each out by installing them, editing the $KDUMP_KERNELVER, and then
doing a "server kdump start".

all the 2.6.20 kernels fail with "Cannot determine file type..."
the 2.6.18 fails with "Invalid memory segment 0x1000000 - 0x1262fff"

Looks like our reads of section headers from the new kdump headers produces
invalid values.  Either the kernel isn't formatting the section headers
properly, or we are reading them incorrectly (my guess is the later).  

update to previous: Turns out it looks like its the kernel thats borked.  ourput
of readelf -S /boot/vmlinux-2.6.20-1.2933.fc6kdump indicates that the section
headers are managled in the kernel image pretty badly.  Looking into why

Ok, it appears that the relocatable patch set has reached the fc6 kernels, which
means the the kdump kernel for i686 is not completely an elf file (it has some
elf headers, which detect it as elf, but fail later tests), we should be able to
just use the vmlinuz file on this system now, but to do that I'll need to port
over the  --args-linux patch and the bzImage patch.  I'll get to those shortly.

Actually there is an easier way to do this.  Can you please update your system
to kdump-1.101-69.fc7? That should set you up to use the relocatable vmlinuz
image and include all the appropriate patches.  If that works for you I can just
do a wholesale update of the latest kexec tools into fc6.  Thanks!

hmmm, no go:  /var/log/messages:

kdump: kexec: failed to load kdump kernel
kdump: failed to start up

I dug for the kexec command line and ran it by hand and straced it... i'll
attach the log (i also appended the command line to the end of the log)

Created attachment 154149 [details]
strace of kexec command

Can you tell me a bit more about this system?  Is it an x86 or an x86_64 system?
 How much memory is there in this system?

this is an intel xeon dual processor blade (8843-E9U) in an IBM Bladecenter H
(8852-4XU).  It's got ~6 GB of memory (/proc/meminfo).  I tried both
kernel-2.6.20-1.2948.fc6 and kernel-PAE-2.6.20-1.2948.fc6, but both fail in the
same way (AFAICT).

If you'd like more detailed output from dmesg et. al. I can get that for you.

forgot to add... I just tried the fc7 kexec-tools on a fc6 desktop x86 IBM
thinkcentre (~512MB memory) I have here and that loaded kdump "OK".  

Yeah, I figured.  You're xeon is an x86_64 machine, it apparently still needs
the kdump (vmlinux) file to boot, rather than the vmlinuz file.  Nominally this
is automatically set in /etc/sysconfig/kdump, but the upgrade process may be a
bit broken in the spec file.  Can you please check /etc/sysconfig/kdump and make
sure that KDUMP_IMG is set to vmlinux rather than vmlinuz?

Thanks!
Neil

sorry, no go.  got back the "Cannot determine file type..." error.

kexec-tools-1.101-69.fc7

/etc/sysconfig/kdump:

KDUMP_KERNELVER="2.6.20-1.2948.fc6kdump"
KDUMP_COMMANDLINE=""
KDUMP_COMMANDLINE_APPEND="irqpoll maxcpus=1"
KEXEC_ARGS=" --args-linux"
KDUMP_BOOTDIR="/boot"
KDUMP_IMG="vmlinux"
KDUMP_IMG_EXT=""

kexec command:

$ /sbin/kexec  --args-linux --elf64-core-headers -p --command-line="ro
root=LABEL=/ irqpoll maxcpus=1"
--initrd=/boot/initrd-2.6.20-1.2948.fc6kdumpkdump.img
/boot/vmlinux-2.6.20-1.2948.fc6kdump
Cannot determine the file type of /boot/vmlinux-2.6.20-1.2948.fc6kdump

interesting.  Ok, I was wrong before, you do need the kernel-kdump packages'
vmlinux file to load with kdump on x86_64.  I'm currently testing with
1.2929.fc6 here and after adding some debug code to kexec I've noticed something
interesting, we're getting permission denied errors when trying to open
/proc/kcore, even with selinux disabled, and running as root.  Looking at the
2.6.20-1.2949.fc6 code base I see that the open_kdump function has been modified
from upstream in the devmem patch such that open_kdump unilaterally returns
-EPERM, meaning the file is forever unreadable.  Davej, can you comment on why
this was done?  Is it in error, or do I need to find another way for kexec to
grab the info it needs about the running kernel?  Thanks much! 

you mean open_kcore I assume ?

I'm not sure why it was done that way.
It was done before we added kdump support, so I guess it just wasn't planned ahead.

For similar reasons, 'crash' broke because of this, and instead of making
/proc/kcore read-only, we added a separate read-only /dev/crash

Yes, sorry open_kcore is what I meant.  so we should be reading /dev/crash
instead.  I'll put a patch together to that end.  Thanks Dave.

Created attachment 154826 [details]
test srpm for x86_64

Heres a srpm with a fix for the problem dave described. Please build/test it
out and let me know if it solves your remaining problem.  Thanks!

I still get 'Cannot determine the file type...", but could it be because I'm
running fedora x86 on this machine?  my uname -m returns 'i686' and the compile
of the srpm only builds the x86 arch tree on this machine.  I also don't see an
open of "/dev/crash" in an strace of the kexec.  

um, yeah.  I wish I'd known that previously.  So are you telling me that you're
running an x86 kernel with an x86 kexec-tools package, but you're trying to get
kexec-tools to load a 64 bit kernel from the x86_64 kernel-kdump package?  Thats
not going to work.  I'd suggest we go back to the fc7 kexec pacakge, make sure
that kdump points to the running vmlinuz image (which it should by default if
you deconfigure everything that you had configured before in the sysconfig file,
and then capture from the startup script the errors tha kexec spits out.  Thats
the case that we need to fix here.  Using a 32 bit kexec-tools package to load a
64 bit kdump kernel isn't going to fly.

sorry for confusion. I'm running an x86 kernel with x86 kexec-tools, and was
trying to load the x86 kernel-kdump.

# uname -a
Linux host-new 2.6.20-1.2948.fc6PAE #1 SMP Fri Apr 27 19:30:08 EDT 2007 i686
i686 i386 GNU/Linux

Ok, I restart back to the fc7 kexec-tools package:

# rpm -q kexec-tools
kexec-tools-1.101-69.fc7
# rpm --qf '%{ARCH}' -q kexec-tools
i386

contents of /etc/sysconfig/kdump:
KDUMP_KERNELVER=""
KDUMP_COMMANDLINE=""
KDUMP_COMMANDLINE_APPEND="irqpoll maxcpus=1"
KEXEC_ARGS=" --args-linux"
KDUMP_BOOTDIR="/boot"
KDUMP_IMG="vmlinuz"
KDUMP_IMG_EXT=""

$ service kdump start
Detected /etc/kdump.conf or /boot/vmlinuz-2.6.20-1.2948.fc6PAE change
Rebuilding /boot/initrd-2.6.20-1.2948.fc6PAEkdump.img
Starting kdump:                                            [FAILED]

error in /var/log/messages:
kdump: kexec: failed to load kdump kernel
kdump: failed to start up

here is the kexec command the script tried to run which returns an error:
# /sbin/kexec --args-linux --elf64-core-headers -p --command-line="ro
root=LABEL=/  irqpoll maxcpus=1"            
--initrd=/boot/initrd-2.6.20-1.2948.fc6PAEkdump.img
/boot/vmlinuz-2.6.20-1.2948.fc6PAE 
Cannot load /boot/vmlinuz-2.6.20-1.2948.fc6PAE

Next, I try the following in /etc/sysconfig/kdump:
KDUMP_KERNELVER="2.6.20-1.2948.fc6kdump"
KDUMP_KERNELVER=""
KDUMP_COMMANDLINE=""
KDUMP_COMMANDLINE_APPEND="irqpoll maxcpus=1"
KEXEC_ARGS=" --args-linux"
KDUMP_BOOTDIR="/boot"
KDUMP_IMG="vmlinux"
KDUMP_IMG_EXT=""

# service kdump start
Detected /etc/kdump.conf or /boot/vmlinux-2.6.20-1.2948.fc6kdump change
Rebuilding /boot/initrd-2.6.20-1.2948.fc6kdumpkdump.img
Starting kdump:                                            [FAILED]

error in /var/log/messages:
kdump: kexec: failed to load kdump kernel
kdump: failed to start up

here is the kexec command that tries to run with following error:
# /sbin/kexec  --args-linux --elf64-core-headers -p --command-line="ro
root=LABEL=/  irqpoll maxcpus=1"      
--initrd=/boot/initrd-2.6.20-1.2948.fc6kdumpkdump.img
/boot/vmlinux-2.6.20-1.2948.fc6kdump
Cannot determine the file type of /boot/vmlinux-2.6.20-1.2948.fc6kdump

Ok, Since we doing x86 here, rather than x86_64, I re-set this up locally and it
appears that we're back to what I was seeing in comment #4.  We need to
understand why thats happening.

No, scratch that last comment.  Man this gets confusing.  With the addition of
the relocatable packages, if you are using x86 kernel images, you don't need to
use the kdump images at all.  And it appears that you are running the kdump
kernel as your normal kernel (as is evidenced by the fact that your initrd is
reading as initrd-2.6.20-1.2948.fc6kdumpkdump.img, rather than
initrd-2.6.20-1.2948.fc6kdump.img).  Please don't do that.  Just boot the normal
smp/up kernel that fc6 offers.  I just tried that here with the fc7 kexec-tools
(which is required now that we can do relocatability on fc6).

I'm going to try booting the PAE kernel here to see what that does.  My guess is
that it isn't working because fc7 needs an el5 patch that I never got around to
forward porting to force 64 bit elf headers.  I can fix that shortly if thats
the case, and move all the fc7 code to fc6.

Results from me running kdump on on my x86 fc6 PAE kernel here using
kexec-tools-1.101-69.fc7

[root@hmssabre ~]# /sbin/service kdump start
No kdump initial ramdisk found.                            [WARNING]
Rebuilding /boot/initrd-2.6.20-1.2952.fc6PAEkdump.img
Starting kdump:                                            [  OK  ]

So at this point both the normal kernel and the PAE kernel are inserting fine
for me with the fc7 kexec-tools package, and the kdump kernel needs to be
discontinued for x86, so it can be ignored.  I'm beginning to think that all our
reinstalls have left your configuration in some unstable state.  I'd suggest
erasing your kexec-tools package entirely (rpm -e), manually removing the
/etc/kdump and /etc/sysconfig/kdump packages, and then installing the fc7
kexec-tools package (and make sure its -69.fc7, which should be latest).  then
restarting the service.  It should just work, as it just did for me.

ok, I removed kexec-tools, kernel-kdump and cleaned out all the config files,
all kdump files, rebooted, started fresh with the latest fc7 kexec-tools:

Using the default installed /etc/sysconfig/kdump i get:
# service kdump start
No kdump initial ramdisk found.                            [WARNING]
Rebuilding /boot/initrd-2.6.20-1.2948.fc6PAEkdump.img
Starting kdump:                                            [FAILED]

/var/log/messages:
kdump: kexec: failed to load kdump kernel
kdump: failed to start up

the kexec command line:
/sbin/kexec  --args-linux --elf64-core-headers -p             
--command-line="ro root=LABEL=/
 irqpoll maxcpus=1"            
--initrd=/boot/initrd-2.6.20-1.2948.fc6PAEkdump.img
/boot/vmlinuz-2.6.20-1.2948.fc6PAE
Cannot load /boot/vmlinuz-2.6.20-1.2948.fc6PAE

I tried the non-PAE kernel and I get same error.  If it's any help, I tried the
load option to kexec and that seemed to work:

# /sbin/kexec --args-linux --elf64-core-headers -l --command-line="ro
root=LABEL=/ irqpoll maxcpus=1"            
--initrd=/boot/initrd-2.6.20-1.2948.fc6PAEkdump.img
/boot/vmlinuz-2.6.20-1.2948.fc6PAE
# cat /sys/kernel/kexec_loaded
1
# /sbin/kexec --args-linux --elf64-core-headers -u --command-line="ro
root=LABEL=/ irqpoll maxcpus=1"            
--initrd=/boot/initrd-2.6.20-1.2948.fc6PAEkdump.img
/boot/vmlinuz-2.6.20-1.2948.fc6PAE
# cat /sys/kernel/kexec_loaded
0
# cat /proc/cmdline
ro root=LABEL=/ crashkernel=128@16M

Don't know why -p wouldn't work... I noticed you have a 2.6.20-1.2952.fc6PAE
version kernel, but I can't find that on the download server... don't know if
that matters though.

Created attachment 155015 [details]
latest fc6 kernel

here you go.  Give it a shot and let me know how it works.  Both it and the PAE
version worked fine for me.

no go...

# service kdump start
Detected /etc/kdump.conf or /boot/vmlinuz-2.6.20-1.2952.fc6 change
Rebuilding /boot/initrd-2.6.20-1.2952.fc6kdump.img
Starting kdump:                                            [FAILED]

from kexec run manually:
Cannot load /boot/vmlinuz-2.6.20-1.2952.fc6

i see the crash memory:
# cat /proc/iomem
00000000-0009d3ff : System RAM
0009d400-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c8fff : Video ROM
000c9000-000ccfff : Adapter ROM
000f0000-000fffff : System ROM
00100000-d7fb057f : System RAM
  00400000-00623830 : Kernel code
  00623831-00745493 : Kernel data
  01000000-08ffffff : Crash kernel
d7fb0580-d7fcffff : ACPI Tables
d7fd0000-d7ffffff : reserved
db000000-dcffffff : PCI Bus #04
  db000000-dcffffff : PCI Bus #05
    dcfe0000-dcfeffff : 0000:05:01.1
      dcfe0000-dcfeffff : tg3
    dcff0000-dcffffff : 0000:05:01.0
      dcff0000-dcffffff : tg3
dd000000-deffffff : PCI Bus #02
  defe0000-defeffff : 0000:02:01.0
  deff0000-deffffff : 0000:02:01.0
e0000000-efffffff : reserved
f0000000-f7ffffff : PCI Bus #01
  f0000000-f7ffffff : 0000:01:01.0
f8000000-f8ffffff : PCI Bus #01
  f8000000-f800ffff : 0000:01:01.0
  f8020000-f803ffff : 0000:01:01.0
f9000000-f90fffff : PCI Bus #02
  f9000000-f90fffff : 0000:02:01.0
f9100000-f91003ff : 0000:00:1f.1
f9100400-f910040f : 0000:00:1d.4
  f9100400-f910040f : i6300ESB timer
fec00000-ffffffff : reserved
100000000-1a7ffffff : System RAM

... and doing kexec -l runs without errors.

Well, I'm not sure what to tell you.  Its pretty clear when you say that -p
doesn't work but -l does, that there is one extra path in do_bzImage_load that
we go down, which must be where our error is occuring.  Oddly enough the error
doesn't occur for me on the latest kernel, and I can't imagine why it would for
you.  Please run this coimmand line manually again (modified from your comment #24):
/sbin/kexec  --args-linux --elf64-core-headers -d -p             
--command-line="ro root=LABEL=/
 irqpoll maxcpus=1"            
--initrd=/boot/initrd-2.6.20-1.2948.fc6PAEkdump.img
/boot/vmlinuz-2.6.20-1.2948.fc6PAE

The extra -d should give us extra debug information about why your system is
failing, and will hopefully explain why yours is failing and mine is not.  Thanks

ok, here's the output, i needed to recompile with -DDEBUG, but I got this:

# /sbin/kexec  --args-linux --elf64-core-headers -d -p --command-line="ro
root=LABEL=/ irqpoll maxcpus=1" --initrd=/boot/initrd-2.6.20-1.2948.fc6.img
/boot/vmlinuz-2.6.20-1.2948.fc6PAE
bzImage is relocatable
Created backup segment at 0x8f60000
Created elf header segment at 0x8ffc000
Cannot load /boot/vmlinuz-2.6.20-1.2948.fc6PAE

oops, here's the exact command you wanted to run... looks the same though:

# /sbin/kexec  --args-linux --elf64-core-headers -d -p --command-line="ro
root=LABEL=/ irqpoll maxcpus=1"
--initrd=/boot/initrd-2.6.20-1.2948.fc6PAEkdump.img
/boot/vmlinuz-2.6.20-1.2948.fc6PAE
bzImage is relocatable
Created backup segment at 0x8f60000
Created elf header segment at 0x8ffc000
Cannot load /boot/vmlinuz-2.6.20-1.2948.fc6PAE

ok, i got success if I rebooted with "mem=1024M"... so this has something to do
with memory size.  I'll attach the successful debug run...

Created attachment 155257 [details]
dump of debug run that worked

this worked with kernel "mem=1024M"

Interesting, that would explain why its working for me.  How much ram do you
have in this box.  I wonder if your ram size is overflowing the 32 bit pointers
we use for storing physical addresses.

it's got 6GB... it's the machine in comment #10.  Here's what /proc/meminfo
looks like:

# cat /proc/meminfo
MemTotal:      6086708 kB
MemFree:       5899600 kB
Buffers:         15552 kB
Cached:         120052 kB
SwapCached:          0 kB
Active:          45440 kB
Inactive:       114044 kB
HighTotal:     5373632 kB
HighFree:      5224340 kB
LowTotal:       713076 kB
LowFree:        675260 kB
SwapTotal:     2031608 kB
SwapFree:      2031608 kB
Dirty:            1188 kB
Writeback:           0 kB
AnonPages:       23836 kB
Mapped:           8752 kB
Slab:            14920 kB
SReclaimable:     3744 kB
SUnreclaim:      11176 kB
PageTables:       1736 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   5074960 kB
Committed_AS:   164936 kB
VmallocTotal:   116728 kB
VmallocUsed:      3404 kB
VmallocChunk:   112700 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

fyi, it didn't matter if I was running the PAE or non-PAE kernel, kexec still
failed.  Only when I reduced the size with mem= kernel parameter did kexec succeed.

hmm, I wonder if there is going to be much we can do about this...

Do you have 64 bit libraries installed on this system, or is it only 32 bit.  Is
it possible for you to install the 64 bit kexec-tools package on this system?

hmmm.  this only has 32 bit libraries.  When you mean install the 64 bit
kexec-tools, you mean install the x86_64 distribution right?  I can do this, if
the current 32 bit install is a dead end.

you shouldn't need the entire 64 bit distro, just the 64 bit kexec package and
its supporting libraries.  You should just need to install the 64 bit glibc, and
64 bit zlib, whcih should be able to co-exist with their 32 bit counterparts.

1. hmm, doesn't look like rpm is happy about that:

# rpm -ivh kexec-tools-1.101-69.fc7.x86_64.rpm glibc-2.5-10.fc6.x86_64.rpm
zlib-1.2.3-3.x86_64.rpm
Preparing...                ########################################### [100%]
        package glibc-2.5-10.fc6 is intended for a x86_64 architecture
        package glibc-2.5-10.fc6 is already installed
        package zlib-1.2.3-3 is intended for a x86_64 architecture
        package zlib-1.2.3-3 is already installed
        package kexec-tools-1.101-69.fc7 is intended for a x86_64 architecture
        file /sbin/ldconfig from install of glibc-2.5-10.fc6 conflicts with file
from package glibc-2.5-10.fc6
...

i'm hesitant to --force install that.  If you have thoughts on that I can try
them...

2. In an effort to see if I could get this to work on a pure x86_64 install, I
installed fc6 x86_64 on another identical blade.  unfortunately I got this from
the srpm package in comment 17 :

kernel: crash memory driver: !page_is_ram(pfn: 0)
kdump: read on /dev/crash of 4096 bytes failed: Bad address Cannot read
/dev/crash: Bad address Cannot load /boot/vmlinux-2.6.20-1.2948.fc6kdump
kdump: kexec: failed to load kdump kernel
kdump: failed to start up

sorry to bring up two issues, i can open a new bugreport if you'd like.

crud, you're right, in order to have 32 and 64 bit user space packaages, you
need to be runniing the 64 bit kernel (since the 32 bit kernel can't handle 64
bit args in the system calls).  Can you install and run the 64 bit kernel?

Regarding your other problem, yes, if you could open up another bug please
against the kernel, that would be appreciated.  Its seeming more and more like
the relocatable changes have just completely borked kexec ability to function in
fc6.  We can't read /proc/kcore, and we can't read /dev/crash, for what looks to
be an adressing problem.

Doesn't look like that's possible, i get:

# rpm -ivh kernel-2.6.20-1.2948.fc6.x86_64.rpm
Preparing...                ########################################### [100%]
        package kernel-2.6.20-1.2948.fc6 is intended for a x86_64 architecture

No, Its possible, I'm sure of that.  grrrr.  I'm starting to wonder if this is
actually 64 bit hardware you're working with.

I'll see if I can locate an x86_64 system here with more than 4GB of ram to
recreate this with.

Ok, I think I've got your problem re-created.  The segment map seems somehow
wrong when we have more than 1GB of RAM in a system, and it leads to the
elfcorehdr pointer in the x86 load_crashdump_segments() function pointing
outside the range defined in the memap_p array.  This in turn leads to the
subsequent delete_memmap operation failing, which leads to kexec failure.  I
need to figure out why thats happening.

Created attachment 155721 [details]
patch to retry locate_hole if there is a segment overlap and to limit elfcorehdr buffer to max mmap end

Ok, I think I've found a solution, at least to the problem that I recreated
here locally.  It should avoid the deletion of non-existant memory maps and
overlapping segments problems that I've found.	Please build it and give it a
try.  Thanks!

Yay!

# service kdump start
bzImage is relocatable
Created backup segment at 0x8f60000
Created elf header segment at 0x8f5b000
Loaded purgatory at addr 0x8f52000
Loaded real-mode code and command line at 0x1000000
Loaded 32bit kernel at 0x1400000
initrd_addr_max is 0x1fffffff
Loaded initrd at 0x8ca5000 size 0x2aca85
Starting kdump:                                            [  OK  ]

do me a favor and make sure that you can still kexec boot on crash using this
patch (my test system is unavailable at the moment).  Thanks!

Ok, I'm not sure if I'm doing this right but:

# echo "c" > /proc/sysrq-trigger

i can see the kexec kernel boot up, at the point where kdump gets started that
fails (this may be normal when booting kexec kernel?):

/var/log/messages:
kernel: Kernel command line: ro root=LABEL=/  irqpoll
maxcpus=1 memmap=exactmap memmap=640K@0K memmap=130412K@16384K elfcorehdr=146796
K
May 31 10:30:03 xxx-new kernel: Misrouted IRQ fixup and polling support enable
d
May 31 10:30:03 xxx-new kdump: No crashkernel parameter specified for running
kernel
May 31 10:30:03 xxx-new kernel: This may significantly impact system performan
ce
May 31 10:30:03 xxx-new kdump: failed to start up

my /etc/kdump.conf:
ext3 /dev/mainvg/varlv

and my /var/crash directory is empty (an image file of vmcore should be there?),
but the system is up and running in the kexec kernel AFAIK.

here are some lines in the kexec boot up which look suspicious (maybe):

Activating logical volumes
  7 logical volume(s) in volume group "mainvg" now active
dm_task_set_name: Device /dev/mapper/-optlv not found
Command failed
dm_task_set_name: Device /dev/mapper/-tmplv not found
Command failed
dm_task_set_name: Device /dev/mapper/-usrlv not found
Command failed
dm_task_set_name: Device /dev/mapper/-varlv not found
Command failed
dm_task_set_name: Device /dev/mapper/-wwwlv not found
Command failed
Saving to the local filesystem /dev/mainvg/varlv
e2fsck 1.38 (30-Jun-2005)
/dev/mainvg/varlv: recovering journal
/dev/mainvg/varlv: clean, 548/2048256 files, 126227/2048000 blocks
kjournald starting.  Commit interval 5 seconds
EXT3 FS on dm-3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
cp: /proc/vmcore: No such file or directory
Creating root device.
Checking root filesystem.
fsck 1.38 (30-Jun-2005)
fsck: WARNING: couldn't open /etc/fstab: No such file or directory
e2fsck 1.38 (30-Jun-2005)
/: recovering journal
/: clean, 8414/1025024 files, 129369/1024135 blocks
Mounting root filesystem.
fsck: WARNING: couldn't open /etc/fstab: No such file or directory
fsck 1.38 (30-Jun-2005)
fsck: WARNING: couldn't open /etc/fstab: No such file or directory
e2fsck 1.38 (30-Jun-2005)
/: clean, 8414/1025024 files, 129369/1024135 blocks
mount -t ext3 /dev/sda1 /sysroot
kjournald starting.  Commit interval 5 seconds
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Switching to new root and running init.

Let me know, i can test/try out other things.

Well, the kdump kernel boots, so thats good.  This line is fatal however:

cp: /proc/vmcore: No such file or directory

Thats where the core is read from.  This suggests that something is just not set
right in the kernel, as that file has to be there for kdump to do anything.  I
assume this is on your 64 bit hardware.  Does this same kexec-tools package that
your testing work on your 32 bit hardware?

Also, if you could add this line to /etc/kdump.conf
default_action shell

and restart/restet the service that would be great.  Doing so should drop you to
a shell in the kdump initrd, which you can use to manually verify that your
target filesystem is mounted, and that /proc/vmcore does or does not exists.  If
you could do that I would appreciate it.  Thanks!

Ok, /proc/vmcore was missing on both my 64bit and a test 32bit system i just setup.

On the 32bit system I could drop into the shell and see that /proc/vmcore was
indeed not there (ps/2 attached keyboard).

On my 64bit system the keyboard is USB attached and I lose all keyboard input
access when dropping into the shell.  So I do get keyboard input without
"default shell" when the kexec kernel/initscripts run to completion, but not
when dropping into the kdump/busybox shell... not sure what's going on there... 

the messages are the same between the two... "cp: /proc/vmcore: No such file or
directory"

fyi, also the 32bit system had the kexec-tools-1.101-69.fc7 installed without
your kexec-x86.patch.  It has only ~600MB of ram.

Fantastic, so FC6 has another problem in the kernel then.  

Ok, here's what we should do, I think.

1) I'm comfortable with our testing that kexec is working properly with this
patch, so I'm going to check it in, and close this bz

2) The other bz that you opened (bz 241362) I am going to close, since it was
the result of a patch that is not in the build, and we didn't wind up using it.

3) The current problem with /proc/vmcore: please open a bug on that, it should
come to me, and I'll investigate why its not getting registered in the kernel.

Thanks

ok, 

I opened up bug #241924 for 3.  For point 2, I think we need that still open,
because kexec-tools-1.101-69.fc7.x86_64 fails... I'll add that info.  Thanks.

Yeah, you're right, I forgot the reason behind why we pursued #2.  I'll use the
open bug to track that.  Thanks.

This patch is checked into -56.fc6, which will be pushed in the next few days. 
Thanks!

*** Bug 220143 has been marked as a duplicate of this bug. ***

Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

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

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