Convert an lm-sensors 2 Configuration Without Losing the Original

You will turn an old lm-sensors 2 sensors.conf into lm-sensors 3 syntax, save the converted file as sensors3.conf, and check what changed before using it. The installed command here is sensors-conf-convert from lm-sensors version 3.6.0-9build1. Its manual page is dated August 2013, so treat the examples as verified behaviour for this installation rather than a guarantee for every package release.

Allow about fifteen minutes for the conversion and a review. You need a readable legacy configuration, a shell, and somewhere to write a candidate file. The conversion itself does not need root when both files are in a directory you can write. Installing the result as /etc/sensors3.conf is a separate, privileged step.

1. Confirm the installed tool

Check the command and package before touching a configuration:

$ command -v sensors-conf-convert
/usr/bin/sensors-conf-convert
$ dpkg-query -W -f='${Package} ${Version}\n' lm-sensors
lm-sensors 1:3.6.0-9build1

The command reads the old file from standard input and writes the new file to standard output. It has no documented option for selecting input or output files. That makes shell redirection the clearest workflow.

Checkpoint: if command -v finds nothing, stop here and install lm-sensors through your normal package-management process. Do not copy a conversion script from an unrelated host.

2. Preserve the source and choose a candidate path

Do not convert directly into a live configuration path. First make a working copy of the old file. Replace the placeholder with the real path on your system:

$ install -m 0644 /path/to/sensors.conf /tmp/sensors.conf.legacy
$ test -r /tmp/sensors.conf.legacy && echo 'legacy source is readable'
legacy source is readable

install creates a separate copy and gives it ordinary file permissions. The original remains unchanged. If the source contains sensitive host details, choose a private working directory instead of a shared temporary directory and restrict its permissions.

Do not use sudo for the copy unless the source cannot be read by your account. If elevated access is genuinely required, run only the narrow read operation with sudo; avoid making the whole shell a root shell.

3. Convert into a new file

Run the converter with input and output redirection:

$ sensors-conf-convert < /tmp/sensors.conf.legacy > /tmp/sensors3.conf.candidate
-i used with no filenames on the command line, reading from STDIN.

The warning is emitted by this installed script because it uses Perl's in-place-editing machinery while still accepting standard input. The converted configuration goes to the redirected standard output. The first line of a successful result is time-stamped, so its exact date and time will vary:

# Converted by sensors-conf-convert on ...

The script converts old feature names and removes or rewrites constructs that are not part of the newer interface. For example, a legacy temp_over reference becomes temp1_max; comments are examined too, so a commented line may be changed. It can also remove obsolete statements. This is a syntax migration, not a hardware validation.

Checkpoint: make sure the candidate exists and is non-empty before reviewing it:

$ test -s /tmp/sensors3.conf.candidate && echo 'candidate written'
candidate written
$ sed -n '1,24p' /tmp/sensors3.conf.candidate

4. Review the conversion before installation

Compare the old and new files as text:

$ diff -u /tmp/sensors.conf.legacy /tmp/sensors3.conf.candidate

Expect deliberate changes to feature names such as temp, temp_hyst, vin0 and sensor1. The converter also handles several chip-specific renames. It removes some old feature references, including obsolete alarm, beep, PWM and state or status forms. A removed line is not proof that the tool failed; it may describe an interface that lm-sensors 3 cannot use.

Review every deletion that matters to your monitoring policy. If the file contains chip-specific formulas, labels or limits, compare the result with the hardware's current output from sensors after installation. Do not assume that a clean exit status means that every sensor label or limit is still semantically correct.

5. Install the candidate only after the review

Back up the existing lm-sensors 3 configuration before replacing it. This changes system-wide sensor behaviour, so schedule it if monitoring consumers depend on the file:

$ sudo cp --preserve=all /etc/sensors3.conf /etc/sensors3.conf.before-convert
$ sudo install -m 0644 /tmp/sensors3.conf.candidate /etc/sensors3.conf

If /etc/sensors3.conf does not exist, the first command will fail. That is useful: stop and decide whether this host is meant to receive a new configuration rather than silently treating a missing baseline as harmless. Do not overwrite /etc/sensors.conf, the legacy source, or any file in /etc/sensors3.conf.d/ as part of this example.

Undo the installation by restoring the backup:

$ sudo install -m 0644 /etc/sensors3.conf.before-convert /etc/sensors3.conf

The converter does not restart a service or apply readings itself. Processes that read the configuration may need their normal reload or restart procedure; check that process's documentation before disrupting it.

6. Verify the resulting configuration

Run the normal sensors command and look for parse errors or obviously broken labels:

$ sensors

The exact output depends on the host's detected chips, drivers and configuration. A successful command should print the available sensor sections without a configuration parse error. If the output is wrong, restore /etc/sensors3.conf.before-convert, rerun diff -u, and investigate the affected chip block rather than repeatedly converting the already converted file.

Do not feed a file beginning with # Converted by sensors-conf-convert back into the converter. The installed command warns that converting an already converted file can produce an incorrect result for some chip types. Always return to the preserved lm-sensors 2 source for another attempt.