Bug 1918382

Summary: post-kickstart hangs shutting down: "failed deactivating swap"
Product: Red Hat Enterprise Linux 8 Reporter: David Lee <david.lee>
Component: systemdAssignee: David Tardon <dtardon>
Status: CLOSED WONTFIX QA Contact: Frantisek Sumsal <fsumsal>
Severity: high Docs Contact:
Priority: unspecified    
Version: 8.3CC: dtardon, msekleta, systemd-maint-list
Target Milestone: rc   
Target Release: 8.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-07-20 07:27:56 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:
Attachments:
Description Flags
screenshot during hang none

Description David Lee 2021-01-20 15:28:46 UTC 
Created attachment 1749100 [details]
screenshot during hang

Description of problem: post-kickstart hangs shutting down: "failed deactivating swap"


Version-Release number of selected component (if applicable):


How reproducible: every time


Steps to Reproduce:
1.Install RHEL8 via kickstart
2.Wait...
3.

Actual results: After kickstart has installed in the OS, it correctly tries to shut down and reboot.  But the shutdown process hangs with a set of six cycling messages, which include "failed deactivating swap /dev/dm-6" and similar.  The hang lasts for many tens of minutes.  (A colleague who was patient enough to wait reports at least two and a half hours.)  We have to force a power cycle of the VM to continue.


Expected results: Shutdown with kickstart should succeed in decent time, not several hours.


Additional info: It looks like a bugzilla that was reported on Fedora but which had been closed because that version of Fedora was EOL.  https://bugzilla.redhat.com/show_bug.cgi?id=1680460
Comment 1 David Tardon 2022-03-17 13:35:26 UTC 
Is this reproducible? If yes, could you attach the kickstart here?
Comment 2 David Lee 2022-03-24 14:21:47 UTC 
Yes, reproducible.

Example.  Need a kickstart client machine or VM with small memory (the idea being to ensure that something goes into swap) and any reasonable size kickstart file (typical server or typical workstation).

Have some sort of "%post" that will take an elapsed time for allowing monitoring.   Something as simple as "sleep 900" (15 minutes) is probably sufficient.

Begin to kickstart that client.

Once that kickstart is going, e.g. started to install packages, switch to an alternate screen (that offers a linux prompt).

(Be comfortable with flipping back and forth between those two screens.)

From that alternate screen, monitor swap usage, e.g. "swapon --summary" or similar.

Hopefully you will see it occupy some real swap space.

When kickstart enters "%post" (e.g. after seeing on the main screen that it has finished its packages), verify swap is occupying real swap space.

Then at the alternate console do "swapoff -a" (which triggers asynchronous removal of swap space)...

... and see how SLOWLY that swap use reduces (monitoring with that "swapon --summary" or similar).

It is that slowness which is the issue.

I hope that helps.
Comment 3 David Tardon 2022-03-30 13:22:06 UTC 
(In reply to David Lee from comment #0)
> But the shutdown process hangs with a set of six
> cycling messages, which include "failed deactivating swap /dev/dm-6" and
> similar.

What are the other messages? This comes from systemd-shutdown, but it definitely shouldn't cycle infinitely. The unmounting loop should be terminated if nothing has been unmounted/deactivated in the current run. And I see no obvious problems with the code.

> Example.  Need a kickstart client machine or VM with small memory

How small is "small"? Can't you just show your configuration to save us time?
Comment 5 RHEL Program Management 2022-07-20 07:27:56 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.