Bugzilla – Bug 150504
YOU: Kernel update script kernel-update.ycp doesn't show anything in ncurses mode
Last modified: 2006-11-02 12:41:07 UTC
When installing a kernel patch which uses the UpdateScript feature of patchinfo files, YOU invokes this UpdateScript to install the rpms it has downloaded. The UpdateScript tries to interact with the user by displaying a dialog window. This works perfectly well under X. In ncurses mode, the y2log shows that all the processes are started correctly, and the log also shows that the ycp script created the GUI, but nothing is shown on screen. I assume that ncurses at this point is in a mode where YOU still defines what is shown on screen, and the ycp script is not given access, or similar. This confirms what Michael Radziej remarked in bug 116935: ncurses needs to be reset/reinitialized in some way. This bug has been seen on 10.0. I got the ncurses mode of the UpdateScript to run successfully on SLES9, but the problem may have been hidden for some reason. The UpdateScript and the ycp script it calls can be found in /work/SRC/old-versions/10.0/all/kernel-update-tool/: install-kernel-rpms-6.sh kernel-update.ycp
Created attachment 68112 [details] Processes running when the bug occurs
Created attachment 68115 [details] y2log of installing the patch This shows what yast is trying to do when installing the patch. The last three lines are interesting: this is what you get when pressing ^L when the ncurses GUI is blocked. The GUI elements of kernel-update.ycp are never displayed; it seems as if the YaST ncurses GUI is blocking the script from displaying anything.
Edith, Klaus, can someone from the YaST team please debug this? I don't know enough about yast in general, or yast in ncurses in particular. (Thanks to Michael for helping me analyze this bug!) Michael and Heiko, it seems that the misleading messages that we saw before about the sub-process having finished were caused by the additional debug option. I thik we can ignore them.
Thats ncurses specific, hopefully someone from Prague can help
Created attachment 72562 [details] Fake repodata with missing tags Here is a spec file and rpm that has the tags, together with how the meta-data should look. The metadata were created by hand-editing, and so unfortunately the checksums are bogus.
Stano, Edith, any chance we can make progress on this one?
Gabi, can you please check this one? Thanks!
Yes, I will check this. Where can I find patch-10823 for testing?
You can get it from you.suse.de (with a YaST2 online update) or from /mounts/work/built/patchinfo/3fc3600c4fce30e7f80b50f5c8095e31/ (with an auto-mounter).
That's an old version. Rudi will generate a new patch for sles9. http://w2d.suse.de/abuildstat/patch-status also has a patch with the kernel-update-tool and yast2-packagemanager update that needs to be installed first.
I will test with new patch.
Gabi, this bug really hurts us. Is there a chance you could please have a look? Thanks.
I have tried to reproduce the bug - but not yet successful. I have followed the test instructions from Heiko, have installed a SLES9, SP3 and novell-kmp-1.1_2.6.5_7.244-0.1. Then I didn't find patch-10845 on you.suse.de. I have installed patch-10929 - but as far as I can see no update script is called. Andreas, could you please have a look on my test environment so that I can test correctly?
Gabi, I have resubmitted a kernel-update-tool package that fixes the bug we ran into today. Could you please grab the new package for testing from blunzn-agruen-8? Thank you.
I have tested with Andreas yesterday and in my opinion the problem is this: YaST Online Update executes the script install-kernel-rpms-7.sh which starts a second YaST to execute a YCP module showing a popup. In case of ncurses the start of a second YaST in one terminal is a problem, the behaviour is undefined. We discussed the solution to add a ncurses call to stop ncurses for the first YaST, start the second and after that restore the terminal. This would work if we had a simple ncurses application. But for YaST it isn't that simple. There is a discussion about that problem -> see Comment #14 from bug #175669: One workaround would be a special SCR agent for that very purpose: An agent that knows how to start an ncurses application. That one would have to block signals (like SIGWINCH used by ncurses), save the terminal status etc., start the other ncurses app and afterwards restore everything. My proposal for the problem: avoiding the call of another YaST and do all work in an YCP module. As far as I can see in SLES9 packagemanager and WFM PkgModuleCallbacks there is a method "executeYcpScript" which should do exactly what we want. Cornelius could you please verify that SLES9 YOU can execute YCP scripts? Andreas, it should be possible to use one YCP script? We could also call the shell script from YCP, open the popup and if required call another script after that.
It turns out that the backport of the UpdateScript patch from Michael hasn't been checked into the yast cvs for SLES9, yet. Could you please get the patch checked in (and possibly reviewed)? See /work/src/done/SLES9-SP4/yast2-packagemanager: updatescript.diff updatescript-fix.diff I have no problem with having the UpdateScript for kernel patches implemented in ycp. Could you please check if that is possible? The current version is available at /work/src/done/SLES9-SP4/kernel-update-tool: install-kernel-rpms-8.sh Please keep in mind that we also need to pass the list of downloaded packages to that script; IIRC there were some potential problems with that.
YOU supports executing YCP scripts from patches. This should allow to open dialogs in ncurses as well as the qt frontends. So the cleanest solution might be to have a patch that just includes the YCP script, but no packages and let the YCP script handle all the rest, including download of packages.
This was one of the solutions we considered. Kernel patches usually contain a range of packages, and you chooses some of them for download and installation. We would need to duplicate all of this logic, so we decided that it makes more sense to use the existing logic, and allow patches to specify a script for installing the downloaded packages (UpdateScript) instead of installing them directly with rpm. Support for this script exists in 10.0 already, so we know quite well that nothing breaks at least for patches that don't use the UpdateScript tag, and we also know that patches that use UpdateScript were successful in several tests. The patches in /work/src/done/SLES9-SP4/yast2-packagemanager are direct backports to SLES9 of code in http://svn.suse.de/svn/yast/branches/SuSE-Linux-10_0-Branch. It is relatively easy to see that the code doesn't change the behavior of YOU in case no UpdateScript tag is found, so we are definitely on the safe side with this change.
I have applied the patch (not yet checked in to CVS) and have tested with a modified kernel-update.ycp script instead of using install-kernel-rpms-8.sh. I modified kernel-update.ycp to read the list of RPMs from the file /var/adm/YaST/you_update_arguments (the patch includes code that writes the file if the UpdateScript ends with .ycp). At the moment the code from install-kernel-rpm.sh which checks the order of the packages is missing in kernel-update.ycp. The question is: is this code necessary? The arguments of the kernel-update-tool are called with --extra-rpm which means: Install the specified rpm package in the same rpm transaction as the kernel and driver packages. And therefore rpm should do the rigth thing. Andreas, could you please check?
Created attachment 88660 [details] kernel-update.ycp
Well, install-kernel-rpms-8.sh has code that checks for kernel-flavor-nongpl packages which won't trigger on SLES9 (we only had kernel-flavor-nongpl packages from 9.2 to 10.0), and we likely won't push out kernel-flavor-debuginfo packages anytime soon in patches. I think we should nevertheless keep that code just in case. Other than that, the code makes sure that all kernel-flavor packages are upgraded before kernel-source and kernel-syms, and that all distinct kernel-flavor packages (e.g., kernel-default and kernel-smp) are upgraded separately, and with all their associated -nongpl and -debuginfo packages if any. It also finally installs the packages that don't have anything to do with KMPs directly with rpm instead of going through the kernel-update-tool. The idea behind all this is to first upgrade all the kernel-flavor packages together with all packages that depend on them, and to install the other packages only if this succeeds. (The kernel-update-tool may decide not to install a package.) The kernel-x, kernel-x-nongpl (and proabably also kernel-x-debuginfo) packages must be installed in a single step, because they have interdependencies. If kernel-default, kernel-source, kernel-syms, kernel-spm, and kernel-smp-nongpl are present on a system, a possible install sequence would be: kernel-default kernel-smp + kernel-smp-nongpl kernel-source kernel-syms
I have changed kernel_udpate.ycp to do the work from script install-kernel-rpms.sh (see attachment).
Created attachment 91573 [details] kernel_update.ycp
Created attachment 92558 [details] Newer version Gabi, could you please have a look at this version? The previous version had a few bugs that I tried to fix. Do you need help testing this?
I have changed the new version of kernel-update.ycp (diff see below) and have tested with a you_update_arguments testfile in /var/adm/YaST (see below). The old and the new version create the same installation order except the old version wouldn't install a nonmatching -nongpl or -debuginfo file (see attached y2log). Is the installation order ok? What else should be tested? diff kernel-update.ycp kernel-update.ycp.save ---------------------------------------------- 696,700d695 < if ( other_rpm == nil ) < { < n = n + 1; < continue; < } 711c706,707 < substring( base_name, pos[0]:0 + 1 + pos[1]:0 ); --- > substring( base_name, pos[1]:0 + pos[1]:0 ); > /*FIXME: check offsets !!! */ 719c715,716 < substring( base_name, pos[0]:0 + 1 + pos[1]:0 ); --- > substring( base_name, pos[1]:0 + pos[1]:0 ); > /*FIXME: check offsets !!! */ file you_update_arguments: -------------------------- /var/lib/YaST2/you/update/SLES-CORE/10/rpms/i586/kernel-default-2.13.25-i586.rpm /var/lib/YaST2/you/update/SLES-CORE/10/rpms/i586/kernel-source-2.13.25-i586.rpm /var/lib/YaST2/you/update/SLES-CORE/10/rpms/i586/kernel-um-nongpl-2.13.25-i586.rpm /var/lib/YaST2/you/update/SLES-CORE/10/rpms/i586/hallo-package-2.13.25-i586.rpm /var/lib/YaST2/you/update/SLES-CORE/10/rpms/i586/kernel-default-debuginfo-2.13.25-i586.rpm /var/lib/YaST2/you/update/SLES-CORE/10/rpms/i586/kernel-um-2.13.25-i586.rpm /var/lib/YaST2/you/update/SLES-CORE/10/rpms/i586/kernel-default-debuginfo-999999.13.25-i586.rpm
Created attachment 92625 [details] y2log y2log: first test with old kernel-update.ycp, second test with new version
Created attachment 92626 [details] kernel-update.ycp
Yesterday I tested with "old" kernel-update.ycp. During installation there were errors messages from kernel-update-tool saying: Kernel package kernel-default-2.6.5-7.244 is not installed (see y2log). I have kernel-update-tool-0.9-20.1 installed. But this seems not to be the newest version. Where can I get it?
Created attachment 92627 [details] y2log y2log from testing on SLES9
Gabi, thanks for fixing my minor bugs with the attachment in comment 36. The installation order makes sense as far as I can see, so I hope this all works as intended now. The kernel-default-2.6.5-7.244 problem was an issue in the kernel-update-tool package, and I added a quick hack for testing to a previous version of kernel-update.ycp. That hack is now gone, and /work/src/done/SLES9-SP4/kernel-update-tool has a fix for this problem. Why doesn't /usr/sbin/kernel-update-tool exist on that machine? Can we run a test tomorrow, build update packages etc., and then have Heiko test this as well?
I run the test with the testfile you_update_arguments only starting 'y2base kernel-update.ycp ncurses' (with a modified kernel-update.ycp which doesn't stop on errors). So I can test different combinations very quickly. I have also a SLES9 installed and a YOU update source where I can provide patches for real testing. I am at the office on Monday, Tuesday and Wednesday. We can run the tests today.
The 'UpdateScript' patch for yast2-packagemanager (updatescript.diff and updatescript-fix.diff from /work/src/done/SLES9-SP4/yast2-packagemanager) is applied and checked in to YaST2 CVS 'SuSE-Linux-9_1-Branch'. cschum@suse.de and me have reviewed the code and I have tested to use the new tag 'UpdateScript'. There should be also tests with existing tags 'PreScript' and 'PostScript', usual update, etc. I have submitted yast2-packagemanager-2.9.69 to /work/src/done/SLES9. The new version is 2.9.69 because there is already a version 2.6.68 in CVS. There is a little confusion about the released versions of yast2-packagemanager. As far as I can see on /mounts/mirror/SuSE/support.suse.de/i386/update/SUSE-CORE/9/patches patch-10614 contains yast2-packagemanager-2.9.67 but the changelog is from 2.9.68 (see also /work/SRC/old-versions/9.1/SLES/all/yast2-packagemanager: changes-File from 2.6.68, tar-file is 2.9.67). Therefore the changes for 2.6.68 should be tested, too.
I have tested with new kernel-update-tool from /work/src/done/SLES9-SP4/kernel-update-tool and new kernel-update.ycp: My test case was test scenario from comment #30, except the kernel-smp-nongpl package (not available for SLES9): kernel-default-2.6.5-7.244 installed and running, additionally installed: kernel-smp-2.6.5-7.244 kernel-source-2.6.5-7.244 kernel-syms-2.6.5-7.244 novell-kmp-2.6.5-7.244 The installation order is like expected (see comment #30). But I think there is a problem with two kernels installed: the last installed wins. The result of this update is that kernel-default-2.6.5-7.244 is updated to kernel-smp-2.6.5-7.253. This problem also existed with previous used script install-kernel-rpms.sh. We could add code to kernel-update.ycp to avoid this (install running kernel at last).
Created attachment 93158 [details] y2log
In addition to test result from recent test (comment #42): some time during the installation procedure the novell-kmp-2.6.5-7.244 is updated to novell-kmp-2.6.5-7.253 but after the script is finished the novell-kmp package isn't installed any longer. I don't know when it's deleted or if this is intended. I am setting the resolution of this bug to FIXED, the script kernel-update.ycp works like expected. The whole scenario of kernel updates will be re-tested.
released