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
