Announcement

Collapse
No announcement yet.

Systemd Adds Feature To Fallback Automatically To Older Kernels On Failure

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

  • Systemd Adds Feature To Fallback Automatically To Older Kernels On Failure

    Phoronix: Systemd Adds Feature To Fallback Automatically To Older Kernels On Failure

    Systemd's latest feature is the concept of "boot counting" that will track kernel boot attempts and failures as part of an automatic boot assessment. Ultimately this is to provide automatic fallback to older kernels should a newer kernel be consistently failing...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Actually , that would be pretty nice.

    Yes , you can boot with last known working one manually but why not?

    Maybe that can be handy for new users.

    Comment


    • #3
      systemd-boot needs to be able to decrypt the boot partition, otherwise I'm stuck with grub unfortunately.
      ## VGA ##
      AMD: X1950XTX, HD3870, HD5870
      Intel: GMA45, HD3000 (Core i5 2500K)

      Comment


      • #4
        This is nice

        Comment


        • #5
          This feature got brought up during his “State of Systemd” at All Systems Go. One of the Desktop folks asked if this would work for pieces higher than the kernel. Supposedly it would take a bit of work, but the over all architecture is flexible enough that it could be extended to take some part of the Desktop into account for whether things are “blessed”. Like it’s one thing for your kernel to boot successfully, but if there’s graphical corruption to the point the user can’t login, then there’s no point to it being blessed as good.
          All opinions are my own not those of my employer if you know who they are.

          Comment


          • #6
            @darkbasic: systemd-boot can't even handle a separate boot partition and requires the kernel/initrd to be in the (FAT32 formatted) ESP. Encrypting boot doesn't prevent evil maid attacks on the ESP where your grub lies, so you still need to use secure boot to sign & verify grub. Instead you can just use efistub or systemd-boot and directly sign the kernel/initrd/cmdline and have the same guarantees (as in an attacker would have to bypass secure boot).

            Now this situation hopefully becomes better with the Boot Loader Specification and legacy free boot and open firmware (e.g. CoreBoot/LibreBoot, LinuxBoot)

            Comment


            • #7
              Doesn't bother me at all. And if it was extended to desktop and X fails to boot you can at least get in to your desktop without manual intervention. Sounds convenient.

              Comment


              • #8
                I too think this is a good idea, though, I'm not sure it should be automatic. The user should be prompted.

                Comment


                • #9
                  Originally posted by schmidtbag View Post
                  I too think this is a good idea, though, I'm not sure it should be automatic. The user should be prompted.
                  I'm thinking this would be great on servers, but prompting sounds like a terrible idea. That would be like Ubuntu server hanging at a prompt when it can't mount something.

                  Comment


                  • #10
                    Originally posted by NateHubbard View Post

                    I'm thinking this would be great on servers, but prompting sounds like a terrible idea. That would be like Ubuntu server hanging at a prompt when it can't mount something.
                    Yeah, like the old famous BIOS "Press F1 to continue". Not so great on remote servers...

                    Comment

                    Working...
                    X