Yep, it's in text mode. The issue arises early, when it fetches the
stage2 over the network it fails with "no space left on device", so
before Anaconda starts up/the kickstart is fetched. I was hoping the
removal of the graphical portions of Anaconda would at least allow the
installer to start up/avoid that problem, but it doesn't sound like it
from Brian's reply.
Thanks for your suggestions! How would I submit an RFE? I have worked
around this issue with our unique constraints, but a slimmed down
"kickstart/tui exclusive" version of Anaconda still seems like it could
be a useful thing for something like the Fedora Server SIG or even the
greater "EL" community who face similar constraints. These machines can
run EL9 without issue, but are just unable to install it over the network.
Best,
Sean
On 8/14/24 11:09 AM, mkolman@xxxxxxxxxx wrote:
On Tue, 2024-08-13 at 15:12 +0000, Sean M wrote:
Hi all,
Firstly, thank you for the work on Anaconda/kickstart, it's very
reliable and is pleasant to work with.
Like many others, I've been busy upgrading several hundred machines
from EL7 to EL9 and in doing this I've had to work around a size/RAM
limitation in Anaconda.
Just making sure - are you running the installation in text mode ?
I it is doing an automated install driven by kickstart, the TUI should
be sufficient & end result the same. By not loading all the GUI stuff
to memory, the peak memory usage should be lower.
Also some other things to try:
- make sure there is a swap partition (IIRC, at least when we create
one, we will use it during the installation), which should also reduce
peak memory pressure
- reduce number of packages being installed, possibly install the rest
after rebooting to the new system (should reduce peak memory pressure
caused by depsolving)
- create a custom minimal image via Image Builder:
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/composing_a_customized_rhel_system_image/index
-> not sure if it can actually make a smaller image, but possibly still
worth checking out/asking around for options/submitting a RFE
-> I think it might be also able to build a non-RPM payload (eq. rootfs
tarball), which could reduce peak RAM pressure (no depsolving) at
installation time
Hundreds of machines I've been upgrading are physical, outside the
country I reside in, and do not have an OOB interface (effectively
only accessible over ssh) making the upgrade process a bit perilous.
When the machine has enough RAM we can boot into the
pxeboot/images/[vmlinuz/initrd.img] pair and source the stage2 and
the rest of the things we need from the network.
When the machine _does not_ have enough RAM, we have to repartition
the disk (a combination of XFS/LVM prevent shrinking, the /boot
partition is too small, and sourcing stage2 from a disk targeted to
be wiped and repartitioned is marked as protected stopping the
installer) with a separate partition labeled "installer", download
the vmlinuz/initrd.img/install.img there, and booting with
`inst.stage2=hd:LABEL=installer`.
This "works", but the extra step to boot the installer off the disk
instead of the network seems like it could be avoided. I know there
are many ways to solve this problem (cat an image over the network
and dd it from a rescue environment, or something along those lines),
but in this case the wide variety of network configurations, limited
access, and time/experience constraints didn't really allow for much
experimenting. Anaconda and the kickstart work reliably, and we have
the most experience with that.
I know this is asking a lot, but as I do not have the expertise to go
down this road myself, is it possible to have a build of Anaconda
that does not contain the graphical interface to keep the size down?
I think this could save a lot of time / resources / e-waste in the
server/sysadmin world.
Thanks,
Sean
Best Wishes
Martin
--
_______________________________________________
Anaconda-devel mailing list -- anaconda-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to anaconda-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/anaconda-devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
