maas-devel team mailing list archive

[Steve Langasek <steve.langasek@xxxxxxxxxxxxx>]

Hi Gavin,

On Tue, Mar 25, 2014 at 05:06:40PM +0000, Gavin Panella wrote:
> In https://code.launchpad.net/~blake-rouse/maas/abstract-boot-methods-hwe/+merge/212228,
> UEFIBootMethod.install_bootloader (starting at line 1780 in the diff,
> for now) Blake has had to reproduce what looks like a lot of the logic
> that apt already implements. For one, it downloads, validates, and
> extracts the shim-signed package.

> The reason is does this instead of installing or depending on
> shim-signed is because shim-signed is only available for amd64 (Julian
> mentioned that it's also arch-indep, which causes build issues when
> depending on it, but I didn't understand), but MAAS might be running
> on i386 or another platform.

> In MAAS we're using it as part of UEFI net-booting of amd64 systems,
> so we're adhering to its intended arch, but apt obviously isn't
> designed for our use-case.

> Colin Watson suggested that python-apt might be useful in some way to
> us, but it seems to be only geared toward the local system. I assume
> I'm missing something. Can you help us understand how we might be able
> to use it?

> I also assume you're very busy right now. If delving into python-apt
> is more work than you can afford in the next couple of days, would you
> be able to do a sanity-check of Blake's approach? It looks sane to me,
> but I'm not qualified to make an absolute statement of that.

I don't have much relevant experience with python-apt itself, so I'll Cc:
Colin here in case you need any advice on the particulars of using the
python API.  But in broad strokes, what I would expect you want here is:

 - set the APT::Architecture conf value to amd64
 - set the Dir::State, Dir::Cache, Dir::Etc::sourcelist conf values to point
   to a private tree (or use RootDir to point everything to a private
   heirarchy; but then you have to deal with keyring management, which may
   or may not be what you want)
 - populate the file indicated by Dir::Etc::sourcelist with the correct list
   of apt sources for your target environment (e.g., trusty/main +
   trusty-security/main + trusty-updates/main)
 - do the equivalent of equivalent of 'apt-get update'
 - do the equivalent of 'apt-get download shim-signed' (which should handle
   cryptographic verification of the package)
 - extract the downloaded .deb with dpkg -x and copy
   /usr/lib/shim/shim.efi.signed into your tftp root dir
 - repeat for grub-efi-amd64-signed, which has similar arch-specific
   installability constraints

I think this is the right overall model; there's no inherent requirement to
install the shim-signed, grub-efi-amd64-signed packages on the server as a
precondition for unpacking them into the tftp root directory, so this nicely
sidesteps any architecture incompatibilities by treating these bits as
"payload" instead of "packages".

Hope that helps,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@xxxxxxxxxx                                     vorlon@xxxxxxxxxx

Attachment: signature.asc
Description: Digital signature