diff --git a/ChangeLog.md b/ChangeLog.md
index 4a6386f0..7da54360 100644
--- a/ChangeLog.md
+++ b/ChangeLog.md
@@ -17,13 +17,6 @@ and [by Yandex](https://translated.turbopages.org/proxy_u/ru-en.en/https/libmdbx
  - В API добавлена функция `mdbx_cursor_count_ex()` позволяющая получить как количество мульти-значений
    соответствующих текущему ключу, так и информацию о вложенном дереве хранящем эти значения.
 
-Изменение поведения:
-
- - Теперь при включении профилирования GC (сборка с опцией `MDBX_ENABLE_PROFGC=ON`)
-   подсчитываются затраты времени ЦПУ на слияние списков страниц (на работу функции `pnl_merge()`).
-
- - В утилите тестирования значение режима данных переименовано из `data.dups` в `data.multi`.
-
 Исправления:
 
  - Устранён регресс состояния вложенного/dupsort курсора после вставки данных в `MDBX_APPEND`-режиме.
@@ -40,24 +33,25 @@ and [by Yandex](https://translated.turbopages.org/proxy_u/ru-en.en/https/libmdbx
    Ошибка проявлялась возвратом неверных значений из `mdbx_cursor_count()`
    или срабатывание assert-проверки в отладочных сборках.
 
- - Получение boot_id при работе внутри LXC-контейнера.
+ - Поддержка получения boot_id при работе внутри LXC-контейнера.
 
    Из LXC-контейнера не доступен файл хостовой системы `/proc/sys/kernel/random/boot_id`.
    Вместо него, при каждом старте контейнера, создается и заполняется
    случайными данными собственный boot_id смонтированный через bind из `tmpfs`.
    https://github.com/lxc/lxc/issues/3027
 
-   Ранее этот замещенный bootid отбраковывался внутри libmdbx,
-   так как располагается в `tmpfs`, а не файловой системе `/proc`.
+   Ранее этот подставной/замещенный boot_id отбраковывался внутри libmdbx,
+   так как файл располагается в `tmpfs`, а не в файловой системе `/proc`.
+   В результате boot_id для проверки целостности БД не был доступен.
    Теперь при работе внутри LXC-контейнера такой bootid будет использоваться.
 
-   Однако, полноценный контроль по boot_id не возможен, так как при
+   Однако, полноценно работающий контроль по boot_id не возможен, так как при
    рестарте LXC-контейнера (но не хоста) boot_id будет меняться, хотя
    данные в unified page cache сохраняются.
 
-   Таким образом, при рестарте LXC-контейнера, libmdbx будет производить
-   откат БД до крайней точки устойчивой фиксации, что может приводить к
-   утрате данных пользователя в случаях когда они могли быть сохранены.
+   Таким образом, при рестарте LXC-контейнера без рестарта хоста, libmdbx придется
+   откатить состояние БД до крайней точки устойчивой фиксации, что повлечет
+   утрату данных пользователя в случаях когда они могли быть сохранены.
    Однако, улучшить ситуацию пока не представляется возможным, как минимум
    до доступности boot_id хостовой системы изнутри LXC-контейнера.
 
@@ -68,6 +62,13 @@ and [by Yandex](https://translated.turbopages.org/proxy_u/ru-en.en/https/libmdbx
    Ошибка была внесена при рефакторинге, коммитом `2f2df1ee76ab137ee66d00af69a82a30dc0d6deb`
    чуть более 5 лет назад и долго оставалось не замеченной.
 
+Изменение поведения:
+
+ - Теперь при включении профилирования GC (сборка с опцией `MDBX_ENABLE_PROFGC=ON`)
+   подсчитываются затраты времени ЦПУ на слияние списков страниц, т.е. на работу функции `pnl_merge()`.
+
+ - В утилите тестирования значение режима данных переименовано из `data.dups` в `data.multi`.
+
 
 --------------------------------------------------------------------------------