Исправление ошибок системы ubuntu
Оригинал: How to Use ‘fsck’ to Repair File System Errors in Linux
Автор: Marin Todorov
Дата публикации: 1 октября 2018 года
Перевод: А. Кривошей
Дата перевода: июль 2019 г.
Файловые системы отвечают за организацию хранения данных. Так или иначе, со временем файловая система может быть повреждена и некоторые ее части могут быть недоступны. Если ваша файловая система имеет такое несоответствие, рекомендуется проверить ее целостность.
Это можно выполнить с помощью системной утилиты fsck (file system consistency check). Эта проверка может быть выполнена автоматически во время загрузки или запущена вручную.
Когда нужно использовать fsck в Linux
Существуют разные сценарии, когда вам понадобится запустить fsck. Вот несколько примеров:
Система не загружается.
Файлы в системе поврежденны (часто вы можете увидеть ошибку ввода/вывода).
Подключенный диск (включая флэшки/SD-карты) не работает должным образом.
Опции fsck
Команда Fsck должна быть запущена с привилегиями суперпользователя (root). Вы можете использовать ее с разными аргументами. Их использование зависит от вашего конкретного случая. Ниже вы увидите некоторые из наиболее важных опций:
-A - используется для проверки всех файловых систем. Список берется из /etc/fstab.
-C - показывать индикатор выполнения.
-l - блокирует устройство, чтобы гарантировать, что никакая другая программа не попытается использовать раздел во время проверки.
-M - не проверять смонтированные файловые системы.
-N - только показывать, что будет сделано - не делать никаких реальных изменений.
-P - если вы хотите проверять файловые системы параллельно, включая корневую.
-R - не проверять корневую файловую систему. Это полезно только вместе с ‘-A‘.
-r - предоставить статистику для каждого проверяемого устройства.
-T - не показывает заголовок.
-t - исключительно указать типы файловых систем, которые будут проверяться. Типы могут быть разделены запятыми.
-V - предоставить описание того, что делается.
Как запустить fsck для исправления ошибок файловой системы Linux
Чтобы запустить fsck, вам нужно убедиться, что раздел, который вы собираетесь проверить, не смонтирован. Для этой статьи я буду использовать мой второй диск /dev/sdb, смонтированный в /mnt.
Вот что произойдет, если я попытаюсь запустить fsck на смонтированном разделе.
Чтобы избежать этого, размонтируйте раздел с помощью команды:
Теперь fsck можно запустить безопасно.
Понимание кодов выхода fsck
После запуска fsck она вернет код выхода. Эти коды можно увидеть в руководстве fsck, выполнив:
Исправление ошибок файловой системы Linux
Флаг -y автоматически даёт ответ "да" на любые запросы от fsck для исправления ошибок.
Точно так же вы можете запустить команду на всех файловых системах (без корневой):
Как запустить fsck в корневом разделе Linux
В некоторых случаях вам может потребоваться запустить fsck в корневом разделе вашей системы. Поскольку вы не можете запустить fsck на смонтированном разделе, вы можете попробовать один из следующих вариантов:
1. Принудительно использовать fsck при загрузке системы
2. Запустить fsck в режиме восстановления
Мы рассмотрим обе ситуации.
Принудительная проверка корневой файловой системы с помощью fsck при загрузке системы
Это относительно легко выполнить, единственное, что вам нужно сделать, это создать файл с именем forcefsck в корневом разделе вашей системы. Используйте следующую команду:
Во время следующей загрузки будет выполняться fsck. Если время простоя является критическим, рекомендуется тщательно спланировать эту проверку, так как если в вашей системе много используемых inode, fsck может занять некоторое, довольно значительное время.
После загрузки системы проверьте, существует ли этот файл:
Если он есть, вы можете удалить его, чтобы избежать запуска fsck при каждой загрузке системы.
Запуск fsck в режиме восстановления
Запуск fsck в режиме восстановления требует еще нескольких шагов. Сначала подготовьте систему к перезагрузке. Остановите все важные службы, такие как MySQL/MariaDB и т. д., а затем перезагрузите компьютер.
Во время загрузки удерживайте нажатой клавишу Shift, чтобы отобразилось меню grub. Выберите «Advanced options».
Затем выберите «Recovery mode».
В следующем меню выберите «fsck».
Вас спросят, хотите ли вы перемонтировать вашу корневую файловую систему. Выберите «yes».
Вы должны увидеть что-то похожее на это.
Затем вы можете вернуться к нормальной загрузке, выбрав «Resume».
Заключение
Из этого руководства вы узнали, как использовать fsck и выполнять проверки согласованности в разных файловых системах Linux. Если у вас есть какие-либо вопросы о fsck, пожалуйста, не стесняйтесь задавать их в разделе комментариев ниже.
Если вы следовали инструкциям по подготовке к разработке Ubuntu, всё должно быть уже готово к работе.
Как вы можете видеть на картинке выше, в процессе исправления ошибок в Ubuntu нет никаких сюрпризов: вы находите проблему, получаете код, исправляете его, тестируете, отправляете на Launchpad и просите, чтобы его проверили и объединили с основным кодом. В этом руководстве мы пройдем через все необходимые шаги, один за другим.
3.2. Поиск проблемы¶
Существуют различные способы найти, над чем можно поработать. Это может быть ошибка, которую вы обнаружили сами (что даёт вам отличную возможность проверить своё исправление) или проблема, которую вы заметили где-то ещё, например в отчёте об ошибке.
Take a look at the bitesize bugs in Launchpad, and that might give you an idea of something to work on. It might also interest you to look at the bugs triaged by the Ubuntu One Hundred Papercuts team.
Если вы не знаете, в каком пакете исходного кода содержится ошибка, но знаете путь к этому приложению в вашей системе, то вы сможете найти пакет исходного кода, над которым требуется поработать.
Команда выведет следующую информацию:
Команда apt-cache установлена в Ubuntu по умолчанию.
3.4. Подтверждение проблемы¶
Предположим, в описании пакета bumprace отсутствует информация о его домашней странице. В качестве первого шага, следует проверить, не исправлена ли уже эта ошибка. Сделать это просто: посмотрите в Центре приложений или запустите:
Вывод команды должен быть примерно следующим:
В качестве контрпримера можно привести gedit , где домашняя страница указана:
В некоторых случаях вы можете столкнуться с тем, что проблема, решение которой вы ищете, уже кем-то устранена. Чтобы избежать напрасной траты времени и труда, имеет смысл проделать кое-какую детективную работу.
3.5. Изучение ситуации с ошибкой¶
Ошибка, над которой мы работаем, необычна в том смысле, что она касается только пакетирования bumprace . Если бы это была ошибка в исходном коде, полезно было бы также проверить систему отслеживания ошибок апстрима. К сожалению, эта процедура часто различается для каждого отдельного пакета, но всегда можно воспользоваться поиском в интернете, и в большинстве случаев вы обнаружите, что она окажется не такой уж сложной.
3.6. Предложение помощи¶
Если вы обнаружили открытую ошибку, которая ещё никому не назначена, и вы готовы взяться за её устранение, следует написать комментарий с вашим решением. Включите в него как можно больше информации: При каких обстоятельствах появляется ошибка? Как вы её исправили? Тестировали ли вы свой способ устранения ошибки?
Будет замечательно, если вы можете предложить свою помощь, и она, несомненно, будет с готовностью принята.
3.7. Получение кода¶
Once you know the source package to work on, you will want to get a copy of the code on your system, so that you can debug it. The ubuntu-dev-tools package has a tool called pull-lp-source that a developer can use to grab the source code for any package. For example, to grab the source code for the tomboy package in xenial , you can type this:
If you do not specify a release such as xenial , it will automatically get the package from the development version.
3.8. Исправление ошибки¶
Есть целые книги о нахождении ошибок, их исправлении, тестировании и так далее. Если вы новичок в программировании, попробуйте исправлять лёгкие ошибки, такие как опечатки. Пытайтесь делать ваши изменения минимальными и чётко документировать ваши изменения и предположения.
Перед тем, как работать над ошибкой, убедитесь, что она не исправлена уже кем-то другим, и никто не занимается в данный момент её исправлением. Не помешает проверить следующие источники:
Система отслеживания ошибок апстрима (и Debian) — открытые и закрытые ошибки,
История версий в апстриме (или в новой версии) может содержать сведения об исправлении ошибки,
отчёты об ошибках и новые версии пакетов в Debian и других дистрибутивах.
You may want to create a patch which includes the fix. The command edit-patch is a simple way to add a patch to a package. Run:
Эта команда скопирует файлы, необходимые для сборки пакета, во временную директорию. Вы можете изменять эти файлы в текстовом редакторе или применять патчи из upstream, например:
После редактирования файла наберите exit или нажмите control-d , чтобы выйти из временной командной оболочки. Новый патч будет добавлен в debian/patches .
You must then add a header to your patch containing meta information so that other developers can know the purpose of the patch and where it came from. To get the template header that you can edit to reflect what the patch does, type this:
This will open the template in a text editor. Follow the template and make sure to be thorough so you get all the details necessary to describe the patch.
3.8.1. Документирование исправления¶
Очень важно документировать свои изменения в достаточной степени, чтобы разработчикам впоследствии не пришлось гадать, какими были основания и предпосылки сделанных вами изменений. Каждый пакет исходного кода Debian и Ubuntu включает в себя файл debian/changelog , в котором отслеживаются вносимые в пакет изменения.
Самый простой способ обновить его — это выполнить:
Эта команда добавит в файл шаблон записи и запустит редактор, в котором вы сможете добавить недостающую информацию. Вот пример этой записи:
Теперь давайте сфокусируемся на том, что должно содержаться в самой записи файла changelog. Очень важно задокументировать:
- Where the change was done.
- What was changed.
- Where the discussion of the change happened.
3.9. Тестирование исправления¶
Чтобы собрать тестовый пакет с вашими изменениями, выполните следующие команды:
This will create a source package from the branch contents ( -us -uc will just omit the step to sign the source package and -d will skip the step where it checks for build dependencies, pbuilder will take care of that) and pbuilder-dist will build the package from source for whatever release you choose.
In this case with bumprace, run this to view the package information:
As expected, there should now be a Homepage: field.
В большинстве случаев вам придётся действительно установить пакет, чтобы проверить правильность его работы. Наш случай намного проще. Если сборка завершилась успешно, готовые двоичные пакеты можно будет найти в
/pbuilder/<выпуск>_result . Установите их с помощью sudo dpkg -i <пакет>.deb или двойного щелчка на них в файловом менеджере.
3.10. Submitting the fix and getting it included¶
With the changelog entry written and saved, run debuild one more time:
and this time it will be signed and you are now ready to get your diff to submit to get sponsored.
In a lot of cases, Debian would probably like to have the patch as well (doing this is best practice to make sure a wider audience gets the fix). So, you should submit the patch to Debian, and you can do that by simply running this:
Эта команда проведёт вас через несколько шагов, необходимых для оформления отчёта об ошибке и отправки его в правильное место. Обязательно просмотрите ваши изменения, чтобы убедиться, что там нет ничего постороннего.
Коммуникация имеет очень большое значение, поэтому при добавлении описания предоставьте хорошее и дружественное объяснение.
It might be beneficial to just get it included in Debian and have it flow down to Ubuntu, in which case you would not follow the below process. But, sometimes in the case of security updates and updates for stable releases, the fix is already in Debian (or ignored for some reason) and you would follow the below process. If you are doing such updates, please read our Security and stable release updates article. Other cases where it is acceptable to wait to submit patches to Debian are Ubuntu-only packages not building correctly, or Ubuntu-specific problems in general.
In this case, debdiff the dsc you downloaded with pull-lp-source and the new dsc file you generated. This will generate a patch that your sponsor can then apply locally (by using patch -p1 < /path/to/debdiff ). In this case, pipe the output of the debdiff command to a file that you can then attach to the bug report:
The format shown in 1-1.0-1ubuntu1.debdiff shows:
- 1- tells the sponsor that this is the first revision of your patch. Nobody is perfect, and sometimes follow-up patches need to be provided. This makes sure that if your patch needs work, that you can keep a consistent naming scheme.
- 1.0-1ubuntu1 shows the new version being used. This makes it easy to see what the new version is.
- .debdiff is an extension that makes it clear that it is a debdiff.
While this format is optional, it works well and you can use this.
Once you have received a review, your patch was either uploaded, your patch needs work, or is rejected for some other reason (possibly the fix is not fit for Ubuntu or should go to Debian instead). If your patch needs work, follow the same steps and submit a follow-up patch on the bug report, otherwise submit to Debian as shown above.
3.11. Дополнительные замечания¶
Если вы можете внести в пакет несколько тривиальных исправлений сразу, сделайте это. Это позволит разработчикам быстрее рассмотреть и применить эти изменения.
Обнаружена ошибка в системной программе
Сообщить о проблеме разработчикам?
Хотя если вы не используете Ubuntu, вы точно никогда не столкнетесь с такой проблемой. В этой статье мы рассмотрим что же делать с уведомлением обнаружена ошибка в системной программе в Ubnutu 16.04 или других версий.
Что делать если возникла "обнаружена ошибка в системной программе"
Что это вообще значит?
Если в других дистрибутивах такая ошибка не наблюдается, это еще не значит что дистрибутив стабильнее и программы не падают. Просто там некому палить такое их поведение.
Как только я нажму сообщить о проблеме, она исчезнет?
Нет, не совсем. После того как вы нажмете на кнопку отправки отчета, вы получите следующее окно:
Утилита Apport соберет всю возможную информацию об ошибке, затем откроется браузер где вы сможете оформить отчет, используя свою или создав новую учетную запись Launchpad. Как вы видите это сложная процедура, которая займет около четырех шагов.
Кроме того, возможно, вы сможете решить проблему сами, если это не баг в программе, а ошибка, вызванная тем, что вы что-то неправильно установили. Посмотрите подробности (Show details) об ошибке в этом окне и попытайтесь сами или с помощью поисковых систем решить что с ней делать.
А если я хочу сообщить разработчикам о проблеме?
Вы предлагаете не сообщать о проблеме?
И да, и нет. Сообщите об ошибке когда увидите ее впервые если хотите. Информацию об ошибке вы можете увидеть, нажав кнопку Show details, как на картинке выше. Но если вы сталкиваетесь с ошибкой повторно и не можете ее решить или не хотите сообщать разработчикам советую вам избавиться от нее навсегда.
Исправляем проблему обнаружена ошибка в системной программе
Отчеты об ошибках хранятся в каталоге /var/crash. Если вы посмотрите содержимое этого каталога, можете увидеть там несколько файлов с данными о предыдущих ошибках.
Отчеты о сбоях лучше удалить, так как со временем они будут накапливаться и занимать дисковое пространство. Для этого выполните команду:
sudo rm /var/crash/*
Отключение Apport в Ubuntu
Вы можете отключить только утилиту, которая показывает вам уведомления, но оставить службу, собирающую данные в /var/crash работающей. Для этого выполните:
gsettings set com.ubuntu.update-notifier show-apport-crashes false
Для полного отключения Apport откройте терминал и введите команду:
gksu gedit /etc/default/apport
Вот содержимое этого файла:
Замените enable=1 на enable=0 и сохраните изменения. Теперь вы не увидите никаких отчетов о сбоях в программах. Программа не будет собирать отчеты об ошибках и вы о них никогда не узнаете. Если вы снова захотите видеть уведомления достаточно просто вернуть флаг enabled в положение 1.
Выводы
Надеюсь, эта статья помогла вам решить проблему обнаружена ошибка в системной программе Ubuntu 16.04. Конечно, это только косметическое решение, и от этого программа не перестанет аварийно завершаться, но большинство из нас обычные пользователи и мы не можем понять почему не работает та или иная программа. Нам остается только сообщить разработчикам, и отключить уведомления дабы они не мешали нормально работать.
Последнюю пару недель практически каждый раз при запуске Ubuntu встречал меня словами “system program problem detected”. Я игнорировал их, но спустя какое-то время мне это надоело. Вам также вряд ли понравится такое оповещение при каждом запуске системы:
Уверен, если вы работаете на Ubuntu, то наверняка встречались с подобным неудобством. В данной статье мы опишем, как справится с проблемой.
Так о чем же она говорит?
По сути она свидетельствует об ошибке в системе. Не переживайте из-за слова “ошибка”. Это не что-то критичное и система не перестанет работать. Просто как-то раз одна из программ плохо отработала и Ubuntu желает знать хотите ли вы об этом сообщить разработчикам, для того чтобы они могли улучшить систему.
То есть надо нажать на “Report problem” (“Cообщить об ошибке”) и никаких проблем?
Нет, не то чтобы. Даже если вы нажмете на вышеуказанную кнопку, то с этого момента оповещение будет таким:
Далее откроется браузер через который вы сможете, создав аккаунт Launchpad, сформировать отчет. Только вот это достаточно сложная процедура, состоящая из 4 шагов.
Но я хочу помочь разработчикам и сообщить об ошибке!
Это очень предусмотрительно и вообще правильно. Но тут есть две проблемы. Во-первых, велик шанс, что об ошибке уже известно. Во-вторых, сообщив об ошибке вы ее не исправите, а значит наверняка придется жить с ней какое-то время.
То есть ты рекомендуешь не сообщать об ошибке?
Да и нет. Если вы видите ошибку впервые, то при желании о ней можно сообщить. Сломанную программу можно посмотреть под “Show Details”. Если же ошибка все не исчезает, а нервов уже никаких нет, то я рекомендую избавить от нее раз и навсегда.
Можно посмотреть данный ролик с решением. Так же рекомендуем подписаться на YouTube канал авторов.
Отчеты об ошибках в Ubuntu хранятся по пути /var/crash. Если вы пройдете по указанному пути, то найдете ряд файлов, которые оканчиваются на crash.
Я рекомендую удалить эти отчеты. Откройте терминала и исполните эту команду:
Это удалит все, что находится в указанной директории. С этого момента надоедливые оповещения вас больше беспокоить не будут. Если одна из программ снова сломается, то вы снова увидите оповещение. Вы можете снова удалить отчеты или можете отключить Apport (дебаг средство) и навсегда избавиться от оповещений.
Если вы решите так поступить, то больше система не будет оповещать вас о каких-либо произошедших в ней неполадках. Как по мне, так это не плохой вариант, если ты только вы целенаправленно не занимаетесь их отловом. Если никакого желания заниматься ими нет, то отсутствие подобных оповещений сильно ничего не изменит.
Для того чтобы отключить Apport и избавить от отчетов об ошибках совсем откройте терминал и используйте данную команду:
Измените enabled=1 на enabled=0. Сохраните и закройте файл. После этого больше не будет оповещений об отчетах об ошибках. Очевидно, что для того, чтобы их обратно включить, надо вернуться в тот же файл и там же изменить 0 на 1.
Надеюсь данный туториал помог вам с оповещением “обнаружена ошибка в системной программе”. Дайте знать в комментариях помогли ли советы или нет.
Читайте также: