wa...@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. st...@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. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1t0ti4-0002b3...@mail.einval.com