Bug 465920 - [5.3] VFAT Or MSDOS Target Not Work
[5.3] VFAT Or MSDOS Target Not Work
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kexec-tools (Show other bugs)
All Linux
low Severity low
: rc
: ---
Assigned To: Neil Horman
Martin Jenner
Depends On:
  Show dependency treegraph
Reported: 2008-10-07 02:59 EDT by CAI Qian
Modified: 2008-10-07 07:07 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-07 06:24:13 EDT
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 CAI Qian 2008-10-07 02:59:29 EDT
Description of problem:
The shipped document "kexec-kdump-howto.txt" claimed it supported VFAT or MSDOS partition as a target to save vmcore. However, it did not work,

Freeing unused kernel memory: 320k freed
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
SCSI subsystem initialized

Loading sd_mod.ko module
Loading libata.ko module
Loading ipr.ko ipr: IBM Power RAID SCSI Device Driver version: (September 26, 2007)
ipr 0000:01:01.0: Found IOA with IRQ: 26
ipr 0000:01:01.0: Initializing IOA.
ipr 0000:01:01.0: Starting IOA initialization sequence.
ipr 0000:01:01.0: Adapter firmware version: 06160018
ipr 0000:01:01.0: IOA initialized.
scsi0 : IBM 572E Storage Adapter
  Vendor: IBM-ESXS  Model: ST973401SS        Rev: B516
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 143374000 512-byte hdwr sectors (73407 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write through w/ FUA
SCSI device sda: 143374000 512-byte hdwr sectors (73407 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write through w/ FUA
 sda: sda1 sda2 sda3
sd 0:0:1:0: Attached scsi disk sda
scsi: unknown device type 31
  Vendor: IBM       Model: 572E001           Rev: 0150
  Type:   Unknown                            ANSI SCSI revision: 00
Loading jbd.ko module
Loading ext3.ko module
Loading dm-mod.kodevice-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.11.5-ioctl (2007-12-12) initialised: dm-devel@redhat.com
Loading dm-log.ko module
Loading dm-mirror.ko module
Loading dm-zero.ko module
Loading dm-snapshot.ko module
Waiting for required block device discovery
Waiting for sda...Found
Waiting for sda...Found
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
Making device-mapper control node
Scanning logical volumes
  Reading all physical volumes.  This may take a while...
  Found volume group "VolGroup00" using metadata type lvm2
Activating logical volumes
  2 logical volume(s) in volume group "VolGroup00" now active
Saving to the local filesystem /dev/VolGroup00/LogVol01
fsck.vfat: not found
mount: Mounting /dev/VolGroup00/LogVol01 on /mnt failed: No such device
umount: Couldn't umount /mnt: Invalid argument
[: 0: unknown operand
Attempting to enter user-space to capture vmcore

From the resulted init file in the initramfs,

fsck.vfat $DUMPDEV
mount -t vfat $DUMPDEV /mnt
if [ $? == 0 ]
  mkdir -p /mnt//var/crash/$DATE
  export VMCORE
  monitor_cp_progress $VMCORE-incomplete &
  cp /proc/vmcore $VMCORE-incomplete >/dev/null
  if [ $exitcode == 0 ]
      mv $VMCORE-incomplete $VMCORE
      echo -e "\\033[0JSaving core complete"

Looks like necessary module was not included in Kdump initramfs. Even if the required module has been loaded manually using,

  extra_modules vfat

It still failed because the target directory's name is too long,

Activating logical volumes
  2 logical volume(s) in volume group "VolGroup00" now active
Saving to the local filesystem /dev/VolGroup00/LogVol01
fsck.vfat: not found
mkdir: Cannot create directory `/mnt//var/crash/': Invalid argument
cp: unable to open `/mnt//var/crash/': No such file or directory
Attempting to enter user-space to capture vmcore

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

How reproducible:

Steps to Reproduce:
1. create a VFAT partition - mkfs.vfat /dev/VolGroup00/LogVol01
2. configure the Kdump - vfat /dev/VolGroup00/LogVol01
3. SysRq-C
Comment 1 Neil Horman 2008-10-07 06:24:13 EDT
I'm not sure where you saw the included documentation claim tha vfat and msdos were supported.  From kexec-kdump-howto.txt:

Note that for local file systems ext3 and ext2 are
supported as dumpable targets.  Kdump will not prevent you from specifying
other filesystems, and they will most likely work, but their operation
cannot be guaranteed.  for instance specifying a vfat filesystem or msdos
filesystem will result in a successful load of the kdump service, but during
crash recovery, the dump will fail if the system has more than 2GB of memory
(since vfat and msdos filesystems do not support more than 2GB files).
Be careful of your filesystem selection when using this target.

I thought that was pretty clear in saying that you can try other filesystems, but only ext2/3 were officially supported. If there is something to further clarify that, please suggest it and I'm happy to add it in.  I've had a request for vfat & msdos previously, and we can fix the module loading if you think its a good idea, but honestly, vfat and msdos simply aren't going to be supported for dump capture.  Between size limitations and name formatting limitations, its simply not feasible.
Comment 2 CAI Qian 2008-10-07 07:07:12 EDT
OK, thanks for pointing out. I should read the document more carefully.

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