Hello,
[@hare: initrd question is the last paragraph]
* Maneesh Soni
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,
Dump Target ----------- (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
o Network - 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: SSH: (ssh|scp)://[user[:pass]]@host[:port]/path Example: ssh://bwalle:very_to_secret@strauss.suse.de:1234//var/log/dump ssh://strauss.suse.de//var/log/dump Default user: nobody Default password: empty FTP: ftp://[user[:pass]]@host[:port]/path Default user: anonymous Default password: $USER@$(hostname --fqdn) NFS: nfs://host/path FILE: [file://]path (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: KDUMP_DUMPLEVEL 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. KDUMP_FORMAT This should be 'compressed' or 'elf'. 'compressed' can only be read by crash while 'elf' can also be read by gdb. 'elf' should be the default (I know it's not the default with makedumpfile, but anyway). 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 for this.
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 such approach
http://lse.sf.net/kdump/patches/automation/sles9-sp2-mkinitrd-1.2-27.9-auto-...
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. Thanks, Bernhard -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org