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.
