Announcement

Collapse
No announcement yet.

GRUB2 EFI Support In Fedora 31 Likely To Include New Security Modules

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

  • #21
    Originally posted by Britoid View Post
    The EFI partition is not very big.
    Resize it, or nuke it together with the Windows installation and have the distro create a new, bigger one automatically during installation.

    Yes but said size is by default set by the factory,
    It's a Fat32 partition with "esp/boot" flags on a HDD/SSD man. Are we unable to resize partitions now? How do we install Linux at all I ask.

    and if /efi gets full of EFI binaries there's no way to sanely clean out anything unused automatically.
    Distros using EFI partition instead of /boot will clean up after themselves just as all distros clean up the /boot folder of unused kernels.

    They are basically using the EFI partition as if it was a FAT32 /boot partition. Because that's all it is. A Fat32 partition with some flags set.

    Comment


    • #22
      Originally posted by Kano View Post
      I don't see a security gain if it is still possible to pass kernel options without a password without encryption. You own the system in seconds this way
      Afaik GRUB can be set to ask for password before editing boot settings

      Comment


      • #23
        Originally posted by starshipeleven View Post
        Sorry but I have to stop you right there good sir.
        rEFInd is VERY good at dealing with multiboot environments as it scans all kernels/OS/bootloaders on boot so it will autodetect everything without any mainteneance on your side.
        It also allows you to edit the command line parameters (actually allows you to set up multiple sets of them in a config textfile beforehand so you can just choose another profile if you don't want to type).

        It also has menu for EFI tools like memtest and EFI shell (that you need to provide and drop in the appropriate folder), and can reboot to UEFI firmware (as long as the UEFI allows this at all).

        It also detects automatically the secure boot management tool things a distro installs in the EFI partition so you can also invoke them on boot to do key management.

        GRUB can do all this only with extensive configuration that has to be updated manually on any kernel/OS/bootloader change.


        What GRUB can do which rEFInd can't do is actually access LVM or RAID (* with metadata=0.9 it can access it but your array size is now limited to 2TB) or encrypted partitions to boot your kernel.
        You're wrong.

        GRUB also auto-detects OS - in distros like Ubuntu, Fedora etc. it's automatically done as a part of kernel updates. In distros like Arch where you choose the bootloader, it doesn't get run automatically, but we just need to run a simple command "grub-mkconfig -o <grub_cfg_file_path>" and GRUB auto-detects all installed OS and adds entries for them.

        You can easily set up the command line parameters for Linux kernels in GRUB, in the config file /etc/default/grub. You can also boot memtest from GRUB - it's not new, that capability has been around for several years.

        I don't know about Secure Boot support, but I use Arch Linux so I have to set up stuff manually. I know someone who has Ubuntu installed on a computer, with Secure Boot enabled and it uses Grub, and it works fine for them, no manual config required.

        Comment


        • #24
          Maybe you should mention that the GRUB os detection uses os-prober - I patched it several times

          The topic is only about Secure Boot enabled installations where you chainload a signed (by the OS vendor) grub.efi from a signed (usually with MS keys) shim.efi. I would prefer a MS signed systemd-boot/gummiboot binary without any limits however - that would be a much cooler news

          Comment


          • #25
            Originally posted by sandy8925 View Post
            You're wrong.
            no sir, you are wrong.

            GRUB also auto-detects OS
            No, that's a helper script that runs and rebuilds a STATIC grub configuration.
            "auto-detection" means that it actually does this on its own power, and GRUB does not.

            The issue for multiboot environments is that you have a single distro that will be the "main GRUB distro" as it is the one running this helper script to update the GRUB STATIC configuration, you can't have all distros update a common grub without screwing up stuff.

            rEFInd by default will scan for stuff on boot so you don't need to write any configuration. It does support static config too but it's not required. It's basically fire-and-forget. I never touched my EFI partition in years (while each time you update the kernel the "auto detection" helper script

            You can easily set up the command line parameters for Linux kernels in GRUB, in the config file /etc/default/grub. You can also boot memtest from GRUB - it's not new, that capability has been around for several years.
            And each time you need to run the grub update script, that updates the STATIC grub configuration. And if you have multiple OS then you need to have different commandlines for each in /etc/default/grub.

            rEFInd reads the kernel commandline parameter file in each distro's /boot every boot so you just edit it and it's ready, and you don't need to have a central file for all distros.

            Comment

            Working...
            X