In GNOME 3.4 (Fedora 17), GNOME Online Accounts (GOA) worked great with Google two-factor authentication (you really should enable that, if you value your data). In GNOME 3.6 (Fedora 18) it works no more, and it might be fixed in GNOME 3.8. When developers break some existing functionality for the sake of “progress”, but don’t bother fixing it or providing an alternative way before an official release, I always feel a bit… disenchanted.
Fortunately you can work around the broken code.
- Open Seahorse, filter your passwords for “GOA”, you should see one or two items of “Gnome Online Accounts password” type. Delete them.
- Re-login to Gnome session.
- Open Online Accounts and log in to your Google account. It will fail.
- Create an application-specific password for your Google account in the web browser.
- Open Seahorse, filter your password for “GOA”, you should see a single item. Open it and display the password. It will be very long, find the following section:
'password': <'your_password'>. - Replace your_password with your application-specific password you’ve generated.
- Close Seahorse and re-login to your Gnome session.
- Online accounts should work now. It worked for me.
It would be really nice if we didn’t have to fix this stuff by hand. Every time I upgrade I have to do lots of these kinds of magic fixes. In Fedora 18, this was one of the minor issues. The big issues still await me.
Now that Fedora 18 Beta has been released, I would like to thank all who contributed to Fedora 18 Alpha/Beta testing (Install, Desktop and Base) . Below is a list of contributors together with the number of results they reported into our release validation wiki matrices.
What to say? Andre Robatino owns the game! A big thanks, Andre, your help is phenomenal! (I guess he has some handy scripts for certain test cases, but that definitely deserves a full credit.)
I am very happy to see significant community participation in the list, not just Red Hatters. Robatino being the first of course, but lots of results were reported also by satellit, followed by bubeck and masami. Thank you guys, and also thanks every one else in the matrix. It wouldn’t be possible to keep Fedora quality high without all of you!
If you haven’t participated in Fedora 18 release validation, you still have the chance and we would love to see you help us. Please read QA/Join#Release_validation or talk to us in #fedora-qa on IRC.
Thanks everyone!
A few footnotes:
- Please bear in mind that the purpose of these numbers is not to evaluate anyone’s amount of contribution to Fedora, it displays just a single piece of a large puzzle. Lots of people test, but they don’t fill in the test case results. And even if they do, different test cases have different complexity.
- The statistics were generated by the release-test-stats.py script.
There is a nice improvement in Fedora 18 related to yum and PackageKit. It fixes a long-standing issue that while PackageKit is active (e.g. checking for system updates), any yum usage is blocked. You would see messages like this:
$ yum install foo
...
Another app is currently holding the yum lock; waiting for it to exit...
The other application is: PackageKit
Memory : 41 M RSS (447 MB VSZ)
Started: Fri Sep 7 09:27:08 2012 - 23:13 ago
State : Sleeping, pid: 1315
Another app is currently holding the yum lock; waiting for it to exit...
The other application is: PackageKit
Memory : 46 M RSS (452 MB VSZ)
Started: Fri Sep 7 09:27:08 2012 - 23:15 ago
State : Running, pid: 1315
...
It could last from seconds to dozens of minutes. Killing PackageKit was often the only choice. For me, as a yum-only user, this was really painful and annoying.
But it is no longer the case! As you can see in Bug 812938, Elad Alfassa implemented a patch to PackageKit-yum-plugin and Richard Hughes incorporated it upstream. If you run yum in Fedora 18 now, it will send a signal to PackageKit to cancel any background operations, run your yum command almost immediately and then resume PackageKit operation. The fix turned out to be quite simple, which is ironic, because this issue caused a lot of grievance among our users.
Elad, Richard, thanks a lot!
And the lessons learned for the rest of us is that if you have at least decent technical knowledge and something troubles you, it’s worth to have a look at it. The solution might turn out quite simple. (Personally, I really miss some team in Fedora that would focus on these small issues that cause a lot of discomfort).
Thanks again, guys.
If you use QEMU-KVM (or virt-manager GUI) for running your virtual machines, you can specify a disk driver to be used for accessing the machine’s disk image. By default IDE is selected, but VirtIO is a very popular choice as well. How do they compare in performance?
I used Fedora 17 as a host, Fedora 18 as a guest system. I used bonnie++ for testing. I ran
$ bonnie++ -s 3g
twice for each driver. The disk images were in the form of raw files. The results are:
IDE round 1:
Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP localhost 3G 76 97 24645 25 15658 17 1229 97 277235 56 717.8 65 Latency 196ms 3233ms 804ms 10194us 7619us 90962us Version 1.96 ------Sequential Create------ --------Random Create-------- localhost -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 4738 72 +++++ +++ 7411 62 4893 74 +++++ +++ 7853 59 Latency 1019us 6430us 7828us 693us 174us 824us
IDE round 2:
Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP localhost 3G 68 87 24893 26 15971 17 1063 85 282355 56 730.7 66 Latency 260ms 679ms 734ms 43305us 8152us 85837us Version 1.96 ------Sequential Create------ --------Random Create-------- localhost -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 4740 72 +++++ +++ 7488 65 4833 73 +++++ +++ 7757 65 Latency 2480us 6227us 7094us 745us 251us 760us
VirtIO round 1:
Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP localhost 3G 77 98 56770 38 32139 19 1222 98 392441 49 937.4 53 Latency 167ms 512ms 666ms 9544us 7309us 85529us Version 1.96 ------Sequential Create------ --------Random Create-------- localhost -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 5303 81 +++++ +++ 8301 74 5398 81 +++++ +++ 8851 68 Latency 3725us 6628us 7241us 738us 970us 795us
VirtIO round 2:
Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP localhost 3G 77 97 57202 35 32640 19 1230 98 395489 48 972.4 50 Latency 241ms 1478ms 684ms 9326us 81461us 84019us Version 1.96 ------Sequential Create------ --------Random Create-------- localhost -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 4753 74 +++++ +++ 8434 71 5473 82 +++++ +++ 8987 69 Latency 8461us 5904us 7358us 706us 72us 779us
The results (see description) are pretty clear. VirtIO is substantially faster for disk I/O operations. If you don’t use it, you should definitely consider it. If you run a lot of installation tests or other heavy disk operations like I do, it can be a pretty significant difference in performance.
I have already warned about broken kernel after upgrade to Fedora 17. The issue is worse than we expected. We thought it would hit only users using development version of Fedora and it would work OK after Fedora 17 is officially released. It’s not the case, the details are in bugs 820351, 826537 and 820340. I hope the fix will be ready soon, in the meantime:
- The current recommended order of upgrade methods is following: using Network install CD, using Install DVD, using preupgrade.
- If you use Network install CD, you should not encounter any kernel problems after upgrade, Fedora 17 kernel should be installed and booted by default.
- If you use Install DVD, your kernel will not be updated to Fedora 17 version, so you will get kernel panic on every shutdown. Just run as root
$ yum update
to fix the issue.
- If you use preupgrade, the new Fedora 17 kernel will be installed, but it won’t be listed in GRUB boot menu and you’ll boot the old Fedora 16 version instead. This is hardest to fix. As root you have to run
$ grub2-install /dev/sda $ grub2-mkconfig -o /boot/grub2/grub.cfg
You should replace /dev/sda with your disk you want to install bootloader on. Usually it is /dev/sda, but in some cases it might be different.
EDIT 2012-06-04: This problem seems to be fixed now.
I hope the preupgrade issue will be fixed in the near future and the extra step won’t be necessary. DVD upgrades can’t be fixed, but in their case the problem is not that crucial as the preupgrade issue.
If you upgrade your Fedora 15/16 to Fedora 17 before it is officially released, there is a high probability that you encounter a bug, where your computer receives a kernel panic when you try to shut down/reboot. This is documented in bug 820351. The problem is that since Fedora 17 updates repository is still not open, your system might still have an older kernel installed. To fix this issue, just install the latest kernel from Fedora 17 updates-testing repository, like this:
$ yum update kernel\* --enablerepo=updates-testing
After one more reboot, your system should be fixed.
Please note: This bug should not appear once we officially release Fedora 17 (a.k.a GOLD), so that extra step won’t be necessary.
EDIT: The problem persists even in final release and different steps are required.
There was a nasty bug in Fedora 17 related to USB devices which I blogged about recently. Rejoice, because your data is safe(r) now. GNOME developers did an outstanding job in fixing this issue. If you try to eject your USB device now, and all the data hasn’t been written to it yet, you’ll see a notification instructing you to wait. After the data operations are finished, you’ll see another notification saying that you can unplug the device now. The device will also disappear from Nautilus side pane.
There are still some less-than-optimal corner cases, e.g. you can click on that notification and hide it, but then it’s not really obvious when you can unplug the device (a second notification will pop up, just wait for it). These issues will hopefully be dealt with in a future GNOME release.
