Announcement

Collapse
No announcement yet.

A Specification Is Being Discussed For Passing Firmware/Bootloader Logs To The OS

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

  • A Specification Is Being Discussed For Passing Firmware/Bootloader Logs To The OS

    Phoronix: A Specification Is Being Discussed For Passing Firmware/Bootloader Logs To The OS

    Stemming from a GRUB bootloader inquiry and discussion that started over one year ago, a new specification is being proposed for possible adoption by the Linux kernel in being able to pass bootloader or system firmware logs to the operating system kernel for in turn exposing them to user-space...

    http://www.phoronix.com/scan.php?pag...Logs-To-The-OS

  • #2
    While passing some log info into Linux is ok, isn't the real problem that Grub and other boot loaders have become waaaay too complicated? Grub has an entire command line scripting language and graphical menu system in it.

    Why not go back to the days where it just switches between the current OS, or a secondary "configuration OS" if you hold a key? At least that way it wouldn't have to duplicate the Linux kernel and command line.

    Comment


    • #3
      Originally posted by OneTimeShot View Post
      While passing some log info into Linux is ok, isn't the real problem that Grub and other boot loaders have become waaaay too complicated? Grub has an entire command line scripting language and graphical menu system in it.

      Why not go back to the days where it just switches between the current OS, or a secondary "configuration OS" if you hold a key? At least that way it wouldn't have to duplicate the Linux kernel and command line.
      systemd-boot? syslinux?

      Comment


      • #4
        Isn't this what BMC/IPMI are for? We do store firmware and bootloader logs already, in separate log storage servers.

        Comment


        • #5
          Yeah, I thought we already that stuff pre-UEFI. How is this differant? It's late and I'm probably reading it wrong
          Hi

          Comment


          • #6
            That stuff (BMC/IPMI) is good for Servers but doesn't work for desktops and workstations. Though I'm not sure how useful such info actually is.

            Comment


            • #7
              Well, I guess it is useful to someone, otherwise they wouldn't be scratching that particular itch.

              There are lots of ways to boot 'stuff', including U-boot, UEFI, GRUB, systemd-boot - each has specific benefits and disadvantages, so I wouldn't be so bold as to say any one of them (or another not listed) is the only solution that covers everyone's use-cases. I find GRUB useful, and if it adds the capability to capture firmware boot messages and expose them to Linux, I suspect I would use that capability. I've had to deal with enough problems related to poor UEFI implementations that any tool that could help with that is welcome.

              Comment


              • #8
                Originally posted by AsuMagic View Post

                systemd-boot? syslinux?
                systemd-boot is wonderful. i use it on all systems now.
                only drawback is that it requires efi.

                Comment


                • #9
                  Originally posted by flower View Post

                  systemd-boot is wonderful. i use it on all systems now.
                  only drawback is that it requires efi.
                  or efi emulation like Clover offers

                  Comment


                  • #10
                    Long term, I can see this would be useful for getting linux support in the desktop space. They can see exactly what windows only component shit itself when trying to load. As it stands now, Ma and Pa kettle have to discern firmware puking from 'dmesg | grep -i error' and don't know what to report to the vendor. MSI gaming laptop bioses come to mind.

                    Comment

                    Working...
                    X