恩，Heresy 這邊自己架的 GitLab 在更新到最新的 18.6（官方部落格）後又出現問題了！這次又是 Container Registry 的問題。
實際上，在 GitLab 推出「container registry metadata database」（之前升級的紀錄）後，其實個人就覺得一直有些小問題，像是在升級到 18.3 的時候、就需要做一定的調整才能運作（當時的紀錄）。
後來在 Heresy 這邊，遇到 Docker 容器重啟也都固定會有問題、需要把整個容器刪除重建才可以；Heresy 後來也有提交問題給官方（參考），不過雖然號稱是修復了，但是似乎到了 18.6 也還沒合併進來。
而現在更新到 18.6 後，重啟之後雖然 GitLab 本身不會當掉、需要刪除重建，但是 container registry 的頁面卻會直接出現錯誤的畫面：
由於之前都是把容器刪除再重建就可以解決，所以這次也很直覺地試試看，但是看來是沒用了。
而看了一下系統的記錄，則是可以看到很多相關的錯誤，例如：
failed to connect to `user=registry database=registry`:
/var/opt/gitlab/postgresql/.s.PGSQL.5432 (/var/opt/gitlab/postgresql):
server error: FATAL: the database system is starting up (SQLSTATE 57P03)
或：
failed to connect to `user=registry database=registry_database`:
/var/opt/gitlab/postgresql/.s.PGSQL.5432 (/var/opt/gitlab/postgresql/):
failed SASL auth: FATAL: password authentication failed for user "registry" (SQLSTATE 28P01)
感覺這次似乎連資料庫登入都有問題了？
由於 Heresy 這次是過了幾天才更新，所以到官方的 issue 裡面找，果然有人有碰到一樣的問題：《After update to 18.6 registry with metadata database breaks “registry filesystem metadata in use, please import data before enabling the database”》，而且看來已經找到原因了？
根據這邊的說法，這個問題主要是因為 GitLab 系統內有「/var/opt/gitlab/gitlab-rails/shared/registry/docker/registry/lockfiles/filesystem-in-use」這個檔案，所以導致 GitLab 誤判成 registry 還在使用 filesystem metadata、而非 database metadata？
解決方法也很簡單，就是把這個檔案刪除就可以了。Heresy 這邊測試過、確實是把問題解決了！
另外也有人反映自己的系統沒這個檔案還是有同樣的問題，而解決方法則是可以透過強制將「REGISTRY_FF_ENFORCE_LOCKFILES」這個變數設定成 false。
大概就是這樣了，這邊基本上就是簡單紀錄一下而已了。
而現在重開機的時候，似乎也不會出現因為 container registry 有問題、而導致 GitLab 整個無法啟動的狀況了。