[yast-devel] Fw: Fwd: Mockups pre kdump
Hi Bernhard, We have the following observations & suggestions about the mock-up screenshots. Sorry about the long mail and taking some time in replying. We would also like to suggest changes in the kdump user scripts (kdump initrd) and based on that the yast kdump configuration screens will need changes. ************************************************************** 1) General Settings =================== We liked the three way enable/disable settings and they are at the right place, but the other portions like kernel command line or kdump commandline should be part of the expert settings as generally user should be provided with default set of kernel command line options and rarely one has to change them. Instead of command line settings, it would be useful to have the setting related to reserving memory for kdump kernel. The tool can have display like ---------------------------------------------------------------------------- Total system Memory (MB): 4096 (just informative) kdump Memory (MB): (A list box with a minimum memory value like 128, and option to increase should be there) Usable Memory (MB): 3968 (this is also informative) ---------------------------------------------------------------------------- 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) 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. 3) Expert Settings ================== - kdump kenrel command line options [ ] - path to custom kdump kernel [ /boot/vmlinuz-my-kdump-kernel ] - path to custom kdump kernel initrd [ /boot/initrd-my-kdump.img ] - Note: The current approach is to provide user a distro built kdump kernel. But some users would like to use their own kernel to minimize the reserve memory requirement. Also. the kdump initrd might be different if the user is trying to save dump thruough initrd in soe unsual envirnment like multipath IO etc. ************************************************************************* These might be confusing but please let me know if I can elaborate more. 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. Thanks Maneesh ----- Forwarded message from Bernhard Walle <bwalle@novell.com> ----- Date: Thu, 12 Apr 2007 00:32:22 +0200 From: Bernhard Walle <bwalle@novell.com> To: Maneesh Soni <maneesh@in.ibm.com> Cc: tiwai@suse.de Subject: Fwd: Mockups pre kdump Hello, as you may remember you wanted some discussion about the new kdump YaST module. Here I got some early screenshots. I think we should continue the discussion about on the yast-devel@opensuse.org mailing list. See http://en.opensuse.org/Communicate how to subscribe. Thanks, Bernhard -- SUSE LINUX Products GmbH Tel. +49 (911) 74053-0 Maxfeldstr. 5 GF: Markus Rex 90409 Nürnberg, Germany HRB 16746 (AG Nürnberg) OpenPGP DDAF6454: F61F 34CC 09CA FB82 C9F6 BA4B 8865 3696 DDAF 6454 From: Jiri Srain <jsrain@suse.cz> To: bwalle@novell.com, tiwai@novell.com Subject: Mockups pre kdump Date: Wed, 11 Apr 2007 15:23:41 +0200 Hi Bernard and Takashi! I already have some mockups for the YaST dialogs for kdump, find them attached to this mail. I hope that the desired functionality of the module is obvious form them, even though some of the widgets may need better labels. Please, comment on them, also feel free to forward them to IBM. Jiri BTW: How should the module be called? Is yast2-kdump OK with you? -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz ----- End forwarded message ----- -- Maneesh Soni Linux Technology Center, IBM India Systems and Technology Lab, Bangalore, India
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 <sh@suse.de> 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
On Thu, Apr 19, 2007 at 03:38:28PM +0200, Stefan Hundhammer wrote:
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 <sh@suse.de> Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany
Extremely sorry about that. I will keep it in mind for future postings. 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
Hello, [@hare: initrd question is the last paragraph] * Maneesh Soni <maneesh@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,
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
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 <maneesh@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,
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
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
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
Stanislav Visnovsky wrote:
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.
Left-handed-tree is a good solution for a bigger number of dialogs and when we expect longer translations strings. Five or six tabs would not work and then we would have to use tree widget. Actually, I do agree, tab-navigation might be better for this case ... if we don't expect adding more and more features (dialogs) later. Dump Settings: We use [Browse] button instead of [Select Directory] Expert Settings: We use [Browse] button instead of [Select File] I'm a bit confused by the Command Line: Append vs. Replace. "Usable Memory" should be above "Kdump Memory" Maybe some other widget labels might be confusing or unclear. But help should clear everything up. (all is a matter of taste, I guess) L. -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic
On Wed, Apr 25, 2007 at 10:31:58AM +0200, Jozef Uhliarik wrote:
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
Hi Jozef, Thanks for updating the screens. I have the following comments about the Start-Up tab: IMO, here we sould only cover the absoulte necessary settings for kdump i.e firstly, enable or disable and secondly amount of memory to reserve. So, the memory settings should be moved from "Expert Settings" to "Start-up" Also the Run-level to boot is not generally changed by a user, the default setting should be ok for most of the users. Basically most of the users would like the system to automatically save the dump instead of booting to Single User mode and then save the dump manually. So, it would be good if the Run-level setting can be moved to "Expert Settings" 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
participants (6)
-
Bernhard Walle -
Jozef Uhliarik -
Lukas Ocilka -
Maneesh Soni -
Stanislav Visnovsky -
Stefan Hundhammer