Попробуйте отключить случайную рандомизацию MAC-адресов : добавьте следующее в /etc/NetworkManager/NetworkManager.conf и перезапустите NetworkManager.service:
[устройство] wifi.scan-rand-mac-address=no
См. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836351 и https://www.reddit.com/r/debian/comments/55ltct/stretch_wifi_issues/
CB
resize2fs
и другие инструменты из набора e2fsprogs предполагают, что системный вызов read
либо возвращает весь запрошенный размер, либо встречает ошибку. В общем случае это не так: read
может возвращать меньше, вы должны вызывать его в цикле. Я думаю, что ядро Linux гарантирует, что read
возвращает все данные с блочных устройств в некоторых обстоятельствах, но я был укушен этим в прошлом, когда e2fsprogs делал неверные предположения о ядре.
Тот факт, что e2fsprogs не зацикливается на read
, на самом деле является ошибкой. В лучшем случае это ограничение: возможно способ написания кода корректен для некоторых версий ядра Linux при обращении к блочному устройству. Но это ограничение нигде не задокументировано. Код определенно глючит при обращении к файлу образа.
Проверьте журналы ядра на наличие ошибок. Если ядро сообщает об ошибке, значит проблема не в ошибке resize2fs (или, по крайней мере, не более чем плохое сообщение об ошибке).
Если ядро не сообщает об ошибках диска, запустите
strace -o resize2fs.strace sudo resize2fs /dev/sda2 115G
и проверьте системные вызовы read
.
read(3, "…", REQUESTED) = READ
Если REQUESTED ≠ READ, происходит короткое чтение. Если вы это заметили и можете воспроизвести, стоит сделать сообщение об ошибке. Объясните, как именно это произошло: точная версия ядра, как было скомпилировано ядро, точная версия resize2fs, какой аппаратный драйвер управляет /dev/sda
, на какой виртуальной машине он запущен. Я рекомендую сообщить об ошибке в Ubuntu, а не в upstream, так как upstream часто не умеет общаться с неспециалистами.