Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Booting an UEFI system [SOLVED]
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
srs5694
Guru
Guru


Joined: 08 Mar 2004
Posts: 434
Location: Woonsocket, RI

PostPosted: Sat Apr 21, 2012 3:10 pm    Post subject: Reply with quote

I have essentially no experience with encrypted filesystems, but my understanding matches what quadbox has said, with a couple of exceptions:


  • The ESP on Macs is normally FAT, although the Mac's EFI implementation understands HFS+, so you could make it HFS+ if you wanted to. This would violate the EFI specification, which might have unpredictable consequences in the future.
  • Apple's EFI starts up a bit weirdly by EFI standards. It normally doesn't touch the ESP; instead, it reads a "blessed" boot loader file, which is conventionally stored on a non-ESP HFS+ partition.


Thus, depending on your needs you might want to either store a boot manager (or even a Linux boot loader) on an HFS+ volume and "bless" it. Once it's booted, the process proceeds as quadbox outlined. The HFS+ "boot volume" needn't be a regular OS X root partition. On my Mac, I've got a smallish (~200 MiB, IIRC) partition set up to hold rEFInd, Linux boot loaders, Linux kernels, and Linux initial RAM disk files. Making this an unjournaled HFS+ volume makes it possible to read and write it from Linux. In effect, it's an "ESP 2.0."

As to boot manager and boot loader selection, I am of course biased, but I've been using my rEFInd in conjunction with the kernel's EFI stub loader on all my EFI systems. As of rEFInd 0.2.7, the program can now load EFI drivers, and a couple of EFI drivers for Linux filesystems are now available -- an ext2fs driver (which also works with ext3fs) and a ReiserFS driver. This makes it possible to store the Linux kernel on a Linux partition, which is handy on Macs; at least on my old Mac Mini, the EFI stub loader can't seem to load its own initial RAM disk from a FAT filesystem, so storing these on the ESP isn't possible unless that's been converted to HFS+. Using ext2fs or ReiserFS on a /boot partition makes for an appealing alternative. Of course, if you go this route, this partition will have to be unencrypted. That's true of just about any solution you use, though, whether the kernel's on the ESP, an HFS+ partition, or a Linux partition.
Back to top
View user's profile Send private message
avx
Advocate
Advocate


Joined: 21 Jun 2004
Posts: 2151

PostPosted: Sat Apr 21, 2012 4:22 pm    Post subject: Reply with quote

Not completely related, but... does anyone know, if/how I can change the greyish startup screen of a Mac, which comes before rEFInd is loaded?
_________________
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.
Back to top
View user's profile Send private message
gw
Apprentice
Apprentice


Joined: 03 Dec 2006
Posts: 215

PostPosted: Tue Apr 24, 2012 3:32 pm    Post subject: Reply with quote

Thanks quadbox! that made it a lot clearer.

I kind of solved the process with regard to encryption, as I tried to create an initram able to decrypt the real root and swith to it:
Code:
#!/bin/busybox sh

mount -t proc none /proc
mount -t sysfs none /sys

sleep 5

cryptsetup -T 5 luksOpen /dev/sda3 root
mount -o noatime -t xfs /dev/mapper/root /mnt/root

umount /proc
umount /sys

exec switch_root /mnt/root /sbin/init


This works very well in a Virtualbox gentoo installation. What else would you put in your init script?

quadbox wrote:
[ESP] Must contain both your kernel and initramfs, and some way to make EFI load it.

Is there a way to put the kernel and the initram on an external (usb) drive and have efi find and boot that?

quadbox wrote:
So the steps are: EFI starts up, finds your primary boot drive. It searches for the ESP, then loads the default .efi application there. We make that refind. Refind loads, searches its configs and the ESP for whatever available bootable OSes it can find on the ESP, gives you a menu. You pick gentoo. EFI then loads the linux kernel and initramfs. The init script in your initramfs initialises every program necessary to get dm-crypt support up, then brings your root device up, then mounts it, and switches root and starts your primary init

Thanks this was really helpful!

quadbox wrote:
The answer to 3) is Yes, though obviously having an LVM within a dm_crypt device just adds even more to the overhead. and you've got to ask why the hell you feel you need an encrypted /, /boot and swap. I mean encrypted /home sure, but seriously?. Also, if you're using the above setup there's no particular need to have a seperate /boot unless you really want to. your ESP can be mounted on /boot. only downside is that it's hfs+ (or vfat on a non-mac machine)

I am trying to make this macbook my only machine, so everything is on it and I carry it around a lot; hence my need for full encryption.

Thanks again.

gw
Back to top
View user's profile Send private message
srs5694
Guru
Guru


Joined: 08 Mar 2004
Posts: 434
Location: Woonsocket, RI

PostPosted: Tue Apr 24, 2012 4:21 pm    Post subject: Reply with quote

gw wrote:
quadbox wrote:
[ESP] Must contain both your kernel and initramfs, and some way to make EFI load it.

Is there a way to put the kernel and the initram on an external (usb) drive and have efi find and boot that?


Yes. In theory, an EFI can run any boot program on any filesystem that it can read, including external USB flash drives. There's subtlety and weirdness around the details, though, and Macs deviate even from the usual EFI weirdness. You might be able to get it to work by naming a Linux boot loader EFI/boot/bootx64.efi on the ESP of an external drive. If the boot loader is configured to look for the kernel on the external drive (or if it was the boot loader, in the form of a kernel with EFI stub support), then you could have a kernel-less hard disk with a kernel on a USB flash drive. Without the flash drive, the computer will boot normally. With the flash drive plugged in (and possibly holding down Option when you boot), you'll get the option to boot Linux.

Another option is to use rEFInd. By default, rEFInd scans internal hard disk partitions, external hard disk partitions (including those on USB flash drives), and optical discs for EFI boot media. Thus, if you install rEFInd on the hard disk and put a Linux boot loader (ELILO, GRUB, or a kernel with EFI stub loader) on a USB flash drive, then when rEFInd starts up with the USB flash drive installed, rEFInd will detect your Linux boot loader and present it as an option.

As a variant on either of these, you can set up your USB flash drive so that it (or one of its partitions) is mounted as /boot (perhaps not automatically, to minimize the risk should you pull the USB flash drive after booting). Then you could use it pretty much normally once booted; just drop your kernels in /boot and, depending on your boot loader, update it when you upgrade your kernel. The caveat is that /boot will have to be EFI-readable. This normally means FAT (or HFS+ on a Mac); however, there are ext2/3 and ReiserFS drivers for EFI, so you could store your kernel on one of those filesystems. Since version 0.2.7, rEFInd has been able to load filesystem drivers automatically, so the combination of rEFInd, a filesystem driver, and the kernel stub loader can make for a very seamless kernel management system, with no need to edit configuration files for kernel upgrades once everything's set up and working.
Back to top
View user's profile Send private message
89c51
Tux's lil' helper
Tux's lil' helper


Joined: 31 Dec 2005
Posts: 113
Location: Greece

PostPosted: Sat Jun 02, 2012 9:42 pm    Post subject: Reply with quote

sorry for bumping a solved thread but i am interested in setting up a bootloaderless system (single kernel using efi stub) i have a question regarding EFI drivers.

i read that it is possible to boot from any partition type but how can someone install these drivers (ie ext2fs) in EFI (intel mobo)?

most examples i've seen thus far use FAT filesystems.

:?:
Back to top
View user's profile Send private message
srs5694
Guru
Guru


Joined: 08 Mar 2004
Posts: 434
Location: Woonsocket, RI

PostPosted: Sun Jun 03, 2012 5:32 pm    Post subject: Reply with quote

89c51 wrote:
i read that it is possible to boot from any partition type but how can someone install these drivers (ie ext2fs) in EFI (intel mobo)?


In theory, you can register the driver with the EFI in much the same way you can register a boot loader with the EFI. In practice, though, few EFI implementations provide a user interface to do this, and I don't know of any OS-hosted tools (equivalents to "efibootmgr" in Linux) that will do the job.

Thus, in practice you're likely to have to do it in some other way. One is to use rEFIt or rEFInd as a sort of "driver loader;" these programs include code to scan certain directories for drivers and to load any that they find. Of course, if you don't want the boot menus that these programs provide, that may be an undesirable complication. You could set a default entry with a timeout period of 1 second, which would at least minimize the time the boot menus appear. If you're a little more ambitious, you could create a patched version of rEFIt or (better) rEFInd that enables setting a timeout period of 0 seconds and skips display of the menu when this is set. I'm willing to consider incorporating such a patch into rEFInd.

Another option is to use an EFI shell and its startup script. If you set an EFI shell as the default boot loader, it will look for a file called "startup.nsh" in the ESP's root directory and run it as a script. This script could include the "load" command to load the driver and then a "map -r" command to remap the filesystem assignments (similar to "mount -a" in Linux). This will work, but there's usually a delay between the shell launching and its running its startup script, so it'll delay the system's boot process -- probably more than using rEFIt or rEFInd would do.

If you really want a system that just boots one fixed kernel via its EFI stub loader, the simplest solution really is to store that kernel on the ESP. This will involve copying the kernel from its normal location in /boot -- or you could mount the ESP as /boot, store the kernel in the normal place, and create an EFI NVRAM entry to point to the kernel in what will be the unusual location of the ESP's root (from the EFI's perspective).
Back to top
View user's profile Send private message
89c51
Tux's lil' helper
Tux's lil' helper


Joined: 31 Dec 2005
Posts: 113
Location: Greece

PostPosted: Sun Jun 03, 2012 7:48 pm    Post subject: Reply with quote

Thanks for the reply and your really helpful webpage (you are rod right?? :) ).

What i was thinking to do was to avoid having a FAT partition. From what i've read so far this doesn't seem possible at least when using the efistub, which was what i wanted. I don't think its possible to store the driver somewhere where it can be read before boot -outside a HD- unless someone includes it to the MB bios.

I'll probably go with the last solution.

Thanks again.
Back to top
View user's profile Send private message
srs5694
Guru
Guru


Joined: 08 Mar 2004
Posts: 434
Location: Woonsocket, RI

PostPosted: Sun Jun 03, 2012 10:58 pm    Post subject: Reply with quote

89c51 wrote:
Thanks for the reply and your really helpful webpage (you are rod right?? :) ).


Yes, I am; and you're welcome for the Web pages.

Quote:
What i was thinking to do was to avoid having a FAT partition. From what i've read so far this doesn't seem possible


It's not possible, at least not with a standard EFI implementation. EFI is designed to read boot loaders from the ESP, and the only filesystem mandated by the EFI spec is FAT. In fact, the ESP is explicitly mandated to be FAT32, although in practice it can be FAT16 on most systems. (Apple includes an HFS+ driver in their version of EFI, so Macs can boot without a FAT partition, although Apple does include a standard FAT32 ESP on their Macs.)

In theory, you could build your own EFI implementation using Coreboot and a TianoCore payload that's been customized to include additional drivers. Such a system could theoretically use a ReiserFS, ext2fs, ext3fs, or HFS+ ESP (to name just those filesystems for which I know open source drivers exist). This would be a lot of work to create with little to no real benefit. I realize some people have an aversion to FAT, but for the limited purposes of the ESP, it's really not that bad, and it's not like it'll infect the rest of your hard disk with a contagious disease or anything.
Back to top
View user's profile Send private message
89c51
Tux's lil' helper
Tux's lil' helper


Joined: 31 Dec 2005
Posts: 113
Location: Greece

PostPosted: Sun Jun 03, 2012 11:30 pm    Post subject: Reply with quote

srs5694 wrote:

In theory, you could build your own EFI implementation using Coreboot and a TianoCore payload that's been customized to include additional drivers. Such a system could theoretically use a ReiserFS, ext2fs, ext3fs, or HFS+ ESP (to name just those filesystems for which I know open source drivers exist). This would be a lot of work to create with little to no real benefit. I realize some people have an aversion to FAT, but for the limited purposes of the ESP, it's really not that bad, and it's not like it'll infect the rest of your hard disk with a contagious disease or anything.


In practice the problem we have is that there is no motherboard (afaik) supporting the latest processors (ie. latest gen i7) open enough to allow that kind of hacking. In coreboot i think you can have the kernel as the payload and there is no need for any "fancy stuff".

Sadly such a hardware piece does not exist.

Thanks again for the replies.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum