This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 463399 - [5.3] "default" Option Conflict with Manpage
[5.3] "default" Option Conflict with Manpage
Status: CLOSED DUPLICATE of bug 463404
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kexec-tools (Show other bugs)
5.2
All Linux
medium Severity medium
: rc
: ---
Assigned To: Neil Horman
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-23 02:25 EDT by CAI Qian
Modified: 2008-09-23 06:36 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-23 06:36:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
init from the generated Kdump initramfs (5.95 KB, text/plain)
2008-09-23 02:25 EDT, CAI Qian
no flags Details

  None (edit)
Description CAI Qian 2008-09-23 02:25:08 EDT
Created attachment 317435 [details]
init from the generated Kdump initramfs

Description of problem:
From kdump.conf(5),

  default <reboot | shell>
  ...
  reboot: If the default action is reboot simply reboot the system and loose
  the core that you are trying to retrieve."

However, I have seen Kdump still saved the vmcore. From the generated initramfs, I have seen,

mount -t ext3 $DUMPDEV /mnt
if [ $? == 0 ]
then
  mkdir -p /mnt//var/crash/127.0.0.1-$DATE
  VMCORE=/mnt//var/crash/127.0.0.1-$DATE/vmcore
  export VMCORE
  monitor_cp_progress $VMCORE-incomplete &
  cp /proc/vmcore $VMCORE-incomplete >/dev/null
  exitcode=$?
  if [ $exitcode == 0 ]
  then
      mv $VMCORE-incomplete $VMCORE
      echo -e "\\033[0JSaving core complete"
  fi
fi
umount /mnt
[ $exitcode == 0 ] && reboot -f
reboot -f

I was using the following kdump.conf,

  ext3 /dev/mapper/VolGroup00-LogVol00
  default reboot

If this behaviour is expected, we may need to fix the manpage.

BTW, there looks like a typo in the manpage,

- Action to preform instead of mounting root fs and running init process reboot: If the default action is reboot simply reboot the system and loose the core that you are trying to retrieve.
+ Action to preform instead of mounting root fs and running init process. reboot: If the default action is reboot, simply reboot the system and lose the core that you are trying to retrieve.

Version-Release number of selected component (if applicable):
kexec-tools-1.102pre-40.el5

How reproducible:
always
Comment 2 CAI Qian 2008-09-23 02:42:55 EDT
"default: shell" has the same problem. It probably does not make any sense by dropping to a shell after the vmcore has already been saved.
Comment 3 Neil Horman 2008-09-23 06:36:45 EDT
This is really a disconnect between an old change in implementation and behavior.  We changed the initrd so the default action was preformed after the core was captured regardless of success or failure.  It dovetailed with the desire for a reboot to happen afterward in most cases.  It was also good because dropping to a shell (or halting) sometimes does make perfectly good sense.  People may to preform manual recovery actions on system components from other vendors, or otherwise interrogate a system before resetting it.  I'll update the documentation to be more clear about this in bz 463404

*** This bug has been marked as a duplicate of bug 463404 ***

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