cmdline: add support for loading config from a local device

[atd9876]

Summary

Add support for loading Ignition configuration from a local device
specified via kernel command-line flags ignition.config.device and
ignition.config.path. This enables bare-metal and air-gapped
environments to provide Ignition configs on a labeled disk partition
(e.g., a config drive) without requiring network access.

Acknowledgments

The initial device-based config loading implementation (commit 6c250bc)
was authored by Jan Larwig (@tuunit). This PR builds on that work with
tests, documentation, and robustness improvements.

Changes

• Device-based config loading: parseCmdline now recognizes
  ignition.config.device and ignition.config.path flags.
  fetchConfig uses both to mount the labeled device read-only and
  read the config file at the specified path.
• tryMounting function: Waits for the labeled device to appear
  (with a 30-second timeout), mounts it read-only into a temporary
  directory, reads the config, and unmounts on return.
• Robustness improvements to parseCmdline:
  • Use strings.Fields instead of strings.Split to correctly
    handle tabs, multiple spaces, and trailing newlines.
  • Rename local url variable to parsedURL to avoid shadowing
    the net/url import.
  • Use errors.Is(err, context.DeadlineExceeded) instead of ==
    to correctly match wrapped errors.
• Tests: Add unit tests covering URL parsing, device+path parsing,
  partial flags, empty flags, invalid URLs, precedence, fileExists,
  and error handling in test helpers.
• Documentation: Update docs for the new command-line flags.

Fixes #2207

[gemini-code-assist]

Code Review

This pull request introduces support for loading Ignition configurations from a local device on bare metal platforms via the ignition.config.device and ignition.config.path kernel parameters. The implementation includes documentation updates, a refactored command-line parser, and logic to mount the specified device and read the configuration file. Review feedback identifies a potential logic error where returning configErrors.ErrEmpty might cause a fatal failure instead of a fallback when a device is missing, and a path traversal vulnerability when accessing the configuration file on the mounted device.

[prestist]

This is looking good overall, thank you for working on this! Some small comments.

I think we could use some integration tests, I would add a blackbox test (in tests/positive/) that sets up a labeled disk image with a config file and boots with ignition.config.device=LABEL ignition.config.path=/config.ign, wdyt?

[prestist]

Just two comments, Im not sure how I feel about them. What are your thoughts?

[prestist]

Thanks for the updates in 9a073d5 -- I've re-reviewed and the error handling changes look good. Incomplete flags, missing config, and device timeout all correctly return hard errors now instead of falling through silently. The negative blackbox tests are a nice addition too.
I'm fine with the 30s timeout -- laenion's data from SUSE backs that up.

A couple of things I'd like addressed before we merge:
configMinVersion in the tests should be "3.0.0" -- this feature is a provider behavior change, not a spec change. Setting it to 3.4.0 means the tests only run against spec versions >= 3.4.0 when there's no reason for that restriction.
Device label should be validated -- the config file path is properly sanitized with filepath.Clean(filepath.Join("/", ...)) which is great, but the device label from the kernel cmdline is passed straight into filepath.Join(distro.DiskByLabelDir(), opts.DeviceLabel) without the same treatment. Something like rejecting labels containing / or .. would keep it consistent.
A few smaller things (not blocking, but worth considering):

• If both ignition.config.url and ignition.config.device/ignition.config.path are set, the URL silently wins. Would be good to log a warning so the user knows their device flags are being ignored.
• Could use a negative test for the "only one of device/path set" error case -- you cover config-not-found and device-not-found but not this one.
• The distro.go change making KernelCmdlinePath() env-overridable is fine (follows the existing pattern for SystemConfigDir etc.) but ideally should be its own commit since it affects all callers.

Lastly the "Require release note" CI check is failing -- can you add a release note?

[atd9876]

I will fix those issues.

Re the

• negative test for the "only one of device/path set" error case - I felt that the unit tests covered that but I will add one.

[prestist]

@atd9876 Okay from my perspective this is lgtm, just need to rebase and resolve any commits to get the CI working :)