RE: i386 EFI - Identifying Parts of the Install Process
Thanks as always Frans,
As this is a somewhat specialize need at the moment (though the expectation
is that someday UEFI would be a standard on AMD64 and i386 platforms) I
expect to spend 99.98% of the work on this myself with minimal guidance from
you and others as needed.
The platform I am working on is not a MiniMac though very similar. Basically
if I could load an old BIOS on my MiniMac prior to them including CSM, I
would have the same setup as the machine I am working on. As it is, when
Debian Linux sees the CSM in the new MiniMac BIOS, it installs as if it was
on a Legacy machine so it isn't as useful for doing UEFI work as I hoped
when we bought one.
I am actually part of a team developing a UEFI compliant BIOS. I am
specifically not including the CSM (Compatibility Support Module) at this
time as it makes the machine look like a Legacy BIOS based machine and then
Linux just installs as it normally does.
I wanted to maintain the pure UEFI BIOS environment specifically to expose
these issues.
I previously worked on the team at HP getting Red Hat Linux to work with the
Itanium (IPF) EFI BIOS. Since the IPF BIOS contained no CSM, Red Hat had to
make the install process work exactly as needed for the UEFI environment.
I assume that Debian IPF includes all the same code and works correctly;
though once I get some IPF hardware I can confirm that.
What my goal is, is to get Debian to install just as nicely on an i386 UEFI
system, then once through all those issues, get it to work with the AMD64
install. That way no matter what UEFI based system someone might be
installing on, Debian always installs deterministically.
As for your specific question:
I assume these boxes can netboot or boot from an USB stick?
Currently I move the initrd.gz and vmlinuz files from the install CD and
copy them to a USB Stick so I can launch them from the EFI Shell. This
combined with elilo.efi which we found on the internet initially and later
was able to extract newer versions from the elilo package. I also use the
NetInst version.
Parted-efi was a mistake as you said; I should have said partman-efi as
appropriate.
And as you stated, I suspect that the changes will ultimately be very minor.
Finally, the process works exceedingly well manually. In fact, we were able
to get Debian Linux working with our initial UEFI BIOS with a huge amount of
BIOS bugs and unconfigured hardware. Debian's dmesg logs helped us debug our
BIOS code to the point where I only have a single warning message in my
dmesg file which I am not sure it's a BIOS bugs since I see a lot of Google
hits on it. (Oops: efitime: can't read time status: 0x80000007). Since this
appears to be a common issue, we have shelved it for the time being.
We have prototype units with Debian w/ KDE showing to people and it works
really nice. I have documented the "work-around" install process and now I
want to start working towards getting the automated process working. The
list of "issues" is in the order that I perform some manual process during
the install.
I will be working on your suggestions and hopefully either figuring things
out or asking more specific questions in the future.
Thank you again Frans,
Charles
-----Original Message-----
From: Frans Pop [mailto:elendil@planet.nl]
Sent: Monday, March 24, 2008 4:14 PM
To: debian-boot@lists.debian.org
Subject: Re: i386 EFI - Identifying Parts of the Install Process
On Monday 24 March 2008, Charles Abdouch wrote:
> 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
Glad you did.
> can be resolved for the official release of Lenny, but if not, at least
> soon afterwards.
Well, that completely depends on having people (such as you) who are
motivated to work on this (probably by having the hardware) not only
identifying the problems, but also doing most of the work to get them fixed
by testing, debugging and providing patches.
You seem to be off to a good start, but you may also want to try and see if
anyone wants to help.
I personally have no interest in this beyond wanting to see D-I work as well
as possible on all hardware supported by Debian, so I'll limit myself to
giving pointers.
Most work on the installer is really very easy because it is all just shell
script: start by running an installation with 'priority=medium', learn what
steps make up an installation and what components (udebs) provide them,
find out what program is executed where (every menu item calls a postinst
script in /var/lib/dpkg/info/<component>.postinst, learn how the steps you
want to improve work by adding 'set -x' in its postinst script and any
scripts it calls.
Use the webserver from the "Save debug logs" option to check the debugging
output in the syslog.
Some basic info about all this can be found here:
- http://d-i.alioth.debian.org/manual/en.i386/ch06s02.html
- http://d-i.alioth.debian.org/doc/talks/debconf6/paper/
> 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.
I've pinged the debian-cd maintainer about that BR, but it should not block
work on this. I assume these boxes can netboot or boot from an USB stick?
> Issue 2: Guided Partitioning program needs to support EFI: (parted-efi or
> its scripts)
First you need to get manual partitioning working, then we can look at
guided partitioning. In principle it should be fairly easy.
Basically, this is not issue 2, but issue 7 or 8 or so.
You'll probably need to create separate recipes for these systems. The only
thing really needed is to correctly identify when they should be used.
Partman normally decides this on the basis of archdetect (see below), but
additional conditions are possible. The basic recipe selection happens in
the function get_recipedir() in /lib/partman/lib/recipes.sh (from
partman-auto).
> 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.
AFAIK there's no such thing as parted-efi, you probably mean partman-efi.
The component "in charge" of guided partitioning is partman-auto.
> 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.
Does it matter here if the system is running pure or with Boot Camp.
Whatever changes are done should ensure that both are supported.
Note that checking /sys/firmware/efi is only one thing, the system can also
be identified by the output of archdetect: that should be i386/mac or
amd64/mac.
The efivars module should already get loaded right at the beginning of
partman (see /lib/partman/init.d/XXefi).
> 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.
Don't try to redesign partman here. As said before, first make it work for
manual partitioning, that should give all the freedom you need.
AFAIK partitioning does not touch the MBR; in general writing to the MBR is
the responsibility of the bootloader installer, not the partioner.
AFAICT the main thing that is really needed is that GPT should be the
default for these systems. This _should_ already be the case
as /lib/partman/lib/disk-label.sh (from the partman-partitioning component)
has:
i386) #same for amd64
case "$sub" in
mac)
echo gpt;;
*)
echo msdos;;
> In addition, there needs to be a FAT File System partition which EFI can
> use to boot the OS.
Should be relatively simple to do with
> 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.
See above. It should already be doing so.
> 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 thing to do here is to get the installer to use elilo-installer. That
will take responsibility for installing elilo in the target system.
> This is a bug I need to file.
No. What is needed is to find out why the installer is not already using
elilo-installer automatically. What's needed is debugging.
> Issue 5: The custom built kernel should load efivars.ko:
If the kernel does not detect that efivars is needed automatically, the
correct thing to do is to have the installer can 'register-module efivars'
at some point, probably in a /usr/lib/base-installer.d hook script.
That will add it in /etc/modules for the target system.
> Issue 6: EFI Boot Files are not being copied to the EFI Partition during
> the install process:
That should be done by elilo-installer.
> Issue 7: GRUB or LILO should not run, nor be required to run on an EFI
> BIOS Based system install.
This should already not be happening.
The scripts /var/lib/dpkg/info/{grub,lilo}-installer already contain code to
make it skip in EFI based systems. Again, debugging is needed.
I hope the info above can help you further. The installer already has a lot
of code to support these systems. What is needed is checking exactly why
things are not working as they should and what we need to fix this is _very
specific_ bug reports about what is going wrong, preferably with patches.
IMO in most cases only minor adjustments should be needed.
Things to check are:
- are partman-efi and elilo-installer getting loaded during anna (check
contents of /var/lib/dpkg/status and syslog)?
- is efivars getting loaded at start of partman?
- is /sys/firmware/efi created at that point?
- try running archdetect both before and after partman; does it return
{i386,amd64}/mac?
- ...
Try to work from the bottom up, not from the top down.
Cheers,
FJP
Reply to: