Announcement

Collapse
No announcement yet.

Going GRUB-less with UEFI

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Going GRUB-less with UEFI

    Yesterday, Phoronix posted an article about Ubuntu switching back to GRUB2 for UEFI secure boot. In the comments, Kano (a Kanotix developer) floated the idea of not using GRUB on a UEFI system. I mentioned that's something I plan to learn; Kano replied with instructions on how to set it up.

    I tested it, and can report that it works perfectly on Quantal. My T520 has a UEFI NVRAM variable pointing directly to the kernel. I created a second one, with the recovery kernel boot option, because it seemed like a good idea. Here is a dump of my EFI boot manager:

    Code:
    steve@t520:~$ [B]sudo efibootmgr -v[/B]
    BootCurrent: 001B
    Timeout: 0 seconds
    BootOrder: 001B,001A,0019,0006,000C,0007,000A,0008,000D,000E,000F,000B,0009,0011,0012,0010,0013
    ---
    Boot0019* Ubuntu recovery mode
              HD(1,28,100000,35a3de7a-7015-4855-b882-1c8e9432b8fe)
              File(\EFI\ubuntu\linux.efi)
              root=UUID=fc16861b-bbd1-4c97-8d70-49839f97db83
              ro nox2apic noop nomodeset recovery
              initrd=EFI\ubuntu\initrd.img
    Boot001A* Ubuntu direct with initrd
              HD(1,28,100000,35a3de7a-7015-4855-b882-1c8e9432b8fe)
              File(\EFI\ubuntu\linux.efi)
              root=UUID=fc16861b-bbd1-4c97-8d70-49839f97db83
              ro nox2apic noop acpi_osi=Linux pcie_aspm=force raid=noautodetect
              initrd=EFI\ubuntu\initrd.img
    Boot001B* Ubuntu direct
              HD(1,28,100000,35a3de7a-7015-4855-b882-1c8e9432b8fe)
              File(\EFI\ubuntu\linux.efi)
              root=PARTUUID=5d630312-d283-4812-94f9-d6ca92b966f5
              ro nox2apic noop acpi_osi=Linux pcie_aspm=force raid=noautodetect
    (I've taken some liberties with the formatting: I removed the variables that reference the UEFI's internal menu options, I've added line breaks in the variables, and I've deleted the periods that normally sit between each letter in the boot parameters -- a Unicode artifact.)

    Boot001B boots the kernel from the EFI partition and the initrd from the root file system. Boot001A boots both the kernel and the initrd from the EFI partition; it takes about one second longer. I've asked for clarification why. Boot0019 is recovery mode. The default is Boot001B; to choose one of the others, I press [F12] during startup to see the UEFI boot manager menu.

    It's nice not having to mess with GRUB! GRUB is certainly overkill for a single-OS machine. It'll be interesting to see what happens when a kernel update comes down the 'tubes. There appear to be no configuration scripts for this kind of setup, so I'll need to manually copy the newer vmlinuz and initrd from /boot to /boot/efi/EFI/ubuntu. And yes, I've purged all of GRUB from my computer.

    I'll update this thread with any new developments.
    Last edited by SteveRiley; Sep 25, 2012, 02:10 AM.

    #2
    This is some scary stuff for us simple, non-professional IT hobbyists. I hope my 3 year old computer keeps on chugging for a long, long time or something more understandable is developed in the not to far future. This whole UEFI business is so far over my head.
    Linux User #454271

    Comment


      #3
      notabug, you have a 3-year-old PC? Lucky you! Actually, me, too, built in 2009. I also have one that's 7 years old, I built it in 2005, (I'm using it now, with Kubuntu 8.04.3). You needn't worry for a very long time.

      " I hope ... something more understandable is developed in the not to far future." I suspect that will happen, too.

      Unified Extensible Firmware Interface
      http://en.wikipedia.org/wiki/UEFI

      I wouldn't worry as this thing shakes out fully. Although I 'was' a GRUB Legacy expert, I'm also a bit behind here with these recent developments, as I'm sure many people are. And, fact is, notabug, you can simply continue using GRUB 2.
      GRUB 2: A Guide for Users
      http://www.kubuntuforums.net/showthr...uide-for-Users
      An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

      Comment


        #4
        Thank you Qqmike. Your reply is very reassuring. The ability for me to control my machine is very important. And thanks for the links.
        Linux User #454271

        Comment


          #5
          I built my comp about 2 year ago and my lappy id about a year old. Both bave BIOS, guess I won't need to deal with EFI for awhile. I kinda wanna try it out though...

          Sent from my GT-I9000 using Tapatalk 2
          Registered Linux User 545823

          Comment


            #6
            Originally posted by SteveRiley View Post
            It's nice not having to mess with GRUB! It's certainly overkill for a single-OS machine. It'll be interesting to see what happens when a kernel update comes down the 'tubes. There appear to be no configuration scripts for this kind of setup, so I'll need to manually copy the newer vmlinuz and initrd from /boot to /boot/efi/EFI/ubuntu. And yes, I've purged all of GRUB from my computer.

            I'll update this thread with any new developments.
            is their no way to point to the 2 system links in / vmlinuz & initrd.img that always point to the newest kernel and initrd?
            i7 4core HT 8MB L3 2.9GHz
            16GB RAM
            Nvidia GTX 860M 4GB RAM 1152 cuda cores

            Comment


              #7
              Originally posted by notabug View Post
              This is some scary stuff for us simple, non-professional IT hobbyists. I hope my 3 year old computer keeps on chugging for a long, long time or something more understandable is developed in the not to far future. This whole UEFI business is so far over my head.
              For the majority of people, UEFI is invisible. Any machine purchased in the last couple years is likely to have it. My posts throughout KFN regarding UEFI reflect my desire to understand the intimate details of how this thing works. Partly just to satisfy my thirst for knowledge, and partly because I hope to be able to coach folks through installing Linux once computers start arriving with secure boot enabled and we all have to deal with signed bootloaders.

              Regarding the specifics of my experiment, I feel that eliminating GRUB greatly simplifies the work required to maintain even a multi-boot computer. All UEFI implementations already have a boot manager, so why not just use that instead of some extra piece of software? The only thing required to automate what I've done is to implement some scripts that copy the kernel into the EFI partition and create the NVRAM variable that points the boot manager to the kernel. This is trivial, especially when compared to all the OS probing that GRUB encumbers itself with. Of course, however, only UEFI-capable operating systems can play here, but this list includes most recent Linux distros, Windows Vista and above, and Mac.

              Comment


                #8
                Originally posted by vinnywright View Post
                is their no way to point to the 2 system links in / vmlinuz & initrd.img that always point to the newest kernel and initrd?
                Answering this requires a brief explanation.

                A UEFI-capable operating system requires two things:
                • A boot loader
                • An entry in the EFI boot manager

                The UEFI specification states that all boot loaders must reside on a dedicated EFI system partition. I've set mine to be 512 MiB. This partition contains one directory: EFI. Within this partition is a separate subdirectory for each operating system. Within each subdirectory is the operating system's boot loader.

                Here is a partial list of the contents of my EFI partition:
                Code:
                steve@t520:/boot/efi$ [B]ll -R EFI[/B]
                EFI:
                total 16
                drwxr-xr-x 4 root root 4096 Sep 16 22:59 ./
                drwxr-xr-x 3 root root 4096 Dec 31  1969 ../
                drwxr-xr-x 2 root root 4096 Sep 23 14:15 ubuntu/
                
                EFI/ubuntu:
                total 27272
                drwxr-xr-x 2 root root     4096 Sep 23 14:15 ./
                drwxr-xr-x 4 root root     4096 Sep 16 22:59 ../
                -rwxr-xr-x 1 root root  5128128 Sep 22 21:02 linux.efi*
                Typically, to make this partition easy to manage, it's useful to mount it into your file system. Here are the relevant lines from my /etc/fstab:
                Code:
                steve@t520:~$ [B]cat /etc/fstab[/B]
                # / was on /dev/sda2 during installation
                UUID=fc16861b-bbd1-4c97-8d70-49839f97db83  /  ext4  noatime,discard,data=writeback  0 1
                # /boot/efi was on /dev/sda1 during installation
                UUID=0B73-BB16  /boot/efi  vfat  defaults  0 1
                I've learned in my experiments is that it's very handy to keep a copy of the UEFI Shell on your computer. This is a miniature operating system that provides important control over your UEFI environment. It's one of the many attributes that make UEFI superior to BIOS -- you really can do more with this new type of firmware.

                Here is a more complete list of the contents of my EFI partition:
                Code:
                steve@t520:/boot/efi$ [B]ll -R EFI[/B]
                EFI:
                total 16
                drwxr-xr-x 4 root root 4096 Sep 16 22:59 ./
                drwxr-xr-x 3 root root 4096 Dec 31  1969 ../
                drwxr-xr-x 2 root root 4096 May 19 20:58 boot/
                drwxr-xr-x 2 root root 4096 Sep 23 14:15 ubuntu/
                
                EFI/boot:
                total 756
                drwxr-xr-x 2 root root   4096 May 19 20:58 ./
                drwxr-xr-x 4 root root   4096 Sep 16 22:59 ../
                -rwxr-xr-x 1 root root 763360 May 19 20:58 bootx64.efi*
                
                EFI/ubuntu:
                total 27272
                drwxr-xr-x 2 root root     4096 Sep 23 14:15 ./
                drwxr-xr-x 4 root root     4096 Sep 16 22:59 ../
                -rwxr-xr-x 1 root root  5128128 Sep 22 21:02 linux.efi*
                EFI/boot/bootx64.efi is the UEFI shell. To run it, I simply press [F12] to invoke the boot manager during startup, and I select it from the menu. EFI/ubuntu/linux.efi is my Linux kernel, and is currently the default "boot loader" chosen when I don't interrupt the startup with [F12].

                Now, why did I type "boot loader" in quotes? Ubuntu kernels are now compiled to appear as UEFI images, and can therefore boot Ubuntu without the need of a separate utility like GRUB or ELILO. But since UEFI requires the boot loaders to be physically present on the EFI system partition, it's necessary to copy the kernel image from the root partition to the EFI system partition. The kernel hasn't yet loaded at this stage in the boot process, so only the EFI system partition is visible. That's why you can't simply symlink to vmlinuz.

                Another feature Ubuntu adds to their UEFI-capable kernels is compiled-in file system support. After the boot loader portion of the kernel completes, all of the file systems on your computer become visible (except RAID). This is why it isn't strictly required that you place the initrd on the EFI system partition. UEFI does allow this, however, and since I wanted to compare the differences, I also copied my initrd there and created an NVRAM boot variable for it.

                Therefore, here's my complete EFI partition:
                Code:
                steve@t520:/boot/efi$ [B]ll -R EFI[/B]
                EFI:
                total 16
                drwxr-xr-x 4 root root 4096 Sep 16 22:59 ./
                drwxr-xr-x 3 root root 4096 Dec 31  1969 ../
                drwxr-xr-x 2 root root 4096 May 19 20:58 boot/
                drwxr-xr-x 2 root root 4096 Sep 23 14:15 ubuntu/
                
                EFI/boot:
                total 756
                drwxr-xr-x 2 root root   4096 May 19 20:58 ./
                drwxr-xr-x 4 root root   4096 Sep 16 22:59 ../
                -rwxr-xr-x 1 root root 763360 May 19 20:58 bootx64.efi*
                
                EFI/ubuntu:
                total 27272
                drwxr-xr-x 2 root root     4096 Sep 23 14:15 ./
                drwxr-xr-x 4 root root     4096 Sep 16 22:59 ../
                -rwxr-xr-x 1 root root 22788838 Sep 22 21:44 initrd.img*
                -rwxr-xr-x 1 root root  5128128 Sep 22 21:02 linux.efi*
                You'll note in my earlier post that the first item in the BootOrder list is 001B. This is the entry that loads the kernel from the EFI system partition and the initrd from the root partition. The second variable, 001A, is the entry that loads both the kernel and the initrd from the EFI system partition. For reasons I don't yet understand, booting the computer with this method is slightly slower (slight = 1 second).

                Hope this is clear.

                Comment


                  #9
                  very cool if had UEFI on this (and not the server) i would try it, one question however doesn't this also need to be updated manually on kernel upgrades? maybe a tool to do this is needed in the future.
                  Mark Your Solved Issues [SOLVED]
                  (top of thread: thread tools)

                  Comment


                    #10
                    Originally posted by sithlord48 View Post
                    very cool if had UEFI on this (and not the server) i would try it, one question however doesn't this also need to be updated manually on kernel upgrades? maybe a tool to do this is needed in the future.
                    Yep, that's the script-fu automation I was mentioning earlier. It's really just two commands. It could even go in the debconfs for the kernel.

                    Comment


                      #11
                      That is COOL, Steve!

                      It reminds me somewhat of my first Linux distro, RH5.0. Kernel "upgrades" were nothing more than downloading the boot files and manually installing them, then updating the LILO boot loader and rebooting.

                      This EUFI madness appears to be disappearing like the dew on the grass on a hot summer morning.
                      "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
                      – John F. Kennedy, February 26, 1962.

                      Comment


                        #12
                        Kernel update today. It was a minor one, so the file name didn't change. Nevertheless, I thought I'd use something more descriptive than linux.efi. After the upgrade, when I copied the kernel image to the EFI partition, I used the full name: vmlinuz-3.5.0-15-generic and appended the .efi filename extension. Then I deleted the NVRAM variable and recreated it, using the new name:

                        Code:
                        sudo efibootmgr -c -d /dev/sda -p -1 -l '\EFI\ubuntu\vmlinuz-3.5.0-15-generic.efi' -L 'Ubuntu direct' -u 'root=PARTUUID={blah} {my-usual-parameters}
                        Then when I rebooted, I got dumped to the EFI Shell! Uh oh, must have done something wrong. I displayed the variable:

                        Code:
                        dmpstore boot001a
                        and noticed the following tidbit in the output:

                        Code:
                        File(\EFI\ubuntu\vmlinuz-3.5.0-15-generic.ef)
                        Notice what's missing? The letter "i" at the end of the filename! Apparently, there's a hard-coded maximum length of 39 characters. (Stupid design decision!) Now what? I have to fix this now, it's my work computer.

                        Since I haven't mastered the intricacies of the EFI Shell yet, I booted the alternate install USB I always keep handy. (Why not the "recovery" entry I created? Because, moron that I am, I modified that one, too. Stupid user decision!)

                        I started a shell on /dev/sda2. I mounted /dev/sda1 into /boot/efi. I shortened the name of the kernel to vmlinuz-3.5.0-15.efi. I deleted the malformed variable and created a new one once more.

                        I rebooted and -- yay! -- normalcy had returned.

                        Of course, when all your stuff works, you can never be truly happy, right? So I downloaded today's -rc7 build of kernel 3.6. After installing it, I copied the image to my EFI partition, being mindful of the 39-character path limit:

                        Code:
                        sudo cp /boot/vmlinuz-3.6.0-030600rc7-generic /boot/efi/EFI/ubuntu/vmlinuz-3.6.0-rc7.efi
                        And I added the requisite NVRAM boot variable:

                        Code:
                        sudo efibootmgr -c -d /dev/sda -p -1 -l '\EFI\ubuntu\vmlinuz-3.6.0-rc7.efi' -L 'Ubuntu direct 3.6-rc7' -u 'root=PARTUUID={blah} {my-usual-parameters}
                        Rebooted once more, interrupted the boot with [F12], and chose Ubuntu direct 3.6-rc7. Voila! Unicorns had farted rainbows across the land.

                        One question remained: how do I know whether the two kernels installed will pick their correct initrd? I've opted to stop placing the initrd in the EFI partition. So now I have two initrds in /boot, one for each kernel. One last time to the reboot, this time selecting the prior entry that pointed to the older kernel. Sure enough, it booted without problem. It appears that the kernel knows which initrd to choose.

                        There is some brittleness to this. One time in bandcamp, I left off the -u switch in front of the boot parameter string. The result was that the parameters were stored in the NVRAM varible in ASCII rather than Unicode. This doesn't work: the kernel fails to locate the root partition.

                        I may try to cobble together some basic scripts to simplify this somewhat. Perhaps even contribute that back, who knows?
                        Last edited by SteveRiley; Sep 25, 2012, 02:13 AM.

                        Comment


                          #13
                          "Awesome and clever", I say, while genuflecting in your direction!:cool:
                          "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
                          – John F. Kennedy, February 26, 1962.

                          Comment


                            #14
                            Originally posted by GreyGeek View Post
                            "Awesome and clever", I say, while genuflecting in your direction!:cool:
                            *blush*

                            Sometimes it feels like I'm fumbling in the dark with a flashlight, documenting what I find along the way for later travelers

                            Comment

                            Working...
                            X