Since we want all the modules in the runtime image, there's no need
to deal with the individual kernels. And workdir was only being used
to mess with the modules, so we don't need that either.
This allows us to create these objects without needing workdir,
which means we can use them outside of __init__.py.
We can also write them directly to their final destination
instead of writing them to the workdir and then copying them in.
Any decisions about arch-specific stuff should happen in the Lorax class
or the arch-specific templates/code. Move that logic up to Lorax.run()
and remove installtree.basearch.
getdata(cmd) will return a generator that yields every token on every
line that starts with the token "cmd". getdata(cmd, mode="lines") will
yield a list for each line rather than every individual token.
this simplifies some things in __init__.py.
arch has three attributes: .buildarch, .basearch, and .libdir
product has six: .name, .version, .release, .variant, .bugurl, and
is_beta
This makes it easier to pass this data into functions/templates.
TreeBuilder uses templates full of commands (like ramdisk.ltmpl) to
create the output tree and boot images. There are 4 arch-specific
templates, plus a bonus EFI template which can handle EFI image creation
for any arch that implements EFI.
This adds the new "mkefiboot" cmd, which creates an efiboot img in the
magical way that EFI requires. There doesn't seem to be a good tool for
this (unlike the existing tools for all the other weirdo boot image
types) so it was necessary to create one.
This contains simple functions for creating disk images:
mkcpio, mksquashfs, mkdosimg, mkext4img, mkbtrfsimg
And the helper functions they use:
truncate, loop_{attach,detach}, dm_{attach,detach},
mount/umount, estimate_size, roundup, cpio_copytree
This adds the remove() function, which works a lot like rm -rf - if you
remove() a file, it uses os.unlink, and if you remove() a directory it
uses shutils.rmtree().
We're already using find and cpio subprocesses, so using
one more subprocess is not a problem. With this approach
we can pipe cpio to the xz/gzip command, which should
help with the memory issues.
