Posts tagged system
I really wanted to look into the new kernel building solutions for Gentoo and maybe migrate to dracut, but last time I tried, ~1.5 years ago, the initreamfs was now working for me.
And now in 2023 I’m still running genkernel for my personal boxes as well as other servers running Gentoo.
I guess some short term solutions really become defined tools :P
So this is how I rebuild my kernel nowadays:
-
Copy old config
|
cd /usr/src
cp linux-6.1.38-gentoo/.config linux-6.1.41-gentoo/
|
-
Remove old kernel build directories
|
rm -r linux-6.1.31-gentoo
|
-
Run initial preparation
|
( eselect kernel set 1 && cd /usr/src/linux && make olddefconfig )
|
-
Call genkernel
1
2
3
4
5
6
7
8
9
10
11
12 |
genkernel \
--no-menuconfig \
--no-clean \
--no-clear-cachedir \
--no-cleanup \
--no-mrproper \
--lvm \
--luks \
--mdadm \
--nfs \
--kernel-localversion="-$(hostname)-$(date '+%Y.%m.%d')" \
all
|
-
Rebuild the modules
If in your /etc/genkernel.conf
you have MODULEREBUILD
turned off, then also call emerge:
|
emerge -1 @module-rebuild
|
System preparation
Qemu
Emerge qemu
with static-user
USE enabled and your wanted architectures.
|
app-emulation/qemu QEMU_SOFTMMU_TARGETS: aarch64 arm x86_64
app-emulation/qemu QEMU_USER_TARGETS: aarch64 arm x86_64
app-emulation/qemu static-user
dev-libs/glib static-libs
sys-apps/attr static-libs
sys-libs/zlib static-libs
dev-libs/libpcre2 static-libs
|
OpenRC
Enable qemu-binfmt
:
|
rc-update add qemu-binfmt default
|
Start qemu-binfmt
:
|
rc-service qemu-binfmt start
|
Chrooting
- select chroot location (eg
/chroots/gentoo-arm64-musl-stable
)
- unpack the desired rootfs
- create needed directories
mkdir -p /chroots/gentoo-arm64-musl-stable/var/cache/distfiles
- execute
bwrap
- with last
ro-bind
mount the qemu emulator binary (eg qemu-aarch64
)
- execute the mounted emulator binary giving it a shell program (eg
bash
)
Chroot with bwrap
:
|
bwrap \
--bind /chroots/gentoo-arm64-musl-stable / \
--dev /dev \
--proc /proc \
--perms 1777 --tmpfs /dev/shm \
--tmpfs /run \
--ro-bind /etc/resolv.conf /etc/resolv.conf \
--bind /var/cache/distfiles /var/cache/distfiles \
--ro-bind /usr/bin/qemu-aarch64 /usr/bin/qemu-aarch64 \
/usr/bin/qemu-aarch64 /bin/bash -l
|
User-mode
By default you would probably have something like this, the user-mode network:
|
<interface type="user">
<mac address="00:00:00:00:00:00"/>
<model type="virtio"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
|
Bridge
Bridges can be easily created using the NetworkManager’s TUI tool called nmtui
.
Bridge XML configuration for Libvirt
|
<interface type="bridge">
<mac address="00:00:00:00:00:00"/>
<source bridge="br1"/>
<target dev="vnet2"/>
<model type="virtio"/>
<alias name="net0"/>
<address type="pci" domain="0x0000" bus="0x06" slot="0x00" function="0x0"/>
</interface>
|
Sysctl options
Be sure the following options are enabled (1
):
net.ipv4.ip_forward
net.ipv4.conf.all.send_redirects
and the following options are disabled (0
):
net.bridge.bridge-nf-call-iptables
Binpkgs generated by user
The binary packages generated by user can have architecture-specific optimizations because they are generated after they were compiled by the host Portage installation.
In addition binpkgs are generated from ebuilds so if there is a
USE flag incompatibility on the consumer system then the binpkg will not be installed on the host and Portage will fall back to
from-source compilation.
Those binary packages can use two formats: XPAK and GPKG.
XPAK had many issues and is getting superseded by the GPKG format. Beware of upcoming GPKG transition and if you must use XPAKs then you should explicitly enable it in your system’s Portage configuration.
To host a binary package distribution server see the Binary package guide on the Gentoo wiki.
Bin packages in a repository
Binary packages in ::gentoo
(the official Gentoo repository) have the
-bin suffix.
Those packages might have USE flags but generally they are very limited in case of customizations or code optimizations because they were compiled either by a Gentoo developer or by a given package
upstream maintainer (or their CI/CD system).
Those packages land in ::gentoo
mostly because it is too hard (or even impossible) to compile them natively by Portage. Most of the time those packages use very complicated build systems or do not play nice with network sandbox like (e.g. Scala-based projects) or use very large frameworks/libraries like (e.g.
Electron).
They can also be added to the repository because they are very
desirable either by normal users (e.g. www-client/firefox-bin) or for (from-source) package
bootstrapping purposes (e.g. dev-java/openjdk-bin). Such packages are sometimes generated from the regular source packages inside ::gentoo
and later repackaged.
Template
File: /etc/systemd/system/APP.service
1
2
3
4
5
6
7
8
9
10
11
12 |
[Unit]
Description=Run APP application
[Service]
Type=simple
ExecStart=/usr/bin/LANG APP_DIR/APP APP_ARGS
Restart=on-failure
User=root
WorkingDirectory=APP_DIR
[Install]
WantedBy=multi-user.target
|
Also, the application might need to reference a PID file, let systemD know abut it via PIDFile
.
Example
File: /etc/systemd/system/julia_dash_app.service
1
2
3
4
5
6
7
8
9
10
11
12 |
[Unit]
Description=Run Julia Dash application
[Service]
Type=simple
ExecStart=/usr/bin/julia /root/julia_dash_app/main.jl
Restart=on-failure
User=root
WorkingDirectory=/root/julia_dash_app
[Install]
WantedBy=multi-user.target
|