From: Ralph Ronnquist Date: Sat, 21 Sep 2024 23:24:01 +0000 (+1000) Subject: Updated for multiple architectures and some note re test running. X-Git-Url: https://git.rrq.au/?a=commitdiff_plain;h=f5b655a1aa26b7c1b99385fe04f6b50e97024e83;p=rrq%2Fbespoke-installer.git Updated for multiple architectures and some note re test running. --- diff --git a/README.adoc b/README.adoc index ce3c7ec..cbe7b9c 100644 --- a/README.adoc +++ b/README.adoc @@ -1,64 +1,116 @@ = bespoke-installer.git -This is a small project for building the Devuan installer software as -a kernel and initrd.gz pair for arm64. +This is a small project for building the Devuan (netinstall) installer +software as a kernel and initrd.gz pair for a range of architectures. +Currently it supports (in debian architecture terms): amd64, arm64, +armhf, i386 and riscv64. The building process is fitted into a single bash script together with a special boot-up `initrd-init` file and two "package lists" files: -* `installer-packages.list` enumerates the packages to install into - the initrd filesystem so as to become installer software execution - core. +* `installer-packages-$TARGET_ARCH.list` enumerates the packages to + install into the initrd filesystem so as to become installer + software execution core. -* `pool-packages-installer.list` enumerates the packages for an - accompanying release pool, which are specifically selected in +* `pool-packages-installer-$TARGET_ARCH.list` enumerates the packages + for an accompanying release pool, which are specifically selected in addition all "required", "important" and "standard" packages. (The latter uses the Priority attribute of the packages themselves). Both package lists are expanded by recursively including dependent and recommended packages starting from the package lists. +Note that all building + +== Running build-$arch + +There are a number of starrt scripts, build-$arch, for building +installer pairs of kernel and initrd.gz towards different +archivetctures. For that to work you need to install `binfmt-support` +and `qemu-user-static`, which together should let your computer +execute binaries for a range of architectures in addiion to its native +architecture. This is similar to a multiarch setup but without +expanding `apt` to install packages for all of them. Thereafter it +should be as simple as running, say, + + $ ./build-arm64 + +for making a pair of kernel and initrd.gz installer for an arm64 +architectire. This may be tested in a qemu VM by running + + $ ./vm.sh arm64 + +The script `vm.sh` relies on having `qemu-system` installed, which +provides system emulations for a range of architectures. `vm.sh` uses +the `virt` machine type and the `cortex-53` cpu. + == Running build-installer.sh The script `./build-installer.sh` is run by a non-root user on the command line. It prepares three `build` subdirectories: -1. `build/sources` contains the Packages file for the sources, which - are the `main`, `non-free-firmware` and `main/debian-installer` - components of the Devuan `daedalus` repository. - -2. `build/media` is a media filesystem with a repository pool of - slightly bespoke structure. It includes - * `build/media/.disk` with description files appropriate for a - debian-installer media; - * `build/media/dists` with a "standard" repository structure of - meta files describing the media as repository; and - * `build/media/pool` with a bespoke layout containing the packages. +1. `$TARGET_ARCH/build/sources` contains the Packages file for the + sources, which are the `main`, `non-free-firmware` and + `main/debian-installer` components of the Devuan `$DISTNAME` + repository (`daedalus` by default). + +2. `$TARGET_ARCH/build/media` is a media filesystem with a repository + pool of slightly bespoke structure. It includes in particular + * `.../dists` with a "standard" repository structure of meta files + describing the media as repository; and + * `.../pool` with a bespoke layout containing the packages. + - The directory tree at `build/media` gets packed up as - `build/initrd/pool.squashfs` to be included in the initrd for use - during the installation. - -3. `build/initrd` is the installers core execution filesystem, which - gets populated by unpacking and configuring the udeb packages - enumerated in `installer-packages.list`. This is augmented with the - media squashfs and the `build/initrd/init` script copied from - `initrd-init` at top level; this script runs the installer. + The `pool` directory contains both all udeb packages (see below) + and the packages mentioned in `pool-packages-$TARGET_ARCH.list` + plus their depends and recommends packages (using a first choice + principle for alternatives) + - The directory tree at `build/initrd` gets packed up at end into - `initrd.gz`at project top level. Further, the linux kernel at + The directory tree at `$TARGET_ARCH/build/media` gets packed up as + `$TARGET_ARCH/build/initrd/pool.squashfs` to be included in the + final `$TARGET_ARCH/initrd.gz`. + +3. `$TARGET_ARCH/build/initrd` is the installer's core execution + filesystem, which gets populated by unpacking and configuring the + udeb packages enumerated in `installer-packages-$TARGET_ARCH.list`. ++ + The `initrd` directory is augmented with the media squashfs and an + `.../init` script copied from `initrd-init`; that's the script that + runs the installer on boot. ++ + The directory tree at `$TARGET_ARCH/build/initrd` gets packed up at + end into `$TARGET_ARCH/initrd.gz`. Further, the linux kernel at `build/initrd/boot/vmlinuz` is also copied up to project to level. -At end, the project toplevel as got the files `vmlinuz` and -`initrd.gz` to be used by the target arm64 system, as well as the -`build` directory which may be deleted. `initrd.gz` is quite large -since it includes the package pool `/pool.squasfs`. The target system -must have enough RAM to accomodate the unpacking of `initrd.gz` as -well as free RAM for the installation process. I would suggest it needs -2Gib RAM. +At end, the `$TARGET_ARCH/` toplevel has got the files `vmlinuz` and +`initrd.gz` with the installer for the target architecture. The latter +includes the media pool as `/pool.squasfs` and is therefore rather +large. The target system needs to have enough RAM to accomodate the +unpacking of `initrd.gz` as well as additional free RAM for the +installation process. I would suggest it needs at least 2Gib RAM. == Running vm.sh -The script `vm.sh` runs a qemu VM for testing the built `vmlinuz` and -`initrd.gz` with console interface only using the `virt` platform with -a cortex-a53 CPU and 4Gib RAM. +The qemu setups in `vm.sh` uses `vde` networking which typically +requires root setup, as follows: + +1. `# apt-get install vde2 iptables dnsmasq` + +2. Add an "iface block" to to `/etc/network/interfaces`: + + iface vmnet inet static + pre-up ip tuntap add vmnet mode tap 2>/dev/null || true + address 10.10.10.100/24 + up vde_switch -tap vmnet -daemon -sock /run/vde.ctl -mod 777 + MASQ POSTROUTING -s 10.10.10.0/24 -j MASQUERADE + up iptables -t nat -A $IF_MASQ + down iptables -t nat -D $IF_MASQ + down pkill -f 'vde_switch -tap vmnet + DHCP 10.10.10.2,10.10.10.99,3600 + up dnsmasq -i vmnet -I lo -h -F $IF_DHCP + down pkill -f "dnsmasq -i vmnet" + +3. `# ifup vmnet` + +By that setup, the qemu emulator will connect to the network, and use +the host as NAT router for Internet access. Note that `dnsmasq` might +need other/more configuration to work well in your setup.