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
here.
>> 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
available.
>> 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
>
>No.
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
>
>Okay.
>
>> 6. Several tweaks to partman-auto:
>> * Switch from fat16 to fat32 in ia64 recipes
>
>Why?
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
>alligned.
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: