[Maas-devel] Getting shim-signed with python-apt on non-amd64 system?

Steve Langasek steve.langasek at canonical.com
Wed Mar 26 01:16:38 UTC 2014

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 at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/maas-devel/attachments/20140325/5c4357d4/attachment.pgp>

More information about the Maas-devel mailing list