#3083 Special blocker for kdump enabled by mistake
Closed: Accepted a year ago by mhayden. Opened a year ago by catanzaro.

Hi,

Bug https://bugzilla.redhat.com/show_bug.cgi?id=2243068 does not appear to violate any blocker criterion, but I'm thinking it would be silly to ship Fedora 39 with kdump enabled by accident rather than intent. Can FESCo please designate this bug as a special F39 blocker?

For cross-reference: Workstation WG issue tracker


Metadata Update from @ngompa:
- Issue tagged with: fast track

a year ago

Out of politeness I was waiting to see if the maintainers would implement the proposed fix in time not to bother with this kind of ticket, but FWIW I do think we should make sure this is fixed before releasing.

Note, the problem is actually kinda worse than stated: you don't really get kdump enabled, you just get some memory eaten for no good reason, because the update does not enable kdump.service , only adds the kernel parameter.

What are the potential downsides of the proposed fix?

FWIW, this is the proposed fix. Off the top of my head it seems pretty safe. Worst case, if something goes wrong with the systemctl call, it should not enable the parameter. But, hey, shell script...

Metadata Update from @ngompa:
- Issue set to the milestone: Fedora Linux 39

a year ago

that's +7, so if anyone wants to call for fast-tracking this, it'd be approved...

This was tagged as fast track by @ngompa.

APPROVED (+7, 0, 0)

I have marked the bug as an accepted blocker.

Metadata Update from @mhayden:
- Issue tagged with: pending announcement

a year ago

Thanks for marking this approved, @tstellar! Saved me some work. 😉

Metadata Update from @mhayden:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

a year ago

Metadata Update from @mhayden:
- Issue untagged with: pending announcement

a year ago

Log in to comment on this ticket.

Metadata