RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2139907 - leapp should check for RAM requirements before running [NEEDINFO]
Summary: leapp should check for RAM requirements before running
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: leapp-repository
Version: 8.6
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Petr Stodulka
QA Contact: Martin Klusoň
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-11-03 19:18 UTC by Vinícius Ferrão
Modified: 2023-05-16 09:58 UTC (History)
1 user (show)

Fixed In Version: leapp-repository-0.18.0-1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-05-16 08:37:40 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pstodulk: needinfo?
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OAMG-7834 0 None None None 2022-11-03 19:20:10 UTC
Red Hat Issue Tracker RHELPLAN-138288 0 None None None 2022-11-03 19:20:07 UTC
Red Hat Product Errata RHBA-2023:2839 0 None None None 2023-05-16 08:37:51 UTC

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
Note You need to log in before you can comment on or make changes to this bug.