LINUXCN-18 Update Linux CN to Debian 12 and LXD 5 #20
Conversation
travispaul
force-pushed
the
LINUXCN-18
branch
from
539f2a9
to
6eb2c58
Compare
Also print size and location of build artifacts
|
I was able to build LINUXCN-18, and add it to our Triton DC cleanly after updating the appropriate SDC services / agents. |
tools/debian-live
Outdated
| function build_python2 { | ||
|
|
||
| fetch_extract_distfile "$python_distfile" | ||
|
|
||
| if [[ -d "$buildcache/Python-$python_ver" ]]; then | ||
| cp -a "$buildcache/Python-$python_ver" "$root/tmp" | ||
| chroot "$root" env PYTHON_VER="$python_ver" bash -c ' | ||
| cd "/tmp/Python-$PYTHON_VER" | ||
| make install | ||
| ' | ||
| return 0 | ||
| fi | ||
|
|
||
| rm -f /tmp/zfs-modules-*.deb | ||
| chroot "$root" env PYTHON_VER=$python_ver bash -c ' | ||
| cd "/tmp/Python-$PYTHON_VER" | ||
| ./configure | ||
| make install | ||
| ' | ||
| cp -a "$root/tmp/Python-$python_ver" "$buildcache" | ||
| } | ||
|
|
||
| function remove_python2 { | ||
| # There is no uninstall target in the Makefile | ||
| rm -rf "$root/tmp/Python-$python_ver" \ | ||
| "$root/usr/local/bin/python2" \ | ||
| "$root/usr/local/lib/python2.7" \ | ||
| "$root/usr/local/bin/smtpd.py" \ | ||
| "$root/usr/local/bin/idle" \ | ||
| "$root/usr/local/bin/pydoc" \ | ||
| "$root/usr/local/bin/2to3" \ | ||
| "$root/usr/local/share/man/man1/python2" | ||
| } |
There was a problem hiding this comment.
I'm ok with this approach for now, but I wonder how much time this adds to the build. We might want to look at a way to cache py2.
There was a problem hiding this comment.
It has a noticeable impact on build times, but it is currently being cached locally (along with ZFS builds.) Caching both of those cut the build time from ~35mins to ~8mins for me.
| apt-get install -y systemd-resolved | ||
| sed -i -e "s/^#DNSSEC=.*/DNSSEC=false/" /etc/systemd/resolved.conf | ||
|
|
||
| # This service will attempt to parse the ip parameter on the kernel | ||
| # command line and fail, it is not needed for Triton | ||
| rm -f /usr/lib/systemd/system/systemd-network-generator.service |
There was a problem hiding this comment.
I'm open to other options if you have any, I've tried quite a few things this was the only working solution I found.
There was a problem hiding this comment.
I mean systemd-resolved itself. Can it operate without that package?
There was a problem hiding this comment.
At the moment the PI cannot operate without it.
I tested removing it (to remind myself) and I can build a PI without it but the CN will be unable to resolve triton service names, the first symptom is that triton-vm-agent.service fails to start, unable to resolve vmapi.
Also, if I attempt to install it with along with the other $packages in the PI, the build will fail early as the chroot becomes unable to resolve DNS names and install packages which is why I added the install step in the postinstall step.
Distribution tarballs (Node, ZFS, and Python) and build artifacts (ZFS, Python) are now being cached which speeds up build times.
Debian packages and npm modules can also optionally be retrieved from a cache using either of the following options which makes the build resilient to network or upstream service disruption:
-a URLTested using apt-cache-ng-n URLTested using verdaccioTesting requirements
The following requirements will be available in the next Triton release ("E.D.I.T.H.") until then one needs to meet the following:
See LINUXCN-18 for more testing notes.