On a lark, I decided to try this option to grab a week's worth of updates.
The laptop rebooted immediately. Churned for a while, I could see on the console that it's trying to do updates. The laptop rebooted again, and the end result was that nothing was updated, so I just did yum update, as I always do.
Now, one thing I don't recall seeing was the wireless getting turned on during the update cycle. Which, I would think, would be a fairly important prerequisite, in order to download the updates.
Or, perhaps, I'm missing something. This laptop was updated from F17 to F18, and perhaps I need to install a package that automatically downloads updates in advance, so on update everything gets installed locally, but poking around with yum didn't find anything that seems to do that.
Hi
On Sat, Feb 2, 2013 at 9:57 AM, Sam Varshavchik wrote:
Or, perhaps, I'm missing something. This laptop was updated from F17 to F18, and perhaps I need to install a package that automatically downloads updates in advance, so on update everything gets installed locally, but poking around with yum didn't find anything that seems to do that.
Whatever is needed should have gotten pulled in via dependencies. It is handled by PackageKit and systemd so should be there by default anyway. You might want to file a bug report if you can reproduce it.
Rahul
Rahul Sundaram writes:
« HTML content follows »
Hi
On Sat, Feb 2, 2013 at 9:57 AM, Sam Varshavchik wrote:
Or, perhaps, I'm missing something. This laptop was updated from F17 to F18, and perhaps I need to install a package that automatically downloads updates in advance, so on update everything gets installed locally, but poking around with yum didn't find anything that seems to do that.
Whatever is needed should have gotten pulled in via dependencies. It is
This is not a dependency issue.
Nothing was pulled in because "Install updates and restart" restarted first, and when the laptop started booting, the update kicked in, but without activating wireless, apparently. As I've described. I'm not sure where someone got the impression that some updates were retrieved, and just some dependencies were missing, I thought that my description was pretty accurate.
I'm no big expert on these things, but I'd imagine it's going to be pretty difficult to pull in anything, never mind their dependencies, if the wireless doesn't turn on, and the laptop is not connected anywhere.
The fact that nothing was pulled in was fairly obvious, because after the second reboot, after the laptop came up, and turned on its wireless, 'yum update' proceeded to download everything that needed to be updated, and it updated succesfully, since "Install updates and restart" failed to bloody do anything at all.
So, can someone tell me whether "Install updates and restart" should actually restart first, and then attempt to do install the updates, but bring up wireless first, and that's what didn't happen here.
Now, I do recall that selecting "Install updates and restart" brought up the usual "I'm gonna shut down in 60 seconds, sucker!" prompt. I didn't want to wait, so I pushed the button to reboot immediately. Perhaps, the way that this is supposed to work is that the download gets kicked off immediately, and everything is expected to get downloaded within the 60 countdown timer, then installed on reboot (but what if it takes more than 60 seconds to download the updates, I wonder).
Which kind of makes sense to me. But, if that's the case, I shouldn't be given the option to reboot immediately, but told to wait until everything gets downloadeded.
On 02/02/2013 02:17 PM, Sam Varshavchik wrote:
I'm no big expert on these things, but I'd imagine it's going to be pretty difficult to pull in anything, never mind their dependencies, if the wireless doesn't turn on, and the laptop is not connected anywhere
I'm not familiar with the program, but judging by its name I'd expect it to download the updates, install them and only then restart. Having the box restart first doesn't seem right, especially when you consider that there might be something like a kernel update that's going to require you rebooting to let it take effect.
Am 02.02.2013 23:33, schrieb Joe Zeff:
On 02/02/2013 02:17 PM, Sam Varshavchik wrote:
I'm no big expert on these things, but I'd imagine it's going to be pretty difficult to pull in anything, never mind their dependencies, if the wireless doesn't turn on, and the laptop is not connected anywhere
I'm not familiar with the program, but judging by its name I'd expect it to download the updates, install them and only then restart. Having the box restart first doesn't seem right, especially when you consider that there might be something like a kernel update that's going to require you rebooting to let it take effect.
the new crap is supposed to update at reboot to force fedora more to be like windows - thankfully you can uninstall the whole packagekit stuff and use "yum upgrade" and hopefully this will never change
maybe you should follow devel list or feature list of fedora: http://fedoraproject.org/wiki/Features/OfflineSystemUpdates
On 02/02/2013 02:57 PM, Reindl Harald wrote:
the new crap is supposed to update at reboot to force fedora more to be like windows - thankfully you can uninstall the whole packagekit stuff and use "yum upgrade" and hopefully this will never change
I see. I removed it a long time ago because it could find my network connection to look for updates but insisted that I was off-line when it came to doing the work. I use yumex because I like being able to decide on-the-fly which updates to accept, especially if I know there's a problem with something.
Hi
On Sat, Feb 2, 2013 at 8:33 PM, Joe Zeff joe@zeff.us wrote:
I see. I removed it a long time ago because it could find my network connection to look for updates but insisted that I was off-line when it came to doing the work.
When it was originally introduced, PackageKit used to rely on NetworkManager to figure out if the network is active and if you had disabled NM, you would have that problem. This was fixed by falling back to testing via the older method which still works even if you had NM disabled. So you wouldn't have this problem anymore. PackageKit GUI still offers the ability to select packages on the fly during updates. Offline updates is just the default method and can be switched off even without uninstalling PackageKit. Also PackageKit itself is just a framework and offers other abilities such as installing codecs or fonts on demand
Rahul
Rahul Sundaram writes:
On Sat, Feb 2, 2013 at 8:33 PM, Joe Zeff <URL:mailto:joe@zeff.usjoe@zeff.us> wrote:
I see. I removed it a long time ago because it could find my network connection to look for updates but insisted that I was off-line when it came to doing the work.
When it was originally introduced, PackageKit used to rely on NetworkManager to figure out if the network is active and if you had disabled NM, you would have that problem. This was fixed by falling back to testing via the older method which still works even if you had NM disabled. So you wouldn't have this problem anymore. PackageKit GUI still offers the ability to select packages on the fly during updates.
What PackageKit GUI would that be? I'm unable to find any PackageKit GUI in F18. After updating F17 to F18, the software update app was removed.
Hi
On Sun, Feb 3, 2013 at 8:00 AM, Sam Varshavchik wrote:
What PackageKit GUI would that be? I'm unable to find any PackageKit GUI
in F18. After updating F17 to F18, the software update >app was removed.
That isn't true. gpk-update-viewer still is there as well as apper, the KDE equivalent
Rahul
Rahul Sundaram writes:
« HTML content follows »
Hi
On Sun, Feb 3, 2013 at 8:00 AM, Sam Varshavchik wrote:
What PackageKit GUI would that be? I'm unable to find any PackageKit GUI in
F18. After updating F17 to F18, the software update >app was removed.
That isn't true. gpk-update-viewer still is there as well as apper, the KDE equivalent
Strange – using Gnome search, I couldn't find it any more. Now, I thought that this is how the usability experts think is the most efficient way to launch an application these days: open Gnome application menu, by slamming the mouse into the right hand corner, then abandon the mouse, and start typing the app's name using the keyboard. Really, it's so intuitive. But, anyway, I eventually got used to it.
I got used to typing 'update' to bring it up. Now, nothing comes up.
I do see that its desktop file has 'nodisplay=true'. Removing that, restores 'software update' as a searchable app.
I'm almost afraid to ask WTF was that about, and whose bright idea it was.
Hi
On Sun, Feb 3, 2013 at 2:34 PM, Sam Varshavchik mrsam@courier-mta.comwrote:
Strange – using Gnome search, I couldn't find it any more. Now, I thought
that this is how the usability experts think is the most efficient way to launch an application these days: open Gnome application menu, by slamming the mouse into the right hand corner, then abandon the mouse, and start typing the app's name using the keyboard. Really, it's so intuitive. But, anyway, I eventually got used to it.
https://live.gnome.org/GnomeShell/CheatSheet
There is an easier way if you are just using the keyboard. press the system or "windows" key and start typing the application name (you don't have to focus). I personally use synapse which makes searching for docs etc easier although the next version of GNOME is supposed to have integrated search.
I do see that its desktop file has 'nodisplay=true'. Removing that,
restores 'software update' as a searchable app.
I'm almost afraid to ask WTF was that about, and whose bright idea it was.
Probably to encourage one obvious method of updating but the alternative (slightly hidden)method is still there for those who want it.
Rahul
On Sat, Feb 2, 2013 at 5:17 PM, Sam Varshavchik wrote:
This is not a dependency issue.
Nothing was pulled in because "Install updates and restart" restarted first, and when the laptop started booting, the update kicked in, but without activating wireless, apparently. As I've described. I'm not sure where someone got the impression that some updates were retrieved, and just some dependencies were missing, I thought that my description was pretty accurate.
It isn't. This feature works by downloading all the updates beforehand and then offering you the option in the menu to restart and install the updates in a special environment
https://fedoraproject.org/wiki/Features/OfflineSystemUpdates
Rahul
Rahul Sundaram wrote:
It isn't. This feature works by downloading all the updates beforehand
I prefer to control when the download happens. This turns off the automatic download:
dconf write /org/gnome/settings-daemon/plugins/updates/auto-download-updates false
and then offering you the option in the menu to restart and install the updates in a special environment
The new option is positioned at the bottom of the menu, where the shutdown option normally lives. I prefer to avoid the possibility of inadvertantly causing an update when I just meant to shut down:
dconf write /org/gnome/settings-daemon/plugins/updates/active false
Ron
Rahul Sundaram writes:
It isn't. This feature works by downloading all the updates beforehand and then offering you the option in the menu to restart and install the updates in a special environment
Well, that's the part that did not work for me. Nothing was downloaded before the "Install updates and restart" went up. So when it rebooted, the updater threw up its hands, and just rebooted again, back where I started.
And the reason I know that nothing was downloaded, because afterwards "yum update" did that.
-
Joe Zeff -
Rahul Sundaram -
Reindl Harald -
Ron Yorston -
Sam Varshavchik