Немного странно.
У меня была постоянная проблема, когда - даже после удаления snap и всех его зависимостей, и связанных с этим снимков уже давно очищены, я вижу системупопытаться повторно добавить их при загрузке.
Например: snap-spotify-21.mount выполняется попытка монтирования при загрузке в ОС.этот файл не существует нигде в файловой системе, но состояние systemctl показывает:
● snap-spotify-21.mount loaded failed failed Mount unit for spotify, revision 21
Я пробовал systemctl reset-failed, что исключает запись в systemctl status.Я пробовал следующее:
- ранее удалил файлы
.mount, когда изучал эту проблему, поэтому теперь их нет на диске - , маскирующих элементы монтирования systemd
systemctl mask <mount> и затем снимите маску reset-failed- grep для имени файла во всех файлах (без результатов)
- убедитесь, что подобъем ядра свободен от всех связанных конфигураций, проверив, что все подобъемы btrfsудалено
- еще раз проверено, что система загружает подсистему btrfs. Я ожидаю, что она будет
У меня также ранее был раздел подкачки, настроенный как зашифрованный своп, например:
swap /dev/<device> /dev/urandom cipher=aes-cbc-essiv:sha256,hash=ripemd160,size=256,swap
Давным-давно устранена необходимость в физическом обмене и удалена запись из /etc/crypttab - Когда я удалил связанный раздел, чтобы повторно использовать пространство для расширения другого раздела, я заметил, что система пытается ввести crypttab запись при загрузке - даже если она больше не существует.Блоки загружаются при попытке смонтировать зашифрованный раздел в раздел, который больше не существует.С тех пор я создал 8-мегабайтный раздел, чтобы сохранить приемлемое время загрузки машины в качестве обходного пути.
Затем я попробовал все перечисленные выше шаги, а затем update-initramfs -u, чтобы посмотреть, очистит ли это - без кубиков.Это было 18.04.10, а теперь 19.04, и я подумал, что это будет какая-то конфигурация загрузки, которая не обновлялась.
Какую конфигурацию я пропустил?