[@hare: initrd question is the last paragraph]
* Maneesh Soni <maneesh(a)in.ibm.com> [2007-04-19 14:57]:
2) Dump Settings
This should capture the settings about dump target and other misc settings
about daump saving. Apart from this, "the dump filtering" options for
the "makedumpfile" utility can also be integrated here. So,
(a radio button to select either of the three targets like
o Local filesystem
- here we can have a list box with list of valid disk partitions
with supported filesystems
- path location
- This is for possible future extention of dump saving mechanism using
which we can save the dump over network ie over NFS or scp, through
the kdump initrd. For this we will need following settings
- a radio button for selecting NFS or SCP
- IP address of the server
- path (exported path for NFS or target path for scp)
o Raw disk
- here we can have list of available paritions without any
filesystem on them
Default dump path (ie relative to the dump target)
[ /var/log/dump ] (select directory button)
IMO it doesn't make sense to set this in the user interface and map
all to KDUMP_TRANSFER in the configuration file. The main problem I
see is that the user can edit KDUMP_TRANSFER and it becomes difficult
to re-read the configuration in YaST.
My proposal is following:
KDUMP_SAVEDIR="" becomes a URL:
Default user: nobody
Default password: empty
Default user: anonymous
Default password: $USER@$(hostname --fqdn)
(file:// may be missing due to compatibility.)
A raw partition doesn't make sense here. This is not in initrd. So if
we are at this place, we already have the file system mounted.
Dump filtering options
- This should capture settings for options for using the dump fitering
tool "makedumpfile". I am not sure right now if we need a separte
screen for this or "Dump settings" is ok.
We have no makedumpfile support now, beside from KDUMP_TRANSFER.
However, using KDUMP_TRANSFER for this is not a good idea for the
reason mentioned above.
Instead, I would suggest using two new configuration variables:
This should be a number between 0 and 32, explained in
makedumpfile(8). If the variable is empty, a simple 'cp' (i.e. no
filtering) is used.
This should be 'compressed' or 'elf'. 'compressed' can
read by crash while 'elf' can also be read by gdb. 'elf' should
the default (I know it's not the default with makedumpfile, but
For the YaST2 interface this means you have to check if makedumpfile
is installed. If not, install it. Also, kernel-default-debuginfo is
needed while creating the dump, so YaST2 must check this, too.
This raises another problem: On SLES, kernel-default-debuginfo
is only available via online updates, not DVD. However, we have to
discuss this internally.
The big question is now if we support makedumpfile in initrd. Of
course it would make sense to support it, because it would lead to a
smaller image. However, because the tool needs the debug information,
it is no option to move the debug information in the initrd.
Because of this, it's possible to create a config file (it has nothing
to do with the kernel .config!) with makedumpfile that can be used as
alternative. For this, we would need the following work flow:
- mkinitrd creates the configuration file
IMPORTANT: if the kdump kernel is changed, the initrd of the kdump
kernel has to be re-built!
- makedumpfile uses that configuration file in the initrd
An additional problem in both cases is that we need the version of the
running kernel (that created the dump) in the kdump kernel. I'll
investigate if it's possible to retrieve this easily from the dump
file (/proc/vmcore). If not, we have to use the kernel command line
The kdump initrd related changes I was taking about
are probably not the
right stuff for this mailing list but please bear it here.. so that we
can have the right context for discussions
1. The current approach in of using a _dedicated_ disk partition somewhat
defeats the purpose of kdump flexibility. This mandates that use has
to have a separte disk parition allocated just for kdump. The alternative
is to have initrd based solution. In past we have done a prototype for
Here using initrd we copy the dump directly to the disk filesystem
and avoid the intermediate step of copying to a raw partition and then
to target path. This approach does make initrd somewhat bigger in size but
it doesn't need user to have a dedicated disk partition just for kdump.
2. As of now there is no support for saving the dump over network using
NFS or scp. The network dump can also be done using the kdump initrd
once the user has specified right config parameters. So, overall kdump
initrd should be able to copy the dump to all possible targets depending
upon the user settings.
3. As of now the dump filtering tool is not integrated with kdump user scripts
so we can get that also integrated in the initrd and have smaller size
dumps based on options given to "makedumpfile" tool.
This would require to move lots of stuff into initrd. I CC'd the
initrd maintained, so he can answer the question.
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
For additional commands, e-mail: yast-devel+help(a)opensuse.org