Thomas, I'd like to revisit the issue of APT keys that I had mentioned earlier.
FAI 5.5.3 changed the task_repository() function in /usr/lib/fai/subroutines <https://github.com/faiproject/fai/commit/140c23b45f351291a76b59bdd3f588dadd9e4711#diff-66f2709eb62796fdd9d538c83ad12389>, such that it copies *.asc files into the target OS's /etc/apt/trusted.gpg.d instead of calling `apt-key add`. This broke APT keys for target OSes that have apt < 1.4~beta1, which only look for /etc/apt/trusted.gpg.d/*.gpg files. Since 1.4~beta1 <https://salsa.debian.org/apt-team/apt/commit/2906182db398419a9c59a928b7ae73cf7c7aa307#d14080a187d34907415113d1099a756db02ae709_260_267>, APT will also look for /etc/apt/trusted.gpg.d/*.asc. FAI 5.6.1 introduces a workaround <https://github.com/faiproject/fai/commit/132348888e697b833f7d1057e3e2138f067abd69#diff-66f2709eb62796fdd9d538c83ad12389>: for each relevant class, it copies a $class.gpg file if it exists, and falls back to copying a $class.asc file. However, the FAI 5.6.1 behaviour still imposes an unreasonable burden of maintaining redundant files in the package_config directory: .asc files for FAI clients older than 5.5.3, and .gpg files for FAI clients since 5.6.1. To summarize, FAI has traditionally supported ASCII-armored .asc key files, and APT has traditionally supported dearmored .gpg key files. I see two possible good solutions: (a) Revert to the pre-5.5.3 behaviour, and call `apt-key add`. A disadvantage is that it requires a working apt-key command in the target OS, which may require the gnupg package to be installed (by debootstrap). Unfortunately, it is neither easy nor desirable for FAI to demand that gnupg be installed in the target OS. (b) Run gpg in FAI to convert .asc files to .gpg files. This requires the gnupg package to be installed in the NFS root (or wherever FAI is running from). We can ensure that the gpg command is available by declaring that the fai-client package depends on (or recommends) gnupg, and by adding the gnupg package to the sample NFSROOT configuration. The following excerpt from /usr/lib/fai/subroutines implements option (b). # add apt keys for all classes for keyfile in ${classes:-}; do [ ! -f $FAI/package_config/$keyfile.asc ] && continue echo -n "Copying APT key from $keyfile.asc to $keyfile.asc.gpg " [ -f $FAI_ROOT/etc/apt/trusted.gpg.d/$keyfile.asc.gpg ] || touch $FAI_ROOT/etc/apt/trusted.gpg.d/$keyfile.asc.gpg gpg --batch -o $FAI_ROOT/etc/apt/trusted.gpg.d/$keyfile.asc.gpg --dearmor $FAI/package_config/$keyfile.asc done I hope that you will incorporate it, since this solution offers maximum compatibility without introducing .gpg files into the package_config directory and without requiring that gnupg be installed into the target OS. (It has the disadvantage of making assumptions about how apt-key interacts internally with its key files, but you already started down that path by removing the apt-key call in 5.5.3.) Derek > On May 18, 2018, at 1:13 PM, Derek Poon <derekp+...@ece.ubc.ca> wrote: > > In my experience, I have found two potential issues when installing Ubuntu > 18.04 using FAI. > > The first is that if using FAI <= 5.5, then FAI_DEBOOTSTRAP_OPTS needs > '--include gnupg'. Otherwise, the `apt-key add` in /usr/lib/fai/subroutines > would fail. (At our site, we always run deboostrap instead of relying on > basefiles, and we often need backwards compatibility for dirinstalls.) > > The second is that netplan (see https://netplan.io/examples) is the new > preferred configuration format for networking [...] > > > >> On May 18, 2018, at 11:04, Thomas Lange <la...@informatik.uni-koeln.de> >> wrote: >> >> After building the basefile for Ubuntu 18.04 LTS aka Bionic, my first >> tests look fine. Setting the release name in class/UBUNTU.var to >> ubuntudist=bionic >> and copying the basefile from >> https://fai-project.org/download/basefiles/BIONIC64.tar.xz >> works. Oh, I didn't test yet if the network is running after the >> installation. I will do this later. >
