Re: Proposed F19 Feature: Fedora Upgrade - using yum
Reindl Harald wrote: oh even if people like i did some hundret dist-upgrades over the years it was us told that linux has to go the windows way: http://fedoraproject.org/wiki/Features/OfflineSystemUpdates Yeah, this is a really insane feature! Let me assure you that this feature is only currently implemented in gnome-packagekit. The command-line tools will probably NEVER implement this. As for Apper, I can assure you that: * this feature is not currently implemented in Apper, * Apper's upstream author plans to support it in the future, but make it optional, and * KDE SIG has strong reservations about the usefulness and desirability of this feature and it will likely end up disabled by default in Fedora if implemented. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Sat, Feb 9, 2013 at 9:10 AM, Kevin Kofler kevin.kof...@chello.at wrote: Reindl Harald wrote: oh even if people like i did some hundret dist-upgrades over the years it was us told that linux has to go the windows way: http://fedoraproject.org/wiki/Features/OfflineSystemUpdates Yeah, this is a really insane feature! Let me assure you that this feature is only currently implemented in gnome-packagekit. The command-line tools will probably NEVER implement this. As for Apper, I can assure you that: * this feature is not currently implemented in Apper, * Apper's upstream author plans to support it in the future, but make it optional, and * KDE SIG has strong reservations about the usefulness and desirability of this feature and it will likely end up disabled by default in Fedora if implemented. Yes become ignoring problems by pretending that they do not exist is the way to go -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Am 09.02.2013 15:52, schrieb drago01: On Sat, Feb 9, 2013 at 9:10 AM, Kevin Kofler kevin.kof...@chello.at wrote: Reindl Harald wrote: oh even if people like i did some hundret dist-upgrades over the years it was us told that linux has to go the windows way: http://fedoraproject.org/wiki/Features/OfflineSystemUpdates Yeah, this is a really insane feature! Let me assure you that this feature is only currently implemented in gnome-packagekit. The command-line tools will probably NEVER implement this. As for Apper, I can assure you that: * this feature is not currently implemented in Apper, * Apper's upstream author plans to support it in the future, but make it optional, and * KDE SIG has strong reservations about the usefulness and desirability of this feature and it will likely end up disabled by default in Fedora if implemented. Yes become ignoring problems by pretending that they do not exist is the way to go why preklink not banned which also touches probably running binaries, but hey in this case it is OK because it was a fedora feature years ago and there must be good which problems? where were they over decades? who did introduce them recently? why this bugs are not fixed? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Am 04.02.2013 18:35, schrieb Miroslav Suchý: On 01/25/2013 12:12 AM, Lennart Poettering wrote: So, you can ignore all of that, but then you have to think about what you actually accomplished by your upgrade? You updated a couple of libraries, and maybe managed to restart a few processes using them, but for the rest of them the vulnerable openssl version is still in memory, still actively used, even though your update script exited successfully leaving the user under the impression that all was good now and that after he made this upgrade his machine was not vulnerable anymore. And how this differ from yum upgrade which I'm doing every day/week? Lets pretend I'm still running Fedora 16 and every day I do yum-upgrade and not rebooted from day zero. I have exactly the same problem as during yum upgrade to next Fedora release. So we are ignoring this behaviour in middle of release, but it is very serious problem between releases? oh even if people like i did some hundret dist-upgrades over the years it was us told that linux has to go the windows way: http://fedoraproject.org/wiki/Features/OfflineSystemUpdates a few years ago you could make a dist-upgrade and even httpd and fileservers like netatalk were running in the old version until reboot, did it, was there then fedora introduced the restart-service-snippets in every SPEC file, after that came Packagekit and after systemd now all the things worked over decades are suddenly not possible in a clean way - i do not buy that the development goes in the right direction at all signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Tue, 2013-02-05 at 08:54 +0100, Miroslav Suchý wrote: On 02/04/2013 10:29 PM, Adam Williamson wrote: https://ohjeezlinux.wordpress.com/2012/11/13/fedup-a-little-background/ ... kinda. That's the best that I know of. It lacks in details how I can put hook in upgrade.pre and upgrade.post. What is the best practise here? It would be nice if you can enhance: http://fedoraproject.org/wiki/Packaging:Guidelines with example snippets and general guidance how packager can create such hook. I agree that would be nice, but I am not actually the author of the feature or a user of it, so I don't have the expertise on tap. :) Will is the one currently best-placed to do so. So far as I'm aware these are simply dracut hooks so dracut docs would apply, but I'm not sure. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 01/29/2013 12:59 AM, Adam Williamson wrote: Well, the other thing fedup does - and the other reason it's necessary compared to a simple online yum upgrade - is provide a mechanism for pretty much any package to hook in pretty much any action to be performed as part of the upgrade. To be sure of what's going to happen during a given fedup transaction, you should also check what scripts are going to get fired as part of the upgrade. In F18 I'm not sure there are any, but this is the kind of mechanism we would use, fr'instance, to switch the default bootloader as part of an upgrade in future, if we decided we wanted to do that again. The kind of stuff that can't be done in %pre/%post etc. Is this documented somewhere? I would like to read more about this feature. -- Miroslav Suchy Red Hat Systems Management Engineering -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 01/25/2013 12:12 AM, Lennart Poettering wrote: So, you can ignore all of that, but then you have to think about what you actually accomplished by your upgrade? You updated a couple of libraries, and maybe managed to restart a few processes using them, but for the rest of them the vulnerable openssl version is still in memory, still actively used, even though your update script exited successfully leaving the user under the impression that all was good now and that after he made this upgrade his machine was not vulnerable anymore. And how this differ from yum upgrade which I'm doing every day/week? Lets pretend I'm still running Fedora 16 and every day I do yum-upgrade and not rebooted from day zero. I have exactly the same problem as during yum upgrade to next Fedora release. So we are ignoring this behaviour in middle of release, but it is very serious problem between releases? -- Miroslav Suchy Red Hat Systems Management Engineering -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Hi On Mon, Feb 4, 2013 at 12:35 PM, Miroslav Suchý wrote: Lets pretend I'm still running Fedora 16 and every day I do yum-upgrade and not rebooted from day zero. I have exactly the same problem as during yum upgrade to next Fedora release. So we are ignoring this behaviour in middle of release, but it is very serious problem between releases? https://fedoraproject.org/wiki/Features/OfflineSystemUpdates Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Mon, 2013-02-04 at 18:11 +0100, Miroslav Suchý wrote: On 01/29/2013 12:59 AM, Adam Williamson wrote: Well, the other thing fedup does - and the other reason it's necessary compared to a simple online yum upgrade - is provide a mechanism for pretty much any package to hook in pretty much any action to be performed as part of the upgrade. To be sure of what's going to happen during a given fedup transaction, you should also check what scripts are going to get fired as part of the upgrade. In F18 I'm not sure there are any, but this is the kind of mechanism we would use, fr'instance, to switch the default bootloader as part of an upgrade in future, if we decided we wanted to do that again. The kind of stuff that can't be done in %pre/%post etc. Is this documented somewhere? I would like to read more about this feature. https://ohjeezlinux.wordpress.com/2012/11/13/fedup-a-little-background/ ... kinda. That's the best that I know of. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 02/04/2013 10:29 PM, Adam Williamson wrote: https://ohjeezlinux.wordpress.com/2012/11/13/fedup-a-little-background/ ... kinda. That's the best that I know of. It lacks in details how I can put hook in upgrade.pre and upgrade.post. What is the best practise here? It would be nice if you can enhance: http://fedoraproject.org/wiki/Packaging:Guidelines with example snippets and general guidance how packager can create such hook. -- Miroslav Suchy Red Hat Systems Management Engineering -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Bruno Wolff III wrote: Note that this doesn't fix problems caused by dropped packages, that block other packages from being updated. That's a problem for all upgrade methods, they might leave your system with broken dependencies instead of erroring out, but in the end the problem is always there. It's not solvable as long as we're as happy to drop packages as we are now, rather than keeping them working by rebuilding them even if there's no active maintainer. One possiblity here would be to create a special package that obsoletes all of the dropped packages from the last release (or two depending on how far back you want to yum update from). Please no! Many of those packages keep working just fine. And where not, it's better to get a clear error message and to remove the offending packages manually and explicitly than to have the upgrade silently (well, with a one-line notice buried under many other lines of text) removing a package one may be depending on! There are going to be some releases where you need to do things outside of yum to upgrade. Then that's a problem with the feature which requires you to do that, and should be a showstopper! (Yes, I think UsrMove should not have been allowed.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Lennart Poettering wrote: The thing is that doing on-line updates only works for stuff you can restart, and that doesn't mind that things are not atomically updated. However, much (most?) of our code isn't like that. Anybody who tried to update the Firefox RPM while it is running knows that this doesn't end well, and you frequently have to manually kill firefox to get it back into a usual state. Strawman alert! Who ever said that this feature is about online upgrades? Even the Upgrading Fedora using yum wiki page clearly says that upgrades should be done in runlevel 3 (multi-user.target), not in runlevel 5 (graphical.target). The point of using yum to upgrade is not to do it in a running user session, but to use the same frequently-tested code paths as for normal updates rather than a special distro-upgrade-only one where half of the functionality has to be reimplemented differently (see e.g. FedUp not supporting something as basic as signature checks; why do we even bother signing our packages if we're happy to deliver an official and recommended upgrade method which won't even bother checking them?). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Lennart Poettering wrote: Ah, so you have to reboot anyway, so where is the difference between your approach and proper offline updates then? Either way you have to interrupt your work to reboot the machine. One just takes a slight bit longer for rebooting... That yum is tested every day and known to work, whereas FedUp is experimental and incomplete (no signature checking) code. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Jaroslav Reznik wrote: = Features/FedoraUpgrade = https://fedoraproject.org/wiki/Features/FedoraUpgrade Feature owner(s): Miroslav Suchý msu...@redhat.com Upgrade Fedora to next version using yum upgrade. I agree this should be officially supported, but: I propose to have FedUp and FedoraUpgrade in Fedora 19. not using that FedoraUpgrade script. Sorry, but IMHO, that script causes more problems than it solves. For one, it's a one step approach, whereas the IMHO nicest solution, which is IMHO the best compromise between safety and minimum downtime, and which also works if you don't have working networking outside of user sessions (NM user connection), is the following: yum --releasever=n+1 --downloadonly distro-sync telinit 3 yum --releasever=n+1 -C distro-sync which cannot be done in a single script (the telinit would kill the script if it's run from the graphical session). (And sorry Lennart for using telinit 3 rather than whatever the native systemd equivalent is. ;-) ) In addition, not all the things the script does are strictly required and wanted by all users, and finally, I don't think the steps are so tedious as to deserve automation. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
drago01 wrote: And the major issue with yum upgrades is that online upgrades can fail not only based on what you have installed but also what is currently running and it cannot handle stuff like usermove without user intervention. 1. That's a problem with UsrMove, not with yum! 2. UsrMove CAN be done online, e.g. with a C program (which won't care if you move ld.so under it after it's already in memory), or – with some trickery – even in shell. It was an explicit decision to require that useless dracut step. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
drago01 wrote: I doubt that you can install all packages without hitting conflicts. That just shows again how Conflicts are evil and how we're way too tolerant about them. There should be NO conflicting packages in the official repositories. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Jóhann B. Guðmundsson wrote: Users are better of keeping /home on a separated partition and re-use it with an fresh install then those poor attempts to support upgrades one way or another which at this point in time we cant do since the bits for that aren't properly aligned to make that happen... Reinstalling all the time is a no go. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Hi, If a fedup upgrade can go offline for a lengthy, but uncertain, amount of time, then the lack of feedback is worrying. You can't hold your breath for 25 minutes, you don't know when to conclude that you have a serious problem that will require help from the data center staff, and you don't have any idea where the process went off-track. I actually like fedup, and I guess I'll go stop using yum for upgrades if I can use fedup instead. I've seen anaconda upgrades (be it dvd-based or via preupgrade) blow up multiple times and settled on using yum instead. But fedup is different. Even though it is still quite young I actually trust it to get things right. It fetches all packages, then does a transaction check and if that fails it says so and allows you to fixup stuff before actually kicking the upgrade. Remove orphaned packages causing dep issues, cleanup disk so filesystems have enough free space to run the transaction, whatever is needed. That is very simliar to how you handle issues when upgrading using yum. Once everything is settled and fedup says reboot to upgrade you can be pretty sure that it will work fine. cheers, Gerd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Mon, 2013-01-28 at 14:01 +0100, Gerd Hoffmann wrote: Hi, If a fedup upgrade can go offline for a lengthy, but uncertain, amount of time, then the lack of feedback is worrying. You can't hold your breath for 25 minutes, you don't know when to conclude that you have a serious problem that will require help from the data center staff, and you don't have any idea where the process went off-track. I actually like fedup, and I guess I'll go stop using yum for upgrades if I can use fedup instead. I've seen anaconda upgrades (be it dvd-based or via preupgrade) blow up multiple times and settled on using yum instead. But fedup is different. Even though it is still quite young I actually trust it to get things right. It fetches all packages, then does a transaction check and if that fails it says so and allows you to fixup stuff before actually kicking the upgrade. Remove orphaned packages causing dep issues, cleanup disk so filesystems have enough free space to run the transaction, whatever is needed. That is very simliar to how you handle issues when upgrading using yum. Once everything is settled and fedup says reboot to upgrade you can be pretty sure that it will work fine. Well, the other thing fedup does - and the other reason it's necessary compared to a simple online yum upgrade - is provide a mechanism for pretty much any package to hook in pretty much any action to be performed as part of the upgrade. To be sure of what's going to happen during a given fedup transaction, you should also check what scripts are going to get fired as part of the upgrade. In F18 I'm not sure there are any, but this is the kind of mechanism we would use, fr'instance, to switch the default bootloader as part of an upgrade in future, if we decided we wanted to do that again. The kind of stuff that can't be done in %pre/%post etc. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 26 Jan 2013, at 15:28, Michael Scherer wrote: Le samedi 26 janvier 2013 à 15:20 -0500, Mike Pinkerton a écrit : On 26 Jan 2013, at 13:09, Chris Murphy wrote: On Jan 26, 2013, at 10:45 AM, Mike Pinkerton pseli...@mindspring.com wrote: If you could SSH into fedup during its offline period and get real time feedback about what it is doing and any errors it encounters, and perhaps the ability to fix any problems when it finishes but before it attempts to reboot, then it would be less scary for remote upgrades. I haven't tried 'systemctl start sshd' during the upgrade to see what happens; it's probably not totally benign to do this, since ssh will be upgraded, but it seems a lot safer, vastly so, than a live yum update while a server is running. Would it work for the network and sshd to be run from the initramfs rather than the file system that is being updated? Then you need to have the network configuration, etc. This can be done, but for now, the feature is not in dracut, see this bug for a similar request for encrypted root : https://bugzilla.redhat.com/show_bug.cgi?id=524727 That bug looks like a superset of what would be needed to run the network and sshd from the initramfs. As for network configuration, in the past (I haven't tried it with F18's new Anaconda), one could do a VNC-enabled install by passing a minimal network configuration (interface and IP address), as well as a VNC password, on the kernel line. Perhaps for a ssh-enabled fedup, one could do something similar, passing an interface and IP address to fedup, possibly as well as a one-time use ssh password and a permitted remote IP address block from which one could connect. How those persist across the reboot -- whether fedup writes those to the kernel line in grub.conf as one would do with a remote VNC install, or they are written into the initramfs -- would be a question. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Le samedi 26 janvier 2013 à 06:21 +, Matthew Garrett a écrit : On Sat, Jan 26, 2013 at 02:16:29AM +0100, Michael Scherer wrote: Well, slightly bit longer is around 2 to 3h vs 2 to 3 minutes. And I already did version upgrade taking 6 to 8h due to slow internet or slow hard drives, that's IMHO a pretty significant downtime. fedup does all network activity before reboot, so presumably you're talking about some upgrade system other than the currently supported one? You are right, the 6 to 8h is indeed unrelated, this was on a very old computer, not using fedup, and this was for the download + install part, just to give a order of magnitude ( heck, i should really refrain from using evo during the night ) And for the 2 to 3h, I didn't look at the details, it was in the LUG meeting and the time between I gave the instruction and the time the person came back to me. While I think the exact time is not important, let me do a test to have more precise data, so my bad memories do not muddle the discussion ( as people around me say depend, maybe 1h, maybe more when asked about fedup ). -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Jan 24, 2013, at 10:42 PM, Matthew Garrett mj...@srcf.ucam.org wrote: Well, that's the problem. Most of our users (including many of the professional sysadmins) are *not* able to make a fully informed choice about whether an online upgrade will ensure that they're no longer running any code with known security issues. That's not a criticism of them - it's just a much harder problem than almost everyone realises. My Scottish co-author and dear friend referred to such cases as giving users razor blades, and telling them to go play on the freeway. After 1/2 dozen fedup upgrades during testing, on average the downtime portion of the upgrade was between 25 and 40 minutes. On a five year old laptop, with 4GB of RAM, and WDC Scorpio Blue rust drive (the new computer with SSD did the fedup upgrade in less than 10 minutes). Meanwhile, a yum upgrade involves a transition from download to upgrade without notification, concomitant with the potential for arbitrary and untimely implosion that could hose the entire upgrade. And this is on a supposedly important computer that can't be down for 2 hours? Umm? I really don't understand this thread. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Jan 25, 2013, at 9:20 PM, Sam Varshavchik mr...@courier-mta.com wrote: William Brown writes: In the future, hopefully once btrfs is a bit more mature, perhaps it could be considered to make a new writable snapshot subvolume of the system, and the use yum prefix to update the new subvolume. When you reboot, the new subvolume can become the new root. a) Currently running system files aren't affected. b) All upgrades are done online c) the update would merely be a switching of the root device on next reboot d) you could even roll-back by remounting the old root subvolume as the root fs. Now, what's not clear to me – what exactly happens if, say, at the same time I'm browsing the web at the same time, watching videos. That generates write activity, changes to the disk, so what happens to all other disk activity while the upgrade takes place. Disk contention, and things may be sluggish. Chances are your videos won't stutter, but I guess that depends on the video bit rate, effectiveness of disk and file system read ahead, and application buffering all are. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 26 Jan 2013, at 12:11, Chris Murphy wrote: After 1/2 dozen fedup upgrades during testing, on average the downtime portion of the upgrade was between 25 and 40 minutes. On a five year old laptop, with 4GB of RAM, and WDC Scorpio Blue rust drive (the new computer with SSD did the fedup upgrade in less than 10 minutes). Meanwhile, a yum upgrade involves a transition from download to upgrade without notification, concomitant with the potential for arbitrary and untimely implosion that could hose the entire upgrade. And this is on a supposedly important computer that can't be down for 2 hours? Umm? I really don't understand this thread. Over the years, I have yum upgraded remote boxes from RHL 7.3 to F16. On a remote yum upgrade, you can follow yum's progress -- see if it hangs, see any failure warnings, etc., fix what you can after it finishes -- then hold your breath when you reboot. If the box isn't back online within 2 minutes, you know you have a major problem and contact the data center immediately. If a fedup upgrade can go offline for a lengthy, but uncertain, amount of time, then the lack of feedback is worrying. You can't hold your breath for 25 minutes, you don't know when to conclude that you have a serious problem that will require help from the data center staff, and you don't have any idea where the process went off- track. If you could SSH into fedup during its offline period and get real time feedback about what it is doing and any errors it encounters, and perhaps the ability to fix any problems when it finishes but before it attempts to reboot, then it would be less scary for remote upgrades. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Jan 26, 2013, at 10:45 AM, Mike Pinkerton pseli...@mindspring.com wrote: If a fedup upgrade can go offline for a lengthy, but uncertain, amount of time, then the lack of feedback is worrying. You can't hold your breath for 25 minutes, you don't know when to conclude that you have a serious problem that will require help from the data center staff, and you don't have any idea where the process went off-track. I think the lack of feedback with fedup is a known weak area that needs improvement. I found that by deleting 'quiet rhgb' and adding one of the debug options to the fedup kenel at reboot time, I can get to a shell during the upgrade, and issue a: journalcti --follow And I get live updates throughout the process. I don't recall hang without some sort of feedback for more than maybe 5 minutes. I forget off hand if top and/or ps are available, I think at least one of them is. If you could SSH into fedup during its offline period and get real time feedback about what it is doing and any errors it encounters, and perhaps the ability to fix any problems when it finishes but before it attempts to reboot, then it would be less scary for remote upgrades. I haven't tried 'systemctl start sshd' during the upgrade to see what happens; it's probably not totally benign to do this, since ssh will be upgraded, but it seems a lot safer, vastly so, than a live yum update while a server is running. I don't know any company that allows major upgrades without user processes being required to quit. Apple and Microsoft both download and stage their upgrades, no user processes allowed, a partially upgraded system reboots, completes the primary upgrade tasks before user sessions are allowed again (and Windows might have one more reboot, I forget). Once upon a time, Apple allows user session to stay live during the installation of minor system software updates. They don't even do this anymore. Apparently it was so fraught with peril. So now, the download occurs in the background during the user session, and you have the option to being the install which also requires a restart. If you agree, you're logged out, user processes quit, the update begins, the system reboots. I just don't see how it's best practices to be doing updates on live processes. This seems sorta like a game to find out just how much one can cheat the upgrade process before the ship will in fact sink. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Jan 26, 2013, at 11:16 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 26.01.2013 19:09, schrieb Chris Murphy: I just don't see how it's best practices to be doing updates on live processes. This seems sorta like a game to find out just how much one can cheat the upgrade process before the ship will in fact sink. bullshit upgraded more than 20 production server from F9 to F18 with yum without any single problem because the upgrade takes around5 minutes and there are no new processes start most of the time and the few are nothing critical I think that's unicorn poop you're talking about. But hey, if you are ninja enough to avoid being cut by machine guns shooting razor blades at you, nice job. But asking other people make you an inflatable raft that can withstand being shot by razor blade shooting machine guns, write documentation for it, test, and support it? I will laugh out loud, and then give you the phone number for my unicorn dealer. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Am 25.01.2013 18:00, schrieb Nicolas Mailhot: Le Ven 25 janvier 2013 00:12, Lennart Poettering a écrit : Applications have deps on all kinds of data in /usr/lib, not just shared libraries. Such as locale data, icons, fonts, artwork, documentation. BTW Firefox seems to be the only application that goes bonkers when fonts are updated while it's running, so it looks more like a bug in Firefox's text rendering than a general problem to me and on the other hand i had longer time ago troubles with my systemdisk suddenly disappear until hard power off and more than one time i used firefox for half an hour because it had anything in the memory and freezed only if it should display a dialog with icons not loaded before proven by /var/log/ on a different disk with errors in a tail -f while all aplications worked for minutes and even VMware machines could be CLEAN powered off via SSH from a notebook as long they were on a different physical drive so no - it's not that bad doing updates while things running signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Am 25.01.2013 19:20, schrieb Lennart Poettering: Nonsense, for a distribution upgrade you just recommend the admin to reboot the system when done. Everybody expects to reboot after a big distro-sync anyway as there is a new kernel and basically new-everything. Ah, so you have to reboot anyway, so where is the difference between your approach and proper offline updates then? Either way you have to interrupt your work to reboot the machine. One just takes a slight bit longer for rebooting... i had enough anaconda upgrades which failed to boot after that by such things like missing initrd, missing rub-entry and so on to have learend i want a upgrade where i can VERIFY all this basic stuff, fix things, cleanup configurations, package-cleanup and AFTER THAT i reboot the machine guess - since i do it this way i survived calculated more than 300 dist-upgares with yum and not a single one had any problem coming up again, said that: from FC7 until F18 und the oldest setups are started with FC8 and now F18 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Am 25.01.2013 21:17, schrieb Jóhann B. Guðmundsson: On 01/25/2013 07:39 PM, Michał Piotrowski wrote: I use Fedora as a server system for my daily developer work. I use many services with different configurations. Actually updating it with preupgrade/fedup is sometimes hard. Reinstalling whole system after each release will be super painful. ? Keep your server configuration in git and keep the relevant data on separated partition then reinstall and checkout the config(s) which part of the configuration? all /etc - well this would be more damage than resolution :-) sorry but this does not work i have made some hundret dist-upgrades with yum over the years nearly zero downtime, normally not more as a kernel update with reboot well, i keep all my systems 100% clear but with reinstalls i had wasted so much more time the big benefit (especially in VM environments) is that the update goes so fast (as long you not install every bullshit) that the timeframe is to short to make any troubles for running services 4-7 minutes per instance here since years signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 26 Jan 2013, at 13:09, Chris Murphy wrote: On Jan 26, 2013, at 10:45 AM, Mike Pinkerton pseli...@mindspring.com wrote: If a fedup upgrade can go offline for a lengthy, but uncertain, amount of time, then the lack of feedback is worrying. You can't hold your breath for 25 minutes, you don't know when to conclude that you have a serious problem that will require help from the data center staff, and you don't have any idea where the process went off-track. I think the lack of feedback with fedup is a known weak area that needs improvement. I found that by deleting 'quiet rhgb' and adding one of the debug options to the fedup kenel at reboot time, I can get to a shell during the upgrade, and issue a: journalcti --follow And I get live updates throughout the process. I don't recall hang without some sort of feedback for more than maybe 5 minutes. I forget off hand if top and/or ps are available, I think at least one of them is. I can see how this would help when sitting in front of the box, but when you're hundreds or thousands of miles away, it isn't really an option. If you could SSH into fedup during its offline period and get real time feedback about what it is doing and any errors it encounters, and perhaps the ability to fix any problems when it finishes but before it attempts to reboot, then it would be less scary for remote upgrades. I haven't tried 'systemctl start sshd' during the upgrade to see what happens; it's probably not totally benign to do this, since ssh will be upgraded, but it seems a lot safer, vastly so, than a live yum update while a server is running. Would it work for the network and sshd to be run from the initramfs rather than the file system that is being updated? It would be nice if one could start fedup with a flag that would tell it to start the network and sshd upon reboot, and enable feedback to a remote user. That would make the process a lot less worrisome. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Le samedi 26 janvier 2013 à 15:20 -0500, Mike Pinkerton a écrit : On 26 Jan 2013, at 13:09, Chris Murphy wrote: On Jan 26, 2013, at 10:45 AM, Mike Pinkerton pseli...@mindspring.com wrote: If you could SSH into fedup during its offline period and get real time feedback about what it is doing and any errors it encounters, and perhaps the ability to fix any problems when it finishes but before it attempts to reboot, then it would be less scary for remote upgrades. I haven't tried 'systemctl start sshd' during the upgrade to see what happens; it's probably not totally benign to do this, since ssh will be upgraded, but it seems a lot safer, vastly so, than a live yum update while a server is running. Would it work for the network and sshd to be run from the initramfs rather than the file system that is being updated? Then you need to have the network configuration, etc. This can be done, but for now, the feature is not in dracut, see this bug for a similar request for encrypted root : https://bugzilla.redhat.com/show_bug.cgi?id=524727 -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
25.01.2013 22:27, Lennart Poettering пишет: On Fri, 25.01.13 13:02, Przemek Klosowski (przemek.klosow...@nist.gov) wrote: On 01/24/2013 06:12 PM, Lennart Poettering wrote: If you restart any of those you bring down the entire machine basically, or bring down at least the bits you really want to avoid, i.e. the user's sessions... Then all code that runs that is not a system service is difficult to restart from a system script. How do you plan to restart Evolution or Firefox, or Gimp? ... Of course, you could tell the user as last step of your script to please reboot now, but if you do that your update isn't online anymore, but is awfully close to real offline upgrades, except that during the upgrade period you have a ton of processes around that might be seriously confused by not being able to find their own resources anymore or in wrong versions... This is a pessimistic view but I think it's not as intractable. There are two separate aspects to it: discovery what needs to be restarted, and the actual process of restarting. The discovery is almost there: we know the resources (libs, files, etc) that were replaced, so it's a matter of walking the list of running processes and checking if they depend on those resources. I can see how transient I/O, including dlopen() could be tricky, but I don't think it's fundamentally impossible---at worst, it'd be implementing some sort of /proc/1234/history-of-opened-fd mechanism. That doesn't work. Let's say my app needs to display a certain icon in some dialog. The next version of that app doesn't need that icon anymore, so on upgrade the icon is deleted. At the same time the user is still running that app, and then enters the dialog. The app now looks for the icon, and doesn't find it. Bang. There is no sane way to determine all these dependencies, because many of them are never explicit, and only temporary in nature. Well written apps load a lot of resources lazily. That has the side effect that you can never know those deps, until they are actually needed. The icon thing is just one example, you can now extrapolate from that... Sorry but how such use case different from simple firefox update in current release when it happened parallel with browsing?? It may also lead to that unpredictable behavior. Off course you will say it shouldn't be major release in stable Fedora. And off course it is true. But anyone can't guaranty what even change or delete 1 file do not lead to unstable app. So for that cases graphical application similar to PackageKit suggests user reboot (and may suggest only reload certain apps) with list of apps, based on maintainers expectation from (suggest reboot in bodhi update system). I hope you do not suggest force reload such apps for user of force always offline update for that thinks. In that point of view online distro update differs only by amount of updated packages which suggest reboot for user. And I may himself plan reboot when I want... -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Fri, 2013-01-25 at 05:42 +, Matthew Garrett wrote: On Thu, Jan 24, 2013 at 11:46:24PM -0500, Simo Sorce wrote: We are all grown up enough to decide for our own, just give the information and let the admin take care of that. Well, that's the problem. Most of our users (including many of the professional sysadmins) are *not* able to make a fully informed choice about whether an online upgrade will ensure that they're no longer running any code with known security issues. That's not a criticism of them - it's just a much harder problem than almost everyone realises. Nobody's suggesting making it impossible to use yum, but blessing it as a first-class distribution upgrade mechanism is a bad idea. There's far too many corner cases, and we can't justify the effort it'd take to fix all of them. Nonsense, for a distribution upgrade you just recommend the admin to reboot the system when done. Everybody expects to reboot after a big distro-sync anyway as there is a new kernel and basically new-everything. But I said my points, I won't argue anymore. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Chris Adams wrote: The way some other Unix OSes I've used worked for version upgrades was to require the admin drop to single-user mode first, optionally with network access. RHL/RHEL/Fedora have never had a single-user with network mode, but that would be nice to have. Then maybe yum upgrade could require (or at least recommend) switching to that mode first. Isn't that essentially what Fedup does? Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Am 25.01.2013 05:46, schrieb Simo Sorce: That said I think trying a distro-sync from a graphical session is just a funny and instructive experience, I wouldn't recommend it as you'll keep the pieces when your session blows up and brings with it your yum upgrade, but it is certainly instructive :) even this is no problem screen is your friend did it multiple times well, there are times due the upgrade where things behave strange, but webbrowsing is fine and even if firefox gets unstable, just restart it the point of distro-sync is to give advanced users a upgrade option where they decide by theirself what they are doing signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Le Ven 25 janvier 2013 00:12, Lennart Poettering a écrit : Applications have deps on all kinds of data in /usr/lib, not just shared libraries. Such as locale data, icons, fonts, artwork, documentation. BTW Firefox seems to be the only application that goes bonkers when fonts are updated while it's running, so it looks more like a bug in Firefox's text rendering than a general problem to me -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 01/24/2013 06:12 PM, Lennart Poettering wrote: If you restart any of those you bring down the entire machine basically, or bring down at least the bits you really want to avoid, i.e. the user's sessions... Then all code that runs that is not a system service is difficult to restart from a system script. How do you plan to restart Evolution or Firefox, or Gimp? ... Of course, you could tell the user as last step of your script to please reboot now, but if you do that your update isn't online anymore, but is awfully close to real offline upgrades, except that during the upgrade period you have a ton of processes around that might be seriously confused by not being able to find their own resources anymore or in wrong versions... This is a pessimistic view but I think it's not as intractable. There are two separate aspects to it: discovery what needs to be restarted, and the actual process of restarting. The discovery is almost there: we know the resources (libs, files, etc) that were replaced, so it's a matter of walking the list of running processes and checking if they depend on those resources. I can see how transient I/O, including dlopen() could be tricky, but I don't think it's fundamentally impossible---at worst, it'd be implementing some sort of /proc/1234/history-of-opened-fd mechanism. That leaves the restarting: again it seems to me that is not as hopeless as you make it sound, either: kernel is hardest but even there people are working on ksplice. Many services are designed to be restarted, like DHCPD which doesn't even have an online reload but has to be bounced if the DHCP data file changes. Regular process restart is of course application dependent, but e.g. Firefox actually restarts relatively graciously: I just killed mine and the new instance reopened all my tabs (a pleasant surprise--I expected the Restore Session (Well this is embarrassing) window I was used to). Maybe there is a couple of classes that the restart falls into: - no problems restarting anytime - availability problems but no data loss on restart (easy restart but maybe needs user confirmation) - some out-of-process support needed (file rotation/cleanup, etc) - user intervention required (saving files, etc). I believe that seamless upgrades are an attractive goal. I am not arguing for infinite upgrades---only a fresh install can guarantee getting all new technologies that one wouldn't get through upgrades because they may not even existed at the original installation. My point is that the reinstall decision should be in principle driven by the user, not by the OS release schedule. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 01/24/2013 06:12 PM, Lennart Poettering wrote: If you restart any of those you bring down the entire machine basically, or bring down at least the bits you really want to avoid, i.e. the user's sessions... Then all code that runs that is not a system service is difficult to restart from a system script. How do you plan to restart Evolution or Firefox, or Gimp? ... Of course, you could tell the user as last step of your script to please reboot now, but if you do that your update isn't online anymore, but is awfully close to real offline upgrades, except that during the upgrade period you have a ton of processes around that might be seriously confused by not being able to find their own resources anymore or in wrong versions... This is a pessimistic view but I think it's not as intractable. There are two separate aspects to it: discovery what needs to be restarted, and the actual process of restarting. The discovery is almost there: we know the resources (libs, files, etc) that were replaced, so it's a matter of walking the list of running processes and checking if they depend on those resources. I can see how transient I/O, including dlopen() could be tricky, but I don't think it's fundamentally impossible---at worst, it'd be implementing some sort of /proc/1234/history-of-opened-fd mechanism. That leaves the restarting: again it seems to me that is not as hopeless as you make it sound, either: kernel is hardest but even there people are working on ksplice. Many services are designed to be restarted, like DHCPD which doesn't even have an online reload but has to be bounced if the DHCP data file changes. Regular process restart is of course application dependent, but e.g. Firefox actually restarts relatively graciously: I just killed mine and the new instance reopened all my tabs (a pleasant surprise--I expected the Restore Session (Well this is embarrassing) window I was used to). Maybe there is a couple of classes that the restart falls into: - no problems restarting anytime - availability problems but no data loss on restart (easy restart but maybe needs user confirmation) - some out-of-process support needed (file rotation/cleanup, etc) - user intervention required (saving files, etc). I believe that seamless upgrades are an attractive goal. I am not arguing for infinite upgrades---only a fresh install can guarantee getting all new technologies that one wouldn't get through upgrades because they may not even existed at the original installation. My point is that the reinstall decision should be in principle driven by the user, not by the OS release schedule. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Fri, 25.01.13 08:58, Simo Sorce (s...@redhat.com) wrote: On Fri, 2013-01-25 at 05:42 +, Matthew Garrett wrote: On Thu, Jan 24, 2013 at 11:46:24PM -0500, Simo Sorce wrote: We are all grown up enough to decide for our own, just give the information and let the admin take care of that. Well, that's the problem. Most of our users (including many of the professional sysadmins) are *not* able to make a fully informed choice about whether an online upgrade will ensure that they're no longer running any code with known security issues. That's not a criticism of them - it's just a much harder problem than almost everyone realises. Nobody's suggesting making it impossible to use yum, but blessing it as a first-class distribution upgrade mechanism is a bad idea. There's far too many corner cases, and we can't justify the effort it'd take to fix all of them. Nonsense, for a distribution upgrade you just recommend the admin to reboot the system when done. Everybody expects to reboot after a big distro-sync anyway as there is a new kernel and basically new-everything. Ah, so you have to reboot anyway, so where is the difference between your approach and proper offline updates then? Either way you have to interrupt your work to reboot the machine. One just takes a slight bit longer for rebooting... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Fri, 25.01.13 13:02, Przemek Klosowski (przemek.klosow...@nist.gov) wrote: On 01/24/2013 06:12 PM, Lennart Poettering wrote: If you restart any of those you bring down the entire machine basically, or bring down at least the bits you really want to avoid, i.e. the user's sessions... Then all code that runs that is not a system service is difficult to restart from a system script. How do you plan to restart Evolution or Firefox, or Gimp? ... Of course, you could tell the user as last step of your script to please reboot now, but if you do that your update isn't online anymore, but is awfully close to real offline upgrades, except that during the upgrade period you have a ton of processes around that might be seriously confused by not being able to find their own resources anymore or in wrong versions... This is a pessimistic view but I think it's not as intractable. There are two separate aspects to it: discovery what needs to be restarted, and the actual process of restarting. The discovery is almost there: we know the resources (libs, files, etc) that were replaced, so it's a matter of walking the list of running processes and checking if they depend on those resources. I can see how transient I/O, including dlopen() could be tricky, but I don't think it's fundamentally impossible---at worst, it'd be implementing some sort of /proc/1234/history-of-opened-fd mechanism. That doesn't work. Let's say my app needs to display a certain icon in some dialog. The next version of that app doesn't need that icon anymore, so on upgrade the icon is deleted. At the same time the user is still running that app, and then enters the dialog. The app now looks for the icon, and doesn't find it. Bang. There is no sane way to determine all these dependencies, because many of them are never explicit, and only temporary in nature. Well written apps load a lot of resources lazily. That has the side effect that you can never know those deps, until they are actually needed. The icon thing is just one example, you can now extrapolate from that... That leaves the restarting: again it seems to me that is not as hopeless as you make it sound, either: kernel is hardest but even there people are working on ksplice. Many services are designed to be restarted, like DHCPD which doesn't even have an online reload but has to be bounced if the DHCP data file changes. kernel is hardest? Yuck. Kernel is not feasible. And much of the rest isn't either. I'll wait your patches for the kernel to allow seamless upgrades of the kernel without reboots. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Lennart Poettering (mzerq...@0pointer.de) said: I'll wait your patches for the kernel to allow seamless upgrades of the kernel without reboots. Sure, just have a ksplice server that generates splices for each new kernel build relative to the previous one, and your upgrade process downloads all of the series of splices and applies them. Voila! The ksplice series from 2.6.18 to 3.7 will be loads of fun. Bill (NOTE: THIS IS NOT A SERIOUS IDEA.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
My point is that it'd be nice to improve the upgrades. I love
upgrades---I love the shiny new toys and I hate them for the disruption
they always bring, at someone else's schedule. As you say, there are
good reasons why it's what it is now, and maybe you're right that it
can't be significantly changed. I am just trying to think what COULD be
done, because such improvements would benefit regular updates ('yum
update') as well.
On 01/25/2013 01:27 PM, Lennart Poettering wrote:
There is no sane way to determine all these dependencies, because many
of them are never explicit, and only temporary in nature. Well written
apps load a lot of resources lazily. That has the side effect that you
can never know those deps, until they are actually needed.
You are right, can't be solved with the simplistic approach I
discussed--it would have to be more complex than that. This of course
is true of any upgrade, even the routine 'yum update', so improving this
situation is desirable even if one disagrees about distribution upgrades.
We know what resources we had and what we replaced them with. Perhaps we
could at least tag the running processes that will need restarting and
notify the users/administrators.
kernel is hardest? Yuck. Kernel is not feasible. And much of the rest
isn't either.
So kernel is out. DHCP is definitely possible. The others are somewhere
in between. My point again is that I think the upgrades are a sore point
for the users and it'd be nice to improve the process. If indeed this
can't be done properly, then the second best is a fall-back of having
the infrastructure to do it anyway and notify the user about which
pieces need special attention.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Fri, 2013-01-25 at 19:20 +0100, Lennart Poettering wrote: On Fri, 25.01.13 08:58, Simo Sorce (s...@redhat.com) wrote: On Fri, 2013-01-25 at 05:42 +, Matthew Garrett wrote: On Thu, Jan 24, 2013 at 11:46:24PM -0500, Simo Sorce wrote: We are all grown up enough to decide for our own, just give the information and let the admin take care of that. Well, that's the problem. Most of our users (including many of the professional sysadmins) are *not* able to make a fully informed choice about whether an online upgrade will ensure that they're no longer running any code with known security issues. That's not a criticism of them - it's just a much harder problem than almost everyone realises. Nobody's suggesting making it impossible to use yum, but blessing it as a first-class distribution upgrade mechanism is a bad idea. There's far too many corner cases, and we can't justify the effort it'd take to fix all of them. Nonsense, for a distribution upgrade you just recommend the admin to reboot the system when done. Everybody expects to reboot after a big distro-sync anyway as there is a new kernel and basically new-everything. Ah, so you have to reboot anyway, so where is the difference between your approach and proper offline updates then? Either way you have to interrupt your work to reboot the machine. One just takes a slight bit longer for rebooting... A) One single reboot you do after not upfront. If you are on a server logged in via ssh you can often keep doing some work while most of the system is being updated and you can more easily remote updates. B) I will *not* trust an update system that cuts me out of my remote server and make me *hope* it will come up later. If yum freaks out for *whatever* reason I want to be there with an emergency shell open via ssh to try to recover the system. Not have to call the colocation and figure out what happened from possibly missing logs *if the system boots at all*. I've been saved more than once by a shell open during changes in the configuration or upgrades, that is non-negotiable to me. C) Not all updates require immediate reboot. If I am updating the kernel and some minor package, I can as well decide to reboot at the end of the day, rarely the update is so critical I have to reboot NOW! Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Fri, Jan 25, 2013 at 14:22:44 -0500,
Przemek Klosowski przemek.klosow...@nist.gov wrote:
My point is that it'd be nice to improve the upgrades. I love
upgrades---I love the shiny new toys and I hate them for the
disruption they always bring, at someone else's schedule. As you say,
there are good reasons why it's what it is now, and maybe you're
right that it can't be significantly changed. I am just trying to
think what COULD be done, because such improvements would benefit
regular updates ('yum update') as well.
Sure any help getting stuff properly obsoleted and the like is good. I don't
think we really want it to be a feaure though.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Hi, 2013/1/23 Jóhann B. Guðmundsson johan...@gmail.com: On 01/23/2013 10:55 PM, drago01 wrote: Supporting none is not an option. Really suddenly not an option. We did that for a long time why is that suddenly not an option so please enlighten me why that's not an option. Users are better of keeping /home on a separated partition and re-use it with an fresh install then those poor attempts to support upgrades one way or another which at this point in time we cant do since the bits for that aren't properly aligned to make that happen... ? 8-) I really can't imagine it. I use Fedora as a server system for my daily developer work. I use many services with different configurations. Actually updating it with preupgrade/fedup is sometimes hard. Reinstalling whole system after each release will be super painful. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ https://getactive.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 01/25/2013 07:39 PM, Michał Piotrowski wrote: Hi, 2013/1/23 Jóhann B. Guðmundsson johan...@gmail.com: On 01/23/2013 10:55 PM, drago01 wrote: Supporting none is not an option. Really suddenly not an option. We did that for a long time why is that suddenly not an option so please enlighten me why that's not an option. Users are better of keeping /home on a separated partition and re-use it with an fresh install then those poor attempts to support upgrades one way or another which at this point in time we cant do since the bits for that aren't properly aligned to make that happen... ? 8-) I really can't imagine it. I use Fedora as a server system for my daily developer work. I use many services with different configurations. Actually updating it with preupgrade/fedup is sometimes hard. Reinstalling whole system after each release will be super painful. ? Keep your server configuration in git and keep the relevant data on separated partition then reinstall and checkout the config(s) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Fri, 2013-01-25 at 20:17 +, Jóhann B. Guðmundsson wrote: On 01/25/2013 07:39 PM, Michał Piotrowski wrote: Hi, 2013/1/23 Jóhann B. Guðmundsson johan...@gmail.com: On 01/23/2013 10:55 PM, drago01 wrote: Supporting none is not an option. Really suddenly not an option. We did that for a long time why is that suddenly not an option so please enlighten me why that's not an option. Users are better of keeping /home on a separated partition and re-use it with an fresh install then those poor attempts to support upgrades one way or another which at this point in time we cant do since the bits for that aren't properly aligned to make that happen... ? 8-) I really can't imagine it. I use Fedora as a server system for my daily developer work. I use many services with different configurations. Actually updating it with preupgrade/fedup is sometimes hard. Reinstalling whole system after each release will be super painful. ? Keep your server configuration in git and keep the relevant data on separated partition then reinstall and checkout the config(s) Why should I do all this when I can simply apt-get upgrade^W^Wyum upgrade ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 01/25/2013 08:32 PM, Simo Sorce wrote: On Fri, 2013-01-25 at 20:17 +, Jóhann B. Guðmundsson wrote: On 01/25/2013 07:39 PM, Michał Piotrowski wrote: Hi, 2013/1/23 Jóhann B. Guðmundsson johan...@gmail.com: On 01/23/2013 10:55 PM, drago01 wrote: Supporting none is not an option. Really suddenly not an option. We did that for a long time why is that suddenly not an option so please enlighten me why that's not an option. Users are better of keeping /home on a separated partition and re-use it with an fresh install then those poor attempts to support upgrades one way or another which at this point in time we cant do since the bits for that aren't properly aligned to make that happen... ? 8-) I really can't imagine it. I use Fedora as a server system for my daily developer work. I use many services with different configurations. Actually updating it with preupgrade/fedup is sometimes hard. Reinstalling whole system after each release will be super painful. ? Keep your server configuration in git and keep the relevant data on separated partition then reinstall and checkout the config(s) Why should I do all this when I can simply apt-get upgrade^W^Wyum upgrade ? You do whatever floats your boat I prefer doing fresh installs and keep relevant data on their own partitions and configuration files in git you prefer to do it via yum or fedupgrade. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Simo Sorce s...@redhat.com writes: [...] B) I will *not* trust an update system that cuts me out of my remote server and make me *hope* it will come up later. If yum freaks out for *whatever* reason I want to be there with an emergency shell open [...] I've been saved more than once by a shell open during changes in the configuration or upgrades, that is non-negotiable to me. [...] I agree that this capability is very important. - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Fri, Jan 25, 2013 at 03:51:14PM -0500, Frank Ch. Eigler wrote: Simo Sorce s...@redhat.com writes: [...] B) I will *not* trust an update system that cuts me out of my remote server and make me *hope* it will come up later. If yum freaks out for *whatever* reason I want to be there with an emergency shell open [...] I've been saved more than once by a shell open during changes in the configuration or upgrades, that is non-negotiable to me. [...] I agree that this capability is very important. Nobody has suggested removing it. It'll continue to work as well (or as badly, if you prefer) as it currently does. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 25 Jan 2013, at 14:23, Simo Sorce wrote: Ah, so you have to reboot anyway, so where is the difference between your approach and proper offline updates then? Either way you have to interrupt your work to reboot the machine. One just takes a slight bit longer for rebooting... A) One single reboot you do after not upfront. If you are on a server logged in via ssh you can often keep doing some work while most of the system is being updated and you can more easily remote updates. B) I will *not* trust an update system that cuts me out of my remote server and make me *hope* it will come up later. If yum freaks out for *whatever* reason I want to be there with an emergency shell open via ssh to try to recover the system. Not have to call the colocation and figure out what happened from possibly missing logs *if the system boots at all*. I've been saved more than once by a shell open during changes in the configuration or upgrades, that is non-negotiable to me. I do the same for the same reasons. C) Not all updates require immediate reboot. If I am updating the kernel and some minor package, I can as well decide to reboot at the end of the day, rarely the update is so critical I have to reboot NOW! For normal updates, yes. But I would not start an upgrade from one Fedora release to another at an inconvenient time and then wait to reboot hours later. In this discussion of whether yum upgrade would be enhanced alongside FedUp, I had assumed that FedUp would only be used for upgrading from one Fedora release to the next, not for regular software updates. Is that assumption wrong? -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Fri, 2013-01-25 at 21:57 +, Matthew Garrett wrote: On Fri, Jan 25, 2013 at 03:51:14PM -0500, Frank Ch. Eigler wrote: Simo Sorce s...@redhat.com writes: [...] B) I will *not* trust an update system that cuts me out of my remote server and make me *hope* it will come up later. If yum freaks out for *whatever* reason I want to be there with an emergency shell open [...] I've been saved more than once by a shell open during changes in the configuration or upgrades, that is non-negotiable to me. [...] I agree that this capability is very important. Nobody has suggested removing it. It'll continue to work as well (or as badly, if you prefer) as it currently does. Unfortunately, lately I have the impression you need to state even obvious things very clearly lest they are removed 'to improve' the system. So, just making it clear. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Le vendredi 25 janvier 2013 à 19:20 +0100, Lennart Poettering a écrit : Ah, so you have to reboot anyway, so where is the difference between your approach and proper offline updates then? Either way you have to interrupt your work to reboot the machine. One just takes a slight bit longer for rebooting... Well, slightly bit longer is around 2 to 3h vs 2 to 3 minutes. And I already did version upgrade taking 6 to 8h due to slow internet or slow hard drives, that's IMHO a pretty significant downtime. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Proposed F19 Feature: Fedora Upgrade - using yum
Ah, so you have to reboot anyway, so where is the difference between your approach and proper offline updates then? Either way you have to interrupt your work to reboot the machine. One just takes a slight bit longer for rebooting... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel In the future, hopefully once btrfs is a bit more mature, perhaps it could be considered to make a new writable snapshot subvolume of the system, and the use yum prefix to update the new subvolume. When you reboot, the new subvolume can become the new root. a) Currently running system files aren't affected. b) All upgrades are done online c) the update would merely be a switching of the root device on next reboot d) you could even roll-back by remounting the old root subvolume as the root fs. This would be similar to boot environments in solaris. Of course, if btrfs wasn't in use, there could be some fallback? -- Sincerely, William Brown pgp.mit.edu http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x3C0AC6DAB2F928A2 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
William Brown writes: In the future, hopefully once btrfs is a bit more mature, perhaps it could be considered to make a new writable snapshot subvolume of the system, and the use yum prefix to update the new subvolume. When you reboot, the new subvolume can become the new root. a) Currently running system files aren't affected. b) All upgrades are done online c) the update would merely be a switching of the root device on next reboot d) you could even roll-back by remounting the old root subvolume as the root fs. Now, what's not clear to me – what exactly happens if, say, at the same time I'm browsing the web at the same time, watching videos. That generates write activity, changes to the disk, so what happens to all other disk activity while the upgrade takes place. pgptHlX9MhB8U.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Proposed F19 Feature: Fedora Upgrade - using yum
Once upon a time, William Brown will...@firstyear.id.au said: In the future, hopefully once btrfs is a bit more mature, perhaps it could be considered to make a new writable snapshot subvolume of the system, and the use yum prefix to update the new subvolume. When you reboot, the new subvolume can become the new root. Even that won't help when there are kernel updates that move kernel filesystems around (like some things have moved from their own top-level mountpoints to under /sys). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Sat, Jan 26, 2013 at 02:16:29AM +0100, Michael Scherer wrote: Well, slightly bit longer is around 2 to 3h vs 2 to 3 minutes. And I already did version upgrade taking 6 to 8h due to slow internet or slow hard drives, that's IMHO a pretty significant downtime. fedup does all network activity before reboot, so presumably you're talking about some upgrade system other than the currently supported one? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Wed, Jan 23, 2013 at 11:57 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 01/23/2013 10:55 PM, drago01 wrote: Supporting none is not an option. Really suddenly not an option. We did that for a long time why is that suddenly not an option so please enlighten me why that's not an option. It was supported as long as fedora exists (and back in RHL days). Users are better of keeping /home on a separated partition and re-use it with an fresh install And loose all other configuration, having to reinstall every application etc etc. then those poor attempts to support upgrades one way or another which at this point in time we cant do We can and always did. since the bits for that aren't properly aligned to make that happen... Works for me ... I always upgrade my systems ... if it does not work for you for whatever reason file bugs and don't claim that it is inherently impossible because isn't. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Wed, Jan 23, 2013 at 10:14:28PM -0800, Adam Williamson wrote: (As a side note, I would like to avoid describing fedup as 'officially supported' and describe it instead as 'officially recommended' - it's an important semantic difference, I think.) Because we don't officially support anything, or because it has lesser status than, say, doing a fresh install and preserving home? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Once upon a time, Adam Williamson awill...@redhat.com said: Several knowledgeable developers have asserted that - while it often happens to work out okay - online upgrading is an inherently dangerous operation, I don't see that the limited amount of validation QA is able to offer can possibly gainsay them. The way some other Unix OSes I've used worked for version upgrades was to require the admin drop to single-user mode first, optionally with network access. RHL/RHEL/Fedora have never had a single-user with network mode, but that would be nice to have. Then maybe yum upgrade could require (or at least recommend) switching to that mode first. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 01/23/2013 07:50 PM, Lennart Poettering wrote: The thing is that doing on-line updates only works for stuff you can restart, and that doesn't mind that things are not atomically updated. However, much (most?) of our code isn't like that. Anybody who What could not be restarted? And what we can do to fix that? If this work for Debian/Ubuntu, why it could not work for Fedora? tried to update the Firefox RPM while it is running knows that this doesn't end well, and you frequently have to manually kill firefox to get it back into a usual state. Interesting. Although I'm doing yum upgrade quite frequently I do not have such experience. -- Miroslav Suchy Red Hat Systems Management Engineering -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Miroslav Suchý (msu...@redhat.com) said: On 01/23/2013 07:50 PM, Lennart Poettering wrote: The thing is that doing on-line updates only works for stuff you can restart, and that doesn't mind that things are not atomically updated. However, much (most?) of our code isn't like that. Anybody who What could not be restarted? And what we can do to fix that? If this work for Debian/Ubuntu, why it could not work for Fedora? Essentially, the idea of a major release is to do the sorts of upgrades that don't work cleanly on a running system. Examples would be: - mysql database version upgrade (or similar upgrades that require a format conversion) - switching out the system python interpreter version - switching from a static /dev to udev - switching init systems - switching a script from being sysv to being a systemd service - refactoring of a systemd service if necessary - /usr move - introduction of changes that require a new kernel subsystem mount point, or the move of one (/selinux to /sys/fs/selinux, for example) None of these things are things that will work perfectly reliably in an on-line upgrade mechanism. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Wed, 23.01.13 22:17, Adam Williamson (awill...@redhat.com) wrote: On Wed, 2013-01-23 at 19:47 -0600, Bruno Wolff III wrote: On Wed, Jan 23, 2013 at 22:47:18 +, \Jóhann B. Guðmundsson\ johan...@gmail.com wrote: b) We QA have alot of QA community members testing this so this does NOT require any additional effort or cause additional LOAD on the QA community. Aren't they just testing an upgrade of the default install? Correct: https://fedoraproject.org/wiki/QA:Testcase_upgrade_fedup_cli_previous_desktop is the only current upgrade test case. We could plausibly extend the range somewhat to cover common package loadouts (GNOME, KDE, minimal perhaps) and common configuration wrinkles (non-US keyboard layout, encryption, a couple of different partition schemes), for _one_ upgrade method. Anything beyond that would be a bit of a stretch, I think. Wouldn't it make sense to test the full install? In contrast to other distributions it should be possible to install all our RPMs at once (modulo arch specific ones that is). If that thing upgrades properly, then you have a pretty good chance it will work for most subsets too? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Thu, Jan 24, 2013 at 6:11 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 23.01.13 22:17, Adam Williamson (awill...@redhat.com) wrote: On Wed, 2013-01-23 at 19:47 -0600, Bruno Wolff III wrote: On Wed, Jan 23, 2013 at 22:47:18 +, \Jóhann B. Guðmundsson\ johan...@gmail.com wrote: b) We QA have alot of QA community members testing this so this does NOT require any additional effort or cause additional LOAD on the QA community. Aren't they just testing an upgrade of the default install? Correct: https://fedoraproject.org/wiki/QA:Testcase_upgrade_fedup_cli_previous_desktop is the only current upgrade test case. We could plausibly extend the range somewhat to cover common package loadouts (GNOME, KDE, minimal perhaps) and common configuration wrinkles (non-US keyboard layout, encryption, a couple of different partition schemes), for _one_ upgrade method. Anything beyond that would be a bit of a stretch, I think. Wouldn't it make sense to test the full install? I doubt that you can install all packages without hitting conflicts. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 24 January 2013 10:25, drago01 drag...@gmail.com wrote: On Thu, Jan 24, 2013 at 6:11 PM, Lennart Poettering Wouldn't it make sense to test the full install? I doubt that you can install all packages without hitting conflicts. You can not. Lots of things conflict so if you try to do a 'yum install *' you get a LOT of different conflicts from say stuff requiring mod_ssl versus nss or gnutls etc. -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Thu, 24.01.13 15:28, Miroslav Suchý (msu...@redhat.com) wrote: On 01/23/2013 07:50 PM, Lennart Poettering wrote: The thing is that doing on-line updates only works for stuff you can restart, and that doesn't mind that things are not atomically updated. However, much (most?) of our code isn't like that. Anybody who What could not be restarted? And what we can do to fix that? The kernel for starters, dbus too, bash, ssh daemon processes of open connections, gdm, ... If you restart any of those you bring down the entire machine basically, or bring down at least the bits you really want to avoid, i.e. the user's sessions... Then all code that runs that is not a system service is difficult to restart from a system script. How do you plan to restart Evolution or Firefox, or Gimp? Of course, you can say that it's OK if those processes just stay running, and then are updated when the user reboots the machine the next time, or restarts his apps the next time, or logs out and back in the next time, but until then you have versions of these programs in memory that might not be able to find their own resources anymore, because those got replaced, or they might find them in different versions than they might expect. But let's pretend for a minute that there was a way how you could restart the kernel, dbus, and everything else without taking the machine or user session down, how would you figure out *what* precisely you need to restart? There are some scripts floating around that try to figure that out via ldd, but that's very incomplete, because that assumes the only kind of dependency that was relevant were shared library deps -- but there are more than that and in times of dlopen() ldd doesn't work comprehensively for those anyway. Applications have deps on all kinds of data in /usr/lib, not just shared libraries. Such as locale data, icons, fonts, artwork, documentation. And much of that might be continously mapped into memory, and others only temporarily. How are you going to figure out that? I mean, here's an example: let's say openssl is updated, which is pulled in by a ton of other things, for example the libc NSS LDAP module. The libc NSS is used by at least half of all processes running on your system, and they all dlopen() the NSS module. So how do you now figure out which ones that are and how do you then figure out what the heck you need to do to get them restarted? So, you can ignore all of that, but then you have to think about what you actually accomplished by your upgrade? You updated a couple of libraries, and maybe managed to restart a few processes using them, but for the rest of them the vulnerable openssl version is still in memory, still actively used, even though your update script exited successfully leaving the user under the impression that all was good now and that after he made this upgrade his machine was not vulnerable anymore. So you kinda promised the user online updates, but you actually just updated a number of things, and leaving the biggest chunk of code in memory still, without a chance to restart it or even figure out what it is that you left unrestarted. Of course, you could tell the user as last step of your script to please reboot now, but if you do that your update isn't online anymore, but is awfully close to real offline upgrades, except that during the upgrade period you have a ton of processes around that might be seriously confused by not being able to find their own resources anymore or in wrong versions... If this work for Debian/Ubuntu, why it could not work for Fedora? Will, because it doesn't work for them either. It works well enough for the knowledgeable, and that's what they focus on. I mean, just think about it: every new Fedora release sofar came with a new kernel version. The only way how to upgrade the kernel probably is by taking the machine offline for a while and rebooting. If you are willing to ignore everything I said above, how would your script keep the machine online during a kernel upgrade? tried to update the Firefox RPM while it is running knows that this doesn't end well, and you frequently have to manually kill firefox to get it back into a usual state. Interesting. Although I'm doing yum upgrade quite frequently I do not have such experience. Well, sooner or later you'll run into that with Firefox, or with some other app. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Thu, 2013-01-24 at 08:56 -0500, Matthew Miller wrote: On Wed, Jan 23, 2013 at 10:14:28PM -0800, Adam Williamson wrote: (As a side note, I would like to avoid describing fedup as 'officially supported' and describe it instead as 'officially recommended' - it's an important semantic difference, I think.) Because we don't officially support anything, or because it has lesser status than, say, doing a fresh install and preserving home? Because we don't 'officially support' anything, correct. When someone files a bug on upgrade our usual response is not to fix it immediately and try to help them recover their borked system, our usual response tends to be to file it in the same place as Arthur Dent's local council filed their bypass designs... being less flippant, it's really just that upgrade is inherently an operation that a project like Fedora can't really 'support'. It's always going to be best effort and it's probably going to break for some people. 'Recommend' just seems like a better verb. I would suggest this, frankly, whatever the method in question is. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Thu, 2013-01-24 at 18:11 +0100, Lennart Poettering wrote: On Wed, 23.01.13 22:17, Adam Williamson (awill...@redhat.com) wrote: On Wed, 2013-01-23 at 19:47 -0600, Bruno Wolff III wrote: On Wed, Jan 23, 2013 at 22:47:18 +, \Jóhann B. Guðmundsson\ johan...@gmail.com wrote: b) We QA have alot of QA community members testing this so this does NOT require any additional effort or cause additional LOAD on the QA community. Aren't they just testing an upgrade of the default install? Correct: https://fedoraproject.org/wiki/QA:Testcase_upgrade_fedup_cli_previous_desktop is the only current upgrade test case. We could plausibly extend the range somewhat to cover common package loadouts (GNOME, KDE, minimal perhaps) and common configuration wrinkles (non-US keyboard layout, encryption, a couple of different partition schemes), for _one_ upgrade method. Anything beyond that would be a bit of a stretch, I think. Wouldn't it make sense to test the full install? In contrast to other distributions it should be possible to install all our RPMs at once (modulo arch specific ones that is). If that thing upgrades properly, then you have a pretty good chance it will work for most subsets too? It's probably a useful test case to add, yeah, but I can think of several scenarios where it wouldn't cover things (by definition it probably wouldn't catch cases where a necessary dependency was missing in an upgraded package, for instance :). It helps to some degree to cover against issues in the package set, but it still doesn't innoculate us against configuration differences - hardware borking between kernel releases, different partition layouts etc. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Fri, 2013-01-25 at 00:12 +0100, Lennart Poettering wrote: I mean, here's an example: let's say openssl is updated, which is pulled in by a ton of other things, for example the libc NSS LDAP module. The libc NSS is used by at least half of all processes running on your system, and they all dlopen() the NSS module. So how do you now figure out which ones that are and how do you then figure out what the heck you need to do to get them restarted? A) there is no 'libc NSS LDAP module', nss_ldap is not part of libc and is also deprecated on its own in favor of nss_ldapd and others. B) Luckily we solved this case with SSSD, and this is exactly one of the use cases we wanted to solve with it. The sssd client side that gets loaded in processes has been made extremely simple and the protocol fixed in stone exactly so that you can upgrade SSSD and it's dependencies and even change sssd's configuration w/o having to restart applications. So I would remove the nsswitch problem, for the most part (we still have some nsswitch things sssd does not handle like hostname resolution, but we may take that over as well if really necessary. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Thu, 24.01.13 21:15, Simo Sorce (s...@redhat.com) wrote: On Fri, 2013-01-25 at 00:12 +0100, Lennart Poettering wrote: I mean, here's an example: let's say openssl is updated, which is pulled in by a ton of other things, for example the libc NSS LDAP module. The libc NSS is used by at least half of all processes running on your system, and they all dlopen() the NSS module. So how do you now figure out which ones that are and how do you then figure out what the heck you need to do to get them restarted? A) there is no 'libc NSS LDAP module', nss_ldap is not part of libc and is also deprecated on its own in favor of nss_ldapd and others. Not part of libc? uh? no, of course not. It's still a module that is loaded into libc via the libc NSS scheme, which is the point I am making here... And anyway you are missing the point here... this is just an example. It's not particularly hard to come up with a different example. Just think of some other NSS module, that uses some library. Because of NSS its's loaded into half of our processes, all they have to do is invoke gethostbyname() and the module and all depending libaries are mapped in, and how would ever detect that? B) Luckily we solved this case with SSSD, and this is exactly one of the use cases we wanted to solve with it. The sssd client side that gets loaded in processes has been made extremely simple and the protocol fixed in stone exactly so that you can upgrade SSSD and it's dependencies and even change sssd's configuration w/o having to restart applications. Well you fixed a tiny facet of the issue. As it turns out however sssd is not the only service we ship, is not the only package we ship, it's not the only NSS module we ship, and update nss_sssd is still not possible either... So I would remove the nsswitch problem, for the most part (we still have some nsswitch things sssd does not handle like hostname resolution, but we may take that over as well if really necessary. Dude, sssd is not the only NSS module in the world, and NSS not the only interface that uses dlopen(). Look at PAM, at gstreamer loading codecs, at iconv loading char maps, gtk loading gtk modules, pulseaudio loading pa modules, python loading any module, apache loading a module, gvfs loading gvfs modules, ppp loading some module, ... There's no way to determine those deps from the outside. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Fri, 2013-01-25 at 04:46 +0100, Lennart Poettering wrote: On Thu, 24.01.13 21:15, Simo Sorce (s...@redhat.com) wrote: On Fri, 2013-01-25 at 00:12 +0100, Lennart Poettering wrote: I mean, here's an example: let's say openssl is updated, which is pulled in by a ton of other things, for example the libc NSS LDAP module. The libc NSS is used by at least half of all processes running on your system, and they all dlopen() the NSS module. So how do you now figure out which ones that are and how do you then figure out what the heck you need to do to get them restarted? A) there is no 'libc NSS LDAP module', nss_ldap is not part of libc and is also deprecated on its own in favor of nss_ldapd and others. Not part of libc? uh? no, of course not. It's still a module that is loaded into libc via the libc NSS scheme, which is the point I am making here... And anyway you are missing the point here... this is just an example. It's not particularly hard to come up with a different example. Just think of some other NSS module, that uses some library. Because of NSS its's loaded into half of our processes, all they have to do is invoke gethostbyname() and the module and all depending libaries are mapped in, and how would ever detect that? cat /proc/$pid/maps B) Luckily we solved this case with SSSD, and this is exactly one of the use cases we wanted to solve with it. The sssd client side that gets loaded in processes has been made extremely simple and the protocol fixed in stone exactly so that you can upgrade SSSD and it's dependencies and even change sssd's configuration w/o having to restart applications. Well you fixed a tiny facet of the issue. As it turns out however sssd is not the only service we ship, is not the only package we ship, it's not the only NSS module we ship, and update nss_sssd is still not possible either... And it is not necessary either, as I already explained. So I would remove the nsswitch problem, for the most part (we still have some nsswitch things sssd does not handle like hostname resolution, but we may take that over as well if really necessary. Dude, sssd is not the only NSS module in the world, and NSS not the only interface that uses dlopen(). Look at PAM, at gstreamer loading codecs, at iconv loading char maps, gtk loading gtk modules, pulseaudio loading pa modules, python loading any module, apache loading a module, gvfs loading gvfs modules, ppp loading some module, ... Dude, nothing is perfect. There's no way to determine those deps from the outside. Of course there is, for the currently running process. But that is besides the point. yum upgrades, just like apt-get upgrades work just fine in the very vast majority of times. For daemons sensible rpms include condrestart statements. If some user app misbehaves after the upgrade you just restart it. If you know in advance which ones you *might* want to restart I will be very glad if you give me a list as part of the final yum output, and I will decide if I want to do that or not. We are all grown up enough to decide for our own, just give the information and let the admin take care of that. That said I think trying a distro-sync from a graphical session is just a funny and instructive experience, I wouldn't recommend it as you'll keep the pieces when your session blows up and brings with it your yum upgrade, but it is certainly instructive :) Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Thu, Jan 24, 2013 at 11:46:24PM -0500, Simo Sorce wrote: We are all grown up enough to decide for our own, just give the information and let the admin take care of that. Well, that's the problem. Most of our users (including many of the professional sysadmins) are *not* able to make a fully informed choice about whether an online upgrade will ensure that they're no longer running any code with known security issues. That's not a criticism of them - it's just a much harder problem than almost everyone realises. Nobody's suggesting making it impossible to use yum, but blessing it as a first-class distribution upgrade mechanism is a bad idea. There's far too many corner cases, and we can't justify the effort it'd take to fix all of them. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposed F19 Feature: Fedora Upgrade - using yum
= Features/FedoraUpgrade = https://fedoraproject.org/wiki/Features/FedoraUpgrade Feature owner(s): Miroslav Suchý msu...@redhat.com Upgrade Fedora to next version using yum upgrade. == Detailed description == In past (until Fedora 17) we could upgrade Fedora using Anaconda Upgrade and PreUpgrade. Now (in Fedora 18) we have only FedUp and previous methods are obsoleted. I propose to have FedUp and FedoraUpgrade in Fedora 19. FedUp is in fact yum-upgrade as well, but in dracut environment (aka off-line upgrade). Some devels say that offline upgrade is only way. But on-line upgrade is possible. E.g in Debian world it is even prefered method. In Fedora exist upgrade using yum as unofficial method for long time. A lot of people are using upgrade using yum for long time and the problem ratio was at least on pair with Anaconda upgrade. In fact most problems comes from improper packaging. E.g. maintainer forgot to obsolete, so during upgrade user get file conflict. Once these problems are reported and fixed the upgrade is without problem. And since FedUp is just different approach to yum-upgrade, FedUp will benefit from fixes on FedoraUpgrade (and vice versa). I propose to support both FedUp and FedoraUpgrade and give user option. If this method will be tested by FedoraQA, then I believe this upgrade method can be safely recommended to user. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Wed, 23.01.13 18:04, Jaroslav Reznik (jrez...@redhat.com) wrote: FedUp is in fact yum-upgrade as well, but in dracut environment (aka off-line upgrade). Some devels say that offline upgrade is only way. But on-line upgrade is possible. E.g in Debian world it is even prefered method. In Fedora exist upgrade using yum as unofficial method for long time. A lot of people are using upgrade using yum for long time and the problem ratio was at least on pair with Anaconda upgrade. In fact most problems comes from improper packaging. E.g. maintainer forgot to obsolete, so during upgrade user get file conflict. Once these problems are reported and fixed the upgrade is without problem. I'd strongly say NO to this. Not because I would have a problem with people doing non-fedup upgrades (I tend to upgrade my machines with yum myself, too). However, making this officially supported, and advertising this as a feature appears to be the wrong move to me. The thing is that doing on-line updates only works for stuff you can restart, and that doesn't mind that things are not atomically updated. However, much (most?) of our code isn't like that. Anybody who tried to update the Firefox RPM while it is running knows that this doesn't end well, and you frequently have to manually kill firefox to get it back into a usual state. Doing manual on-line upgrades with yum distro-sync is a fine thing to do, but this requires people to understand that things might go wrong, and requires a certain skill set from people so that they know what to do if things go wrong (like for example knowing how to kill firefox from the command line). But by making this an officially supported feature fedora would suggest this as something that would work for anybody, without any additional knowledge, and Fedora would have to deal with the additional support work/bug burden this creates. It's OK if an RPM for this enters the archive, it's OK if people who know how to fix their machines use this, it's OK if people suggest this as hidden functionality. But I think it would be a big mistake for Fedora to advertise this as official feature, and to accept the support burden this creates. Fedora doesn't have unlimited resources, we have more than enough bugs to fix anyway, making online updates an officially supported feature would amplify this disparity. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Wed, Jan 23, 2013 at 7:50 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 23.01.13 18:04, Jaroslav Reznik (jrez...@redhat.com) wrote: FedUp is in fact yum-upgrade as well, but in dracut environment (aka off-line upgrade). Some devels say that offline upgrade is only way. But on-line upgrade is possible. E.g in Debian world it is even prefered method. In Fedora exist upgrade using yum as unofficial method for long time. A lot of people are using upgrade using yum for long time and the problem ratio was at least on pair with Anaconda upgrade. In fact most problems comes from improper packaging. E.g. maintainer forgot to obsolete, so during upgrade user get file conflict. Once these problems are reported and fixed the upgrade is without problem. I'd strongly say NO to this. Not because I would have a problem with people doing non-fedup upgrades (I tend to upgrade my machines with yum myself, too). However, making this officially supported, and advertising this as a feature appears to be the wrong move to me. The thing is that doing on-line updates only works for stuff you can restart, and that doesn't mind that things are not atomically updated. However, much (most?) of our code isn't like that. Anybody who tried to update the Firefox RPM while it is running knows that this doesn't end well, and you frequently have to manually kill firefox to get it back into a usual state. Doing manual on-line upgrades with yum distro-sync is a fine thing to do, but this requires people to understand that things might go wrong, and requires a certain skill set from people so that they know what to do if things go wrong (like for example knowing how to kill firefox from the command line). But by making this an officially supported feature fedora would suggest this as something that would work for anybody, without any additional knowledge, and Fedora would have to deal with the additional support work/bug burden this creates. It's OK if an RPM for this enters the archive, it's OK if people who know how to fix their machines use this, it's OK if people suggest this as hidden functionality. But I think it would be a big mistake for Fedora to advertise this as official feature, and to accept the support burden this creates. Fedora doesn't have unlimited resources, we have more than enough bugs to fix anyway, making online updates an officially supported feature would amplify this disparity. I, speaking for the stuff I'm involved and maintain, will certainly not work on things to make online upgrades work correctly, if they don't for whatever reason. It's a huge lie to pretend we can reliably do this, and just a I-hope-it-will-work-out thing not based on the technical reality. Anybody who claims this can and will always work flawlessly as a general model, seems not to understand the problems well enough. We all do these kind of updates ourselves, sure, and we surely don't want to make that impossible in the future; but it's nothing I personally would *ever* want to *support* on other people's systems. There is a reason we partly switched to offline updates now, it can at least work in the theory behind it, unlike the online updates. Please never try to *support* that officially, it cannot and will not work out. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Wed, Jan 23, 2013 at 1:04 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Features/FedoraUpgrade = https://fedoraproject.org/wiki/Features/FedoraUpgrade Feature owner(s): Miroslav Suchý msu...@redhat.com Upgrade Fedora to next version using yum upgrade. I see no reason to make this an officially supported method to upgrade Fedora. The QA team is already swamped with work just getting the new install tests done, and now fedup tests. Having a third way of getting a Fedora release onto a machine is going to expand the testing matrix even more. This isn't replacing something, it's just creating more work. Yum upgrade has always been possible but not supported. Seems it can stay that way. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
If this method will be tested by FedoraQA, then I believe this upgrade method can be safely recommended to user. The feature owners of this need to do the testing and prodding, not QA. The way this feature is written, it seems to imply that QA is supposed to implement this feature. Note that this doesn't fix problems caused by dropped packages, that block other packages from being updated. One possiblity here would be to create a special package that obsoletes all of the dropped packages from the last release (or two depending on how far back you want to yum update from). There are going to be some releases where you need to do things outside of yum to upgrade. I don't know that we want to advertise this as a feature when it can't really be supported from release to release. However, a group of people who wanted to report bugs for missing obsoletes and the like would be appreciated. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Le mercredi 23 janvier 2013 à 19:50 +0100, Lennart Poettering a écrit : On Wed, 23.01.13 18:04, Jaroslav Reznik (jrez...@redhat.com) wrote: FedUp is in fact yum-upgrade as well, but in dracut environment (aka off-line upgrade). Some devels say that offline upgrade is only way. But on-line upgrade is possible. E.g in Debian world it is even prefered method. In Fedora exist upgrade using yum as unofficial method for long time. A lot of people are using upgrade using yum for long time and the problem ratio was at least on pair with Anaconda upgrade. In fact most problems comes from improper packaging. E.g. maintainer forgot to obsolete, so during upgrade user get file conflict. Once these problems are reported and fixed the upgrade is without problem. [...] It's OK if an RPM for this enters the archive, it's OK if people who know how to fix their machines use this, it's OK if people suggest this as hidden functionality. But I think it would be a big mistake for Fedora to advertise this as official feature, and to accept the support burden this creates. Yet, there is enough people ( like you, like me ) using it. While I agree that pushing this as fully supported in all cases do not seems a wise move, maybe we could restrict to some use cases, like upgrading a lxc container with a minimal downtime, or sometimes like that, and see how it goes. And the more I think about, the more I think we should rather have a SIG than a feature ( like the move of arm to PA ) : - this need to have a specific set of ressources for QA, etc. We cannot increase QA by magic and should not increase the workload of the current team, but we cannot forbid to people to test what they want. So as long as the interested people organize themselves, this would not be a issue - this is a effort that must be sustained in time. So we need a team of people to do it. IE, a SIG, not a Feature. And if this permit to find bugs sooner, this is good because AFAIK fedup use distro-sync as well. And having a SIG permit also to direct people who want to do it to see with the SIG, who can explain the caveats better than this is not supported as it currently is. If this work for Rawhide (since Kevin is IMHO on a good track for that), it can work for that too. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 01/23/2013 07:29 PM, Josh Boyer wrote: On Wed, Jan 23, 2013 at 1:04 PM, Jaroslav Reznikjrez...@redhat.com wrote: = Features/FedoraUpgrade = https://fedoraproject.org/wiki/Features/FedoraUpgrade Feature owner(s): Miroslav Suchýmsu...@redhat.com Upgrade Fedora to next version using yum upgrade. I see no reason to make this an officially supported method to upgrade Fedora. The QA team is already swamped with work just getting the new install tests done, and now fedup tests. Having a third way of getting a Fedora release onto a machine is going to expand the testing matrix even more. This isn't replacing something, it's just creating more work. Yum upgrade has always been possible but not supported. Seems it can stay that way. a) QA was never asked when preupgrade got approved as an official upgrade method in the first place... b) We QA have alot of QA community members testing this so this does NOT require any additional effort or cause additional LOAD on the QA community. c) We ( QA ) already have discussed this and it takes minor criteria changed for us to implement this ( either or ). yum upgrade is equally broken from my pov as preupgrade or fedup thus to me we can just as well support two failed upgrade mechanism or non et all. It does not take a rocket scientist to figure out we cant probably support upgrading until we default to brtrfs and users can rollback and boot into their old environment just incase heck our own so called default desktop does not handle upgrades very well. So I say let's support both or non et all.. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Wed, Jan 23, 2013 at 11:47 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: So I say let's support both or non et all.. Supporting none is not an option. And the major issue with yum upgrades is that online upgrades can fail not only based on what you have installed but also what is currently running and it cannot handle stuff like usermove without user intervention. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 01/23/2013 10:55 PM, drago01 wrote: Supporting none is not an option. Really suddenly not an option. We did that for a long time why is that suddenly not an option so please enlighten me why that's not an option. Users are better of keeping /home on a separated partition and re-use it with an fresh install then those poor attempts to support upgrades one way or another which at this point in time we cant do since the bits for that aren't properly aligned to make that happen... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Wed, Jan 23, 2013 at 22:47:18 +, \Jóhann B. Guðmundsson\ johan...@gmail.com wrote: b) We QA have alot of QA community members testing this so this does NOT require any additional effort or cause additional LOAD on the QA community. Aren't they just testing an upgrade of the default install? I don't think people are doing any automated testing of proper obsoletes for dropped packages, though most problems could probably be detected. And this still doesn't handle dropped packages that are being replaced. yum upgrade is equally broken from my pov as preupgrade or fedup thus to me we can just as well support two failed upgrade mechanism or non et all. Anaconda does some tricks that get packages installed even when there are problems that don't get handled by a normal yum update. (Or at least used to. (With the move toward not using special stuff in anaconda, maybe this isn't true any more.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Wed, Jan 23, 2013 at 10:57:59PM +, Jóhann B. Guðmundsson wrote: Users are better of keeping /home on a separated partition and re-use it with an fresh install then those poor attempts to support upgrades one way or another which at this point in time we cant do since the bits for that aren't properly aligned to make that happen... If you don't like what we produce, you're not obliged to use it. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Wed, 2013-01-23 at 18:04 +, Jaroslav Reznik wrote: If this method will be tested by FedoraQA, then I believe this upgrade method can be safely recommended to user. On a practical level, this is not a good thing to rely on. It is impossible for QA to cover the entire set of possible upgrades, or even an appreciable fraction of it. The upgrade testing we do can reliably expose major problems with the upgrade mechanism itself, and - mostly - major problems in core and commonly-used package scripts. It can never be relied upon to expose anything beyond that; and any scenarios in which 'FedoraUpgrade' would produce a worse result than fedup are likely to fall into this set. Thus, QA testing of 'FedoraUpgrade' would not be a reasonable foundation on which to build an assertion that it is a safe upgrade method, worthy of recommendation to end users. Several knowledgeable developers have asserted that - while it often happens to work out okay - online upgrading is an inherently dangerous operation, I don't see that the limited amount of validation QA is able to offer can possibly gainsay them. Personally, I'd agree with several other responders that yum upgrade should stay in its current status: we document it but discourage it. (As a side note, I would like to avoid describing fedup as 'officially supported' and describe it instead as 'officially recommended' - it's an important semantic difference, I think.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Wed, 2013-01-23 at 19:47 -0600, Bruno Wolff III wrote: On Wed, Jan 23, 2013 at 22:47:18 +, \Jóhann B. Guðmundsson\ johan...@gmail.com wrote: b) We QA have alot of QA community members testing this so this does NOT require any additional effort or cause additional LOAD on the QA community. Aren't they just testing an upgrade of the default install? Correct: https://fedoraproject.org/wiki/QA:Testcase_upgrade_fedup_cli_previous_desktop is the only current upgrade test case. We could plausibly extend the range somewhat to cover common package loadouts (GNOME, KDE, minimal perhaps) and common configuration wrinkles (non-US keyboard layout, encryption, a couple of different partition schemes), for _one_ upgrade method. Anything beyond that would be a bit of a stretch, I think. I don't think people are doing any automated testing of proper obsoletes for dropped packages, Correct. though most problems could probably be detected. And this still doesn't handle dropped packages that are being replaced. yum upgrade is equally broken from my pov as preupgrade or fedup thus to me we can just as well support two failed upgrade mechanism or non et all. Anaconda does some tricks that get packages installed even when there are problems that don't get handled by a normal yum update. (Or at least used to. (With the move toward not using special stuff in anaconda, maybe this isn't true any more.) fedup does not use anaconda in any way. anaconda didn't really do any 'tricks', IIRC, it just ran the upgrade in skip-broken mode. I don't know if fedup uses skip-broken or not. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
