Skip to content
  • Categories
  • Recent
  • Popular
  • World
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse

isurg

  1. Home
  2. LinuxNews
  3. Ubuntu drops Btrfs, XFS & ZFS boot support with Secure Boot
Please log in to access the MRCS stations.
00:00

Ubuntu drops Btrfs, XFS & ZFS boot support with Secure Boot

Scheduled Pinned Locked Moved LinuxNews
linuxnews
3 Posts 2 Posters 0 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A
    A
    auzy1@lemmy.world
    wrote last edited by
    #1

    Canonical has changed how Ubuntu 26.10 boots on system with Secure Boot enabled, in an effort to reduce the attack surface of the boot process.

    Ubuntu 26.10’s signed build of GRUB, which is only used on systems if Secure Boot is turned on, no longer supports /boot on Btrfs, XFS, ZFS, LVM, LUKS encryption or software RAID (other than RAID1).

    HFS+, Apple partition table support and JPEG and PNG image loading is also removed.

    Since GRUB needs to read the /boot directory to load the kernel and boot Ubuntu, if those files are on one of the affected filesystems, it can’t access them and the system won’t boot.

    Ubuntu 26.10 still supports /boot on ext4, FAT and ISO9660 (used for booting from CD/DVDs), as well as, naturally, squashfs for snaps with Secure Boot enabled

    If Secure Boot is disabled, GRUB’s full feature set is loaded, meaning exotic /boot setups and any GRUB customisation tweaks, like image backgrounds work as normal.

    Link Preview Image
    Ubuntu drops Btrfs, XFS & ZFS boot support with Secure Boot

    Canonical has changed how Ubuntu 26.10 boots on system with Secure Boot enabled, in an effort to reduce the attack surface of the boot process.

    favicon

    OMG! Ubuntu (www.omgubuntu.co.uk)

    A 1 Reply Last reply
    0
    • A auzy1@lemmy.world

      Canonical has changed how Ubuntu 26.10 boots on system with Secure Boot enabled, in an effort to reduce the attack surface of the boot process.

      Ubuntu 26.10’s signed build of GRUB, which is only used on systems if Secure Boot is turned on, no longer supports /boot on Btrfs, XFS, ZFS, LVM, LUKS encryption or software RAID (other than RAID1).

      HFS+, Apple partition table support and JPEG and PNG image loading is also removed.

      Since GRUB needs to read the /boot directory to load the kernel and boot Ubuntu, if those files are on one of the affected filesystems, it can’t access them and the system won’t boot.

      Ubuntu 26.10 still supports /boot on ext4, FAT and ISO9660 (used for booting from CD/DVDs), as well as, naturally, squashfs for snaps with Secure Boot enabled

      If Secure Boot is disabled, GRUB’s full feature set is loaded, meaning exotic /boot setups and any GRUB customisation tweaks, like image backgrounds work as normal.

      Link Preview Image
      Ubuntu drops Btrfs, XFS & ZFS boot support with Secure Boot

      Canonical has changed how Ubuntu 26.10 boots on system with Secure Boot enabled, in an effort to reduce the attack surface of the boot process.

      favicon

      OMG! Ubuntu (www.omgubuntu.co.uk)

      A
      A
      auzy1@lemmy.world
      wrote last edited by
      #2

      Honestly, I do get it, but imho, this seems a bit crazy. I don't remember normally using a dedicated boot partition these days...

      Feels like it should be an option

      However to defend canonical, their LTS releases are 15 years, so it makes sense they make the best choice now

      P 1 Reply Last reply
      0
      • A auzy1@lemmy.world

        Honestly, I do get it, but imho, this seems a bit crazy. I don't remember normally using a dedicated boot partition these days...

        Feels like it should be an option

        However to defend canonical, their LTS releases are 15 years, so it makes sense they make the best choice now

        P
        P
        partial_accumen@lemmy.world
        wrote last edited by partial_accumen@lemmy.world
        #3

        Honestly, I do get it, but imho, this seems a bit crazy. I don’t remember normally using a dedicated boot partition these days…

        What was old is new again! I'm fine with this change as its not removing support for the file systems altogether, its simply saying those can't be the boot volume. Seems like a small price to pay to significantly reduce the attack surface. I'm also wondering if this decision was driven from histories of compromised machines. As in, did a data analyst show a chart that 90% of a specific breech comes from this group of file system vulnerabilities? If so, then removing boot support for them dramatically would reduce compromised machines.

        1 Reply Last reply
        0

        Hello! It looks like you're interested in this conversation, but you don't have an account yet.

        Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

        With your input, this post could be even better 💗

        Register Login
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Popular
        • World