Bug 2139907

Summary:	leapp should check for RAM requirements before running
Product:	Red Hat Enterprise Linux 8	Reporter:	Vinícius Ferrão <vinicius>
Component:	leapp-repository	Assignee:	Petr Stodulka <pstodulk>
Status:	CLOSED ERRATA	QA Contact:	Martin Klusoň <mkluson>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	8.6	CC:	mmacura
Target Milestone:	rc	Keywords:	Triaged
Target Release:	---	Flags:	pstodulk: needinfo? pm-rhel: mirror+
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	leapp-repository-0.18.0-1.el8	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-05-16 08:37:40 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Vinícius Ferrão 2022-11-03 19:18:10 UTC

Description of problem:
`leapp` should check if there's enough RAM on the running server to be executed without any issues. It does not check it, and if you don't have enough RAM to run it, it will eventually trash the server on the first reboot.

As a real case, I've run leapp on a 768MB RHEL8 server on the cloud and the server was trashed. `leapp` finished successfully and asked for a reboot. During the upgrade-reboot phase it run out of memory and OOM, killing `dnf`. The result was a broken server with `el8` and `el9` packages with no way to run `leapp` again due to broken Python dependencies.

Version-Release number of selected component (if applicable):
leapp-upgrade-el8toel9-0.16.0-6.el8_6.noarch
leapp-0.14.0-1.el8_6.noarch
leapp-upgrade-el8toel9-deps-0.16.0-6.el8_6.noarch
python3-leapp-0.14.0-1.el8_6.noarch
leapp-deps-0.14.0-1.el8_6.noarch

How reproducible:
100%

Steps to Reproduce:
1. Run leapp on a low memory server
2. Expect the worse

Actual results:
Broken and unusable system after `leapp` run on low memory system.

Expected results:
Check if there's enough memory and halt `leapp` execution.

Additional info:
1GB seems to be sufficient, but I would enforce something like 1.5GB.

Comment 1 Petr Stodulka 2022-11-04 15:06:44 UTC

Hi, thank you for the report. The described system configuration is already unsupported on RHEL 8 as the minimal system requirement for RHEL 8 on x86_64 architecture is 1.5 GiB (same for RHEL 9):
    https://access.redhat.com/articles/rhel-limits

However, checking the code, we are actually blocking upgrades for systems with less than 1.5GiB.
Can you share content in /proc/meminfo?:
    # cat /proc/meminfo

Comment 2 Vinícius Ferrão 2022-11-04 15:42:42 UTC

Hi Petr, there you go:

[root@cinnabar ~]# cat /proc/meminfo
MemTotal:         810708 kB
MemFree:          139732 kB
MemAvailable:     338236 kB
Buffers:            5348 kB
Cached:           302700 kB
SwapCached:            8 kB
Active:           158644 kB
Inactive:         356908 kB
Active(anon):       7360 kB
Inactive(anon):   218832 kB
Active(file):     151284 kB
Inactive(file):   138076 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       1048572 kB
SwapFree:        1048560 kB
Dirty:                 4 kB
Writeback:             0 kB
AnonPages:        207096 kB
Mapped:            61548 kB
Shmem:             18688 kB
KReclaimable:      28248 kB
Slab:              66212 kB
SReclaimable:      28248 kB
SUnreclaim:        37964 kB
KernelStack:        3024 kB
PageTables:         2320 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     1453924 kB
Committed_AS:     384408 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       18536 kB
VmallocChunk:          0 kB
Percpu:             8576 kB
HardwareCorrupted:     0 kB
AnonHugePages:    131072 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
FileHugePages:         0 kB
FilePmdMapped:         0 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      126240 kB
DirectMap2M:      819200 kB

Not sure if `leapp` is considering the swapfile or not.

Comment 3 Petr Stodulka 2022-11-08 16:49:47 UTC

I am sorry for the delayed response. Checking the code again based on the output, it's now clear what's happening. Leapp is reading correctly the MemTotal value from the file. However the limits have been specified in MiBs instead of KiBs:
   810708 > 1536
which is obviously wrong and the upgrade should be definitelly stopped in such a case.

Also discovered that limits in the official documentation have been changed
over time, so updating the limits for all architectures based on the current
values in the table.

The upstream PR fixing the issue:
   https://github.com/oamg/leapp-repository/pull/984

Comment 4 Vinícius Ferrão 2022-11-08 18:18:45 UTC

Thank you Petr.

Comment 5 Petr Stodulka 2022-11-26 12:20:27 UTC

The fix has been merged in the upstream. It will be part of the next release.

Comment 14 errata-xmlrpc 2023-05-16 08:37:40 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (leapp-repository bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2839