https://bugzilla.novell.com/show_bug.cgi?id=309837#c1 --- Comment #1 from Stephan Kulow 2007-09-12 06:52:04 MST --- I believe #300935 is basically the same problem just less severe as the default kernel boots. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c3 --- Comment #3 from Stephan Kulow 2007-09-12 09:22:07 MST --- huh? the main problem is the (hda7) in there and the XEN kernel line. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c5 Stephan Kulow changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|coolo@novell.com | --- Comment #5 from Stephan Kulow 2007-09-12 10:15:49 MST --- the update was done booting from a CD the solver only found a solution with two kernels, the -default one was picked by yast as default and the -bigsmp was picked to satisfy the dependencies of a kernel module that only exists for bigsmp, but satisfy the thinkpad modinfo. Ludwig and Schubi looked at the log files and the case with the two kernels should be an artefact, but that can also happen with a normal install and some build service repositories. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c7 --- Comment #7 from Olaf Dabrunz 2007-09-12 12:43:36 MST --- Thanks for the comments, this helps. I should add this to the list of things that are strange here: - the old entries for openSUSE 10.2 still exist. These should have been removed when the 10.2 kernel was updated to the 10.3 kernel. The current bootloader_entry script in 10.2 still contains a bug that prevents the entry from being removed, here is the patch to fix it: ------------------------------------------------------------------ function update_bootloader() { - [ -x /sbin/update-bootloader -a "$YAST_IS_RUNNING" != instsys ] || return 0 + [ -x /sbin/update-bootloader ] || return 0 /sbin/update-bootloader "$@" } ------------------------------------------------------------------ Unfortunately, also the upcoming perl-Bootloader patch for 10.2 still contains this bug (/work/built/patchinfo/510e090e5ef9cf0d15b43f08a8242b20). One problem down, but needs to be submitted for 10.2. Next: I understand what happened this far: - I only have the standalone logs from perl-Bootloader for the last kernel kernel added (2.6.22.5-10-bigsmp). The reason is that the update-bootloader script removes the standalone log before adding a new entry (AFAICR, in an attempt not to confuse the logs of different actions, because no timestamps are recorded with the log entries). The new version of perl-Bootloader that I submitted today adds pseudo-timestamp and deletes the logfile-removal code. - The bigsmp kernel is added after the default kernel during the 10.3-update, that is the reason for it having the "Original name" "linux". So that is OK. Conclusion: the crucial logs from the update of the "default" kernel (with the broken "(/dev/hda5)") are still missing. They will only be kept when we re-test with the version of perl-Bootloader that I submitted today. Should I test myself (run createrepo and create an extra instsource with the fresh perl-Bootloader, and hope it will be installed before the kernel during the update), or should I wait for a new 10.3 build that contains perl-Bootloader-0.4.24? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c9 --- Comment #9 from Stephan Kulow 2007-09-12 13:00:29 MST --- ok, I did a fresh install with two kernels selected and there I only get the default kernel added. That's maybe a bug in itself, but I had hoped it would make it easier to reproduce this bug. Damn :) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c11 --- Comment #11 from Olaf Dabrunz 2007-09-12 21:44:23 MST --- Looks like a conversion from /dev/hda -> /dev/sda which is not reflected somewhere. An immediate candidate is bootloader/routines/lilolike.ycp:794: according to the logs it does not convert correctly and looks broken (disabled by a typo). But I have not really traced the problem to this code, so there may be other places where this does not work. IOW, we still need a test with the new perl-Bootloader. Fixed lilolike.ycp, rest tomorrow. Fix is in yast2-bootloader-2.15.20.rpm. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c13 Stephan Kulow changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bwalle@novell.com --- Comment #13 from Stephan Kulow 2007-09-13 02:50:18 MST --- ok, my theory so far is: the %post of kernel-default and kernel-bigsmp both play around with the 10.2 bootloader config, which can't be reliable converted due to libata migration (#308984) and then later yast-bootloader has a very hard time figuring what's user config and what is messed up update config. In today's build (without 2.15.20, but with 0.4.24) there are no more two kernels automatically pulled in, but I test an update with two kernels anyway. Let's see what happens after the fix for #308984 was checked in. My hopes are high. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c15 Stephan Kulow changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #163538|0 |1 is obsolete| | --- Comment #15 from Stephan Kulow 2007-09-13 03:33:40 MST --- Created an attachment (id=163802) --> (https://bugzilla.novell.com/attachment.cgi?id=163802) yast logs + menu.lst (build 1012) Same problem - more verbose logs -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c17 --- Comment #17 from Stephan Kulow 2007-09-13 05:40:02 MST --- The XEN entry seems to be invented by yast-bootloader, but I'm afraid the broken 10.2 entry is really from the kernel. So run_bootloader in kernel's post.sh should check for YAST_IS_RUNNING != instsys. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c19 --- Comment #19 from Stephan Kulow 2007-09-13 12:19:33 MST --- ok, with one kernel the same problem exists also with 2.15.20. So the bug is very generic for the update case - but I'm not suprised as the bug is in the post of the kernel calling perl bootloader, so the yast bootloader would have to merge the sections - which sounds hard to do. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c21 Torsten Duwe changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mfrueh@novell.com --- Comment #21 from Torsten Duwe 2007-09-14 05:06:10 MST --- *** Bug 308224 has been marked as a duplicate of this bug. *** https://bugzilla.novell.com/show_bug.cgi?id=308224 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c23 Torsten Duwe changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msvec@novell.com --- Comment #23 from Torsten Duwe 2007-09-14 05:13:31 MST --- *** Bug 309437 has been marked as a duplicate of this bug. *** https://bugzilla.novell.com/show_bug.cgi?id=309437 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c25 Torsten Duwe changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gp@novell.com --- Comment #25 from Torsten Duwe 2007-09-14 05:15:15 MST --- *** Bug 299614 has been marked as a duplicate of this bug. *** https://bugzilla.novell.com/show_bug.cgi?id=299614 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c27 --- Comment #27 from Torsten Duwe 2007-09-14 05:24:29 MST --- *** Bug 307137 has been marked as a duplicate of this bug. *** https://bugzilla.novell.com/show_bug.cgi?id=307137 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c29 --- Comment #29 from Torsten Duwe 2007-09-14 05:29:24 MST --- This is a rather complex issue with various symptoms, so I marked all similar issues as dups. We'll use this bug to track them. If this bug is fixed and your "duplicate" is not, feel free to reopen, but please not earlier. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c30 Stephan Kulow changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |asvetter@cip.physik.uni-wuerzburg.de --- Comment #30 from Stephan Kulow 2007-09-14 07:22:52 MST --- *** Bug 310588 has been marked as a duplicate of this bug. *** https://bugzilla.novell.com/show_bug.cgi?id=310588 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c32 --- Comment #32 from Torsten Duwe 2007-09-14 09:14:11 MST --- *** Bug 249873 has been marked as a duplicate of this bug. *** https://bugzilla.novell.com/show_bug.cgi?id=249873 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c34 --- Comment #34 from Olaf Dabrunz 2007-09-14 12:48:19 MST --- This comment addresses the problems of the wrong device names and the wrong default section. coolo@, your theory is correct. In short, perl-Bootloader expects a fairly consistent view of the system for the information it needs. This includes that /etc/fstab, /boot/grub/device.map and the output of udevinfo all present a consistent view to perl-Bootloader. But we have the libata migration, and some parts of the system already use the information about the new devices (udevinfo, because we have bind-mounted the devices from the inst-sys which runs the new kernel), other parts will only be migrated to the new device names at the end of the installation (including /etc/fstab and /boot/grub/device.map). Possible solutions: We can either solve this by correcting the information in the system early during the update or by updating the bootloader configuration late (in yast2-bootloader, as we did before). 1) Some suggestions have been made to correct the information in the system early, such as: a.1) Moving(/copying/calling) the libata migration code of yast2-storage and yast2-bootloader into some yast client that runs directly before package installation starts (e.g. packager/src/clients/inst_kickoff.ycp). - This requires that this code does not need a consistent system view itself. AFAICS it may just work in this case, as we mainly need to know the version of the system before the update and the version of the system after the update to find the correct pre-configured mapping of device names for this case. Anyhow the code needs to be adapted to this special case, so that e.g. the device.map libata migration code does not try to find the BIOS device for that device, because then at least an up-to-date yast2-storage, libstorage, hwinfo, a working /sys tree and who knows what (e.g. evms-to-BIOS-device mapper?) are required in the target system. a.2) Porting/re-implementing the libata migration code of yast2-storage and yast2-bootloader in some script that can be called from pre-/post-install code that needs it, and from YaST. - Same requirements as in a.1). b) Using callbacks into YaST-code, e.g. from pre-/post-install scripts, to make the parts of the system consistent that are required to run the rest of the code in the pre-/post-install scripts. - This requires that routines in the running YaST are callable from the outside, specifically from code running on the target system. ATM, this is not designed or implemented. - Callback code needs to be written. c) Calling pre-/post-install hooks from yast2-installation: YaST modules could then register pre-/post-install handlers for specific packages with yast2-installation, and set up a consistent system view as required by these packages. - This requires support for these hooks from yast2-installation. ATM, this is not designed or implemented. - Callback code needs to be written. All these approaches require that - packages required to execute the pre-/post-install scripts are known and specified as dependencies in the to-be-installed package and - the steps to have a running environment for each of these packages are known and it is clear how to set this up in the target system (e.g. for hwinfo have a /sys file system mounted (at the adequate place) in the target system). Altogether, these approaches add several requirements to YaST, packaging, maintaining special code and variants of existing code, etc. And these concepts and methods are not even tried and tested, conceptually simple or known to work. These are new concepts and new features, so I do not see how we can fix the problem in this way for 10.3. I have been asked before what problems I would see when the post-installation of the kernel executes perl-Bootloader during an update. Unfortunately, as I do not have documentation myself to refer to *), my answer was rather incomplete: "I would really not do this, as I do not know which things do not work during installation or update." and "The system configuration is not consistent during package installation or update." **) Please take this as a more complete answer. *) We really need more documentation about workflows, information flows and implementation. Otherwise we keep forgetting things ourselves. This is really something we need to put more time into, but this unfortunately has not been possible so far. Big Problem (TM), it would save us a lot of work and at least half of the mess. **) As far as YaST is concerned, the system configuration state during package installation was not expected to be consistent. Rather, YaST needed to assume that the system configuration would only stabilize when package installation was finished (and this is currently the policy of YaST). This was especially true during the time when files were moved between packages, dependencies changed and lots of code in YaST, in package pre-/post-installation scripts, system rc scripts, hwinfo, HAL and the like was changing quickly, dramatically and at the same time. Maybe today the situation is somewhat more stable, and we can actually start to rely on interdependencies during the package installation workflow. If this is the case, we have a chance to introduce and document some sort of installation staging, so each package knows roughly when it is installed and what state of the system it can expect and rely on. Also, during the first years the YaST license did not allow others to reuse YaST or YaST code. That seems to be one of the reasons why YaST was not called back from package installation scripts: this would tie the installation of these packages too tightly to the SUSE-owned YaST. But now that YaST is Open Source, it may be possible to integrate it better with package installation scripts in one or the other way. AFAIK, making YaST code callable from the outside is actually a wanted feature. If we can go in that direction, we could make it possible to do such things like concentrating section removal and creation code in perl-Bootloader (which would actually help maintainability). 2) Updating the bootloader configuration late (in yast2-bootloader, as we did before). This means that we do not call perl-Bootloader (bootloader_entry, update-bootloader) from the postinstall-script during an installation or update any more, but let yast2-bootloader adjust the configuration. The only problem here is that we now loose the information about the previous default kernel flavour, because the section for the old (oS 10.2) kernel will be deleted by the postuninstall script of the old kernel (which is OK, this can always be done without real problems). To keep this information, we need perl-Bootloader to save the default flavour somewhere, so yast-bootloader can try to make the same flavour of kernel the default when it needs to make that decision. I would suggest to introduce a new comment into menu.lst: ### YaST: default kernel flavour: bigsmp ### perl-Bootloader would save this comment whenever it removes a default section. yast2-bootloader would use this comment during an update only, and fall back to a builtin list as in: if it exists use "bigsmp", otherwise "default". This requires some changes in perl-Bootloader and in yast2-bootloader. I believe this should not be difficult and it could be finished in a few days (with the help of aosthof@ from Monday). So I believe solution 2 is what we need to do. duwe@ and sf@ have acked this. Implementing... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c36 Olaf Dabrunz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #36 from Olaf Dabrunz 2007-09-18 02:57:19 MST --- Fixes are in yast2-bootloader-2.15.22.rpm perl-Bootloader-0.4.27.rpm kernel-*-2.6.22.5-21.src.rpm The device name conversion works. Still testing setting the default section, but looks ok. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c38 Olaf Dabrunz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #38 from Olaf Dabrunz 2007-09-19 08:54:18 MST --- Reopening, because sometimes still the old sections of 10.2 are not removed (and remain the default). We were able to reproduce this problem once again ourselves. On the basis of our additional logging there and more code analysis we now have the theory that sometimes the /sys filesystem may be available to perl-Bootloader, while sometimes it is not. We need at least one more reproduction with even more logging that we implemented now (not yet packaged). Our second attempt at reproducing this failed (the update finished successfully, old sections were removed). Probably this requires some special previous system setup. Trying to reproduce on the basis of coolo@'s 10.2 system backup. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c39 Andreas Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aj@novell.com --- Comment #39 from Andreas Jaeger 2007-09-19 12:18:55 MST --- I hit the bug while updating my 10.2 test machine to 10.3 as well. If you need access to the machine, please tell me soon - otherwise I use it for further tests. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c41 Andreas Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jgrant@novell.com --- Comment #41 from Andreas Jaeger 2007-09-19 12:33:52 MST --- *** Bug 326466 has been marked as a duplicate of this bug. *** https://bugzilla.novell.com/show_bug.cgi?id=326466 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c43 Olaf Dabrunz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #43 from Olaf Dabrunz 2007-09-21 08:23:53 MST --- After still more additions to logging, we have found the root cause for the removal problem: the removal code in perl-Bootloader fails because of the libata migration. The code tries to find the correct sections to remove by matching the pathes of the kernel and initrd files against the sections. To do this, it tries to resolve the GRUB device in a section to a Unix device and then to a mountpoint in /etc/fstab. It would then prepend the found mountpoint to the pathes of the kernel and initrd in the section. But as the information in both device.map and fstab are still not libata migrated, while the information in /dev and udevinfo is, finding a mountpoint for the GRUB device fails. The fix is to delay the execution of bootloader_entry and call it with the saved parameters from yast2-bootloader. Fixes are in yast2-bootloader-2.15.25.rpm perl-Bootloader-0.4.30.rpm -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=309837#c45 joerg reisenweber changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #45 from joerg reisenweber 2007-10-03 20:14:07 MST --- #44: Bug 330606 sorry i can't tell which versions were installed via net install bootCD from factory at 2007-09-29. So it's 8 days after patch of #43, i reopen the bug. jOERG -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.