Не могу обновиться на RaspberryPi3

[a.m.samarin]

Добрый день. У меня RaspberryPi3, на которой крутилась ДК 615 версии. Решил обновиться, но до версии 637 не смог. Обновление отрабатывает слишком быстро. Далее при запуске, появляется маленькое окошко с прогрессом (запуск служб), как обычно, но через некоторое время пропадает. И всё. Программа не запускается.
Пришлось откатиться(обновиться) до 620 версии.
Как это исправить? Куда копать? И когда для малины выйдет актуальный апдейт (657 версия)?
С уважением.

[Alexander]

Можно скачивать сборку 2.3.1_657 для Raspberry.
Файл образа при обновлении а /home/pi/ копируете?

[a.m.samarin]

Файл образа при обновлении а /home/pi/ копируете?

Да. Я скопировал сразу все образы обновления туда и обновлял по очереди.

Теперь о грустном: обновление 657 так же, как 637 не сработало. Пришлось опять откатиться до 620.

Может проблема в системе?
Распберрипай3
Linux8 jessy
[uname -a] raspberrypi 4.4.9-v7

[Alexander]

Наверное самый простой вариант - перезалить образ SD-карты с нашей текущей сборкой ОС, потому что на ней всё обновляется и работает корректно.
С малиной3 эта сборка работает.
Базы LinCash и Transaction можно перенести через экспорт/импорт БД.
Серийник и ключ можно скопировать из /etc/hwsrv/. Если карта SD останется та же, то ключ должен работать.

[a.m.samarin]

Я так и понял.

Серийник и ключ можно скопировать из /etc/hwsrv/.

А за эту фишку огромное спасибо!
Новая проблема: теперь при загрузке товаров в кассу, загрузка идёт настолько медленно, что не понятно, загрузилось или нет. При этом малина3 начинает греться (загорается значок "t", и на ощупь она горячая). В базе примерно 7,5 тысяч товаров.
1. Есть способ отслеживать прогресс работы демона загрузки товаров?
2. Как, не снося базу транзакций, проверить и, если надо, восстановить целостность базы данных?

[Alexander]

1. Есть способ отслеживать прогресс работы демона загрузки товаров?

Штатного в Д:К нет.
Если пытаться мониторить базу, то многое зависит от того, чистится ли БД перед загрузкой.
Можно еще пытаться мониторить состояния in_progress/loaded в шапке goods.txt, либо строки старта/завершения загрузки в upload.log в каталоге обмена.

2. Как, не снося базу транзакций, проверить и, если надо, восстановить целостность базы данных?

Тут проще смотреть документацию на PostgreSQL (причем, конкретную версию).
Для попытки восстановления битой БД мы как-то использовали vacuumdb с опцией zero_damaged_pages.

[a.m.samarin]

Проблему решил при помощи буферной папки на кассе. Скрипт сначала скачивает туда файлы из сетевой шары (долго), а потом уже касса начинает их обрабатывать (быстро). Оказалось на точках, где стоят сотовые модемы, очень низкая скорость vpn-тоннелей - буквально до одного килобайта в секунду с частыми обрывами. Просто после обновления забыл про это и не восстановил скрипт синхронизации.
За подсказки огромное спасибо.