Created attachment 11919 [details] e2fsck: Cannot continue, aborting Не знаю пока, кто крайний, но с очередным новым ядром система не грузится. Встаёт на /dev/sda7: clean, ... /dev/sda6 is mounted e2fsck: Cannot continue, aborting Эта вот пара грузится (сделано ещё в p10, какой make-initrd был не знаю пока, может быть старее, чем в p10 на 19 октября): Sep 23 21:16 vmlinuz-5.10.145-std-def-alt1 Oct 19 20:26 initrd-5.10.145-std-def-alt1.img Эта вот уже нет (Sisyphus, make-initrd-2.32.1-alt1): Nov 11 01:31 vmlinuz-5.15.78-std-def-alt1 Nov 22 17:43 initrd-5.15.78-std-def-alt1.img На самом деле p10 ноябрьского это тоже касается (make-initrd-2.31.0-alt2), но стенд пока с Sisyphus. /dev/sda2 488M 74M 379M 17% /boot /dev/sda5 3,9G 1,7G 2,0G 46% / /dev/sda6 3,9G 2,7G 1009M 73% /usr /dev/sda7 3,9G 21M 3,6G 1% /home /dev/sda8 3,9G 3,3G 385M 90% /var /dev/sda9 42G 1,2G 38G 4% /var/cache/nfcapd sysvinit, хотя вряд ли важно.
Насколько я вижу падение происходит уже после initrd в системе. А ошибка возникает из-за того, что в fstab для sda6 прописана проверка и она падает из-за того, что usr уже смонтирован.
Покажите пожалуйста что написано в fstab для sda6.
(In reply to Alexey Gladkov from comment #2) > Покажите пожалуйста что написано в fstab для sda6. UUID=2800a0c4-6081-48b3-bd09-56f9f6fd8e00 /usr ext4 nodev,relatime 1 2 (In reply to Alexey Gladkov from comment #1) > Насколько я вижу падение происходит уже после initrd в системе. А ошибка > возникает из-за того, что в fstab для sda6 прописана проверка и она падает > из-за того, что usr уже смонтирован. Да, но зависимость от initrd получается прямая. Сейчас откатил до make-initrd-busybox-1.32.1-alt3.x86_64 make-initrd-2.16.0-alt2.x86_64 из p9 (в остальном остался Sisyphus), пересоздал initrd, и загрузка c 5.15.78-std-def прошла. То есть, видимо, что-то в initrd начало /usr монтировать, либо перестало размонтировать.
Если сходу идей нет, завтра постараюсь поточнее версию поймать, с которой ломается.
Да, make-initrd по умолчанию стал монтировать /usr из initrd. Это было намеренное изменение. Оно было необходимо в рамках предполагаемой миграции /bin -> /usr/bin в сизифе. Я не предполагал проблем, но упустил из виду, что у нас fsck вызывается без опции -M, а также что её нет в FSCKOPTIONS по умолчанию.
На самом деле правильнее всего поправить startup.
Попробуйте пожалуйста startup из задания: https://git.altlinux.org/tasks/310472/
(In reply to Alexey Gladkov from comment #7) > Попробуйте пожалуйста startup из задания: > > https://git.altlinux.org/tasks/310472/ По крайней мере грузится. Что при это пишет - сегодня не посмотрю. По reboot -f c открытым для редактирования текстовым файлом в /usr тоже перегрузилось.
(In reply to Alexey Gladkov from comment #7) > Попробуйте пожалуйста startup из задания: > > https://git.altlinux.org/tasks/310472/ Посмотрел изменения. Добавление -M просто игнорирует проверку /usr. Если там есть повреждения, они остаются. Моя проверка вчерашняя с открытым файлом не очень удачной вчера оказалась. На сколько я вижу, в rc.sysinit есть отдельно "check_filesystem "Checking root filesystem:" -Tay $fsckoptions /". Может оставлять /usr так же в ro и, далее, так же в rw перемонтировать? Только надо ещё проверку на его наличие.
(Ответ для Sergey Y. Afonin на комментарий #9) > (In reply to Alexey Gladkov from comment #7) > > > Попробуйте пожалуйста startup из задания: > > > > https://git.altlinux.org/tasks/310472/ > > Посмотрел изменения. Добавление -M просто игнорирует проверку /usr. Если там > есть повреждения, они остаются. Моя проверка вчерашняя с открытым файлом не > очень удачной вчера оказалась. Да, если /usr монтируется в initrd, то и проверяться он должен там. У make-initrd есть такая возможность, но эта фича не включается по умолчанию. Возможно, стоит активировать её. > На сколько я вижу, в rc.sysinit есть отдельно "check_filesystem "Checking > root filesystem:" -Tay $fsckoptions /". Может оставлять /usr так же в ro и, > далее, так же в rw перемонтировать? Только надо ещё проверку на его наличие. Да, можно продублировать этот код для /usr. Меня лишь смущает то что если завтра умные люди решат /var отделить, то придётся и его специально обрабатывать.
(In reply to Alexey Gladkov from comment #10) > Да, можно продублировать этот код для /usr. Меня лишь смущает то что если > завтра умные люди решат /var отделить, то придётся и его специально > обрабатывать. Отделять /var идея здравая. И не только /var. А специально обрабатывать придётся только то, что решено монтировать в initrd. /var ведь в initrd пока нет планов монтировать? :-)
(Ответ для Sergey Y. Afonin на комментарий #11) > Отделять /var идея здравая. И не только /var. А специально обрабатывать > придётся только то, что решено монтировать в initrd. /var ведь в initrd пока > нет планов монтировать? :-) Ну вообще-то make-initrd уже давно не выделяет рут как-то особо. Он монтирует точки монтирования. Если пользователь хочет, то initrd смонтирует ему /home, /var, etc. Хардкода нет. Продублировать проверку в startup выглядит наипростейшим решением, но я не уверен, что оно правильное. Дим? Глеб?
(In reply to Alexey Gladkov from comment #7) > Попробуйте пожалуйста startup из задания: > https://git.altlinux.org/tasks/310472/ Пока суть да дело, может это задание отправить в Сизиф и p10, как временное решение?
startup-0.9.9.16-alt1 -> sisyphus: Tue Nov 22 2022 Alexey Gladkov <legion@altlinux.ru> 0.9.9.16-alt1 - Do not check mounted filesystems (ALT#44394).
(In reply to Alexey Gladkov from comment #12) > Продублировать проверку в startup выглядит наипростейшим решением, но я не > уверен, что оно правильное. > > Дим? Глеб? Завёл Bug 44409
