Проблема

После обновления с stretch на buster, мой ноутбук зависает во время загрузки во время проверки fsckd, с сообщением:
fsckd-cancel-msg: Нажмите Ctrl+C, чтобы отменить все проверки файловых систем, которые выполняются
Он не отвечает на ‘Ctrl+C’ или что-либо еще.

Предыстория

Обновление

Я обновил систему с stretch на buster, следуя этому руководству. Чтобы избежать проблем с недоступностью ссылки, вот команды в последовательном порядке:

su
sed -i 's/stretch/buster/g' /etc/apt/sources.list
apt update
apt upgrade
apt dist-upgrade
apt autoremove
apt clean
shutdown -r now

Ошибок не было.

Загрузка

Во время перезагрузки была обязательная проверка fskd, которая раньше никогда не вызывала проблем. Теперь же она заканчивается вышеупомянутым сообщением об ошибке. Ручное выключение и повторное включение приводят к тому же результату.

Что я пробовал

Этот вопрос имеет ту же проблему в Ubuntu. Поскольку Debian и Ubuntu похожи, я подумал, что принятый ответ может исправить мою проблему. Мой подход основан на ответе:

Режим восстановления

У меня не было под рукой Live USB, поэтому я загрузился в Linux 4.19.0-12-amd64 x86_64 (режим восстановления) и ввел пароль root для обслуживания.

fdisk -l

Устройство     Загрузка  Начало       Конец   Секторы   Размер Id Тип
/dev/sda1  *      2048    499711    497664   243M 83 Linux
/dev/sda2       501758 625141759 624640002 297.9G  5 Расширенный
/dev/sda5       501760 625141759 624640000 297.9G 83 Linux

Затем я запустил вручную fsck на всех перечисленных дисках, также на /dev/mapper/debian--vg-root и /dev/mapper/debian--vg-home, все из которых вернули чистые результаты. Затем я перезагрузился, думая, что возможно проблема решена.

Графический режим восстановления

К сожалению, перезагрузка показала ту же ошибку. Поэтому я снова ручным способом выключил и включил, снова загрузившись в режиме восстановления. На этот раз, однако, вместо ввода пароля root, я нажал Ctrl+D чтобы продолжить. Он завершил загрузку, показывая только черный экран. Поэтому я переключился на tty с помощью Ctrl+Alt+F1, войдя под своей стандартной учетной записью без привилегий root. Затем я начал сеанс X11 с помощью startx (нет особой причины для этого, кроме того, что мне удобнее работать в графическом сеансе).
Это уже показало мне, что обновление прошло успешно, поскольку визуальный интерфейс buster немного отличается от stretch. Чтобы убедиться, я проверил свою дистрибуцию с помощью lsb_release -a

No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 10 (buster)
Release:    10
Codename:   buster

Проверка плохих секторов

Я выполнил sudo e2fsck -fccky на всех /dev/sdaX и /dev/mapper/debian-vg-X, что заняло почти два часа. Перезагрузка показала, что ошибка все еще сохраняется.

Gparted

Я запустил gparted, но так как мой диск зашифрован LUKS, я не смог увидеть ничего полезного (сопутствующий вопрос).

Проверка /var

Я видел в нескольких источниках, что полный /var может вызывать аналогичные проблемы. Так как я не мог проверить его с помощью gparted, как рекомендовали, я проверил его, как предложено здесь:

sudo du -ks *|sort -nr

Однако вывод не выглядит так, будто он сильно заполнен:

698456  lib
100720  cache
53824   log
6688    backups
76  spool
68  tmp
32  snap
8   mail
4   opt
4   local
0   run
0   lock

Также вывод df выглядит так:

Файловая система                  1K-блоки     Использовано Доступно Использование% Смонтировано на
udev                          1988192        0   1988192   0% /dev
tmpfs                          402032     6508    395524   2% /run
/dev/mapper/debian--vg-root  28703652 10165160  17057380  38% /
tmpfs                         2010160   133528   1876632   7% /dev/shm
tmpfs                            5120        4      5116   1% /run/lock
tmpfs                         2010160        0   2010160   0% /sys/fs/cgroup
/dev/sda1                      240972    89448    139083  40% /boot
/dev/mapper/debian--vg-home 273421644 24010648 235452240  10% /home
/dev/loop0                     212864   212864         0 100% /snap/firefox/172
/dev/loop2                     100096   100096         0 100% /snap/core/10185
/dev/loop1                     100096   100096         0 100% /snap/core/10126
tmpfs                          402032       24    402008   1% /run/user/1000

Так что я не думаю, что это проблема.

Остановка fsck при загрузке

Загрузка на батарейном питании

Я подумал, что могу просто предотвратить выполнение fsck при загрузке, как здесь. Однако загрузка на батарейном питании и нажатие Ctrl+C не дало заметного эффекта, ошибка осталась прежней.

tune2fs

Как предложено здесь, я использовал tune2fs -c 0 -i 0 /dev/sda1. Но даже несмотря на то, что Максимальное количество монтирования установлено на -1 и Интервал проверки на 0 (<без>), ошибка остается.

Я также нашел это решение, но так как это для archlinux, и также я ничего не знаю о grub, я не попытался это сделать.

Дополнительная информация

• При загрузке я был сбит с толку, увидев, что на моем ноутбуке, похоже, есть две версии ядра, 4.19 и 4.9. Это из-за обновления или это всегда было, и я просто никогда этого не замечал?
• Распространенная проблема, похоже, возникает, когда установлены драйверы nvidia, именно поэтому в указанном выше руководстве рекомендуется удалить их перед обновлением. Однако у меня никогда не было установленных драйверов nvidia, так что это не может быть причиной.
• Подобный вопрос был решен установкой nvidia-drivers. Однако apt сообщает мне Не удается найти пакет nvidia-drivers.

Вопрос

Как я могу предотвратить fsckd от блокировки моей системы при загрузке?

Я предлагаю проверить, достаточно ли свободного места на том разделе, где находится Debian. Если он каким-то образом полон или почти полон, вам нужно увеличить его доступное пространство, а затем перезагрузить. Debian загрузится. Voilà.

Ниже то же самое предложение, но с подробностями для тех, кто не знаком с тем, как проверить доступное пространство и увеличить его.

Мы сталкиваемся с тем же самым вызовом с одним из наших устройств. В нашем случае причиной этой проблемы было то, что каким-то образом объем устройства, на котором хранится Debian, был полон. Ноль доступного пространства. В свою очередь, во время загрузки автоматически запускался fsck. fsck требует небольшое количество пространства, чтобы завершить свою автоматизацию. В свою очередь, fsck завис. Поскольку он не смог завершить свою автоматизацию. К сожалению, fsck не проверяет доступное пространство перед запуском своей автоматизации. Это было бы хорошей новой функцией.

Мы смогли воспроизвести эту проблему на еще трех устройствах. Просто заполнив их хранилище.

Шаги для решения этой проблемы:

1. С помощью терминала выполните эту команду, чтобы узнать, полны ли объемы

   sudo df -h

2. В качестве альтернативы, если у вас есть доступ к GNOME, с помощью терминала выполните эту команду, чтобы открыть Baobab

   sudo baobab

3. Подождите несколько секунд или минут, пока Baobab проанализирует объем. Он покажет, какие папки занимают больше всего места. Интерфейс интуитивно понятен.

4. Если необходимо, увеличьте доступное хранилище. Для этого, например, если это уместно, выполните эти команды, чтобы очистить временные кэшированные установочные пакеты:

   sudo apt-get clean

   sudo aptitude clean

5. Перезагрузитесь

6. fsck автоматически завершит свою автоматизацию. Иногда это очень быстро. Он даже не отобразится. Это нормально.

7. Debian загрузится. Voilà.