June 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 303809] Partitioner: allow cloning of disk layouts - was: easier creation of RAID 1
by fate_noreply＠suse.de 03 Jun '09

03 Jun '09

Feature changed by: Christoph Thiel (cthiel1) Feature #303809, revision 22 Title: Partitioner: allow cloning of disk layouts - was: easier creation of RAID 1 openSUSE-11.1: Rejected by Matthias Eckermann (mge1512) reject date: 2008-07-30 16:50:50 reject reason: Moving to SLE 11 SP 1 / openSUSE 11.2 Priority Requester: Important Projectmanager: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-06-03 08:23:34 + reject reason: no resources for 11.2. Priority Requester: Important Projectmanager: Important + openSUSE-11.3: Evaluation + Priority + Requester: Important + Projectmanager: Important Requested by: Matthias Eckermann (mge1512) Description: Proposal is to offer an option in YaST to clone a disk layout for RAID use and probably jump into the RAID-creation-mode directly Below the original request from C. Boltz / openSUSE community: ----------------------------------------------------------------------------------------------------- It would be good to have an easier way to setup a raid 1 (mirroring). Currently you have to: * create partitions on first disk * create partitions on the second disk (usually using the same layout). * put the corresponding partitions (sda1+sdb1, sda2+sdb2, ...) into a raid array. The easier way would be * [x] I want to create a raid 1 * define the partitioning once for both disks YaST should then partition both disks as requested and create the raid volumes This would save the user/admin some time. However, the traditional method should still be available in case someone wants to have a different layout for some partitions for whatever reason. Relations: - Partitioner: allow cloning of disk layouts - was: easier creation of RAID 1 (novell/bugzilla/id: 387373) https://bugzilla.novell.com/show_bug.cgi?id=387373 Discussion: #2: Matthias Eckermann (mge1512) (2008-05-06 20:10:22) Thanks for the proposal. I am happy that there are more people out there sharing my problems:-) Yet, looking at the current "model" we have in mind for partitioner enhancements, I wonder, if we could probably make that more "generic" by adding something like a "clone disk partitioning scheme" button: You would partition hd0 first and then say: please clone this to hd1, hd2, ... and be able to adjust settings on hd1, ... later. Would that fit? so long - MgE #3: Christian Boltz (cboltz) (2008-05-08 05:07:14) Cloning the disk layout sounds like a good idea and would help. To make it more useful for RAID creation, add "clone to md*", maybe combined with a selection dialog to choose the disks to use. #4: Matthias Eckermann (mge1512) (2008-05-08 05:26:16) Well, you know, we indeed are planning to have such a dialog for creation of raids in the future, ...:-) I changed the "title" according to our discussion, and will 1transfer the request into our internal Feature tracking system soon. Thanks! so long - MgE #6: Martin Schmidkunz (mschmidkunz) (2008-05-15 11:37:58) AFAIK it is currently possible to create one partition after the other. So it does not make sense for me to have a "Clone this partition for future use" at the end. Instead I thought of: http://en.opensuse.org/Image:Idea_303809_1.png When the user presses "Add" in the "partitioning" tab he can choose whether to create one new partition or to use the whole partition scheme from another physical harddisk. Does that make sense? #7: Matthias Eckermann (mge1512) (2008-05-15 12:05:53) (reply to #6) Well, no:-( We are not asking for _partition_ cloning, but _disk_ cloning, i.e. if you have several harddisks, and you want to copy the partitioning from sda to sdb or the like. #8: Martin Schmidkunz (mschmidkunz) (2008-05-16 10:01:41) As discussed live with mge we agree on my proposal. #9: Arvin Schnell (aschnell) (2008-05-16 10:33:01) (reply to #8) That approach has some problems: 1) Hiding "Cloning" behind "Add Partition" is incomprehensible. Cloning affect the whole disk, adding a partition not really. 2) The step to select the partition type is omitted if only one type of partition can be selected. 3) The complete workflow of adding a partition is omitted when no partitions can be created. We (mge, mschmidkunz and aschnell) now agreed upon adding an entry to the "expert" menubutton in the partition overview. #16: Arvin Schnell (aschnell) (2009-02-04 11:08:08) Summarising the request: Add a entry "Close disk layout" to the "Expert" button in the disk view. This opens a dialog showing all disks that are suitable for being a clone (constraints: new disks must have equal or larger size). Several disks can be selected. On the selected disks: Delete everything (including RAIDs and LVMs somehow using that disk), create new partition table (if different from existing) and create partitions with same start and sizes (in cylinders as libstorage calculates internally) and partition IDs. Other parameters, e.g. filesystem, are not copied. -- openSUSE Feature: https://features.opensuse.org/303809

1 0

[openFATE 302485] sync GPT and MBR on MacBook (mactel)
by fate_noreply＠suse.de 02 Jun '09

02 Jun '09

Feature changed by: Nathan Slingerland (slingn) Feature #302485, revision 35 Title: sync GPT and MBR on MacBook (mactel) openSUSE-10.3: Rejected by Stephan Kulow (coolo) reject date: 2007-10-01 12:11:18 reject reason: not done from what I heared Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-04-28 09:46:04 reject reason: lacking parted maintainer for the moment Priority Requester: Mandatory Projectmanager: Important openSUSE-11.1: Done Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Done Priority Requester: Mandatory Requested by: Ruediger Oertel (oertel) Description: on multiboot setups on MacBooks and other mactel machines, using a combination of GPT and MBR is pretty common (and necessary if you either want to use grub or are also using Windows) for installation on these machines we need to offer a way to sync the GPT to the MBR whenever a change to the GPT is made. There exists a patch for parted to do just this (see bugzilla#220839) and also the sources of refit (refit.sourceforge.net, tool gptsync). Relations: - GPT partitioning and boot support (feature/id: 303026) - fully support disks with GPT (feature/id: 303924) Discussion: #1: Stephan Kulow (coolo) (2007-08-01 12:37:33) sounds like a dataloss we should fix for 10.3 too #2: Edith Parzefall (emapedl) (2007-08-01 17:42:46) We need to find out more about what actually needs to be done, before we can consider making an attempt for 10.3 despite the approaching deadline. #3: Edith Parzefall (emapedl) (2007-08-07 11:53:32) There's not enough time left, please reject for 10.3. #4: Ruediger Oertel (oertel) (2007-11-06 12:29:36) for reference, the patch for parted is in bug#220839. This patch adds the method "map_gpt_to_msdos" to parted and was written by Olaf Hering and discussed on the parted mailing list in May 2007. #5: Duncan Mac-Vicar (dmacvicar) (2008-02-04 21:29:52) Olaf, you wrote the patch, can you please describe us what is exactly needed so YaST makes this kind of configuration to work? There is little knowledge about this situation and we imagine adding the patch to parted is not the only required step. Some additional code in YaST and while setting up the bootloader might be required. Do you know about it? #6: Olaf Hering (olh) (2008-02-18 10:04:25) (reply to #5) There are comments in the patch. Once the GPT partitioning is done, map one GPT partition to a primary msdos partition. yast2-storage knows what the boot partition is, so it can force the mapping. #7: Arvin Schnell (aschnell) (2008-04-03 17:11:26) Duncan asked me to summarise the task for implementation: 1) Include parted patch "parted.msdos-on-gpt.patch". Thomas saw the risk of breaking parted by this. Issue for parted maintainer (we have none). 2) Add new calls to parted to establish the mapping from GPT to MSDOS disk labels. Issue for yast2-bootloader and/or yast2-storage. 3) Fix bootloader config to not call "parted ... boot on" when it's already on. Should fix the update problem Rudi has. Issue for yast2- bootloader. AFAIS not required with patched parted. #8: Duncan Mac-Vicar (dmacvicar) (2008-04-14 11:43:17) Coolo, points 1 and 3 call for reject until bootloader situation and parted one is better. #9: Joachim Plack (jplack) (2008-04-28 12:30:48) michl@ : AFAIK The MacBooks are to date not handled as a supported platform. But they should be last but not least due to there pretty wide spread of that thingy. Please check, define and prioritize. Thanks. BTW there are some booting issues involved #10: Michael Loeffler (sprudel24) (2008-04-28 13:36:54) (reply to #9) That's a clear "nice to have" feature. Needed ressources and involved risks need to be low. #11: Stephan Kulow (coolo) (2008-06-12 12:39:54) (reply to #10) I'm not so sure about this. Depending on what market you look at, you get a market share of 10 - 50 percentage. I didn't fail to notice that Saturn Fürth's laptop departement is basically built around macbooks. #12: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:21:19) Please reject for 11.0. All resources allocated with mandatory features already. #13: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:46:29) (reply to #12) meant SLE11/openSUSE11.1 #14: Alexander Graf (algraf) (2008-08-22 19:54:25) (reply to #13) For openSUSE 11.1 / SLES11 it's done already. I checked in a patch for parted a while ago. #15: Stephan Kulow (coolo) (2009-04-22 14:22:43) (reply to #14) opening to openfate to have a link #16: Lars Vogdt (lrupp) (2009-05-13 12:43:12) (reply to #14) For me it doesn't look like "done already". I've a MacBook Pro here and tried to install openSUSE 11.1 without success. FYI: I'm using rEFIt as "bootloader" here - and after each installation, rEFit tells me that the MBR and GPT is out of sync and can't be repared. With the older openSUSE (10.3) it works with this workaround: http://en.opensuse.org/Installation_on_MacBook_Pro_Intel_(x86) <-- grub is not installed Sadly I need the MacBook for my work, but if you can't find another one, I can run a backup and reproduce my problems for you. #17: Eddy Figueroa (efiggy) (2009-05-27 03:41:47) (reply to #16) I can verify that I'm still having the issue here with openSuSE 11.1 and 11.2 Milestone 1. I've got the MacBook Pro 2,2 (late 2006) model. I tried to configure the partitions (just a swap and ext3 partition, nothing special) with gParted and was able to successfully sync the GPT and MBR tables. Then I installed openSuSE and even though I didn't even have it format or recreate the partitions my MBR was destroyed; I could no longer sync the GPT and MBR tables. If there is a clear, definitive guide on what needs to be done to work around this issue I would love to see it... I haven't run into anything that has helped (including the guide that Lars linked to) and I would really love to see openSuSE running on my MacBook Pro. I don't want to give up! Thank you for all your hard work, guys (and gals)! + #18: Nathan Slingerland (slingn) (2009-06-02 23:05:50) (reply to #17) + Same problem here on my MacBook Pro - switched to Ubuntu for now, but I + would really love to go back to OpenSUSE. Please consider for the next + release. -- openSUSE Feature: https://features.opensuse.org/302485

1 0

[openFATE 305394] Move KDE software updates notifications to upstream infrastructure
by fate_noreply＠suse.de 02 Jun '09

02 Jun '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #305394, revision 21 Title: Move KDE software updates notifications to upstream infrastructure openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: As kpackagekit matures, it may be the case that for 11.2 it is mature enough for replacing kupdateapplet. It already implements various aspects of kupdateapplet: * notifications (knotify) using a kded service (which takes care of refreshing too) * single update selection (kpackagekit gui) * uses a upstream client library for communication with PackageKit, which are better than our PackageKit communication code. Scope kpackagekit is meant here only to replace kupdateapplet. There is not relation with YaST here. Open Issues: * tray notification: may require implementing a plasma tray icon * SUSE specific code (smolt, registration, hardware search) * Requires some research how to introduce those extensions in kpackagekit, or move SUSE specific parts out, like another kded service. User experience Should stay the same Dependencies * PackageKit * libpackagekit-qt Contingency Plan In the case kpackagekit is not yet mature enough, the same resources invested now in kupdateapplet can be invested in improving kpackagekit. Otherwise, we can stay with kupdateapplet as a fallback. Relations: - kpackagekit author interview (url: http://polishlinux.org/kde/kpackagekit-interview/) - kpackagekit screenshot (url: http://www.packagekit.org/img/kpk-update.png) Test Case: * new patches should be notified by knotify * user should be able to see update availability * user should be able to see detailed update information, as well as selecting individual updates * user should get informed if the update repositories configuration has a problem * user should be informed of (available) drivers for plugged hardware Business case (Partner benefit): openSUSE.org: Right now software notifications are done using the kupdateapplet, which comes from the opensuse-updater code,(renamed in a non sucessful attept to upstream it). This applet come from a summer of code project, originally done as a zmd client, then evoluted to a zypper client, and now working as a PackageKit client. Sadly, during 10.3 cycle this applet got the feature to select updates individually and other small stuff which turned it into a very complicated piece of code, and started to became a package manager on its own. Later it became the favorite place to plug any kind of notifications, like registration needed, smolt participation, etc, and right now the code is much more complex that it should be (thus taking more maintenance and testing than it should require). This feature has the objective of cleaning up this situation to free resources in this area. With the progress of packagekit and recently, kpackagekit, this should be possible. kpackagekit already implements various of the needed aspects, and therefore it would mean getting rid of in house code for upstream code. Additionally, it would result in a much more consistant user experience as the tools would be similar across distributions. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 14:24:20) Looks like Duncan is in favor of this. Stano? If you guys are comfortable with the change, I am all for it. But remember, priority #1 is dist-upgrade. + #5: Duncan Mac-Vicar (dmacvicar) (2009-06-02 18:00:54) + I will evaluate this feature later, we don't know the status of + KPackageKit, we have the package and Thomas contributed patches, so + only the decision to switch or not to switch is important. + Feedback from the KDE team about upstream KDE 4.3 would also be + useful. -- openSUSE Feature: https://features.opensuse.org/305394

1 0

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

02 Jun '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #120340, revision 85 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: 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. -- openSUSE Feature: https://features.opensuse.org/120340

1 0

[openFATE 300763] Warn about services using old libraries
by fate_noreply＠suse.de 02 Jun '09

02 Jun '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #300763, revision 47 Title: Warn about services using old libraries openSUSE-10.2: Rejected by Edith Parzefall (emapedl) reject date: 2006-10-02 16:05:01 reject reason: Not enough time for 10.2, rejecting with TPM approval. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-31 12:35:05 reject reason: Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-11-21 12:16:55 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-08-01 18:25:29 reject reason: Cutting scope to match project schedule. Priority Requester: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Martin Vidner (mvidner) Description: Fou4s has a useful feature: after installing updates, it runs "lsof | grep RPMDELETE" to see processes that are accessing the old libraries and recommends to restart them. Our update stack should do this as well, and notify users of processes that need to be restarted. I see this as both a zypper feature and a PK-UI pop-up. Documentation Impact: Software management documentaiton needs to be updated. Discussion: #7: Sherry Arnold (sfarnold) (2007-07-31 22:06:27) (reply to #4) The Debian outdated-libraries script that runs at package update time (perhaps only for libc?) only shows program names to the admin at the end. #5: Stanislav Visnovsky (visnov) (2006-09-06 10:57:53) Edith, Jiri, feel free to postpone this for 10.3 if out of resources. #6: Edith Parzefall (emapedl) (2007-07-31 11:49:06) Sorry, we had no time to look into this. Please reject for 10.3. #8: Federico Lucifredi (flucifredi) (2008-06-12 20:52:41) I like this. Stano, Klaus, please sanity-check. #9: Jiri Srain (jsrain) (2008-07-07 09:03:59) Jiri, please, add the check into YaST online update (I must admit that the suggested command didn't work for me, thus some investigation may be needed). Duncan, please, assign the applets. #10: Jiří Suchomel (jsuchome) (2008-07-14 15:55:27) Uhm, what should be the output of "lsof | grep RPMDELETE" and what should actually YaST do with the result? Or, if we use the command from comment 4: what should YaST do with these results? #11: Martin Vidner (mvidner) (2008-07-16 09:52:28) When packages are updated, the effect of the update may not be yet realized because the system is still using the old files (they are unlinked but still in use). A well known case is the kernel which needs a reboot (or kexec or ksplice...). For the apps, we can ask (in zypp app layer?) about all open files which are already unlinked. Then we can say "Updates will not take effect until these processes are restarted: sshd (pid 42), apache2 (pid 31337). If you are unsure, rebooting will do the job.". There can be a Details button or a reference to "zypper checkdeleted" (TODO) to show the gory details. It seems that RPMDELETE no longer works, but there is a simple fix (http://archives.neohapsis.com/archives/linux/suse/2006-q1/0034.html) for that. This thread (http://lists.opensuse.org/opensuse/2002-09/msg00532.html) shows how fou4s presents the info. Marcus has good points in comment 4 but we can address them when we have a prototype working. #12: Jiří Suchomel (jsuchome) (2008-07-16 10:04:16) (reply to #11) IMHO such check belongs to zypp, YaST/zypper/applets should show the results. Duncan, is it possible to assign this to someone from the zypp team? #13: Duncan Mac-Vicar (dmacvicar) (2008-07-30 17:09:22) (reply to #12) yes, will be done as part of the commit refactoring. + #21: Duncan Mac-Vicar (dmacvicar) (2009-06-02 14:52:10) + This will be implemented as a chain in the commit refactoring, by + calling a external binary that will look in /proc for binaries with + deleted libraries opened. + The RPMDELETE stuff does not work in reality like it is described. + Also may be good to create a good set of callbacks so libzypp can + present a summary of services to restart and also config files that + were modified. -- openSUSE Feature: https://features.opensuse.org/300763

1 0

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

02 Jun '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #305634, revision 116 Title: Debian-like dist-upgrade live system full version upgrade - openSUSE-11.2: Evaluation + 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: - 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). -- openSUSE Feature: https://features.opensuse.org/305634

1 0

[openFATE 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 02 Jun '09

02 Jun '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #305503, revision 11 Title: zypper: allow update by issues/bugs/advisories - openSUSE-11.2: Evaluation + openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Mandatory Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Description: YUM security plugin allows to filter updates showing only ones that mention certain issues. Example: yum update --security yum update --bz 410101 yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5 As our patches contains this metadata, we could add similar functionality to zypper. Scope The scope is only for zypper. Other front ends would require some GUI concept first. Open Issues: libzypp's PoolQuery would need support for subattributes (updateinfo. xml references are stored as subarrays) User experience * Adds command line options like the ones described above. Dependencies * libzypp Contingency Plan * Feature is new, so in a bad scenario it can simple be deactivated. Relations: - Tips and tricks: yum-security (url: http://www.redhatmagazine.com/2008/01/16/tips-and-tricks-yum-security/) Documentation Impact: New command line options would need to be documented. Test Case: The testing of this feature can be done creating a repository (for example using enhancerepo) containing patches that reference issues, like described in http://en.opensuse.org/Maintenance/Code11/Howto , and then performing updates passing to zypper command line the issues, confirming that only those issues are shown. Use Case: Sysadmin is only interested in particular updates to solve security issues or specific bug numbers or advisories. Business case (Partner benefit): openSUSE.org: Sysadmins do not update ther systems without a strict process and maximum care. Therefore it is very important to allow them to update the system to fix a single issue. It would save them the time to look that themselves package per package. Discussion: #1: Marcus Meissner (msmeissn) (2008-12-03 14:51:14) Random notes: - CVE-XXXX-YYYY RPM provides after fixing issues? - OVAL relation? #2: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:02:46) (reply to #1) About CVE provides. Right now the CVE information is in the patch (since 11.0). I don't have anything against having it as Fix(CVE-XXX-XXX) provides, but I am not sure if having them in both makes sense. Specially in the case that one issue needs more than one package, you will need to install all packages fixing the issue, and if you have 2 repos with 2 same packages providing the issue, they will conflict. #3: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:08:13) (reply to #1) I don't have knowledge how OVAL works, may be you can provide some very concrete example scenarios for the feature described above. What I can say is that the reason why the repository/product compatibility and update information in SLE11/openSUSE 11.1 is supported using CPE ( that is, product can contain a CPE id, and repos can tell to which CPE they are compatible and which CPE they update with fixes ) was to enhance our ability to do semantic queries like relate upstream security issues and installed products. OVAL uses CPE as the platform descriptor AFAIK. #4: Dirk Mueller (dirkmueller) (2008-12-04 14:58:01) adding rpm provides was also my first idea, but that has a side effect: often enough, CVE numbers are not yet known when the package is built and ends up in QA, and editing rpm provides essentially needs a rebuild, which invalidates QA. so preferably we need a way to update the rpm provides without doing a rebuild (bad) or we need a way to add it to the meta information (which is currently generated via patchinfo and where it is also too late). an idealistic approach would be to make sure that we can update this meta information after patchinfo checkin (entering the data into swamp and autobuild fetches that information when the update is released and adds it to the meta info). #5: Federico Lucifredi (flucifredi) (2009-01-07 15:52:34) This has quite a bit of customer value. BTW, there may be a duplicate out there -- openSUSE Feature: https://features.opensuse.org/305503

1 0

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

02 Jun '09

Feature changed by: Jiri Srain (jsrain) Feature #305623, revision 9 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? -- openSUSE Feature: https://features.opensuse.org/305623

1 0

[openFATE 302159] zypper: Add option to only download packages (-d)
by fate_noreply＠suse.de 02 Jun '09

02 Jun '09

Feature changed by: Jiri Srain (jsrain) Feature #302159, revision 36 Title: zypper: Add option to only download packages (-d) openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-06-19 14:19:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-04 14:32:54 reject reason: Running out of time, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 22:23:41 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Important Requested by: Jiri Srain (jsrain) Description: rug has a '-d' option which causes it only download packages, not to install them. zypper does not have one. to make use of such options (download packages and install them later) zypp must be able to keep the packages downloaded and use them later instead of downloading them again (eg. some kind of persistent cache). References: https://bugzilla.novell.com/show_bug.cgi?id=230704 See also feature #300747 and #305624 Discussion: #2: Ján Kupec (jkupec) (2007-06-05 13:43:33) (reply to #1) First, we must have a clue how to do it :O) #5: Michael Andres (mlandres) (2007-06-18 13:21:51) (reply to #2) We need a persistent package cache, where packages are indexed by MD5, SHA. Commit has to be rewritten to separate download and install code (still offering alternating download/install or download all then install). And we need some cache cleanup policies. But we probabely don't want to do this before we know the refactored zypp runs smoothly, so I would not promise this for 10.3 #8: Federico Lucifredi (flucifredi) (2007-06-18 15:48:59) (reply to #5) As an aside, indexing will cause you probelsm with blind-revisioned packages, depending on how you implement it. #4: Duncan Mac-Vicar (dmacvicar) (2007-06-18 09:19:27) (reply to #3) This means changing the commit, and we can only do that if we are ahead of time with the other changes. #6: Jiri Srain (jsrain) (2007-06-18 14:40:08) Duncan, Michael, thanks! Stano, please, postpone for 11.0. #7: Federico Lucifredi (flucifredi) (2007-06-18 15:46:55) Lets not forget that 70%+ of OpenSUSE users have broadband according to the survey, which means this is a marginal advantage, albeit a nice one (I imagine, users who are charged by the bit, and advanced users doing who-knows-what will take advantage of the ability to retrieve packages from the cache). #13: Jan Engelhardt (jengelh) (2009-03-01 17:02:04) (reply to #7) Broadband is actually a pretty broad term, and so the survey item probably did not have much value. #10: Stanislav Visnovsky (visnov) (2007-11-23 11:26:31) zypper improvements, commit re-factoring. #14: Elmar Stellnberger ATK (estellnb) (2009-03-26 13:04:40) One advantage will be that packages can be inspected by a prog. such as mc in advance to installation or to manually take them apart by rpm2cpio. Sometimes it is necessary to add special rpm-installation options as --excludepath or --excludedocs to install several versions of a single package for downward compatibility. Furthermore in combination with an upcoming --arch switch it may enable to download packages on a server to be installed on another system/machine. f.i. the ati repo can not be browsed via http so that it is necessary to download packages from it via zypper rather than a web browser. -- openSUSE Feature: https://features.opensuse.org/302159

1 0

[openFATE 305641] Bring Puppet to fully supportable status
by fate_noreply＠suse.de 02 Jun '09

02 Jun '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #305641, revision 19 Title: Bring Puppet to fully supportable status - openSUSE-11.2: Evaluation + openSUSE-11.2: Candidate Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: Dedicate a developer for the duration of the 11.2 cycle to shaking out Puppet on openSUSE, contribute patches upstream correcting integration with our base system, and analyzing what future integration areas (particularly with YaST, but not limited) appear promising. The objective is to walk through the Puppet documentation (http://reductivelabs.com/trac/puppet/wiki/DocumentationStart) Turnbull's book (ISBN 159059978), and test out that things work as they should, patching and sending upstream when they do not. Finally, contribute a small "Puppet on SUSE" document to the community detailing any platform- specific factors (you will see there are a number for other distors already). Additional notes: The plan is to _INSTALL_ the Puppet infrastructure by default. No default-running is planned - I thought it was important to clarify this. Addtionally, Facter needs to be packaged and supportable alongside Puppet. Cft should be packaged, but not default installed, and not the target of this focused infrastructure work in this cycle (i.e. Best effort). Relations: - Feature for 11 GA tech Preview (feature/id: 303687) Business case (Partner benefit): openSUSE.org: The ultimate intent is to integrate a policy management framework into the platform and have it available as default infrastructure. This has a number of consequencies: for one, the ability of third parties, both internal and external, to leverage the policy language for platform management. Secondly, I want to support the Puppet objective of being a pervasive policy language for *NIX, which may or may not be achievable. This combines with the set of enabling management technologies we want to have on the platform as blocks to build on: integrated libraries (libzypp, libstorage, ..), management instrumentation (SFCB, management profiles exposing the libraries wherever possible), Stateless YaST interface (to enable access to configuration facilities), and support instrumentation (the Novell Support Link, formerly known as Aurora and Onstar). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-08 16:25:48) . #2: Federico Lucifredi (flucifredi) (2009-01-26 18:49:40) As per for phone conversation, this requirement is not only about technology ("Policy framework"), but also about the political decision of what solution to adopt - in which context the technology is not an Engineering decision, but a Business one. I am chosing Puppet on the theory that we will do our bit to help the rise of a cross-*NIX management tool by making it available and supported. If the interest in Puppet contines at this pace, and other things go the right way, we will consider further investment. For now, we just make Puppet (and Facter with it) L3 supported. If the market keeps moving in this direction, then good, we will integrate beyond the "managing by configuration file" scheme, and look at what YaST integration we can do. If it does not, we just keep the L3 package and move3 on. Think of it as Perl - it is on Every *NIX, and if you use it is good if not, it does not hurt. #3: Pavol Rusnak (prusnak) (2009-02-10 15:45:06) I think anicka did some experiments with puppet. #4: Duncan Mac-Vicar (dmacvicar) (2009-04-15 09:35:35) Progress note: integration of the community authored zypper plugin for puppet is integrated (and working) and will be submitted to stable. + #5: Duncan Mac-Vicar (dmacvicar) (2009-06-02 11:24:28) + We added a patch to support zypper for puppet package ensure policies, + which is submitted. + Marking as in implementation. Could in theory be marked as done if we + had any criteria. -- openSUSE Feature: https://features.opensuse.org/305641

1 0