Announcement

Collapse
No announcement yet.

Fedora 18 "Spherical Cow" Beta Finally Released

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

  • #11
    I'm not sure if my system uses (would use) efi or non efi since I'm not a hacker, but I recall clearly being baffled by how the clean install of F16 defaulted to grub (legacy), and I even posted an (angry) comment on either fedora forums or here and it was like "well we're aware of this issue and we're transitioning, it's not easy bla bla etc etc", my MB is Asus "p7p55d-e lx", it's relatively new and I'm not sure which grub it would require or if has anything to do with that.

    As to grub-install etc, I've used these 2 simple (and working well) commands under Ubuntu for years since Ubuntu adopted grub2, and having to use "grub-mkconfig -o /boot/grub2/grub.cfg" instead - thanks but no thanks, I'll stick to Ubuntu.
    Last edited by mark45; 27 November 2012, 08:35 PM.

    Comment


    • #12
      Originally posted by mark45 View Post
      I'm not sure if my system uses (would use) efi or non efi since I'm not a hacker, but I recall clearly being baffled by how the clean install of F16 defaulted to grub (legacy), and I even posted an (angry) comment on either fedora forums or here and it was like "well we're aware of this issue and we're transitioning, it's not easy bla bla etc etc", my MB is Asus "p7p55d-e lx", it's relatively new and I'm not sure which grub it would require or if has anything to do with that.

      As to grub-install etc, I've used these 2 simple (and working well) commands under Ubuntu for years since Ubuntu adopted grub2, and having to use "grub-mkconfig -o /boot/grub2/grub.cfg" instead - thanks but no thanks, I'll stick to Ubuntu.
      Your motherboard does not support UEFI. If you did an out-of-the-box F16 install on it you would get grub2. You must be misremembering in some way. I can't find any relevant posts on the forums, but I didn't look crazy hard.

      Comment


      • #13
        Originally posted by AdamW View Post
        Your motherboard does not support UEFI. If you did an out-of-the-box F16 install on it you would get grub2. You must be misremembering in some way. I can't find any relevant posts on the forums, but I didn't look crazy hard.
        You're right on this one, I actually downloaded & clean installed F16 right now and despite the boot screen looking like legacy (black-n-white and clunky) grub, it says "grub 1.9" which is technically grub2 or so, so I was wrong on that one, though you're also right that I'm misremembering: the fact that it looks old and didn't detect Ubuntu contributed to this misbelief I guess. But here's the more important part to me as a (grub) user - it (F16) doesn't (and didn't) detect Ubuntu, which to a user it is as bad as using grub legacy - both sucked - F15 with grub legacy and F16 with grub2 (1.99) - while Ubuntu's grub2 worked fine long before (e.g. it detected Fedora).

        So my question would be - does Fedora 18 detect Ubuntu? And are there plans to use Ubuntu's simpler commands like grub-install & update-grub?
        Last edited by mark45; 27 November 2012, 10:00 PM.

        Comment


        • #14
          Originally posted by mark45 View Post
          You're right on this one, I actually downloaded & clean installed F16 right now and despite the boot screen looking like legacy (black-n-white and clunky) grub, it says "grub 1.9" which is technically grub2 or so, so I was wrong on that one, though you're also right that I'm misremembering: the fact that it looks old and didn't detect Ubuntu contributed to this misbelief I guess. But here's the more important part to me as a (grub) user - it (F16) doesn't (and didn't) detect Ubuntu, which to a user it is as bad as using grub legacy - both sucked - F15 with grub legacy and F16 with grub2 (1.99) - while Ubuntu's grub2 worked fine long before (e.g. it detected Fedora).

          So my question would be - does Fedora 18 detect Ubuntu? And are there plans to use Ubuntu's simpler commands like grub-install & update-grub?
          The detection of existing OSes is a pure grub feature, both we and Ubuntu are simply using that code from upstream grub - when you call grub(2)-mkconfig it does that automatically. If it didn't work for you in F16 then it simply means the version of grub2 in F16 had a bug in that code of some kind. That may have been fixed by the version in F18, it is a much newer version. I've only tried installing F18 alongside Ubuntu once, and the grub detection worked, but that's hardly enough testing for me to guarantee that it always works in all configurations ever, so I'm not going to do that, but hey, the code is there and it fires.

          Now having said that, even if a Fedora install does detect an Ubuntu install and add it to the bootloader configuration written by the Fedora install process, booting Ubuntu from that config is not necessarily going to be trouble-free, especially as Fedora uses grubby to update the config afterwards, not mkconfig, so it won't update the Ubuntu entry each time the config is updated.

          I have a giant screed on dual booting I could go into here but won't, but suffice it to say that the traditional x86 way(s) of handling dual/multiple boot are all terrible, terrible hacks and every one of them is badly flawed. Multiboot is one of the few things UEFI at least potentially improves, as it keeps the OS selection stuff in the firmware, which is the only logical place for it. Having five operating systems fighting over how to boot the system, each with their own bootloader and bootloader config - or, equally, having five operating systems fighting to maintain *one* bootloader config - are both recipes for pain, whatever the precise details of your setup. The only way of dual-booting in a non-UEFI setup that I'd be happy with would be not more than one OS per disk, with each OS controlling the MBR on its own disk and never touching any of the others, tbh.

          I haven't tested the grub2 method extensively but I know how it works, and at least in theory, if you have multiple grub2-based OSes dual-booting and they all use grub(2)-mkconfig to update whichever bootloader config file they decide to touch, it _ought_ to mostly hang together. But it's still a pretty creaky mess. Sigh, PCs.

          edit: there aren't any clear plans to use grub2-mkconfig to maintain the Fedora bootloader config file in the near future, no. It will probably keep popping up as a discussion topic and happen eventually, though. That's just my guess.

          Comment


          • #15
            Thanks, since in reality neither Apple nor M$ want to be compatible with desktop Linux (recall the recent news with UEFI/keys/whatever being dependent on silverlight is yet another reminder of M$'s dirty games), the most reasonable way to me is to keep updating grub2 with new code capable of listing new versions of window$ and mac and those unix-like systems that use grub2 - if you're not either of these 3 you're not worth the effort since those other OSes would be like 0.01% of the desktop market - this imo would be straightforward and would save quite a lot of code and maintenance woes.
            Though this thought doesn't apply to the new uefi/secure boot standard.
            Last edited by mark45; 27 November 2012, 10:31 PM.

            Comment


            • #16
              Originally posted by mark45 View Post
              Thanks, since in reality neither Apple nor M$ want to be compatible with desktop Linux (recall the recent news with UEFI/keys/whatever being dependent on silverlight is yet another reminder of M$'s dirty games), the most reasonable way to me is to keep updating grub2 with new code capable of listing new versions of window$ and mac and those unix-like systems that use grub2 - if you're not either of these 3 you're not worth the effort since those other OSes would be like 0.01% of the desktop market - this imo would be straightforward and would save quite a lot of code and maintenance woes.
              Though this thought doesn't apply to the new uefi/secure boot standard.
              In practice that doesn't narrow down the problem space much.

              For gedanken purposes, the problem space is this, on a BIOS PC.

              * There can be almost any amount of disks attached to the system.
              * The user can choose to 'boot from' - that is, initiate the boot sequence using whatever is in the MBR of - any one of those disks on any given boot.
              * What is on any of those disks and what is in the MBR of any of those disks can change without any warning to you if you are a single OS on the system.
              * Any of the MBR-based bootloaders can, and may, chainload another bootloader located in the header of any partition on any disk in the system.
              * Any bootloader on the system (MBR or partition) can attempt to directly boot any other OS installed on the system (including any kernel pair that has ever existed, potentially, for any Linux install present).
              * There is absolutely no de jure or de facto standard or even best practice for configuring multiboot. Different sysadmins and OSes can and will have things set up via shared bootloaders, or chainloading, or any other way in any given system.

              So...yeah. That's your problem space. Migraine commencing in...3...2...1...

              The UEFI design is at least theoretically miles, miles better than this. The design is that a list of 'things that can be booted' is maintained by the system firmware, and *only* by the system firmware. If you are an OS, at install time, you register yourself in the firmware's boot menu, with an entry which tells the firmware what your OS is called and what second-stage bootloader it should call when the user chooses to boot you. You install your second-stage bootloader (in a fairly standardized way) and configure it to handle _only_ booting yourself. You do not attempt to deal in any way at all with booting any other operating system, you leave that up to the firmware and the OS in question. It's a far better design. I dream of a future where everyone's finally adopted it and I can forget all the hideous knowledge I've built up about BIOS-based booting...

              Comment


              • #17
                Yes, from this perspective UEFI sounds attractive.
                But imo the problem is that the firmware is closed source (with restrictions like it's forbidden to reverse engineer it or so) and usually of bad quality (has bugs and tested like "if it boots windows it's fine").
                Not to mention that hardware/firmware vendors might do something against desktop Linux on behalf of Microsoft under the aegis of some euphemism (like security or whatever), and if those firmware stop working in a standard way with Linux - you're helpless. In the current environment you at least program grub2 yourself and no one controls you.

                Comment


                • #18
                  Originally posted by mark45 View Post
                  Yes, from this perspective UEFI sounds attractive.
                  But imo the problem is that the firmware is closed source (with restrictions like it's forbidden to reverse engineer it or so) and usually of bad quality (has bugs and tested like "if it boots windows it's fine").
                  All commercial BIOS implementations are also closed source, nothing is different there. UEFI is a standard, not a codebase: you can write a closed source or open source implementation as you wish. (There are, I believe, already two open source implementation of UEFI available for virtualization use - one for qemu/kvm, one for VirtualBox). BIOS is also a standard, though it's a de facto rather than de jure standard. Anyone can write an implementation of either, and release it under any license they choose. If anything, UEFI is better than BIOS here, because at least UEFI is an *actual defined standard* and we can write Linux to comply with it, and if a UEFI implementation is out of spec, we can complain about that. Since there's no formal BIOS standard, a manufacturer could theoretically build a machine with a gimped-up 'BIOS' that can only boot Windows or anything else you like, and there is no actual written document you could accuse them of violating. (edit: if you mean the movement of some bootloader logic from the potentially-open source OS layer to the probably-proprietary system firmware layer constitutes a loss of freedom, now I think about it, you're right, but frankly, I'd trade that off against the hideousness of the BIOS design any day...a system with an open source UEFI firmware would be the best thing though, of course).

                  Originally posted by mark45 View Post
                  Not to mention that hardware/firmware vendors might do something against desktop Linux on behalf of Microsoft under the aegis of some euphemism (like security or whatever), and if those firmware stop working in a standard way with Linux - you're helpless. In the current environment you at least program grub2 yourself and no one controls you.
                  Again, this is not at all unique to UEFI. They could do that anyway. If someone wants to gimp up a firmware such that it doesn't work with Linux, they don't need to do that via the bootloader mechanism. You could do that with a BIOS implementation if you really wanted to.

                  Comment


                  • #19
                    how about those:

                    70% SysV to Systemd Porting from sysVinit init scripts to systemd unit files.
                    80% New Installer UI Enhancing the anaconda installer with a new user interface, improving both the end-user experience as well as ease of implementation of new features, particularly new storage technologies, for developers.
                    95% rngd default-on rngd (part of the rng-tools package) should be enabled by default.
                    99% Secure Boot "Secure Boot" describes a UEFI feature by which malware is prevented from inserting itself into the boot process before the operating system loads. The UEFI feature is required to be enabled on all machines bearing the Windows 8 Client logo, which will be the overwhelming majority of all desktop and notebook systems.

                    Comment


                    • #20
                      It makes sense, but in reality it's not just about fixing the OS loading issue, it opened up a big opportunity for Microsoft to screw us (probably like never before), just read this blog. As I said, the catch is that some euphemism would be a /must/, in this case it's "security" which is used as a tool to wage and cover Microsoft's warfare strategy.
                      Last edited by mark45; 28 November 2012, 12:08 AM.

                      Comment

                      Working...
                      X