Announcement

Collapse
No announcement yet.

GRUB 2.04 Release Candidate Brings Globs Of New Features

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

  • #31
    To all the people with encryption/compression problems with GRUB:
    Why can't you just keep /boot as a separate EFI partition?

    Comment


    • #32
      Originally posted by rmoog View Post
      To all the people with encryption/compression problems with GRUB:
      Why can't you just keep /boot as a separate EFI partition?
      1) Because we're stuck with GRUB due to not having UEFI to begin with or we have a 32-bit UEFI that doesn't support a 64-bit OS. I reckon that most of us complaining are in one of those situations.

      2) Laptop theft, physical access reasons, security paranoia.

      Comment


      • #33
        Originally posted by hreindl View Post
        no idea why you are that married with 0.90 when 1.0 is fine too, otherwise my /boot won't work
        because I always used 0.9 for these things, and I don't see why your /boot can't work with 0.9.

        yeah, that sure will work on a MBR partitioned disks
        EFI partitions work also in MBR disks as it's required by UEFI spec.

        It's also perfectly possible to convert MBR partitions to GPT, as long as you shrink a few dozen MB the end of the partitions so it leaves some space for the backup GPT partition table.
        http://www.rodsbooks.com/gdisk/mbr2gpt.html

        that's bullshit, touching your partitioning *is* destructive
        reinstalling from scratch is destructive.
        copying to a folder and then rebuilding /boot array in another way that will still boot fine in legacy boot is not.

        and other than you i am responsible for 6 machines sharing the same partitioning, same UUIDs and /etc/fstab content with just different network config and adjusted package set - and no you can't make sure to never forget stop rsync fstab after tested changes on a local machine when you trained for a decade that it works that way and never did reinstalls on any linux setup
        Only 6? Those are rookie numbers.

        that UEFI fuck don't even work proper in a VMware guest
        I routinely boot completely untouched physical USB drives I passthrough inside a UEFI VMWare VM, so I'll just assume you are a noob like debianxfce.

        yeah, that all will work fine having most of the machines up to 300 km away and only reachable via SSH....
        Why do you want to migrate production servers to UEFI? Isn't that stupid and useless?

        Don't shift the goalposts now that I answered your previous question.

        Comment


        • #34
          Originally posted by skeevy420 View Post

          1) Because we're stuck with GRUB due to not having UEFI to begin with or we have a 32-bit UEFI that doesn't support a 64-bit OS. I reckon that most of us complaining are in one of those situations.

          2) Laptop theft, physical access reasons, security paranoia.
          I think that's a silly notion because:

          1) GRUB is a bootloader. It's meant to load a kernel - not have laise faire access to your encrypted volumes. End of story. What do you want to do with GRUB-level access to encrypted stuff anyway? Watch porn from the bootloader in 8086 real mode? Maybe you want GoogleDocs, BattleNet, League of Legends and Amazon EC2 support in GRUB too?
          2) regurgitate_point(1);

          Here's how I managed this problem so far.
          For any computer that I have, I have a USB drive. The content of the USB drive is a fitting GRUB setup - GPT with hybrid MBR for BIOSes, GPT with EFI for EFIs.
          The makeup of the /boot partition on all of these drives is more or less this:
          - kernels
          - initrd matching each kernel with appropriate additions like ZFS, LVM, LUKS, GPG, NFS, MD support
          - GRUB config
          - additional GRUB files, but not that many really
          Meanwhile the dormant drive is encrypted before anything else. It doesn't even have a partition table.
          So here's how to properly boot:
          1. Insert USB
          2. Power on
          3. Select kernel
          4. Wait for GPG/ZFS/LUKS password prompt
          5. At this point you can remove the drive since it's guaranteed the initrd and kernel loaded entirely into RAM
          6. Enter password
          7. The rest takes care of itself

          Easy? Easy. No need to bother GRUB devs with adding LGFSoT encryption (Latest Gimmick File System or Thing).
          This way any thief will have the impression the computer contains no OS unless they also obtain the bootloader USB.

          Comment


          • #35
            Originally posted by rmoog View Post

            I think that's a silly notion because:

            1) GRUB is a bootloader. It's meant to load a kernel - not have laise faire access to your encrypted volumes. End of story. What do you want to do with GRUB-level access to encrypted stuff anyway? Watch porn from the bootloader in 8086 real mode? Maybe you want GoogleDocs, BattleNet, League of Legends and Amazon EC2 support in GRUB too?
            2) regurgitate_point(1);

            Here's how I managed this problem so far.
            For any computer that I have, I have a USB drive. The content of the USB drive is a fitting GRUB setup - GPT with hybrid MBR for BIOSes, GPT with EFI for EFIs.
            You know damn well we were all discussing single disk systems and the inherent limitations GRUB has in those setups. Full disk LUKS2 encryption? Not if you have to use GRUB. Full featured ZFS volume? Not with GRUB.

            FWIW, I use the USB method with LUKS from time to time, but it doesn't mean that I wouldn't like having the contents of /boot covered with my system snapshots, the ability to use the same encryption implementation as everything else, to simply not have that one special disk that needs special treatment regardless of what the disk is actually used for...that last one is the reason I'm a ZFS user since it covers damn near anything I could do with a storage device in extremely flexible ways.

            If you read the thread you'd realize that I have indirectly answered your GRUB level access question already...well starshipeleven did and I just agreed...

            Originally posted by skeevy420 View Post
            Yep. There are just better alternatives these days and GRUB can be slow to keep up since it implements everything on its own.

            Makes more sense to use a bootloader that relies on the kernel for supported features than on the bootloader itself. It's one of the biggest limitations I run into as a person that uses GRUB due to my older system. If you (want to) move on to LUKS2, BTRFS, or ZFS, GRUB starts to show its limitations that UEFI and other loaders don't have.
            We don't necessarily want the bootloader to be able to access all of that or to have all of those capabilities and would rather rely on our kernels for whatever functionality that we need. The only time you'd want the bootloader to be able to access all of that is if you FUBAR'd something and need a rescue shell.

            Comment


            • #36
              Originally posted by skeevy420 View Post

              You know damn well we were all discussing single disk systems and the inherent limitations GRUB has in those setups. Full disk LUKS2 encryption? Not if you have to use GRUB. Full featured ZFS volume? Not with GRUB.
              Like I said - delegate this functionality to the initrd.

              Comment


              • #37
                Originally posted by q2dg View Post

                Systemd's bootctl just works fine if you want a menu
                It boots the default or I press F12 and select the kernel / OS I want to load instead

                Comment

                Working...
                X