Ошибка EXT4-fs после обновления Ubuntu 17.04
У меня Dell XPS 15 9550. Я запускаю Ubuntu 16.10 на нем четыре месяца без драм.
Два дня назад я обновился до Ubuntu 17.04. Примерно через час после обновления мой жесткий диск перешел в режим только для чтения. Когда я прыгнул на tty экран, это появилось:
Вот что fdisk -l показывает:
Я перезагрузился и продолжал получать ошибку примерно раз в час. Поэтому я переустановил Ubuntu 17.04 с нуля. Однако я все еще получаю ту же проблему.
Я попытался запустить fsck, создав файл /forcefsck (я создал сценарий оболочки оболочки, который добавляет -v флаг и выводит стандартный вывод в файл). Вот результат:
Я попытался загрузить с живого USB и работает e2fsck -p /dev/nvme0n1p7 как предложено здесь ( /questions/34413/soobschenie-ob-oshibke-oshibka-ext4-fs-ext4findentry-1451/34426#34426). Это не дало никаких ошибок.
Я тоже пытался бежать smartctl -t long /dev/nvme0n1p7 однако результаты показывают, что инструмент не работает с моим конкретным SSD:
Любая идея о том, почему эта проблема может возникать и как я могу решить ее? Спасибо!:)
3 ответа
Из сообщения об ошибке:
Поддержка APST только что появилась в последнем ядре Zesty (4.10.0-14.16) как часть https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664602. Этот патч имеет причуду для некоторых 256-гигабайтных дисков Samsung, которые можно найти в ноутбуках Dell, которые плохо работают при включенном APST. Я испытываю те же симптомы с ноутбуком той же модели, за исключением Samsung 512 ГБ. Перед ручным отключением APST диск погибнет, и система загорится с ошибками ввода-вывода в течение 20-40 минут после загрузки.
До тех пор, пока не будет выполнено правильное исправление, предлагается обходной путь, который включает добавление параметра ядра:
Пожалуйста, попробуй nvme_core.default_ps_max_latency_us=5500 Если проблема не устранена, попробуйте nvme_core.default_ps_max_latency_us=200 ,
Чтобы добавить параметр загрузки ядра, отредактируйте файл конфигурации для GRUB:
Найдите начало строки GRUB_CMDLINE_LINUX_DEFAULT и добавьте параметр загрузки к другим уже между кавычками. Например, в этом случае вы, вероятно, в конечном итоге
Сохраните файл и выйдите, затем, чтобы изменения вступили в силу, запустите
Источник
Ошибка EXT4-fs после обновления Ubuntu 17.04
У меня Dell XPS 15 9550 . Я запускаю Ubuntu 16.10 на нем четыре месяца без драм.
Два дня назад я обновился до Ubuntu 17.04 . Примерно через час после обновления мой жесткий диск перешел в режим только для чтения. Когда я прыгнул на tty экран, это появилось:
Вот что fdisk -l показывает:
Я перезагрузился и продолжал получать ошибку примерно раз в час. Поэтому я переустановил Ubuntu 17.04 с нуля . Однако я все еще получаю ту же проблему.
Я попытался запустить fsck, создав файл / forcefsck (я создал сценарий оболочки-оболочки, который добавляет -v флаг и выводит stdout в файл). Вот результат:
Я попытался загрузить с живого USB и запустить, e2fsck -p /dev/nvme0n1p7 как предложено здесь ( /ubuntu//a/768813/679041 ). Это не дало никаких ошибок.
Я также попытался запустить, smartctl -t long /dev/nvme0n1p7 однако результаты показывают, что инструмент не работает с моим конкретным SSD:
Любая идея о том, почему эта проблема может возникать и как я могу решить ее? Благодарность! 🙂
Из сообщения об ошибке:
Поддержка APST только что появилась в последнем ядре Zesty (4.10.0-14.16) как часть https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664602 . Этот патч имеет причуду для некоторых 256-гигабайтных дисков Samsung, которые можно найти в ноутбуках Dell, которые плохо работают при включенном APST. Я испытываю те же симптомы с ноутбуком той же модели, за исключением Samsung 512 ГБ. Перед ручным отключением APST диск погибнет, и система загорится с ошибками ввода-вывода в течение 20-40 минут после загрузки.
До тех пор, пока не будет выполнено правильное исправление, предлагается обходной путь, который включает добавление параметра ядра :
Пожалуйста, попробуйте nvme_core.default_ps_max_latency_us=5500 , если проблема не устранена, попробуйте nvme_core.default_ps_max_latency_us=200 .
Чтобы добавить параметр загрузки ядра, отредактируйте файл конфигурации для GRUB:
Найдите начало строки GRUB_CMDLINE_LINUX_DEFAULT и добавьте параметр загрузки к другим уже между кавычками. Например, в этом случае вы, вероятно, в конечном итоге
Сохраните файл и выйдите, затем, чтобы изменения вступили в силу, запустите
Источник
Сообщения «EXT4-fs error (device dm-2): . » и другое
Нужны телепаты. Про что последние сообщения об ошибках?
Систему я ССЗБ уже полностью сломал, больше показать нечего.
На сетевые юниты не обращайте внимания — включил без ethernet-адаптера.
Контекст: переустановил Debian, разметил LVM поверх DM-Crypt, первый раз загрузился удачно, потом systemctl reboot и вот.
Ну и чтобы два раза не вставать:
- Какого [censored] debian-installer в GPT из моего protective MBR сделал hybrid?
- Как посмотреть время последнего монтирования ntfs? Есть в метаданных ФС такое?
Лор, ты чего не отвечаешь?
А в гугле тебя забанили? Так вот в гугле советуют fsck задействовать.
А в гугле тебя забанили? Так вот в гугле советуют fsck задействовать.
Мне интересно, что было на данном этапе? Крах файловой системы? Почему он мог случиться?
А fsck я использовал, но это было уже потом, когда я не дождался окончания загрузки и перезагрузил по питанию. Попытка починить ФС оказалась неудачной, но здесь я ССЗБ и об этом не спрашиваю.
Ну и на два последних вопроса тоже хотелось бы получить ответы. Моего умения гугл-фу не хватает.
На два последних вопроса я тебе тоже ничего не подскажу.
На моём ноуте dm-crypt постоянно тормозит процесс остановки системы. Т.е. если шифрование не используется система останавливается/ребутится стремительным домкратом, 3 секунды и питание отключается, если шифрование используется — система висит по 20-30 секунд, прежде чем отключается питание. Эти 20-30 сек всегда напрягают т.к. думается, что там что-то не может нормально отмонтироваться а питание вот прям сейчас отрубиться. Может у тебя именно это и произошло? Знаешь, я не настоящий телепат.
Если кому-нибудь ещё интересно, задал последние два вопроса здесь:
На моём ноуте dm-crypt постоянно тормозит процесс остановки системы
Полезное замечание, спасибо. А у меня система после systemctl reboot остановилась очень быстро — хорошо, если из-за скорости PCIe SSD, но может быть что-то пошло нет так.
Источник
Стали появляться проблемы с диском.
Уже второй раз (первый был несколько дней назад) возникают ошибки ФС и диск перемонтируется в ро:
Сам я в этом смарте ничерта не понимаю:
После перезагрузки система не грузится и просит fsck. После проверки начинает работать нормально.
UPD: Проблема проявляется на всех ядрах от 4.15 до 4.19 включительно.
Пока всегда только с диском /dev/sda2 (но он и используется интенсивнее). На данный момент диски смонтированы так:
Сервис Lenovo с помощью встроенного тестировния выявил неисправность планки RAM, которую надо сказать к чести Lenovo заменили в течении недели у меня на дому и мне даже не пришлось никуда ехать.
Тест железа встроенный прогнал 4 раза — никаких ошибок ниразу не вылезло. Следующим этапом по совету сервисника обновил BIOS (была и правда очень старая версия). Потом скачал SanDisk Dashboard и проверил диск им (пришлось венду на флэшку ради этого вкорячить), в том числе расширенное тестирование SMART. Прошивка диска последняя.
UPD:
С момента переустановки прошел месяц. Полет нормальный. Нужно констатировать следующее — источником проблем стала оперативная память, что привело к повреждению данных записываемых на диск, а это в свою очередь повлекло все остальные последствия. Считаю что сервис Lenovo отработал оперативно — от момента обращение в чат, на сайте производителя, до замены планки памяти прошло 6 дней. Учитывая погодные условия и то что я не в ДС считаю это хорошей реакцией + мне не пришлось никуда ехать — специалист СЦ, приехал для выполнения работ ко мне, в тот же день когда в СЦ поступила деталь, не смотря на то, что к этому времени рабочий день уже завершился.
Источник
Linux ext4 fs error
The most terrible thing a Linux could have may be some errors reported by the file system. It is usually caused by power outages or bad blocks/sectors within the hard drive. Eventually, as a Linux user, you may at least have suffered from file system errors once, where you have to reinstall the OS and for sure to lose all the existing data. This post is the summary of the recent file system errors happened on my Fedora 20. May give some hints.
0. File system errors seem to be inevitable
There was sth wrong with my Fedora 20 after a recent kernel update to 3.14.4. After megasas kernel module (a kernel module for LSI RAID cards) init’d, the whole system fell into emergency mode (single user mode). However, a manually CTRL-D would force the system going into the normal mode. I hunted for the changes of megasas which has been stable for years. Then I was looking forward to the next kernel release which may fix this weird issue. Interestingly, things were getting more weird.
After a ‘ yum clean all ‘ (trying to fix the broken dependency but not working anyway), I was not able to run ‘yum update’ anymore, always with the same error from Python: OSError [Errono 5]: Input/Output error . Tried to reboot the system and rebuild the yum cache manually but still got the same error. While I was wondering what happened within yum, there was sth going wrong within my file system.
1. Use tools to figure out what happens
1.1 dmesg
Please do use this powerful tool to check kernel’s complain and I found sth like below:
May 23 08:28:29 daveti kernel:EXT4-fs (dm-0): warning: mounting fs with errors, running e2fsck is recommended
May 23 08:28:29 daveti kernel:EXT4-fs (dm-0): re-mounted. Opts: (null)
May 23 08:28:29 daveti systemd: Started Remount Root and Kernel File Systems.
May 23 08:28:29 daveti systemd: Starting Configure read-only root support…
May 23 08:28:29 daveti systemd: Starting Import network configuration from initramfs…
May 23 08:28:29 daveti systemd: Starting Load/Save Random Seed…
May 23 08:28:29 daveti systemd: Starting Local File Systems (Pre).
May 23 08:28:29 daveti systemd: Reached target Local File Systems (Pre).
May 23 08:28:29 daveti systemd: Started Load/Save Random Seed.
May 23 08:28:29 daveti systemd: Started Configure read-only root support.
May 23 08:28:29 daveti systemd: Started Import network configuration from initramfs.
May 23 08:28:29 daveti systemd: Starting Emergency Shell…
May 23 08:28:29 daveti systemd: Started Emergency Shell.
May 23 08:28:29 daveti systemd: Starting Emergency Mode.
May 23 08:28:29 daveti systemd: Reached target Emergency Mode.
May 23 08:28:29 daveti systemd-fsck: /dev/sda1: clean, 410/128016 files, 244603/512000 blocks
May 23 08:28:29 daveti systemd: Started File System Check on /dev/mapper/fedora_dyn–184–171–61–7-home.
May 23 08:28:29 daveti systemd: Started File System Check on /dev/disk/by-uuid/c96cf320-40a7-42d5-9406-bf80c866faa6.
May 23 08:28:29 daveti systemd: Mounting /boot…
May 23 08:28:29 daveti systemd: Mounting /home…
May 23 08:33:08 daveti kernel:[ 301.924281] EXT4-fs (dm-0): error count: 45
May 23 08:33:08 daveti kernel:[ 301.924299] EXT4-fs (dm-0): initial error at 1400170854: __ext4_get_inode_loc:3919: inode 2238830: block 8913590
May 23 08:33:08 daveti kernel:[ 301.924307] EXT4-fs (dm-0): last error at 1400799080: __ext4_get_inode_loc:3919: inode 2238830: block 8913590
May 23 08:33:08 daveti kernel:EXT4-fs (dm-0): error count: 45
May 23 08:33:08 daveti kernel:EXT4-fs (dm-0): initial error at 1400170854: __ext4_get_inode_loc:3919: inode 2238830: block 8913590
May 23 08:33:08 daveti kernel:EXT4-fs (dm-0): last error at 1400799080: __ext4_get_inode_loc:3919: inode 2238830: block 8913590
What does this tell us? First, it tells my file system (EXT4) screws. Second, it tells the reason why the system falling into emergency mode (because of file system errors). Last, it tells some screwed inode operations.
1.2 smartctl
If your hard drive support SMART, try ‘ smartctl -a /dev/yourDevice ‘. Mine’s not. Let me know if this tool helps.
1.3 badblocks
This tool is used to see if there is any bad blocks within the drive – ‘ badblocks /dev/yourDevice ‘. NOTE, first it does NOT fix these bad blocks and second nothing from badblocks does not mean the file system in a good state. Again, dmesg!
2. Rescue mode?
We probably all know the right solution for this case – umount the bad disk and run fsck! The point is how to do that if you are not able to umount the disk even in single user mode when the root file system is screwed. If you have a second machine, you can unplug the issued hard drive and plug it into the other machine and run fsck there. If not, what else shall we do?
It is said that most Linux distribution installation ROMs have the so-called rescue mode where you can try to fix issues on the current system. I tried Fedora 20 live DVD and booted into ‘Try’ mode where a live image is loaded into the memory as the active OS. Unfortunately, I am still not able to umount the root file system for certain reasons.
3. Workaround
Fortunately, I have got a Ubuntu 14.04 LTS live DVD ROM. Booting from this system, I am able to umount all the partitions and run ‘ fsck -yvf /dev/yourPartition ‘ to fix all the bad blocks. After a reboot, my Fedora 20 runs smoothly into the Gnome login.
4. At last
File system errors may be inevitable for Linux (and eventually for all OSes). Once it happens, try to fix it ASAP. While I was trying to figure out how to umount the root file system, the number of errors (bad blocks) reported by EXT4 was increasing indeed! And please UMOUNT your disk/partition before fsck , otherwise you will hate Linux…
Источник
