August 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 120340] Run download and install in parallel
by fate_noreply＠suse.de 05 Aug '09

05 Aug '09

Feature changed by: Jörn Knie-von Allmen (Phisiker) Feature #120340, revision 97 Title: Run download and install in parallel openSUSE-10.2: Rejected by Klaus Kämpf (kwk) reject date: 2006-08-09 11:36:10 reject reason: Not possible in 10.2 timeframe Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-08-01 10:25:01 reject reason: Out of time. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Jiri Srain (jsrain) reject date: 2008-03-28 13:56:11 reject reason: Out of resources for 11.0. Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 12:06:35 reject reason: This needs to wait. Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:43:03 reject reason: No resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Klaus Kämpf (kwk) Requested by: Peter Poeml (poeml) Requested by: Reinhard Max (rmax) Description: Network installation could be improved by running package download and package installation in parallel. References: https://bugzilla.novell.com/show_bug.cgi?id=60844 https://bugzilla.novell.com/show_bug.cgi?id=209799 https://bugzilla.novell.com/show_bug.cgi?id=128050 https://bugzilla.novell.com/show_bug.cgi?id=370457 https://bugzilla.novell.com/show_bug.cgi?id=370054 https://bugzilla.novell.com/show_bug.cgi?id=385711 http://en.opensuse.org/Libzypp/Failover http://metalinker.org/ Fate #300660: Download package groups before install Discussion: #2: Klaus Kämpf (kwk) (2006-08-09 11:36:42) Michael already looked at this. Should be further evaluated for 10.3 #3: Edith Parzefall (emapedl) (2007-07-31 16:56:12) Problem is: what do we do if we lost the network connection when only half the packages are installed? #7: Reinhard Max (rmax) (2008-04-10 11:42:43) (reply to #3) I think this is a general problem for network based installations. Can you elaborate if/why you see this as a special problem when download and installation are running in parallel? #8: Peter Poeml (poeml) (2008-05-19 14:49:53) (reply to #7) For reliable operation of a business critical server, it is a must that packages are downloaded first, before the installation/update is started. Otherwise a network outage can lead to a broken system which is half updated. So if parallel download/install is implemented (for desktop users, maybe...) then please make sure that it is possible to disable it. #9: Reinhard Max (rmax) (2008-05-19 16:01:15) (reply to #8) As we just sorted out on IRC, the current implementation also doesn't allow to complete download before starting installation and the feature proposed here wouldn't make this worse. But as the wish of server admins to have all packages downloaded before starting to install them is very valid, I think we should extend this feature request to contain that requirement as well, and probably rename it to "decouple download and installation". If download and installation are properly decoupled, it should just be a matter of the parameters the algorithm is called with to get one of the following behaviours: * Download and install packages one by one (as it is now) * Keep downloading subsequent packages while installing (as originally proposed here) * Use a fixed-size download cache for flow control between download an installations (in situations where download is faster than installation and disk space is limited) * Download all packages of an update or installation and install them afterwards (as requested by Peter for server admins) #10: Jiri Srain (jsrain) (2008-05-20 10:22:10) (reply to #9) We already do have similar feature: #300660: Download package groups before install #4: Edith Parzefall (emapedl) (2007-07-31 16:57:22) Please reject for 10.3. #5: Duncan Mac-Vicar (dmacvicar) (2008-01-10 16:23:46) This is included in the ZYpp plan for 11.0, however implementation will start after beta. Will keep in evaluation, it depends on other milestones for beta1 #14: Chris Hills (chaz6) (2009-02-16 16:42:06) Is there a feature request to install using both the base and updates repo so that the latest packages available at install-time are used, thus saving bandwidth? #15: Jiri Srain (jsrain) (2009-02-17 08:45:38) (reply to #14) This is how it works for quite some time. Repositories providing patches also provide the packages so that they can be installed directly from the update repositories (provided they contain newer version). #16: Duncan Mac-Vicar (dmacvicar) (2009-06-02 15:18:00) For 11.2 we will focus on flexibility of the download and install order (like installing after everything is downloaded), however parallel stuff should be done after we have this in place. Please reject. + #20: Jörn Knie-von Allmen (phisiker) (2009-08-05 12:12:29) (reply to + #16) + Please do not reject. With a downloadprotocol this should be solvable. The + Installtask can poll an that protocol (or be informed by a Signal when + a download has ended. This is better then polling. Or if prefering an + IPC-Framework: D-BUS. Never mind!). Such problems I had some times + often to solve (but in Java) and generally, it isn't so dificult. #17: Michal Papis (mpapis) (2009-07-04 20:58:23) I think great example here may be Gentoo, there You can chose the way of getting packages, by default download and installation go in paraler, but it is possible to get first sources and then run build/installation. If you are on the default and something breaks, ex. network, Yuo can always resume the last download&installation task. #18: Giuseppe Salinaro (superpeppo89) (2009-07-16 19:37:27) (reply to #17) This idea of gentoo is good... #19: Ján Kupec (jkupec) (2009-07-20 10:59:31) (reply to #18) Guys, as Duncan wrote in c#16, we are already developing the "download all, install all" mode (currently we only have "download one, install one, ..."), and yes, users will be able to choose one of these. This particular feature would be an improvement of the current mode: "download one, install one while downloading others, ...". I hope this clarifies the current status a bit. -- openSUSE Feature: https://features.opensuse.org/120340

1 0

[openFATE 307175] Yast2 integrated in kde system config
by fate_noreply＠suse.de 05 Aug '09

05 Aug '09

Feature added by: fsk aio (fasiko) Feature #307175, revision 1 Title: Yast2 integrated in kde system config openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: fsk aio (fasiko) Description: Integrated YaST2 into kde system config for easily newbie . Example: image url (http://www.fasiko.es/yast-control-center.jpg) -- openSUSE Feature: https://features.opensuse.org/307175

1 2

[openFATE 305553] zypper: dist upgrade could error out if more than one repository with a base product exists
by fate_noreply＠suse.de 04 Aug '09

04 Aug '09

Feature changed by: Marcus Meissner (msmeissn) Feature #305553, revision 24 Title: zypper: dist upgrade could error out if more than one repository with a base product exists openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. #10: Ján Kupec (jkupec) (2009-06-24 09:33:26) Michael, is this still relevant? Is this related to the planned --from option? #11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10) This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled. #12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11) So multiple repositories are not a problem in general, but multiple repos for different products are! OK, so now back to the solution: can you tell me or point me to some info abou these CPEs Duncan mentions in c#6? I guess they are part of the product solvable and are available as solv attribute? If so, all that's needed is to check whether there are multiple repos with a different product and write a warning if that's the case, right? #13: Michael Schröder (mlschroe) (2009-07-07 16:34:14) (reply to #12) ma, is there a libzypp interface? #14: Michael Andres (mlandres) (2009-07-13 14:16:11) (reply to #13) Yes. Since you can ask for a products CPEid, or for the CPEids related to a repository (supported or updated products). But I don't know if those CPEids are meanwhile included in the metadata (see bnc #459527). #15: Ján Kupec (jkupec) (2009-07-14 18:17:17) (reply to #14) OK, so this should not be too much work. So to sum it up: * zypper: show a warning in 'dup' if there are multiple base repos with different CPEids enabled. * metadata: check/include the CPEid in product metadata (who should do this?) #16: Ján Kupec (jkupec) (2009-07-27 17:30:09) (reply to #14) Rudi, please look at c#14 and 15 #17: Ján Kupec (jkupec) (2009-07-29 19:04:40) Current status: * TODO: put CPE IDs to content/prodcuts.xml metadata (still nobody assigned to do this!) * TODO: satsolver will need to parse the above (or is this ready already?) * PROBLEM: we need to figure out which repos don't go together for dup. I proposed to compare CPEs of 'base' or 'platform' repos, but we have no 'isBase' flag in product or repo metadata. Simply checking for different CPEs is not enough (think of one base product and one addon - two different CPEs, but 'dup' is OK with them). * PROBLEM: even if we'll have the 'isBase' flag, we'll be stuck in case of two different, but compatible bases, like e.g. SLES and SLED could be used standalone or with SLED as an add-on to SLES in the past. Do we still allow this? Any ideas? #18: Ruediger Oertel (oertel) (2009-07-30 17:20:05) adding more data (like the CPE-ids) is not a big issue. the problem for me is rather how to obtain a CPE-id + #19: Marcus Meissner (msmeissn) (2009-08-04 17:55:08) + CPE ids can be defined by the vendor as I udnerstand ;) + I mailed Jan and Rudi. + my suggestions would be: cpe:/o:opensuse:opensuse:11.1 + cpe:/o:novell:suse_linux_enterprise:11:ga:server cpe:/o:novell: + suse_linux_enterprise:10:sp2:desktop -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 04 Aug '09

04 Aug '09

Feature changed by: Ralph Ulrich (ulenrich) Feature #305634, revision 129 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Candidate Priority Requester: Mandatory Projectmanager: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Relations: - Fedora Upgrade Instructions (feature/id: http://fedoraproject.org/wiki/YumUpgradeFaq) - Wiki page for implementation (url: http://en.opensuse.org/Upgrade/11.2) - Debian Upgrade How-to (url: http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.ht…) Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) There were a number of different forum poster's hitting it, just after 11.1 released (I think due to zypper dup not YaST upgrade and therefore unreported to BugZilla). It is not something I had, because I did fresh installs. Interestingly though I have used Debian less, I have done several dist-upgrade's, simply because it is expected to work well. So it is a mistake to focus on specific tech issues alone. This problem is also about expectations and user perceptions. Announcing "support" for dist upgrade and appealing for test, so work rounds can be found, for release notes at time matters to. #21: Cristian Rodríguez (elvigia) (2009-02-02 15:29:32) (reply to #19) as you failed to elaborate on the problem, I will.. Some people end with broken /etc/pam.d/login they have the following line session required pam_resmgr.so but that module is gone, and rpm upgrade does not remove that line (probably because that file has been modified) #24: JP Rosevear (jproseve) (2009-02-02 10:15:19) (reply to #21) Isn't that simply a packaging problem? #25: Klaus Kämpf (kwk) (2009-02-02 19:42:45) (reply to #24) In this case, it looks like a packaging problem, indeed. However, we had more complicated upgrade tasks in the past, like dropping devs.rpm and running udev instead. See Removing devs.rpm (http://en.opensuse.org/Software_Management/Upgrade/Devs_Rpm) for a discussion of the problem. #30: Peter Poeml (poeml) (2009-03-10 15:31:10) (reply to #25) Interesting discussion about that particular issue, but simple to solve. What works is keeping devs.rpm, and/or simply rpm -e --justdb it. (It's enough to do so later.) The more complicated issues in the past where a case where the kernel changed its major version, and some networking applications could not start with the (still running) old kernel. Didn't prevent an online upgrade over the network though, and applications could keep running. When skipping several openSUSE versions, and differences have accumulated, in can happen that an upgrade in one step is not possible. It's not possible to upgrade from 9.0 to 10.1 without first updating to 9.1, due to the kernel. These issues are quickly found by experimentation though. Other than that, the most hurting issue during remote upgrades is the difficulty to ensure persistent device naming for NICs, because that is reimplemented / changed with each openSUSE version, the upgrade procedure is not well documented, and funny surprises are the rule, and it often simply doesn't work. Other small hurdles are the increasing modularization of kernel, which can lead to lack of support for chipsets and storage in the initrd, package split-offs (mingetty) that lead to lack of essential components after the upgrade. It pays to make sure that all packages are installed which are in the "minimal" patter of that openSUSE version. And the required but disappeared PAM module locked us out once also... A word to all the non-believers who think that upgrades don't work: I have upgraded dozens of systems remotely during the last decade. All my productive systems are repeatedly upgraded that way since day one. Unfortunately, the tools we have didn't help with this. Apart from using rpm, I started doing this with yum a few years ago (if it works, metadata is available, falling back to rpm if needed). Last year I documented some steps: http://poeml.de/~poeml/10.1-11.0-update/update-11.0.howto. With today's conveniency of virtualization at hand, I actually did an upgrade by experiment with a VM first, to minimize the risk, and documented all the steps. Since I had to upgrade several 10.1 machines, this seemed like a good idea to reduce the risk and save brain energy. The notes from it are a good outcome, too. #26: Klaus Kämpf (kwk) (2009-02-02 19:43:24) (reply to #21) Whats the bug number for this problem ? #20: Robert Davies (robopensuse) (2009-02-02 14:48:34) On Scope, here are the Release Notes for Lenny - http://www.uk.debian.org/releases/testing/amd64/release-notes/ 4.1.4 - Prepare a safe environment for the upgrade - text mode or via ssh login, Article on how to go from Etch to Lenny - http://www.debianadmin.com/howto-upgrade-from-debian-etch-40-to-lenny-50.ht… #27: Federico Lucifredi (flucifredi) (2009-02-04 15:32:01) (reply to #20) this is very helpful, we should look at the bumps that Debian hits while doing this. On a separate note, just tried to "yum upgrade" frlom RHEL 5.2 to RHEL 5.3, and it went without a hitch. There may be something to be gathered from Fedora as well here. #22: Manuel Trujillo (toomany) (2009-02-02 15:44:44) I think this is a really helpful characteristic, because a lot of people like me, use openSUSE as server, and is a true hell to upgrade servers in any datacenter, at kilometers off distance. I hope this feature will be a reallity in the next 11.2. #23: Duncan Mac-Vicar (dmacvicar) (2009-02-02 15:46:27) (reply to #22) Please, if you just want to express your favorites, use the voting feature. Comments is for discussion around solving the problem itself. #28: Javier Llorente (javierllorente) (2009-03-10 14:08:21) Just a few comments... A few weeks ago, I upgraded one server from 11.0 to 11.1 via ssh using zypper dup. zypper and its related libraries have to be upgraded first in order to avoid problems, especially if the upgrade process is interrupted. Another issue besides the order of the upgrade, would be restarting daemons and dealing with new .conf. Maybe we could check if it has been edited, if not, then automerge it. Some stuff could malfunction due to old config files. We could also have a manual merge option. Another thing... wouldn't it be better to download all the packages at once and install them afterwards instead of downloading/installing package by package? On a side note, I want to say that my upgrade went smoothly (rcpbind wasn't installed but I consider that a small issue). zypper has been improved a lot. It would be great if zypper dup was officially supported as another upgrade method. #29: Peter Poeml (poeml) (2009-03-10 14:35:19) (reply to #28) Regarding config merge on update, I have played with two things. First, the yum plugin called yum-merge-conf, which allows for interactive merging of config files during the upgrade. Works and gets the job done, and could be done in zypper as well, however from my own experience I have to say that it protracts the update more than I sometimes like, and I typically want to do this job in a separate step (after the packages are updated). not protract the update for merging all files. So I rather use another approach, which is a script called rpmresolve (https://build.opensuse.org/package/view_file?file=rpmresolve&package=server… 3Apoeml), which works in a similar way, based on presence of rpmsave/rpmnew files. It opens vim in diff mode, lets you merge and asks you which version you want to keep. Works well for me since years, it just might require refinement of some things of the implementation in a more generic way (e.g. calling $EDITOR with different option than - d). #31: andrea florio (anubisg1) (2009-07-10 00:11:07) i think that we miss something like that: https://help.ubuntu.com/community/JauntyUpgrades it's so easy to upgrade an ubuntu version that also my 5 years old student was able to do it.. + #32: Ralph Ulrich (ulenrich) (2009-08-04 16:14:39) + I just did a distribution upgrade from 11.1 to 11.2 factory using + "zypper dup". I did uninstall a lot before to have less problems. + After upgrade there were some repository problems, like I was not able + to see opera any more. I remove all of /var/cache/zypp/raw/* after + which I could install opera. Seems to be some work left on zypper to be + able to dist-upgrade .... -- openSUSE Feature: https://features.opensuse.org/305634

1 0

[openFATE 306411] Configuration files merge
by fate_noreply＠suse.de 04 Aug '09

04 Aug '09

Feature changed by: Elmar Stellnberger ATK (estellnb) Feature #306411, revision 14 Title: Configuration files merge openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Michal Hrusecky (-miska-) Description: If we want to make our distribution friendly even to advanced users, I think that we shouldn't touch users configuration files. Luckily this isn't problem as in spec file Ican state that this file is configuration and I don't want to replace it if user did some manual changes. Or I can say that I want to replace it and keep backup of original one. But what I'm missing is some tool to easily merge these files. In Gentoo there is etc-update (http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=4#doc_…) or dispatch-conf (http://en.gentoo-wiki.com/wiki/Dispatch-conf) . I'll describe more precisely what feature I'm missing and why I think it's needed. Let's say that I've got some package and there was quite big change in package default configuration file which will affect most of the users. On the other hand users can have pretty complicated constructions in their configuration files and if they did something like that, it's quite possible that they don't need to update their configuration file. So it is needed to tell users that if they are experiencing problems it is most likely because they touched default configuration. I can take care of it manually, mention it in various README and such, but more easier way would be following. User installs some packages. At the end of zypper or yast installation there will be warning "You've got 42 configuration files to merge, please run etc-update/dispatch-conf/whatever". Then user will run some easy interactive tool which will state which configuration files can use some manual merging, it will allow user to see difference between them and let him choose which one he wants or let him merge them manually somehow. Same warning about unmerged configuration files should appear each time user installs something, no matter if this installation didn't add any conflict, until all conflicts are fixed. User will be warned about possible problems, hacker can play with it and keep his changes against distribution defaults and ordinary user will just click on "use distribution default for all" if he ever encounter such a problem (shouldn't happen as ordinary user wouldn't touch configuration files). I explained basic expected work flow, so now what I think should be supported: * detect configuration files, their conflicts and allow their merge - this shouldn't be a big problem as rpm already stores conflicting files as .rpmnew/.rpmold * we probably want to keep even old versions to support three way merge to achieve even better results * if we are already storing these configuration files, maybe we should let users to backup their own changes as well, add support for versioning these configuration files * warn user that he has conflicts in configuration files - will require a little bit yast/zypper integration * merging tool should support both console and graphical interface (maybe use yast as possible frontend) * support for various formats (expandable by plugins) - ordinary diff may not be the best tool for merging XML files or ini files * ordinary user who don't change anything shouldn't need to know about this tool Relations: - Debian-like dist-upgrade live system full version upgrade (feature/id: 305634) Discussion: #1: Michal Hrusecky (-miska-) (2009-06-02 09:49:38) I was thinking about this a little bit more and if we want to support some kind of versioning and we want to use plugins for getting differences, it may be a good idea to request that plugins will be capable not only of producing nice output of difference between configuration files, but it probably should be able to apply it (behave not only as a 'diff', but also as a 'patch'). And we can build some simple version control system on top of it. Advantages: * can handle non-plain text files better (via plugins) * we can implement feature to discard or merge several commits into one to save space/make commit log more readable * can handle nicelly even insane configuration files like sqlite database or compressed directory with configuration files or any other binary format Disadvantages: * probably worse handling of text files * another thing to maintain/possible source of bugs #2: Stephan Kulow (coolo) (2009-06-09 11:51:14) this sounds like a lot of work to do right and with little gain. We lived quite well for years without it and whatever tool you come up will create new problems, there won't be a perfect tool. Applications with very bizzare config format usually come with their own configuration update tool that can be called from %post So I would put very low imporance on this. #3: Andreas Jaeger (a_jaeger) (2009-06-09 14:20:14) (reply to #2) The question is what is really needed to do here. If we could take some scripts from Gentoo and those would work without changes - cool. If we would need to change each and every config file for this, I'm also for rejecting. So, for me it's not clear what the cost is. #4: Michal Hrusecky (-miska-) (2009-06-12 16:12:55) (reply to #3) Well, merging utility can be probably ported from Gentoo with few minor tweaks (although it would be console only utility) or it could be written from scratch (with possible features in mind). This shouldn't be a big problem (it will just take some time). In feature #305634 comment #19 there is even an example how to write such a simple utility. With current rpm workflow, I think there is no need for packages changes. Only thing that would need some adjustements for this feature to be fully functional is integration with yast/zypper so thay will print warning about possible conflicts. I wouldn't suggest to force people to solve, just printing that there are some and that they should solve them using this utility should be enough. So it will need just some hack/new feature in installation procedure - run a program and allow it to create some notification for user. This is probably related to feature #301175 (301175) #5: Michael Andres (mlandres) (2009-06-15 12:02:05) (reply to #3) Libzypp checks for changed configfiles, and if they differ the 'diff' output is written to /var/log/YaST2/ (I don't know if YaST still mails this to root). Notification is also /var/log/zypp/history, and AFAIK zypper displays some info as well. But it's not a big deal to have a more flexible consumer for this information. The easiest would be to check for the presence of a certain script (or a directory containing scripts), and if it exists invoke it with package names and configfiles as argument. Then you can install any handler you like. + #6: Elmar Stellnberger ATK (estellnb) (2009-08-04 11:48:04) + At Bug 506815, Comment #2 we have a more simple proposial simply + notifying the user about changes in configuration files and selecting + an appropriate .rpmnew/.rpmold strategy. This should be the first thing + to be implemented in this regard before we can move on to fancier + things like an interactive auto-diff&merge + (https://bugzilla.novell.com/show_bug.cgi?id=506815#c2). + I personally would not regard the gain as little since forgetting to re- + create config files can be very tedious especially if you forget about + it and especially if there are regular upgrades as for the buildservice + repos. -- openSUSE Feature: https://features.opensuse.org/306411

1 0

[openFATE 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 03 Aug '09

03 Aug '09

Feature changed by: Frank Sundermeyer (fsundermeyer) Feature #305634, revision 127 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Candidate Priority Requester: Mandatory Projectmanager: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Relations: - Fedora Upgrade Instructions (feature/id: http://fedoraproject.org/wiki/YumUpgradeFaq) + - Wiki page for implementation (url: http://en.opensuse.org/Upgrade/11.2) - Debian Upgrade How-to (url: http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.ht…) - - Wiki page for implementation (url: - http://en.opensuse.org/Upgrade/11.2) Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) There were a number of different forum poster's hitting it, just after 11.1 released (I think due to zypper dup not YaST upgrade and therefore unreported to BugZilla). It is not something I had, because I did fresh installs. Interestingly though I have used Debian less, I have done several dist-upgrade's, simply because it is expected to work well. So it is a mistake to focus on specific tech issues alone. This problem is also about expectations and user perceptions. Announcing "support" for dist upgrade and appealing for test, so work rounds can be found, for release notes at time matters to. #21: Cristian Rodríguez (elvigia) (2009-02-02 15:29:32) (reply to #19) as you failed to elaborate on the problem, I will.. Some people end with broken /etc/pam.d/login they have the following line session required pam_resmgr.so but that module is gone, and rpm upgrade does not remove that line (probably because that file has been modified) #24: JP Rosevear (jproseve) (2009-02-02 10:15:19) (reply to #21) Isn't that simply a packaging problem? #25: Klaus Kämpf (kwk) (2009-02-02 19:42:45) (reply to #24) In this case, it looks like a packaging problem, indeed. However, we had more complicated upgrade tasks in the past, like dropping devs.rpm and running udev instead. See Removing devs.rpm (http://en.opensuse.org/Software_Management/Upgrade/Devs_Rpm) for a discussion of the problem. #30: Peter Poeml (poeml) (2009-03-10 15:31:10) (reply to #25) Interesting discussion about that particular issue, but simple to solve. What works is keeping devs.rpm, and/or simply rpm -e --justdb it. (It's enough to do so later.) The more complicated issues in the past where a case where the kernel changed its major version, and some networking applications could not start with the (still running) old kernel. Didn't prevent an online upgrade over the network though, and applications could keep running. When skipping several openSUSE versions, and differences have accumulated, in can happen that an upgrade in one step is not possible. It's not possible to upgrade from 9.0 to 10.1 without first updating to 9.1, due to the kernel. These issues are quickly found by experimentation though. Other than that, the most hurting issue during remote upgrades is the difficulty to ensure persistent device naming for NICs, because that is reimplemented / changed with each openSUSE version, the upgrade procedure is not well documented, and funny surprises are the rule, and it often simply doesn't work. Other small hurdles are the increasing modularization of kernel, which can lead to lack of support for chipsets and storage in the initrd, package split-offs (mingetty) that lead to lack of essential components after the upgrade. It pays to make sure that all packages are installed which are in the "minimal" patter of that openSUSE version. And the required but disappeared PAM module locked us out once also... A word to all the non-believers who think that upgrades don't work: I have upgraded dozens of systems remotely during the last decade. All my productive systems are repeatedly upgraded that way since day one. Unfortunately, the tools we have didn't help with this. Apart from using rpm, I started doing this with yum a few years ago (if it works, metadata is available, falling back to rpm if needed). Last year I documented some steps: http://poeml.de/~poeml/10.1-11.0-update/update-11.0.howto. With today's conveniency of virtualization at hand, I actually did an upgrade by experiment with a VM first, to minimize the risk, and documented all the steps. Since I had to upgrade several 10.1 machines, this seemed like a good idea to reduce the risk and save brain energy. The notes from it are a good outcome, too. #26: Klaus Kämpf (kwk) (2009-02-02 19:43:24) (reply to #21) Whats the bug number for this problem ? #20: Robert Davies (robopensuse) (2009-02-02 14:48:34) On Scope, here are the Release Notes for Lenny - http://www.uk.debian.org/releases/testing/amd64/release-notes/ 4.1.4 - Prepare a safe environment for the upgrade - text mode or via ssh login, Article on how to go from Etch to Lenny - http://www.debianadmin.com/howto-upgrade-from-debian-etch-40-to-lenny-50.ht… #27: Federico Lucifredi (flucifredi) (2009-02-04 15:32:01) (reply to #20) this is very helpful, we should look at the bumps that Debian hits while doing this. On a separate note, just tried to "yum upgrade" frlom RHEL 5.2 to RHEL 5.3, and it went without a hitch. There may be something to be gathered from Fedora as well here. #22: Manuel Trujillo (toomany) (2009-02-02 15:44:44) I think this is a really helpful characteristic, because a lot of people like me, use openSUSE as server, and is a true hell to upgrade servers in any datacenter, at kilometers off distance. I hope this feature will be a reallity in the next 11.2. #23: Duncan Mac-Vicar (dmacvicar) (2009-02-02 15:46:27) (reply to #22) Please, if you just want to express your favorites, use the voting feature. Comments is for discussion around solving the problem itself. #28: Javier Llorente (javierllorente) (2009-03-10 14:08:21) Just a few comments... A few weeks ago, I upgraded one server from 11.0 to 11.1 via ssh using zypper dup. zypper and its related libraries have to be upgraded first in order to avoid problems, especially if the upgrade process is interrupted. Another issue besides the order of the upgrade, would be restarting daemons and dealing with new .conf. Maybe we could check if it has been edited, if not, then automerge it. Some stuff could malfunction due to old config files. We could also have a manual merge option. Another thing... wouldn't it be better to download all the packages at once and install them afterwards instead of downloading/installing package by package? On a side note, I want to say that my upgrade went smoothly (rcpbind wasn't installed but I consider that a small issue). zypper has been improved a lot. It would be great if zypper dup was officially supported as another upgrade method. #29: Peter Poeml (poeml) (2009-03-10 14:35:19) (reply to #28) Regarding config merge on update, I have played with two things. First, the yum plugin called yum-merge-conf, which allows for interactive merging of config files during the upgrade. Works and gets the job done, and could be done in zypper as well, however from my own experience I have to say that it protracts the update more than I sometimes like, and I typically want to do this job in a separate step (after the packages are updated). not protract the update for merging all files. So I rather use another approach, which is a script called rpmresolve (https://build.opensuse.org/package/view_file?file=rpmresolve&package=server… 3Apoeml), which works in a similar way, based on presence of rpmsave/rpmnew files. It opens vim in diff mode, lets you merge and asks you which version you want to keep. Works well for me since years, it just might require refinement of some things of the implementation in a more generic way (e.g. calling $EDITOR with different option than - d). #31: andrea florio (anubisg1) (2009-07-10 00:11:07) i think that we miss something like that: https://help.ubuntu.com/community/JauntyUpgrades it's so easy to upgrade an ubuntu version that also my 5 years old student was able to do it.. -- openSUSE Feature: https://features.opensuse.org/305634

1 0

[openFATE 305623] Remove gnomesu dependancies from YaST
by fate_noreply＠suse.de 03 Aug '09

03 Aug '09

Feature changed by: Frank Sundermeyer (fsundermeyer) Feature #305623, revision 13 Title: Remove gnomesu dependancies from YaST openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Federico Lucifredi (flucifredi) Description: The Gnome team informs me gnomesu is obsoleted. We need to stop depending on gnomesu on YaST, ideally moving towards PolicyKit as much as possible but at a minimum matching the current mainline Gnome behavior. Discussion: #5: Jiri Srain (jsrain) (2009-06-02 11:43:54) The only dependency I found is the yast2-control-center-gnome package; Jared, can you handle it? #6: Jared Allen (jpallen) (2009-07-01 17:09:54) (reply to #5) Yes, we'll need to look into an alternative. I'm not sure that PolicyKit itself is enough to replace the functionality of gnomesu. I'll ask Gabriel to look into this. #7: Gabriel Burt (gabrielburt) (2009-07-06 22:11:34) (reply to #6) $ sudo zypper remove libgnomesu The following packages are going to be REMOVED: deskbar-applet gedit gedit-lang gnome-applets gnome-applets- lang gnome-python-desktop libgnomeprintui libgnomeprintui-lang libgnomesu libgnomesu0 libgnomesu-lang planner planner-lang tomboy tomboy-lang yast2-control-center-gnome - So those are the packages on a default GNOME install that depend on libgnomesu. - To replace this with something powered by PolicyKit, it looks like gksu is the best option (though Rodrigo wsa working on AdminKit, but it never got traction or a lot of work, from what I can tell). Vincent has a related FATE feature opened, FATE #305640 - but it's more general, deals with getting rid of gnomesu entirely. Should we keep these boht open/separate? - The actual usage of gnomesu is coming from a SUSE patch to libgnome- desktop. -- openSUSE Feature: https://features.opensuse.org/305623

1 0

[openFATE 305317] Default to hidden bootloader menu
by fate_noreply＠suse.de 03 Aug '09

03 Aug '09

Feature changed by: Frank Sundermeyer (fsundermeyer) Feature #305317, revision 19 Title: Default to hidden bootloader menu openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Desirable Info Provider: Jan Engelhardt (jengelh) Requested by: Jiri Srain (jsrain) Description: As long as there is no other operating system present (SUSE is the only system), it makes sense to default to hidden bootloader menu (and booting directly). References: http://www.gnu.org/software/grub/manual/grub.html#Hidden-menu-interface https://bugzilla.novell.com/show_bug.cgi?id=425717 Discussion: #1: Stephan Kulow (coolo) (2009-04-16 10:34:48) I like that idea. I guess it's a tiny change for bootloader, but has possibly some docu impact. #2: Stanislav Visnovsky (visnov) (2009-05-28 16:45:13) How should it behave with option to keep kernels from updates (libzypp option)? What about failsafe? #3: Jiri Srain (jsrain) (2009-06-01 11:21:11) From the GRUB documentation: When your terminal is dumb or you request GRUB to hide the menu interface explicitly with the command `hiddenmenu' (*note hiddenmenu::), GRUB doesn't show the menu interface (*note Menu interface::) and automatically boots the default entry, unless interrupted by pressing ESC. When you interrupt the timeout and your terminal is dumb, GRUB falls back to the command-line interface (*note Command-line interface::). This sounds to me like this GRUB feature is intended for different purpose, and the use case described here does not make much sense (unlike lowering the time-out to e.g. 1 second). Torsten, what is your view? According to the documentation, GRUB allows to display the boot menu via pushing the Escape button. #7: Christoph Thiel (cthiel1) (2009-07-16 11:27:26) (reply to #3) Torsten, could you please provide your view on this? Fedora and others seem to be doing this for years. #4: T. J. Brumfield (enderandrew) (2009-06-13 03:31:06) This option would only be utilized when no other OS is present, and you can still get back to the menu with Esc. This isn't that much different than needing F8 for the boot menu for Windows. It would speed up boot times. How is that a bad thing? #5: Jan Engelhardt (jengelh) (2009-06-18 23:53:45) Does not Fedora do something similar? #6: Christoph Thiel (cthiel1) (2009-06-28 10:00:44) (reply to #5) I haven't looked at how Fedora handles this. Jan, would you be able to dig into what Fedora does technically? This would be very much appreciated! #8: Stefan Kunze (kunzes) (2009-07-28 16:03:50) The only problem I see with this is when the installer does not pick up another installed OS (happens to Windows once in a while) and defaults to a hidden Bootloader? - -- openSUSE Feature: https://features.opensuse.org/305317

1 0