|
Now that the Beta release is out, I hope that contributor's
workloads are reduced sufficiently to help me with some questions. I originally sent this email out 12-Dec-2007 but with the
apparent workload everyone had, and the fact this was certainly a low priority
for most people, I waited till now to resend it. I am hoping all these issues
can be resolved for the official release of Lenny, but if not, at least soon
afterwards. I have already posted a bug against Debian-CD to have a
mixed mode i386 Install CD, but there are other issues with the install I need
to address and I am not sure what package to look at or report a bug with, so I
want to summarize the issues here: By the way, I believe none of these issues exists on the
IA64 version. ---------------------------------------- Issue 1: Booting the Install CD: Bug #455914 Need to have i386 EFI boot files included to kick off the
install on an i386 EFI based system. The "Boot CD" would contain a file system in the
El Torito area instead of just a boot file. El Torito either points to an Image which is loaded into
memory and executed to perform the boot (current method), or it points to a
File System which can contain multiple files. This File System area contains a
Boot Sector which points to the Boot Loader image. So the original El Torito
bootable image simply gets moved down one level into a file system to make this
transparent to Legacy systems. EFI systems ignore the Bootloader and simply
assigns an "fs#" (File System Number) to the partition, then look for
the file Startup.nsh to autorun (similar to booting DOS and running
Autoexec.bat). ---------------------------------------- Issue 2: Guided Partitioning program needs to support EFI:
(parted-efi or its scripts) I am not sure if this is a 'parted-efi' problem or if there
is some script that just invokes it after querying the user. The "Guided Partitioning" scripts should detect if
'efivars.ko' is loaded (or /sys/firmware/efi exists). If it is not loaded then we can assume this is a standard
Legacy system and install normally. If we find that 'efivars.ko' (or /sys/firmware/efi) is
present, then we can assume this is an EFI based system and do the following: 1. If the hard drive is currently
"raw", create a GPT (GUIDed Partition Table) on it. 2. If the hard drive has a MBR but no
other File System (no Windows or Linux already on it), then offer the primary
choice of creating a GPT with a secondary choice of leaving the MBR on it. 3. If the hard drive has a MBR and an OS
taking the entire drive (like Windows normally does) among the offers of
resizing the Windows partition, or wiping the drive and install Linux only,
should be a GPT offer. a. If the drive
is being wiped, then a GPT should be recommended. b. If the drive
is being resized, then the MBR should remain. In addition, there needs to be a FAT File System partition
which EFI can use to boot the OS. 1. If the drive is raw or being wiped and
a GPT being made, then the first partition should be the EFI Partition (type
0xEF) with a default size of 1% of the total drive size with a minimum of
100MB. 2. If the drive is currently all one
partition like for Windows and is being resized to allow Linux to have a
partition, then part of the freed space must be for the EFI Partition
(hopefully 100MB). 3. If the drive already contains a FAT
File System then it can be used for the EFI Booting but there must be enough
free space on it to copy the EFI boot files to (about 16MB). I am not sure what "module" to file this bug
against. Is there a "Guided Partitioning" script that is part of the
Install CD that I can file this against? ---------------------------------------- Issue 3: Parted-efi should support creating a GPT drive: There should be an option of creating a GPT or MBR in parted
for users using the manual process on EFI BIOS based systems. It could be automatic based on the user creating an EFI
Partition –vs– a FAT Partition. If the user performs a manual partitioning instead of the
Guided one, then the resultant configuration should be checked for an EFI or
FAT Partition being at least 1% of the total drive size or a minimum of 100MB. I believe this is a 'feature' requirement against
parted-efi. ---------------------------------------- Issue 4: Base packages being loaded on EFI-BIOS based
systems need to include the package 'elilo': (which I believe has a dependency
on including 'efibootmgr' and 'DosFsTools') The packages elilo and efibootmgr should always be included
as part of the base packages on an EFI based system. The package elilo contains elilo.efi which is required for
subsequent boots. The program efibootmgr will create the elilo.conf file also
required to boot and will also create an EFI Variable for the Linux Boot entry
as well as change the EFI Variables for BootOrder and BootTimeOut. I don't know what package is responsible for the base system
or how to make it conditional based on efivars.ko being present. This is a bug I need to file. ---------------------------------------- Issue 5: The custom built kernel should load efivars.ko: This could be debated as; the runtime kernel doesn't require
efivars, and that the packages elilo and efibootmgr don't need to stay around
after the install. Option 1: Leave efivars.ko loaded and the
packages installed. Although efivars takes a small amount of system memory, it
allows that the System Table and EFI Variables are available in
/sys/firmware/efi It is possible someone might want to recreate the EFI Boot
Manager entry for Linux using the efibootmgr utility. Leaving the packages elilo and efibootmgr doesn't consume
much disk space and could possibly be needed in the future. A requirement of EFI systems is that Dmidecode should use
the /sys/firmware/efi/systab/smbios file to determine where the SM Table is in
memory. This is because on EFI based systems, the SM Table doesn't have to be
located in the F0000h region. The benefits to loading efivars on boot and leaving elilo
and efibootmgr installed far outweigh the small amount of memory and disk space
it would use on an EFI Based system. Option 2: Uninstall elilo and efibootmgr
after the install and don't load the efivars module. Once the install is complete, a user wouldn't typically need
to run efibootmgr again, and so the module efivars isn't needed and frees a
small amount of system memory, and removing the elilo and efibootmgr frees a
small amount of disk space. Problems might occur if programs such as dmidecode expect to
find the SM table in the F0000h region as on an EFI BIOS based system it
doesn't have to be there. I believe that the custom built kernel should include
efivars.ko by default on a platform with an EFI Based BIOS so that the System
Table and EFI Variables are present. Although the efivars.ko module is loaded during the install,
it isn't included on the installed system. I believe this is a bug. I am not sure what package to file this bug against. This is also a possible bug report against dmidecode if it
assumes the SM table resides in the F0000h region as on EFI based systems it is
not a requirement. If /sys/firmware/efi/systab/smbios exists, then it has the
address of the SM table and dmidecode should use it. If it doesn't exist, then
dmidecode can scan the F0000h region for the SM table. ---------------------------------------- Issue 6: EFI Boot Files are not being copied to the EFI
Partition during the install process: These files are required to boot Linux on an EFI based
system and should be present in the EFI Partition: Elilo.efi - EFI Linux Loader
(Loaded in /efi/boot) Elilo.conf - Config file for elilo
(Loaded in /efi/boot) Initrd.img - Ram file system image
(Loaded where elilo.conf specifies it to be, probably /debian) Vmlinuz - Boot
kernel (Loaded where elilo.conf specifies it to be, probably /debian) This file is optional, but is executed if the user drops
into EFI Shell instead of booting the OS. StartUp.nsh - Automatically loaded script
on boot (in / if present) Linux could copy a default Startup.nsh to the EFI Partition
if one doesn't exists. This file only gets executed if the Shell is loaded and
isn't the normal boot path. EFI Shell environment settings could be configured
in it. As mentioned in Issue 4, the package elilo contains
elilo.efi and efibootmgr creates elilo.conf. These two files should be copied
to the EFI Partition to be able to boot. The install process builds initrd.img and vmlinuz, but they
aren't copied to the EFI Partition either. I believe there is an expectation that the EFI Partition is
mounted in the /EFI directory, but that is not occurring either. After Issue 4 above where elilo.efi and elilo.conf exists,
and after the kernel build process where vmlinuz and initrd.img exists, there
should be a step to mount the EFI Partition to /EFI and copy these files there. I am not sure who is responsible for this or who to file a
bug against. ---------------------------------------- Issue 7: GRUB or LILO should not run, nor be required to run
on an EFI BIOS Based system install. At the end of the install process, there is a step to write
the MBR with either GRUB or alternately LILO. Neither of these should be run on
a GPT drive. The install process should detect whether the drive contains
a GPT and if so, skip the GRUB (LILO) step of the install. I am not sure who is responsible for kicking off GRUB during
the install but that script needs to be fixed to skip the step on an EFI Based
BIOS. This also includes removing the warning when you skip the GRUB step. I am not sure who to file this bug against. ---------------------------------------- I believe that covers all the minor issues to making the
i386 Install CD work flawlessly on an i386 EFI BIOS based system. Any suggestions who to talk to, or which modules to file
bugs against to track this would be appreciated. I am working on each of these issues myself as well. Best regards, Charles Abdouch |