Збереження налаштувань OpenWrt під час оновлення прошивки

Під час оновлення прошивки OpenWrt через веб-інтерфейс можна скористатися прапорцем “Keep settings”. Він створює резервну копію налаштувань перед оновленням і відновлює її після завершення.

Якщо ви не до кінця розумієте, коли доцільно використовувати цю опцію — знімайте прапорець “Keep Settings” при кожному оновленні OpenWrt, щоби не зберігати налаштування.

• Залишайте прапорець “Keep Settings” лише при незначних оновленнях (наприклад, виправленнях помилок), які не змінюють структуру конфігурації.
• Використовуйте його лише в межах одного каналу прошивки (release → release, snapshot → snapshot).
• Прапорець зберігає лише частину конфігураційних файлів, але не весь розділ overlay.
• Якщо ви часто оновлюєте прошивку, краще знімати “Keep Settings” і створити власний скрипт налаштувань.
• Особливо обережними слід бути при оновленнях основних версій (наприклад, з 18.06 до 19.07 або з 19.07 до 21.02).
• Іноді конфігурація може змінюватися навіть у межах однієї гілки, але це рідко.
• У master-гілці (розробницька) зміни можливі частіше, але й там конфігурація змінюється не так часто.

Див. також: Резервне копіювання та відновлення

Цей розділ актуальний лише у разі використання метаданих образу для оновлення.

Часто трапляються ситуації, коли конфігурація пристрою змінилася таким чином, що зробила його несумісним із попередніми версіями. Це може бути пов'язано зі змінами у файловій системі або в конфігурації, які унеможливлюють оновлення через `sysupgrade`.

Починаючи з серпня 2020 (версії 20.xx), введено механізм попередження при спробі оновлення між несумісними версіями.

Це досягається шляхом використання номера сумісності (compat-version), який містить головну (x) та додаткову (y) версії у форматі: x.y

Для всіх пристроїв і образів, створених до цього моменту, за замовчуванням вважається значення “1.0”.

Це значення призначається для кожного пристрою індивідуально — воно не стосується загальної версії OpenWrt.

Якщо внесено несумісні зміни:

• Підвищення мінорної версії (наприклад, з 1.0 до 1.1) — дозволяє оновлення, але вимагає скидання налаштувань (зняти “Keep Settings”, або використати `sysupgrade -n`).
• Підвищення мажорної версії (наприклад, з 1.0 до 2.0) — забороняє оновлення навіть із скиданням налаштувань. Буде виведено попередження. Необхідно дотримуватися інструкцій від розробників.

Зазвичай, окрім зміни номера сумісності, додається пояснювальне повідомлення з підказками.

Оновлення все ще можна примусово виконати через `sysupgrade -F`, але це може призвести до проблем, яких система намагається уникнути.

У такому випадку зверніть увагу: версія сумісності зберігається в конфігурації: `uci: system.@system[0].compat_version`

Оскільки примусове оновлення не скидає конфігурацію, версія сумісності також не зміниться автоматично. Її потрібно встановити вручну:

uci set system.@system[0].compat_version="1.1"
uci commit system

Як уже зазначено, всі пристрої без `compat-version` вважаються такими, що мають значення 1.0.

Новий механізм сумісності доступний лише на пристроях, прошитих після його впровадження.

На старих пристроях, при спробі оновлення до “несумісного” образу, буде виведено попередження. Але оновлення доведеться примусово виконати з обов’язковим скиданням налаштувань: `sysupgrade -F -n`

Якщо ви цього не зробите, отримаєте наслідки, описані вище в розділі “Примусове оновлення”.

Виняток: ранні пристрої, що використовують DSA, можуть зберегти налаштування. Деталі в розділі вище.

Розділ для розробників, які реалізують підтримку compat-version при впровадженні несумісних змін.

Складається з двох частин:

Щоб встановити версію для перевірки під час оновлення, у визначенні пристрою потрібно вказати:

define Device/somedevice
  ...
  DEVICE_COMPAT_VERSION := 1.1
  DEVICE_COMPAT_MESSAGE := Неможливо перенести конфігурацію з swconfig на DSA
endef

`DEVICE_COMPAT_VERSION` обов’язковий для значень, відмінних від “1.0”. `DEVICE_COMPAT_MESSAGE` — необов’язковий, але рекомендований для пояснення причин несумісності.

На самому пристрої версія сумісності також повинна бути вказана — для цього в `board.d` додається команда:

ucidef_set_compat_version "1.1"

Під час виконання firstboot це значення буде додано до `/etc/board.json` та автоматично перетворено у `uci` конфігурацію.

Таким чином, версія сумісності є властивістю конфігурації, а не прошивки. Вона може бути збережена або змінена вручну, а також відновлена з резервної копії.