[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: EFI approach and patches

waldi@debian.org wrote:
>On Mon, Aug 13, 2012 at 01:10:31AM +0100, Steve McIntyre wrote:
>> 1. Add a new subarch of "efi" for i386 and amd64 in
>>    libdebian-installer, worked out (as usual for EFI) from whether
>>    /sys/firmware/efi is accessible. This filters through readily to
>>    archdetect, used all over the place elsewhere in d-i.
>This needs efivars loaded AFAIK. I'm not yet familiar with the EFI part
>of the Linux kernel.

Yes, it does. It's automatically loaded by the point when it's needed

>> 2. Build efi-reader for amd64 as well as ia64. Not sure if this
>>    provides anything important, but it doesn't hurt. :-)
>This is needed for what?

On ia64, it provides access to EFI variables for things like language
preference. As far as I can see, they're also present on amd64. Not
critical, but there's no point to not use the package if it's already

>> 3. Build elilo-installer for amd64 too, and mark it as installable for
>>    i386/efi|amd64/efi.
>Does elilo provide 32 and 64-bit efi binaries? All the current machines
>need 64-bit binaries.

Yes, it already includes ia32, ia64 and x86_64 code and was already
building for all 3 architectures.

>> 4. Mark grub-installer as not installable for i386/efi|amd64/efi

Not in the long term, agreed. I've just turned it off for now as I was
having problems getting grub-efi to install. Should be fixed shortly,
I hope.

>> 5. Mark lilo-installer as not installable for i386/efi|amd64/efi
>> 6. Several tweaks to partman-auto:
>>   * Switch from fat16 to fat32 in ia64 recipes

For consistency with partman-efi. AFAICS it can only support one
filesystem without significant changes (or maybe a split into
partman-efi and partman-uefi). AFAIK UEFI explicitly wants fat32, so
I've switched over to that consistently.

>>   The first of these needs testing - is EFI on ia64 *definitely* ok
>>   with fat32, or must it have fat16? I've also upped the size of the
>>   EFI partition to 512MB, a more sensible minimum in case of multiple
>>   OS installs. I cloned tha ia64 recipes, then the diff shows the
>>   changes since. Not 100% sure of the best approach for partman-auto,
>>   I'll admit here. Thoughts?
>It works fine with FAT16, however grub needs the partition properly

Alignment seems fine for me:

tack:~/debian/efi$ gdisk -l efi-hard-disk.img 
GPT fdisk (gdisk) version 0.8.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk efi-hard-disk.img: 16777216 sectors, 8.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 4F312FA0-5643-4775-9AB8-01BF3F207487
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 16777182
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          999423   487.0 MiB   EF00  
   2          999424        15994879   7.2 GiB     0700  
   3        15994880        16775167   381.0 MiB   8200  

>> 8. partman-partitioning: for amd64/efi and i386/efi, use gpt instead
>>    of msdos
>Nope. EFI works fine with msdos.

But not reliably on all disks. We'd need to switch to GPT for large
disks (> 2TB), which people are going to want with new UEFI
installations anyway. Looking at the code, I think it's much easier to
just use GPT with UEFI than to bugger with the rest of the partman
code to switch partition style depending on disk size.

>> +/* Are we on an EFI system? Check to see if /sys/firmware/efi
>> + * exists */
>> +static int is_efi(void)
>> +{
>> +       int ret = access("/sys/firmware/efi", R_OK);
>> +    if (ret == 0)
>> +               return 1;
>> +    else
>> +               return 0;
>> +}
>Whitespace damage.

ACK, easily fixed.

Steve McIntyre, Cambridge, UK.                                steve@einval.com
Google-bait:       http://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.

Reply to: