При обновлении слетают настройки

Question

Добрый день.

АТС крутится на виртуальной машине Hyper-V.

При попытке обновления с 2021.2.194 на 2021.3.86 или на 2021.4.175 слетают настройки. Сценарии немного разные при разных попытках:

• Иногда обновление проходит нормально, но позже может пропасть диск с хранилищем данных.
• Иногда теряются все настройки.
• Иногда теряется диск с хранилищем данных.
• Иногда теряются все настройки и диск с хранилищем данных.

Было замечено, что иногда в процессе обновления перед самой перезагрузкой машины появляется сообщение. В этом случае слетают все настройки.

Error: Partition(s) 1, 2, 3 on /dev/sda have been written, but we have been unable to inform the kernel of the change...

Перед обновлением:

~# df -h
Filesystem                Size      Used Available Use% Mounted on
devtmpfs                963.0M    328.0K    962.7M   0% /dev
tmpfs                     1.7G     35.8M      1.7G   2% /
/dev/sda2               401.7M    353.7M     43.9M  89% /offload
/dev/sda3                14.1M    463.0K     13.4M   3% /cf
/dev/sdb1               124.5G     93.1G     25.0G  79% /storage/usbdisk1

~# fdisk -l
Disk /dev/sda: 2048 MB, 2147483648 bytes, 4194304 sectors
261 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sda1 *  0,0,2       56,12,61             1      57264      57264 27.9M  6 FAT16
Partition 1 has different physical/logical end:
     phys=(56,12,61) logical=(3,143,61)
/dev/sda2    56,12,62    916,5,37         57265     923679     866415  423M 83 Linux
Partition 2 has different physical/logical start (non-Linux?):
     phys=(56,12,62) logical=(3,143,62)
Partition 2 has different physical/logical end:
     phys=(916,5,37) logical=(57,126,37)
/dev/sda3    916,5,38    948,1,33        923680     955679      32000 15.6M 83 Linux
Partition 3 has different physical/logical start (non-Linux?):
     phys=(916,5,38) logical=(57,126,38)
Partition 3 has different physical/logical end:
     phys=(948,1,33) logical=(59,124,33)
/dev/sda4    600,0,1     1023,63,32     1228800    4194303    2965504 1448M 83 Linux
Partition 4 has different physical/logical start (non-Linux?):
     phys=(600,0,1) logical=(76,124,49)
Partition 4 has different physical/logical end:
     phys=(1023,63,32) logical=(261,21,16)
Disk /dev/sdb: 127 GB, 136365211648 bytes, 266338304 sectors
16578 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sdb1    0,1,1       1023,254,63         63  266325569  266325507  126G 83 Linux

В каком направлении можно подвигаться?

Comments

Объясню, что я понимаю под потерей диска с хранилищем данных.

Команда df -h показывает, что /storage/usbdisk1 это /dev/sdb1. Перезагружаем машину и та же команда уже показывает /dev/sda4.

Как система при загрузке ищет диск с хранилищем данных?

И, кстати, есть какой-то способ на живую изменить расположение хранилища? Ну, скажем самостоятельно поставить вместо /dev/sda4 старый диск /dev/sdb1?

---

в первую очередь проверьте диск для хранения данных на наличие ошибок. 

основной диск также лучше проверить, у Hyper-V вроде есть свои утилиты для этого

Как система при загрузке ищет диск с хранилищем данных?

В базе данных настроек хранится имя диска. Настройки хранятся на третьем разделе системного диска, пример /dev/sda3. 

 есть какой-то способ на живую изменить расположение хранилища

да, нужно подключиться к АТС по ssh. 

отключить смонтированный раздел:

freestorage

подключить корректный раздел:

php -f /etc/rc/connect.storage

Answer 1

Сперва смотрим какой диск смонтирован как storage:

~# df -h

Filesystem   Size      Used Available Use% Mounted on

devtmpfs   472.6M    360.0K    472.2M   0% /dev

/dev/sda2  311.5M    294.5M         0 100% /offload

/dev/sda3   13.5M      2.4M     10.1M  19% /cf

/dev/sdb1   98.4G     85.4G      8.0G  91% /storage/usbdisk1

Далее смотрим какой у раздела идентификатор:

~# /bin/lsblk /dev/sdb -b -r -o NAME,UUID

NAME UUID

sdb 

sdb1 f55bd961-f575-4c3f-bbdf-bdaf99c6f8ba

Далее проверяем что в базе данных настроек:

~# sqlite3 /cf/conf/mikopbx.db 'Select * FROM m_Storage'

1|Дисковый накопитель|/dev/sdb|/storage/usbdisk1|STORAGE-DISK-4741397845384e6777cd67|ext2|||||0|0

В данном случае видно, что идентификатор отличается, а имя диска совпадает. 

Правим идентификатор:

sqlite3 /cf/conf/mikopbx.db "UPDATE m_Storage SET uniqid='f55bd961-f575-4c3f-bbdf-bdaf99c6f8ba'"

Тут следует указать корректный UUID, который получен из команды lsblk

Итоговая команда:

sqlite3 /cf/conf/mikopbx.db "UPDATE m_Storage SET uniqid='$(/bin/lsblk -p  -b -r -o NAME,UUID | grep "$(df -h | grep '/storage/usbdisk1$' | cut -d ' ' -f 1)" | cut -d ' ' -f 2)'"

Обновляться лучше сразу на актуальный релиз 2022.3.15 - он стабилен. Проблемы с дисками после правки идентификатора быть не должно. 

Пред обновлением обязательно сделайте снэшот машины. 

Comments

Ух, ты!!! Алексей, большое спасибо. Я уже смирился, что придется машину с нуля настраивать.

Попробуем обновиться в ближайшее время. Обязательно отпишу о результате.

---

релиз  2022.3.15 как оказалось еще не опубликован. надеюсь в течение дня будет доступен. 

---

Мы вчера переехали на 2022.2.102. Повылазила всякая мелочевка, но в целом обновление состоялось. Еще раз спасибо за инструкцию.