v1.0.6

Changed

• add to .spec only show the message is leftlover exist

v1.0.5

Added

• Added the purge command for complete removal of resources managed by
  v4l2loopback-manager followed by removal of the manager RPM through DNF.
• Added explicit tracking of pending MOK certificate deletion during
  uninstall and purge.
• Added final purge status reporting to distinguish a fully completed removal
  from one that still requires manual MOK deletion confirmation after reboot.

Changed

• uninstall now also disables and removes the dynamically-created systemd
  integration before removing locally managed v4l2loopback resources.
• uninstall continues to keep the v4l2loopback-manager RPM installed,
  while purge performs resource cleanup and then removes the RPM.
• reinstall preserves the existing systemd integration while reusing the
  uninstall cleanup logic, avoiding unintended service removal during a
  reinstall operation.
• purge uses DNF without automatic confirmation so the user retains control
  over the final RPM removal transaction.
• MOK deletion remains explicitly asynchronous: when certificate deletion is
  staged with mokutil, the manager reports that a manual reboot and
  confirmation in the blue MOK Manager screen are still required.
• RPM removal no longer attempts or recommends interactive cleanup from the
  %preun scriptlet; interactive resource cleanup is handled by the manager
  commands instead.
• Direct dnf remove v4l2loopback-manager removes only the RPM-managed
  manager files and intentionally preserves locally-created resources.

Fixed

• Fixed the package-removal workflow where %preun recommended running
  v4l2loopback uninstall after the DNF removal transaction had already
  started and /usr/bin/v4l2loopback was about to be removed.
• Fixed systemd integration being left behind when explicitly uninstalling
  resources managed by v4l2loopback-manager.
• Prevented reinstall from unintentionally disabling an existing
  v4l2loopback systemd integration.
• Prevented purge from reporting complete removal when MOK certificate
  deletion is still pending confirmation during the next reboot.

Security

• MOK certificate deletion continues to require explicit user confirmation
  and is never completed automatically by the RPM removal process.
• Reboot after staging MOK certificate deletion remains explicitly manual.

v1.0.4

Added

• Added the status command to report the Fedora default boot kernel, Secure
  Boot state, signing-key files, MOK enrollment, target-module presence,
  module signer, and running-kernel module state.
• Added explicit MOK enrollment verification before deciding whether a valid
  signed module requires attention.
• Added recovery guidance for BIOS/UEFI or firmware changes that can leave the
  existing signing certificate unenrolled.

Changed

• genkey now preserves an existing complete signing key pair and reuses the
  existing DER certificate when MOK enrollment must be restored.
• MOK enrollment detection now handles Fedora/mokutil combinations where
  mokutil --test-key can print is already enrolled while still returning
  exit status 1.
• needs-rebuild now distinguishes module validity from MOK trust: a module
  that already exists and has the expected signer is not rebuilt merely
  because its MOK enrollment is missing.
• rebuild now avoids unnecessary compilation when the module is already
  correctly signed and instead directs the user to re-enroll the existing
  certificate when needed.
• MOK recovery instructions now make the reboot step explicitly manual.

Fixed

• Fixed false Signing certificate is NOT enrolled reports caused by relying
  only on the exit status of mokutil --test-key.
• Avoided regenerating signing keys as a response to lost MOK enrollment.

v1.0.3

Added

• Added CHANGELOG.md to maintain a structured release history following
  Keep a Changelog conventions.
• Added CONTRIBUTING.md with development requirements, contribution workflow,
  testing guidelines, RPM validation, commit conventions, and security guidance.
• Added SECURITY.md documenting supported versions, private vulnerability
  reporting, MOK private-key handling, privileged operations, and the project
  security model.
• Added GitHub Issue Forms for bug reports and feature requests.
• Added GitHub issue configuration with dedicated links for private security
  reports and upstream v4l2loopback issues.
• Added a Pull Request template with testing, packaging, documentation, and
  security checklists.
• Added a GitHub Actions ShellCheck workflow for Bash syntax validation and
  static analysis.
• Added a GitHub Actions RPM build workflow to validate the SPEC, build SRPM
  and binary RPM packages, rebuild from the generated SRPM, and inspect the
  resulting package.
• Added RPM artifact validation for the installed manager path and packaged
  documentation.
• Added release-preparation tooling for synchronizing release information
  between CHANGELOG.md and v4l2loopback.spec.
• Added automatic GitHub Release support based on version tags and
  CHANGELOG.md release entries.
• Added example.work-flow.md as a example of a Work-Flow for future use.

Changed

• Expanded README.md into the main project landing page with installation,
  architecture, Secure Boot, kernel-selection, rebuild, systemd, verification,
  removal, and project-scope documentation.
• Added project flow diagrams describing the module build, signing, rebuild,
  systemd, and responsibility-boundary workflows.
• Improved project documentation navigation with tables of contents and
  cross-document references.
• Extended ShellCheck coverage to include project maintenance and release
  scripts.
• Extended RPM CI triggers to include SPEC, changelog, release tooling, and
  workflow changes.
• Improved RPM CI validation to verify package metadata, expected files,
  generated SRPMs, binary RPMs, and SRPM rebuildability.
• Standardized release preparation around CHANGELOG.md as the primary
  human-maintained source of release changes.
• Prepared the project for automated GitHub Release and COPR release workflows.

v1.0.2 — Default boot kernel and signature verification

v1.0.2 — Default boot kernel and signature verification

v1.0.2 improves Fedora kernel selection and Secure Boot signature verification for v4l2loopback-manager.

Highlights

• Uses Fedora's configured default boot kernel as the build target.
• Detects the target kernel with grubby --default-kernel.
• Verifies that v4l2loopback.ko is signed by the expected MOK certificate.
• Rebuilds the module when it is missing, unsigned, unreadable, or signed by another key.
• Keeps needs-rebuild compatible with systemd ExecCondition= semantics.
• Adds grubby as a runtime dependency.

Kernel Selection

The manager now targets the kernel configured by Fedora as the default boot kernel:

sudo grubby --default-kernel

This avoids assuming that the numerically newest installed kernel or kernel-devel package is necessarily the kernel Fedora intends to boot.

Both:

needs-rebuild
rebuild

use the same target-kernel selection logic.

Secure Boot Verification

For the selected kernel, the manager checks:

/lib/modules/<kernel>/updates/v4l2loopback.ko

and verifies its signer with modinfo.

The expected signer is:

V4L2Loopback Module Signing

The module is rebuilt when it is:

missing
unsigned
unreadable
signed by another certificate

systemd Behavior

needs-rebuild is designed for:

ExecCondition=/usr/bin/v4l2loopback needs-rebuild

Its exit codes are:

0 → rebuild required
1 → module already valid

Therefore, systemd may show:

status=1/FAILURE
Skipped due to 'exec-condition'

when the module already exists and is correctly signed.

This is expected behavior and does not indicate a failed module build.

Installation

Enable the COPR repository:

sudo dnf copr enable hhlp/v4l2loopback

Install or upgrade:

sudo dnf install v4l2loopback-manager

or:

sudo dnf upgrade v4l2loopback-manager

Verify the installed version:

rpm -q v4l2loopback-manager

Verification

Check Fedora's default boot kernel:

sudo grubby --default-kernel

Check whether a rebuild is required:

sudo v4l2loopback needs-rebuild
echo $?

Inspect the module signer:

TARGET="$(sudo grubby --default-kernel)"
TARGET="${TARGET##*/}"
TARGET="${TARGET#vmlinuz-}"

modinfo -k "$TARGET" v4l2loopback |
    grep -E '^(filename|version|signer|sig_key|sig_hashalgo):'

Expected signer:

V4L2Loopback Module Signing

Upgrade Note

If v4l2loopback-rebuild.service was generated by an older release, regenerate it with:

sudo v4l2loopback disable-systemd
sudo v4l2loopback enable-systemd

Then verify:

systemctl status v4l2loopback-rebuild.service
systemctl is-enabled v4l2loopback-rebuild.service

Cleanup

Before removing the package, the recommended cleanup sequence is:

sudo v4l2loopback uninstall
sudo v4l2loopback disable-systemd
sudo dnf remove v4l2loopback-manager

Changes Since v1.0.1

• Use Fedora's default boot kernel as the module build target.
• Detect the target kernel using grubby --default-kernel.
• Verify module signatures against the expected MOK certificate.
• Rebuild missing or incorrectly signed modules.
• Preserve needs-rebuild semantics for systemd ExecCondition=.
• Add the grubby runtime dependency.
• Update systemd descriptions, documentation, and tests.

---

Package: v4l2loopback-manager
Release: v1.0.2
Platform: Fedora Linux
Manager: /usr/bin/v4l2loopback