UEFI System Partition + ramdisk confusion

Tie-fighter · 2013-08-21 12:48:18

Hi.

I want to install 2013.08 using UEFI and GPT.

I have created the following partitions using cgdisk /dev/sda:
x 3.0 KiB free space (due to sector alignment)
1 512.0 MiB EFI System
2 465.3 GiB Linux LVM (encrypted)

Do I need to have another partition for the initrd? (I mount /dev/sda1 under /boot/efi as suggested here: https://wiki.archlinux.org/index.php/Gr … _systems_2)
Where do I put it?

Last edited by Tie-fighter (2013-08-21 12:49:17)

Tie-fighter · 2013-08-21 13:08:52

Will try again with a third partition as mentioned here:

http://superuser.com/a/587521

Tie-fighter · 2013-08-21 14:19:47

Using another partition for /boot I suceeded

WonderWoofy · 2013-08-21 18:54:59

It depends on what you are using as a bootloader. As of right now, most of the UEFI bootloaders and boot managers require the kernel and initramfs to be in the ESP itself, as they don't have the required filesystem drivers to read from the normal Linux partitions. There are two that are capable of this though, one is grub2, which is a traditional bootloader (has the mechanisms necessary to load kernel and initramfs) and the other is rEFInd, which is a boot manager. The boot manager depends on CONFIG_EFISTUB in the kernel itself to launch the kernel. Therefore, the kernel is acting as its own bootloader (or efi application).

The problem you are facing here is that your kernel and initramfs are now not only on a normal Linux filesystem, but they are also within a Linux LVM. This setup currently is only supported by one bootloader and that is grub2 (for both UEFI and legacy bios). I am not sure exactly how to set it up, but I imagine that like most things, grub2 tries to autodetect the situation at hand, and then apply the required features into the grub.efi it installs. For new users, this can be a blessing, but also introduces a number more fails points. Automation also means that detecting what has gone wrong is also not quite as easy, as you don't really know what the hell happened in the first place.

Recently, I moved my ESP to /boot/efi so that I can have my kernels and initramfs' included with the btrfs snapshots I create. This makes it so that the kernel version matches with the modules in /usr/lib/modules. But before I made this change I simply mounted the ESP at /boot so that the normal kernel installation procedure would drop the kernel directly on the ESP. Mkinitcpio would also put the generated initramfs on the ESP as well with the default setup. This allowed for me to use any bootloader or boot manager I pleased, as they all have the ability to read the kernel and initramfs from the ESP itself. So my first choice in boot managers is gummiboot, but I also have rEFInd set up so that I can use it launch the btrfs snapshots as well, in the event that I want to roll back.

You should be aware though, that some firmwares have had real issues with the efistub feature of the kernel. Various kernel versions have ended up unbootable via this method sometimes. This has typically affected Thinkpads, but it is not limited to them. So for this reason, you should also have a backup bootloader (the traditional kind) ready to go, just in case efistub craps out on you. My choice until recently was elilo, as it is super reliable, and incredibly easy to configure. But as of v6 of syslinux, there is UEFI support. This package is in [testing] (and has been for a while), but I do believe that you can build the syslinux-efi package from the AUR. The configuration file for syslinux-efi is exactly the same as the bios version, so it is also super simple.

Anyway, I'm glad you got things working. I just thought you might want a better idea of the problem you were actually facing and why creating a separate /boot was able to make things workable.

cfr · 2013-08-23 02:39:18

I think the central problem was that the LVM was encrypted. No boot loader or manager can work with the configuration described. You could mount the ESP at /boot and that would work. Or, as you discovered, you can add a separate /boot partition. You could also use a separate device, I think, such as a USB key. But whatever you do, the initramfs and kernel must be outside the encrypted container.

EDIT: Note that this is because it is hooks in the initramfs etc. which decrypt the encryption container. Only at that point can the system see the LVM. So grub's ability to use LVM at boot is no good because the LVM isn't available at that point in the boot process. At least, that's how I understand it.

Last edited by cfr (2013-08-23 02:41:35)

WonderWoofy · 2013-08-23 03:30:40

Damn, again, I just totally missed that relevant part. And again, thanks cfr for pointing that out. That would indeed be the issue at hand here.

cfr · 2013-08-23 20:32:35

WonderWoofy wrote:

Damn, again, I just totally missed that relevant part. And again, thanks cfr for pointing that out. That would indeed be the issue at hand here.

I have the advantage of using a configuration which is essentially identical - everything bar the ESP and /boot is in LVM and the volume group sits inside a LUKS container. Maybe we should call it lvm-IN-luks rather than lvm-ON-luks ?

WonderWoofy · 2013-08-24 00:30:40

Honestly, I think that lvm in luks is actually quite a bit more clear, and might make more sense to those who aren't native English speakers… though this is coming from a native English speaker.

cfr · 2013-08-24 00:51:32

That's what I thought.

If the mess is on the table, I have to deal with the mess first to get to the table. If the mess is in the drawer, I have to open the drawer first to deal with the mess. So with lvm-in-luks.

WonderWoofy · 2013-08-24 01:14:00

That kind of analogy didn't come to mind, but it makes perfect sense. Now talking about this, in hindsight, both the words container (luks) and volume (lvm) seem to be things which one would put other things in not on.

cfr · 2013-08-24 01:25:33

Yes. I actually always think of luks as a sort of large empty tin can which has lost the original label and is rusting a bit. (Not terribly secure because the lid is off but I guess that's fine for the opened container. I guess that's why I though in better than on.) Not sure where the mess metaphor came from - except for the obvious cause surrounding me .

Arch Linux

#1 2013-08-21 12:48:18

UEFI System Partition + ramdisk confusion

#2 2013-08-21 13:08:52

Re: UEFI System Partition + ramdisk confusion

#3 2013-08-21 14:19:47

Re: UEFI System Partition + ramdisk confusion

#4 2013-08-21 18:54:59

Re: UEFI System Partition + ramdisk confusion

#5 2013-08-23 02:39:18

Re: UEFI System Partition + ramdisk confusion

#6 2013-08-23 03:30:40

Re: UEFI System Partition + ramdisk confusion

#7 2013-08-23 20:32:35

Re: UEFI System Partition + ramdisk confusion

#8 2013-08-24 00:30:40

Re: UEFI System Partition + ramdisk confusion

#9 2013-08-24 00:51:32

Re: UEFI System Partition + ramdisk confusion

#10 2013-08-24 01:14:00

Re: UEFI System Partition + ramdisk confusion

#11 2013-08-24 01:25:33

Re: UEFI System Partition + ramdisk confusion

Board footer