On Thursday 19 April 2007 14:57, Maneesh Soni wrote: [kdump mockups] [215 K attachment cut off] I strongly suggest for future postings on this list to NOT attach screen shots or any other large objects to postings. Rather, please use the openSUSE wiki or another publicly accessible place and add hyperlinks to the screen shots (or whatever other large data you might want to post). As a matter of fact, I would like to ask the list admins to please set up a reasonable limit for postings. IMHO ~50 KB should be plenty for the text; anything else should go someplace else and be linked to the list rather than duplicated in everybody's mail archive. Thank you for your cooperation. CU -- Stefan Hundhammer Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Hello, [@hare: initrd question is the last paragraph] * Maneesh Soni [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,

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

Hi! This looks cool! It seems we could even convince some users to use kdump ;-) I think the UI should use tabs instead of left-hand tree. The 'settings' in the part is superflous. Stano Dňa St 25. Apríl 2007 10:31 Jozef Uhliarik napísal:

Hello,

Last mock-ups are in http://en.opensuse.org/YaST/yast-kdump.

There are some open points and therefore I will continue with:

- kernel parameters - memory size - runlevel - rebooting - verbosity / logging

If you have some hints for this parts you can write me them please.

I will add parts such as: filtering, including initrd and saving location (FTP/SSH/NFS/file) later.

Best regards

Jozef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

On Mon, Apr 23, 2007 at 09:25:15PM +0200, Bernhard Walle wrote: Hi Bernhard,

Hello,

[@hare: initrd question is the last paragraph]

* Maneesh Soni [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,

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.)

The idea was to provide the user ease of use by just clicking to set the dump configuration. With URL style the user should be aware of what all dump options are available and should know the way to write the URL.

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.

I think the "makedumpfile" tool can extract the debug info from the kernel-default-debuginfo and the same can be packaged in kdump initrd and applied while saving the dump.

...

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. We would like to discuss this and also the dump filtering options with initrd maintainer. Regards Maneesh -- Maneesh Soni Linux Technology Center, IBM India Systems and Technology Lab, Bangalore, India -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Hi Joseph, I have seen the updated screen shots on yast web-site and feel good about them. But wondering if these screens are actually integrated with latest yast. I would love to try them out. Thanks Maneesh -- Maneesh Soni Linux Technology Center, IBM India Systems and Technology Lab, Bangalore, India -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org