8:57 a.m.
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.
1:47 p.m.
Hi
On Sun, Feb 3, 2013 at 2:34 PM, Sam Varshavchik <mrsam(a)courier-mta.com>wrote:
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
1:34 p.m.
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.
12:22 p.m.
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
7:06 a.m.
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.
7 a.m.
Rahul Sundaram writes:
On Sat, Feb 2, 2013 at 8:33 PM, Joe Zeff
<<URL:mailto:joe@zeff.us>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.
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.
2:36 a.m.
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
10:50 p.m.
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
10:48 p.m.
Hi
On Sat, Feb 2, 2013 at 8:33 PM, Joe Zeff <joe(a)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
7:33 p.m.
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.
4:33 p.m.
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.
4:57 p.m.
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
4:17 p.m.
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.
2:46 p.m.
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
4150
days inactive
4151
days old
14 comments
5 participants
participants (5)
-
Joe Zeff -
Rahul Sundaram -
Reindl Harald -
Ron Yorston -
Sam Varshavchik