Hi,
it's possible to try upgrades RHEL-7 -> 8 -> 9:
Another option might be creating your own RHEL-9 installation images using lorax with modified templates (from the lorax-templates-rhel package) and removing more kernel drivers or firmware files (or other files) that you do not need for the installation process. Obviously, this is an unsupported path.
Regards,
Jan
On Tue, Aug 13, 2024 at 5:12 PM Sean M <seanmottles@xxxxxxxxxx> 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.
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
--
_______________________________________________
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
-- _______________________________________________ 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
