Bug 2006432 - [4.9] Remove workaround keeping /boot RW for kdump support
Summary: [4.9] Remove workaround keeping /boot RW for kdump support
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: RHCOS
Version: 4.8
Hardware: All
OS: Linux
unspecified
low
Target Milestone: ---
: 4.9.0
Assignee: Timothée Ravier
QA Contact: Michael Nguyen
URL:
Whiteboard:
Depends On: 2003743 2013590
Blocks: 2013593
TreeView+ depends on / blocked
 
Reported: 2021-09-21 17:34 UTC by Timothée Ravier
Modified: 2021-10-18 17:52 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of: 2003743
Environment:
Last Closed: 2021-10-18 17:51:56 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift os pull 634 0 None open Bug 2006432: [release-4.9] Revert "overaly: Keep /boot RW when kdump is enabled" 2021-09-23 10:38:18 UTC
Red Hat Product Errata RHSA-2021:3759 0 None None None 2021-10-18 17:52:20 UTC

Description Timothée Ravier 2021-09-21 17:34:57 UTC
+++ This bug was initially created as a clone of Bug #2003743 +++

This is a tracking bug for upstream (and will be cloned for backports) for removing the workaround keeping /boot RW for kdump support.

This is essentially reverting https://bugzilla.redhat.com/show_bug.cgi?id=1971738 now that those packages are in:
- https://bugzilla.redhat.com/show_bug.cgi?id=1976252
- https://bugzilla.redhat.com/show_bug.cgi?id=1976260

See:
- https://github.com/coreos/fedora-coreos-config/pull/1212
- https://github.com/openshift/os/pull/622

--- Additional comment from Timothée Ravier on 2021-09-15 16:23:58 UTC ---

Correction: Only 4.8+ had /boot RO.

Comment 2 Michael Nguyen 2021-09-24 20:49:08 UTC
I couldn't verify this BZ for day-1 kdump enablement.  /usr/lib/systemd/system/kdump.service.d/remount-boot.conf still exists from the boot image.

Comment 3 Timothée Ravier 2021-09-27 13:37:15 UTC
To simplify things, I chose to not force a boot image bump for this one as although the previous workaround is still is present in the boot image, this should not impact the final system where the kdump setup actually happens, even on day-1.

Comment 4 Michael Nguyen 2021-09-28 15:44:42 UTC
I was able to enable kdump on OCP day 1 with the previous boot image.  I also verified that RHCOS 49.84.202109241334-0 can enable kdump on first boot.

I used the following ignition file and added karg `crashkernel=256M`.  The overlay file is no longer present and kdump works as expected.
{
  "ignition": {
    "version": "3.2.0"
  },
  "passwd": {
    "users": [
      {
        "name": "core",
        "sshAuthorizedKeys": [
          "ssh-rsa AAAAB..."
        ]
      }
    ]
  },
  "systemd": {
    "units": [
      {
        "enabled": true,
        "name": "kdump.service"
      }
    ]
  }
}



[core@cosa-devsh ~]$ sudo rpm-ostree status
State: idle
Deployments:
● ostree://6c47f493ad929a256859f96a1a558f1a144b07e6adf9722aefe1b9b3a1664f50
                   Version: 49.84.202109241334-0 (2021-09-24T13:37:14Z)
[core@cosa-devsh ~]$ sudo systemctl status kdump
● kdump.service - Crash recovery kernel arming
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
   Active: active (exited) since Tue 2021-09-28 15:30:33 UTC; 4s ago
  Process: 1351 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
 Main PID: 1351 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 3974)
   Memory: 0B
   CGroup: /system.slice/kdump.service

Sep 28 15:30:21 cosa-devsh dracut[1719]: Stored kernel commandline:
Sep 28 15:30:21 cosa-devsh dracut[1719]: No dracut internal kernel commandline stored in the initramfs
Sep 28 15:30:21 cosa-devsh dracut[1719]: *** Install squash loader ***
Sep 28 15:30:22 cosa-devsh dracut[1719]: *** Squashing the files inside the initramfs ***
Sep 28 15:30:31 cosa-devsh dracut[1719]: *** Squashing the files inside the initramfs done ***
Sep 28 15:30:31 cosa-devsh dracut[1719]: *** Creating image file '/var/lib/kdump/initramfs-4.18.0-305.19.1.el8_4.x86_64kdump.>
Sep 28 15:30:32 cosa-devsh dracut[1719]: *** Creating initramfs image file '/var/lib/kdump/initramfs-4.18.0-305.19.1.el8_4.x8>
Sep 28 15:30:33 cosa-devsh kdumpctl[1351]: kdump: kexec: loaded kdump kernel
Sep 28 15:30:33 cosa-devsh kdumpctl[1351]: kdump: Starting kdump: [OK]
Sep 28 15:30:33 cosa-devsh systemd[1]: Started Crash recovery kernel arming.
[core@cosa-devsh ~]$ ls /usr/lib/systemd/system/kdump.service.d/
ls: cannot access '/usr/lib/systemd/system/kdump.service.d/': No such file or directory

Comment 7 errata-xmlrpc 2021-10-18 17:51:56 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 (Moderate: OpenShift Container Platform 4.9.0 bug fix and security 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/RHSA-2021:3759


Note You need to log in before you can comment on or make changes to this bug.