Announcement

Collapse
No announcement yet.

Fedora 19 Officially Released

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by GreatEmerald View Post
    openSUSE has been there, done that. Apparently 12.2 was really bad with PackageKit locks (at the time I just outright uninstalled Apper, so I don't actually have firsthand experience with it), and 12.3 solved that. There's a prompt asking you whether you want to attempt to tell PackageKit to go away if it just so happens to be trying to run when you start YaST. And they also have plans for some "app store", although I couldn't care less (YaST Qt software manager is pretty much already as good as it gets).
    That is a rather ugly workaround, not a fix. If some other operation has the rpm or yum database locked, then you can 'ask that operation to go away', but it is not always going to be in a cancel-able state, and it's probably more dangerous to go around offering to let people cancel packaging operations willy-nilly just so another packaging operation will start faster.

    Proper fixes would involve making locking less necessary and adjusting tools to need to use it less often and for less time.

    Comment


    • #17
      Great release!!!

      GREAT RELEASE!!!

      I've already tryed it on 2 different laptops and it's looking great with AMD C-60 (Bobcat+R600) and Intel i3 (Sandy Bridge+HD3000). Everything just works! As soon as I get my new laptop I'll install Fedora 19 and hopefully never look back to Ubuntu again! Ubuntu with Gnome just doesn't cut it anymore.

      Thank you devs! You're awesome!

      Comment


      • #18
        Originally posted by AdamW View Post
        I don't recall specific versions, but I'm pretty sure there's still fresh work planned.
        It was a version greater than 0.7.6 (0.8.9 is mainline) because thats the version thats still in Arch's repos and pacman + packagekit still locks all the time (as of 2 months ago when I last used arch) and they couldn't update it because of pacman not supporting the new packagekit API's or something like that.


        Originally posted by AdamW View Post
        That would be https://bugzilla.redhat.com/show_bug.cgi?id=975800 , we are fixing it right now (it was supposed to be fixed already, but the fix was faulty). 'yum install grub2-starfield-theme' will get the theme back if you want it.
        Yeah I knew it was known bug and I had to reinstall the theme when I did a test upgrade like a week ago, I was just mentioning it for anyone else reading

        Originally posted by AdamW View Post
        So, the fact it gets lost on upgrade is just a bug (see above). But fresh F19 installs do actually use an un-themed, console mode grub2. There's a few reasons for this. Themed graphical grub2 seems to be very slow on some systems, for one thing. We ran into various problems with the modesetting and theming stuff for the releases we were using it; pjones and I and others are now of the general opinion that just using console mode is likely the safest thing to do for the foreseeable future. And theming grub turned out just not to look that great if you take a step back and look at the whole boot process - we had this vision a few releases back that we'd try to keep the entire boot process very visually consistent, with grub, bootsplash and gdm all using the same background and minimizing mode switches, but that's just not all in place at present, so it actually looks more jarring to do a modeswitch / theme for grub2 then suddenly jump back to console mode briefly while plymouth comes up, then modeset again and show an entirely different image (the 'plain blue background with a Fedora logo' bootsplash) than it does to simply use console mode for grub.
        Thanks for the clarification Adam I did notice just now that there is a modeswitch on KDE VERY late in the boot-- like way later than should be necessary. Fedora 19 KDE x64, boot looks great, minimal jarring all the way to the login prompt for KDM. Login to KDM, and when KDM switches over to the splash screen (to fade into the desktop) it looks like there's a modeswitch during the KDM -> Splash handoff. Why? For clarification: I say there's a modeswitch happening because its quite obvious and visible that the background of the login screen, and the background of the KDE Splash are at minimum different resolution images because the patterned background visibly jumps and changes its positioning so either the background images aren't the same resolution, oooor there's a modeswitch.

        Originally posted by AdamW View Post
        How do you mean 'broken'? I'm running F19 on my laptop with encrypted LVM and it works fine so far as I can see.
        The last time I checked the bug reports was about a week ago and it was still marked as unsolved, the last time i tried it was like 2 or 3 days ago so MAYBE its been fixed with an update since then.... search "red hat bugzilla dracut crypttab" and you should get some bug reports back. Basically dracut wasn't including /etc/crypttab in the initramfs, LUKS defaults to disallowing discard ( TRIM ) commands, so initramfs was loading, and disallowing discard because there was nothing there telling it otherwise. Initramfs hands off to real root and real root accepts the same boot environment that initramfs had-- disallowing discards and completely ignoring whether or not you had "allow-discards" in /etc/crypttab. You had to manually specify /etc/crypttab to dracut everytime initramfs was generated, OR force LUKS to check real-root for its configuration (loading /etc/crypttab in the process) by removing kernel parameters in grub.

        Again this was ONLY an issue for LUKS encryption + SSD, if you have a real hard drive you'd never know otherwise. And if you have an SSD you'd never know something was wrong unless you actually started playing around with things-- THEN you'd realize that "TRIM" wans't being passed off to the device, regardless of what /etc/crypttab had. If its been fixed, awesome-- because then I need to reinstal haha, but I can't seem to find the exact same bug report that I followed a link to a few weeks ago, I know LP and some other devs were trying to decide whose fault it was-- systemd, dracut, or LUKS in the comments of the bug report

        EDIT: Adam, do you know if Fedora 19 is now using the Intel Pstate driver? I noticed that on Fedora 18 even if you had a 3.9.x kernel, Fedora didn't use the Intel P-state driver and instead stuck to OnDemand
        Last edited by Ericg; 07-02-2013, 05:49 PM.

        Comment


        • #19
          Originally posted by GreatEmerald View Post
          Depends on which VDPAU you want. radeon has both shader-based VDPAU and UVD. If you want the latter, make sure the correct firmware is loaded.
          uvd of course ^^ does shader based even give you anithing that helps at all? ^^ I thought thats nothing usefull.

          But back to the point... is the right firmware not included int he kernel-3.10-package?

          Comment


          • #20
            Getting bad lockups when using the global search function in Gnome Shell.
            They last about five seconds, but the entire UI freezes for this time, not just the Activities screen.
            So I've given this release a miss, for now.

            Comment


            • #21
              Adam, Rahul,

              is FedUp going to be the new "recommended" way to upgrade Fedora? Not meaning to bash Fedora per say, but if you want a fully functioning desktop on Fedora (all codecs, plugins, everything) its kind of a pain to install EVERYTHING EVERY 6months, which you would have to do if you wipe and reinstall fresh. I know PreUpgrade never really lost the aura of "Sure you can use it, it SHOULD work in theory... but don't come crying if it doesnt" and I was just curious if the Fedora team had more faith in FedUp to handle proper upgrading between versions to where reinstalling could be considered "Plan B" for upgrades.

              Comment


              • #22
                Originally posted by Ericg View Post
                Adam, Rahul,

                is FedUp going to be the new "recommended" way to upgrade Fedora? Not meaning to bash Fedora per say, but if you want a fully functioning desktop on Fedora (all codecs, plugins, everything) its kind of a pain to install EVERYTHING EVERY 6months, which you would have to do if you wipe and reinstall fresh. I know PreUpgrade never really lost the aura of "Sure you can use it, it SHOULD work in theory... but don't come crying if it doesnt" and I was just curious if the Fedora team had more faith in FedUp to handle proper upgrading between versions to where reinstalling could be considered "Plan B" for upgrades.
                Fedup is the *only* recommended way to do Fedora upgrades since Anaconda doesn't directly have any upgrade functionality in it anymore and hence should be more usable/better tested than PreUpgrade. Fedup also tries to do pretty much just a yum upgrade within a confined systemd target and nothing really fancy.

                Comment


                • #23
                  Originally posted by RahulSundaram View Post
                  Fedup is the *only* recommended way to do Fedora upgrades since Anaconda doesn't directly have any upgrade functionality in it anymore and hence should be more usable/better tested than PreUpgrade. Fedup also tries to do pretty much just a yum upgrade within a confined systemd target and nothing really fancy.
                  Lemme rephrase the question

                  Fedora fresh installs are annoying (again, not bashing, I love fedora). I've got a desktop that I like to keep upgraded on the latest version of X distro-- right now its running Win7 for gaming but with the UVD and DPM work I may come back to Linux on it. Do the Devs have enough faith in FedUp to say "If you're on Fedora 18 and want to go to 19, we completely and whole heartedly believe that a 'fedup --network 19' is more than enough and stable enough to do that upgrade 99 times out of 100 and you should only have to reinstall fresh if you want to change something, like partition layout, that can only be done from an installer"

                  OR

                  does FedUp fall into the same boat as PreUpgrade did where its "You can try, but you get to keep the pieces."

                  My desktop is more of my workhorse, laptop is my playground, so I've got no problem doing a fresh install on my laptop every 6months-- that doesnt bother me, but If I put Fedora back on my desktop I want to be like "okay, when Fedora 20 comes out all I have to do is 'fedup --network 20', let it run overnight and when I get up in the morning everything will be sunshine and daisies and perfect!"

                  Comment


                  • #24
                    Originally posted by Ericg View Post
                    does FedUp fall into the same boat as PreUpgrade did where its "You can try, but you get to keep the pieces."

                    My desktop is more of my workhorse, laptop is my playground, so I've got no problem doing a fresh install on my laptop every 6months-- that doesnt bother me, but If I put Fedora back on my desktop I want to be like "okay, when Fedora 20 comes out all I have to do is 'fedup --network 20', let it run overnight and when I get up in the morning everything will be sunshine and daisies and perfect!"
                    Preupgrade was never really a do it on your own risk thing. It was recommended and tested but it never got as much as developer attention as fedup does because Anaconda provided an alternative upgrade path. fedup being the only recommended solution is bound to get more testing and fixes. My personal experience with fedup so far has been good but I don't expect it to be perfect for everyone.

                    Comment


                    • #25
                      Originally posted by RahulSundaram View Post
                      Preupgrade was never really a do it on your own risk thing. It was recommended and tested but it never got as much as developer attention as fedup does because Anaconda provided an alternative upgrade path. fedup being the only recommended solution is bound to get more testing and fixes. My personal experience with fedup so far has been good but I don't expect it to be perfect for everyone.
                      The same experience i've had, two perfectly fine updates. And I say PreUpgrade was a "do it at your own risk" because the wiki was filled with "Good luck!" warnings and the likes last I checked, which at least to me always made PreUpgrade come across as half-assed or not-fully supported upgrade method. I am glad to hear though that FedUp will get more testing and fixes, even if comes at the cost of Anaconda having lost its upgrade capabilities
                      Last edited by Ericg; 07-02-2013, 10:32 PM.

                      Comment


                      • #26
                        Originally posted by AdamW View Post
                        That is a rather ugly workaround, not a fix. If some other operation has the rpm or yum database locked, then you can 'ask that operation to go away', but it is not always going to be in a cancel-able state, and it's probably more dangerous to go around offering to let people cancel packaging operations willy-nilly just so another packaging operation will start faster.

                        Proper fixes would involve making locking less necessary and adjusting tools to need to use it less often and for less time.
                        That's why I said "ask", not "force". PackageKit can refuse to quit if it's in an important stage, in which case YaST will tell you that it didn't quit when asked, and so you can retry later.

                        Of course, making things more efficient is always nice, but locks are always going to be there. If PackageKit could search for updates without locking, and you installed something new during the time, the things that it needs to update could then be outdated. Asking PackageKit to suspend checking for updates while the user is doing package management themselves makes sense.

                        Originally posted by blackiwid View Post
                        uvd of course ^^ does shader based even give you anithing that helps at all? ^^ I thought thats nothing usefull.

                        But back to the point... is the right firmware not included int he kernel-3.10-package?
                        Of course it does, otherwise it wouldn't be there. It's just relatively inefficient and quite buggy.

                        Not sure about Fedora, but in openSUSE the firmware is in its own package, kernel-firmware.

                        Comment


                        • #27
                          I've had the worst Linux experiences with Fedora (particularly 18 and 16), that I think I'll pass this time (the only reason I kept trying was because my first Linux experience was with Fedora (Fedora Core 6, I think)). Last time neither proprietary nor open-source video drivers worked so had to fallback to VESA (open-source for Intel and AMD didn't recognize the models, and I upgraded to the latest with yum; proprietary Catalyst seg faulted).

                          Comment


                          • #28
                            Originally posted by Ericg View Post
                            Not meaning to bash Fedora per say, but if you want a fully functioning desktop on Fedora (all codecs, plugins, everything) its kind of a pain to install EVERYTHING EVERY 6months, which you would have to do if you wipe and reinstall fresh.
                            Don't be lazy I reinstall everything, and it keeps PCs clean. It's a good incentive to remove unnecessary data off your disk, and also roots out any possible problems with misconfiguration that can arise between different versions. And if you think it's a pain to reinstall every 6 months, you can use a distro with a slower release cycle Or just don't upgrade at all. If it's not broken, don't fix it. Our laptop in the household still runs on openSUSE 12.2, because it works just fine. I'll upgrade only once 12.2 goes out of support.
                            Last edited by GreatEmerald; 07-03-2013, 01:44 AM.

                            Comment


                            • #29
                              Originally posted by GreatEmerald View Post
                              Don't be lazy I reinstall everything, and it keeps PCs clean. It's a good incentive to remove unnecessary data off your disk, and also roots out any possible problems with misconfiguration that can arise between different versions. And if you think it's a pain to reinstall every 6 months, you can use a distro with a slower release cycle Or just don't upgrade at all. If it's not broken, don't fix it. Our laptop in the household still runs on openSUSE 12.2, because it works just fine. I'll upgrade only once 12.2 goes out of support.
                              Good point. Really, I have to admit, I love the "If it aint broke" argument. It makes sense in many, many situations.

                              Comment


                              • #30
                                Originally posted by Sergio View Post
                                I've had the worst Linux experiences with Fedora (particularly 18 and 16), that I think I'll pass this time (the only reason I kept trying was because my first Linux experience was with Fedora (Fedora Core 6, I think)). Last time neither proprietary nor open-source video drivers worked so had to fallback to VESA (open-source for Intel and AMD didn't recognize the models, and I upgraded to the latest with yum; proprietary Catalyst seg faulted).
                                If you may share your device specification, many of Fedora guys here might help.

                                Fedora 19 is equipped with latest open source graphic stack. It should be fine with majority of GPUs.

                                Comment

                                Working...
                                X