xCAT/xcat-core
2
0
Fork 0
mirror of https://github.com/xcat2/xcat-core.git synced 2026-09-04 20:17:55 +00:00
Code Issues Releases Wiki Activity

docs(xcat-core): note the memory an Ubuntu diskful install needs

Browse Source 
toram copies the live filesystem into RAM, so the node needs memory for it on top of the
installer -- about 1.5G on 24.04 and growing per release. Nothing enforced or documented that.

A node with too little fails part-way and reboots into the installer, which looks like a
boot-flip failure rather than an out-of-memory condition, so the troubleshooting page says
where to look and how to raise vmmemory.

Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
This commit is contained in:
Daniel Hilst
2026-08-28 09:41:42 -03:00
parent 1cbdad2531
commit e62a66c70d
3 changed files with 33 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/source/troubleshooting/os_installation/index.rst
+1
View File
@@ -41,4 +41,5 @@ Next chapter introduces the procedures on how to troubleshoot operating system i
log_to_mn_cn.rst
debug_port.rst
ssh_enable.rst
ubuntu_subiquity_memory.rst
docs/source/troubleshooting/os_installation/ubuntu_subiquity_memory.rst
+28
View File
@@ -0,0 +1,28 @@
Ubuntu diskful install needs memory for the live filesystem
===========================================================
An Ubuntu diskful (Subiquity) install boots the live installer over NFS and then copies it
into RAM, because the kernel command line xCAT generates carries ``toram``. This is
deliberate: with the NFS root still mounted at the end of the install, ``systemd-shutdown``
blocks on I/O to it and the node never reboots into the disk it just installed.
The consequence is that the compute node must have enough memory for the live filesystem on
top of whatever the installer itself needs. The squashfs layers are roughly 1.5 GB on 24.04
and grow with each release, so **4 GB is a practical floor and 8 GB is comfortable**.
A node with too little memory fails part-way through the install, and the symptom resembles
an unrelated problem: the node reboots back into the installer, so it looks like a PXE loop
rather than an out-of-memory condition. Check the console before assuming a boot-flip
failure. ::
rcons <node>
To confirm, look for the OOM killer in the installer's kernel messages, or watch the node's
memory from the hypervisor while it installs. For a libvirt-hosted node the memory is
``vmm``/``vmmemory`` in the **vm** table. ::
lsdef <node> -i vmmemory
chdef <node> vmmemory=8192
Diskless (netboot) nodes have a related but separate requirement: the rootimg is unpacked
into a tmpfs, and on ppc64le the 64 KB page size inflates it considerably.
xCAT-server/lib/xcat/plugins/debian.pm
+4 -1
View File
@@ -524,7 +524,10 @@ sub copycd
network root at shutdown. Without it a process doing I/O to it blocks uninterruptibly,
systemd-shutdown waits forever and the node never reboots into the disk it just installed.
casper parses only nfsroot= and takes the whole value as the path, so mount options cannot
be appended; toram is its supported alternative.
be appended; toram is its supported alternative. It does mean the node needs memory for the
live filesystem on top of the installer -- roughly 1.5G on 24.04 -- or it dies part-way
through and reboots into the installer again, which looks like a boot-flip failure. See
docs/source/troubleshooting/os_installation/ubuntu_subiquity_memory.rst.
Arguments:
$base the command line built so far