Re: Live-Build a Multi Arch Debian ISO with live desktop
On Sat, 2020-02-29 at 05:47 +1100, Michael . wrote:
> Do you mean multi-arch where an 64bit system can use 32 bit packages?
> or do you mean an iso that has 2 different live systems one being 43
> bit and the other being 64 bit?
>
> If it;s the 1st you simply enable 32 bit libraries.
> If it's the 2nd there is no built in way to do it that I am aware of
> although it would be extremely helpful if there was. I think it could
> be done but you would need to build 2 different systems and then
> merge
> them ensuring you have either 2 different live folders (e.g. live-32
> and live-64) or 2 different squashfs files (also named *-32 and
> *-64). You would then need to change the syslinux menu to show the
> appropriate 32 or 64 bit options on the appropriate machines. Rebuild
> the iso, and test it.
Support for the second setup described here was experimented with back
around 2010 but abandoned (I don't know why). At least one pointless
artifact remains in the codebase from this never-completed support. It
is thus not possible (currently) to have more than one such separate
arch sat side by side in the same image in different folders with
different bootloader entries. If you want such separation then you'll
have to make a separate image for each and thus use 2+ discs/pendrives.
In terms of the first setup (merged multi-arch), this might be
possible. I am only somewhat uncertain because I've never tried it.
Everything below concerns it...
1) Kernel selection: Take note of --linux-flavours. While --
architectures defines the base arch of the image (don't be confused
that its name is a plural, it only takes one arch - it needs renaming
imo!), --linux-flavours supports multiple arches!
--linux-flavours controls the set of kernels selected for inclusion!
You can thus specify "686 amd64" for this and get both of those kernel
flavours bundled.
While the old grub-legacy bootloader will only create bootloader menu
entries for the first, the newer and better maintained grub-pc, grub-
efi and syslinux bootloaders will create them for both. In fact with
grub-pc and grub-efi they will also add entries using grub arch auto-
detection such that the default selected corresponds to the running
system arch.
This means for instance that with --architectures="i386" --linux-
flavours="686 amd64", you can have an i386 userland running on top of
either an i386 or amd64 kernel.
Note that it would not make sense to specify --architectures="amd64" --
linux-flavours="amd64 686", since you can not run 64-bit userland on
top of a 32-bit kernel.
2) Userland: The userland defaults to the arch in --architectures.
However, if you have any package lists in your config (used to specify
lists of packages you want to be included), and if any of them specify
a foreign architecture, e.g. 'firefox:amd64', then `dpkg --add-
architecture` will be used to add that architecture to the userland and
thus the resulting userland should be multi-arch.
So to ensure that the userland is multi-arch, you can pick a userland
package you know you want included like say firefox and add entries
like 'firefox:amd64' and 'firefox:i386' to ensure that userland
includes both amd64 and i386 (well, adding one for the --architectures
arch would be redundant but does no harm). To be clear, you do not have
to do this for every package; only one entry in your list specifying a
particular arch will be enough to expand userland to include that arch.
Note though that from what I can tell, injecting packages held locally
in your config directory can only be done for those for the "all" (non-
specific) arch and the --architectures arch. This is based on the use
of LB_ARCHITECTURES in chroot_archives and binary_package-lists.
Also note, there is a package called 'multiarch-support', but for all
supported architectures it is described as an obsolete transitional
package so you shouldn't need to worry about including that. However I
notice that there is also a 'binutils-multiarch' package, which you may
want (by listing in a package list in your config). I'm not certain not
having played with multiarch myself.
3) Installer: Note though that the optional bundled installer is for
only one arch, that of --architectures.
4) Firmware: Note that the list of firmware packages that will be
included (if firmware is to be included) is determined by those
packages available for the --architectures arch. This is unlikely to be
a problem, since most firmware packages are arch=all (not arch
specific) and thus will be listed for any and all arch based searches.
It would only be a problem if there were a firmware package targetted
to a specific arch and that arch was not the --architectures arch (and
you actually needed that package for something of course).
Again, I have not personally built an image like this, so I cannot
testify that it really works.
Reply to: