Repository navigation
Void with 512 megs of RAM (VM) - xbps sync causes OOMkill #635
Copy link
Copy link
Open
Description
In the 2024 ISO, this wasn't a problem. Now I have a packer build as follows:
└» cat void-autoinstall.pkr.hcl
source "qemu" "void-musl" {
iso_url = "https://repo-fastly.voidlinux.org/live/current/void-live-x86_64-musl-20250202-base.iso"
iso_checksum = "sha256:0c46bf13a7a019c1fec0b2969201aecf09ff9a7646ef749e04ea63ead0c86404"
output_directory = "output-void-musl"
shutdown_command = "echo 'voidlinux' | sudo -S shutdown -P now"
disk_size = "25G"
format = "qcow2"
accelerator = "kvm"
headless = true
http_directory = "http"
ssh_username = "admin"
ssh_password = "voidlinux"
ssh_timeout = "90m" # How long we give the system to get installed
boot_wait = "2s"
boot_command = [
"<tab><wait>",
"auto autourl=http://{{.HTTPIP}}:{{.HTTPPort}}/basic-void.cfg",
"<enter>"
]
}
build {
source "source.qemu.void-musl" {
vm_name = "void-nova"
}
}
and the config I load:
└» cat http/basic-void.cfg
#!/bin/sh
export username=admin
export password=voidlinux
export XBPS_ARCH=x86_64-musl
export xbpsrepository="https://repo-fastly.voidlinux.org/current/musl"
export timezone="America/New_York"
export pkgs="docker git neovim temporal-cli nomad uv"
export end_action=func
end_function() {
printf "Linking default services\n"
ln -s /etc/sv/docker "${target}/etc/runit/runsvdir/default/docker"
ln -s /etc/sv/dhcpcd "${target}/etc/runit/runsvdir/default/dhcpcd"
ln -s /etc/sv/sshd "${target}/etc/runit/runsvdir/default/sshd"
ln -s /etc/sv/agetty-ttyS0 "${target}/etc/runit/runsvdir/default/agetty-ttyS0"
echo "***"
echo "***"
printf "Let's continue with our life.\n"
sync
reboot -f
}
# Skip boot partition
VAI_partition_disk() {
sfdisk "${disk}" <<EOF
,${swapsize},S
;
EOF
}
VAI_format_disk() {
mkfs.ext4 -F "${disk}2"
mkswap -f "${disk}1"
}
export swapsize="1G"
VAI_mount_target() {
mkdir -p "${target}"
mount "${disk}2" "${target}"
}
VAI_configure_fstab() {
uuid_root="$(blkid -s UUID -o value "${disk}2")"
uuid_swap="$(blkid -s UUID -o value "${disk}1")"
echo "UUID=$uuid_root / ext4 defaults,errors=remount-ro,noatime 0 1" >> "${target}/etc/fstab"
echo "UUID=$uuid_swap swap swap defaults 0 0" >> "${target}/etc/fstab"
}
# Removable when this is closed
VAI_install_base_system() {
# Install a base system
XBPS_ARCH="${XBPS_ARCH}" xbps-install -Sy -R "${xbpsrepository}" -r /mnt base-system grub
# Install additional packages
if [ -n "${pkgs}" ] ; then
# shellcheck disable=SC2086
XBPS_ARCH="${XBPS_ARCH}" xbps-install -Sy -R "${xbpsrepository}" -r /mnt ${pkgs}
fi
}
(yes most of this can be removed in the newest mklive but the newest mklive is newer than the ISO)
The point is this image ends up in trouble because xbps-install triggers an OOMkill reliably. I believe xbps is allocating a lot of memory where it didn't always, and the system has a 512 meg limit. If I increase the system RAM from the default (512) to 648 megs, the install works flawlessly.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels

Activity
Duncaen commentedon Aug 2, 2025
Might be fixed now, I reduced a bunch of temporary allocations, most memory is basically spent on keeping repository indexes and package database in memory since they are not the most compact format there is. But it never actually allocated that much memory in total, I think its just that it temporarily allocated a bunch of stuff.
#636
Vaelatern commentedon Aug 10, 2025
I'll test again
Vaelatern commentedon Nov 25, 2025
Very impressive!
I had to
set +earound thetarcommand in this script because tar would OOM. I had to remove the tarball and excess files because if I didn't the system would OOM. But xbps-install with0.60.4_1was able to install a whole system with the default 512 megs provided by qemuIf I add void-repo-nonfree to the mix, the additional repository does seem to scale past the remaining memory. Might be able to squeeze by if I'd been using an image with xbps-install not being replaced.