Debian ошибка ввода вывода

I found my server can’t run any command, and it shouws «input output error»

The error code EIO («Input/output error») on command launch would happen when your filesystem is damaged; or worse, when you are running on a faulty storage.

Cross your fingers; either way, be aware that at this point you should NOT try to power on the server unless really necessary.¹

The Test

There is one sure-fire way to distinguish between two root causes: conduct block-level read scan on the system, and watch out for kernel messages.

1. Boot your system with GNU/Linux recovery boot disk.
2. Change the system to the plain old text console (press Ctrl+Alt+F1); don’t use graphical terminal for this.
3. Login as root.
4. Run dmesg -E to enable live kernel message display on the console.
5. Run dmesg -n debug to let low-level kernel message though.
6. Run blkid to see which disk contains system partition. (Note that blkid will list partitions; strip number off the end of partition path and you will get the disk)
7. Run time -p dd if=/dev/sda of=/dev/null bs=4M to conduct an entire-disk read test (please type this carefully). If your system disk is not /dev/sda, substitute accordingly.
8. Watch the screen (it will take a long while)…

Results

• In the best case where dd completed successfully and uneventfully, then it is likely a filesystem problem.

  • If you are comfortable doing filesystem check from boot disk, you can do it now (recommended).
  • If you would rather let the system sort it by itself, reboot (also remove the boot disk), and boot your usual system but with fsck.mode=force appended to the end of kernel command line. (See this question for details)
  • Discussing the result of filesystem check will warrant a different question though.

• However, in the worst case, you would see kernel messages like this spewing on the screen:

  ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
  ata2.00: irq_stat 0x40000001
  ata2.00: failed command: READ DMA EXT
  ata2.00: cmd 25/00:08:78:15:c5/00:00:6c:00:00/e0 tag 0 dma 4096 in
           res 51/40:00:78:15:c5/00:00:6c:00:00/e0 Emask 0x9 (media error)
  ata2.00: status: { DRDY ERR }
  ata2.00: error: { UNC }
  ata2.00: configured for UDMA/100
  sd 1:0:0:0: [sda] Unhandled sense code
  sd 1:0:0:0: [sda]  
  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
  sd 1:0:0:0: [sda]  
  Sense Key : Medium Error [current] [descriptor]
  Descriptor sense data with sense descriptors (in hex):
          72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
          6c c5 15 78 
  sd 1:0:0:0: [sda]  
  Add. Sense: Unrecovered read error - auto reallocate failed
  sd 1:0:0:0: [sda] CDB: 
  Read(10): 28 00 6c c5 15 78 00 00 08 00
  end_request: I/O error, dev sda, sector 1824855416
  Buffer I/O error on device sda, logical block 228106927
  ata2: EH complete
  

  Look for the key parts:

  • DRDY, ERR and UNC in braces
  • Medium Error status
  • Unrecovered read error sense message

  If you glanced and find these in the messages (even once), they show that you are facing physical disk error.

  When this is the case, don’t let dd finish, press Ctrl+C to stop, NOW; shut down your system, and bring your disk to a data recovery shop you trust.

• If you did not find the above worst-case telltales, and rather found this kind of kernel messages repeated:

  ata2: exception Emask 0x10 SAct 0x0 SErr 0x4040000 action 0xe frozen
  ata2: irq_stat 0x00000040, connection status changed
  ata2: SError: { CommWake DevExch }
  ata2: hard resetting link
  ata2: link is slow to respond, please be patient (ready=0)
  

  Key parts:

  • hard resetting link
  • link is slow to respond

  Then you are rather facing SATA link problem (e.g. bad cabling): press Ctrl+C to stop, shut down your system, fix your disk cable and connection, and try again.

Side Notes

And I made a smartctl test to confirm if there is any promblem with hard disk. And it passed without error.

Beware that some hard disks tell straight lies in their S.M.A.R.T status (I’m looking at you, Toshiba); my previous laptop hard disk just ground to halt when reading, spewing read errors, and it still said «nothing’s wrong» in its status registers.

If your server is mission-critical, then you should consider RAID-based setup.

• ¹ Cautionary tale: My housemate once ignored this warning, and keep filesystem checker grinding on his desktop system anyway. He didn’t wait for me to check it up until it eventually failed to boot. Once I got a chance to check it, the disk damage had been already beyond recover (the 500 GB disk could only barely read at snail-pace KB/s, and there was no significant continuous readable area found even after several days).

  On the other hand, in another case with the same symptom, the machine owner heeded my warning and left the thing off until I could check it. Of course, it was a hard disk failure. After half a day of GNU DDRescue session and one new hard disk, I brought a good news to him that his system and data was 100% recovered at block level- i.e. all files intact, and ready to boot again without any modification.

0

0

/mnt/data1# ls
ls: чтение каталога .: Ошибка ввода/вывода
/mnt# umount /mnt/data1
umount: /mnt/data1: device is busy

/mnt# mount /mnt/data1/
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so
 /mnt#  dmesg | tail
[17460448.112039] sd 1:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
[17460448.112047] end_request: I/O error, dev sdb, sector 12361
[17460448.112080] Buffer I/O error on device sdb1, logical block 1545
[17460448.112109] lost page write due to I/O error on sdb1
[17460454.396189] sd 1:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
[17460454.396189] end_request: I/O error, dev sdb, sector 3
[17460454.400189] EXT3-fs: unable to read superblock
[17460495.935851] sd 1:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
[17460495.935851] end_request: I/O error, dev sdb, sector 3
[17460495.935851] EXT3-fs: unable to read superblock

Ошибка при получении информации о файле «X.txt»: Ошибка ввода/вывода. Неожиданная ошибка: Ошибка при получении информации о файле «X.txt»: Ошибка ввода/вывода

Опишем окружение в котором возникла ошибка ввода/вывода:

• ОС: Linux совместно с Windows
• HDD: два диска, на одном Windows XP (далее ДИСК 1), на другом Linux Debian 7.x (далее ДИСК 2)

Каждый диск разбит на два раздела, — на диске с Windows XP два раздела с файловой системой NTFS, на втором диске с Linux Debian 7.x один раздел EXT4, на котором и установлен Linux, а на втором собственно NTFS. Окружением для рабочего стола Linux было выбрано Xfce, файловый менеджер по умолчанию Thunar 1.2.3 (Thunar это быстрый и простой в использовании файловый менеджер для рабочего окружения Xfce.), текстовый редактор gedit.

Ошибка ввода/вывода появилась на ДИСК 2 в разделе с файловой системой NTFS, который монтировался вручную после входа в уч. запись Linux.

Когда именно появилась Ошибка ввода/вывода на NTFS разделе сказать сложно, но предположительно после очередного переключения между ОС. На ДИСК 2 были расположены совместно редактируемые файлы, — т.е. эти фалы (Test.txt один из них) были открыты в текстовом редакторе notepad++ под ОС Windows XP и в текстовом редакторе gedit под Linux Debian 7.x. Перед переключением между ОС каждая ОС переводилась в спящий режим с сохранением запущенных программ и открытых файлов.

Иногда выполнялась перезагрузка ОС Linux Debian 7.x, но ОС Windows XP всегда переводилась в спящий режим, при этом после перезагрузки Linux Debian 7.x восстанавливалась сессия запущенных на момент перезагрузки/выключения программ, в том числе и редактора gedit с совместно редактируемым Test.txt. Потому как раздел NTFS с ДИСК 2 монтировался вручную, то после перезагрузки в gedit был открыт Test.txt с сообщением об ошибке доступа, но после ручного монтирования NTFS раздела редактор gedit предлагал обновить файл по причине его изменения.

Не скажу, как и почему стала появляться Ошибка ввода/вывода, — возможно gedit попутал uid/gid (файловые/индексные дескрипторы) и при сохранении в Master File Table (MFT) прописал не то, не тем и не туда, но вот, что получилось после очередного переключения между ОС при совместном редактировании файлов:

Попытка открыть каталог «/media/SATA2/PROFILE/User/Рабочий стол» в Thunar:

Не удалось открыть папку: «Рабочий стол».
 
Ошибка при получении информации о файле «/media/SATA2/PROFILE/User/Рабочий 
    стол/Test.txt»: Ошибка ввода/вывода.

Остальное содержимое каталога было не доступно для просмотра/редактирования

Попытка сохранить уже открытый в gedit текстовый файл Test.txt:

Не удалось сохранить файл /media/SATA2/PROFILE/Use…бочий стол/Test.txt.
 
Неожиданная ошибка: Ошибка при получении информации о файле «/media/SATA2/ 
    PROFILE/User/Рабочий стол/Test.txt»: Ошибка ввода/вывода

При использовании файлового менеджера NAUTILUS удалось открыть каталог /media/SATA2/PROFILE/User/Рабочий стол и удалить «Test.txt«, но вот создать заново Test.txt или создать «Безымянный документ» и переименовать его в «Test.txt» не удалось:

Не удалось переименовать объект.
 
Не удалось переименовать объект «Безымянный документ» в «Test.txt»: Произошла 
    ошибка при переименовании файла: Ошибка ввода/вывода

Следующий глюк сопутствовал Ошибкам ввода/вывода, но вот при каких условиях возник не припомню (вероятно при нескольких одновременных попытках монтирования):

Не удалось подключить «SATA2».
 
DBus error org.gtk.Private.RemoteVolumeMonitor.Failed: An operation is already 
    pending.

Владелец и права на файл Test.txt не известны:

root@linux:/media/SATA2/PROFILE/User/Рабочий стол# ls -la
ls: невозможно получить доступ к Test.txt: Ошибка ввода/вывода
итого 4415
drwx------ 1 User User   12288 Сен  2 22:21 .
drwx------ 1 User User    8192 Авг 18 07:48 ..
-rw------- 1 User User    1830 Сен  2 11:56 Test_2.txt
-rw------- 1 User User    3722 Сен  2 21:22 Test_3.txt
-????????? ? ?      ?            ?            ? Test.txt

В некоторых манах для лечения предлагалось использовать ntfsfix -b /dev/sdb5, предварительно отмонтировав его, — но проблема не решилась…

В среде Linux на ДИСК 2 были созданы текстовые файлы «Test_2.txt» и «Test_3.txt» и совершено переключение на Windows XP где эти файлы были не доступны даже для просмотра, хотя после перехода обратно в Linux их можно было просматривать и редактировать…

Проблему с косяком в NTFS разделе на ДИСК 2 удалось решить только с помощью стандартного средства проверки дисков входящего в ОС Windows XP в процессе перезагрузки:

CHKDSK is verifyng indexes (stage 2 of 5)
 
    Deleting index entry .Trash-1000 in index $I30 of file 5
    Deleting index entry Test.txt in index $I30 of file 702196
    Deleting index entry Test_2.txt in index $I30 of file 702196
    Deleting index entry Test_3.txt in index $I30 of file 702196

Увидев на экране Deleting index entry … я зразу же понял, что этих файлов нам уже не видать как своих ушей, — разумеется, так и есть.

Вероятно (http://ru.wikipedia.org/wiki/NTFS#Linux) поддержка NTFS в Linux осуществляется при помощи ntfsmount (использующая FUSE), которая позволяет монтировать NTFS-разделы на запись, но с некоторыми ограничениями.

Существует также ещё один способ монтирования NTFS с возможностью чтения/записи, — это Проект NTFS-3G, который по заявлениям является более функциональным и стабильным вариантом (также использующий FUSE) дающий более широкие возможности по созданию/изменению/удалению/перемещению файлов (исключая сжатые и зашифрованные файлы) в файловой системе NTFS. В тоже время тесты показывают, что NTFS-3G не оптимизирован для производительности, а разработчики заявляют, что это связано с обеспечением повышенной надёжности и, что производительность является второстепенной задачей.

Никто не застрахован от возникновения каких-то ошибок на разделах с файловой системой NTFS или же вовсе полного краха таких разделов с необходимостью полного форматирования. Поэтому, при использовании Linux лучше вовсе не использовать NTFS разделов, или же использовать их как можно реже.

Основные причины ошибок ввода/вывода

• Значит это всё масонский заговор дядюшки Билла… На буржуйских веб-ресурсах бродит информация о том, что стандарт NTFS меняется в каждой новой версии Windows, что вполне предсказуемо, включая сервис-паки и промежуточные патчи. При этом, разумеется, изменения не придаются общественной огласке, а следовательно нет возможности в полной мере обеспечить стабильную работу с NTFS в свободных ОС таких как Linux.
• Отмечено также, что на разделах NTFS возможно изменение уже существующих файлов с незначительным изменением их размера, но при создании новых файлов или существенного изменения уже существующих может вызвать проблемы и даже «запороть» весь раздел.
• Проблемы с отображением созданных в Linux на NTFS разделе файлов, а также проблемы с ошибками ввода/вывода, могут возникнуть если на ПК установлено несколько ОС (ака Мультизагрузка, Multi-boot), — Windows vs Linux. Пик ошибок ввода/вывода отмечен когда Windows была переведена в спящий режим, а после очередного включения запущен Linux из-под которого на NTFS разделе создавались/редактировались файлы. Другими словами если мы хотим из-под ОС Linux, в условиях мультизагрузки (Multi-boot), относительно безопасно создавать/редактировать файлы на NTFS разделах совместно используемых обеими ОС, то перед запуском ОС Linux мы должны выполнить полную перезагрузку или остановку ОС Windows, но не в коем случае не переводить Windows в спящий режим!
• SRT-кэширование (Smart Response Technology) — ещё одна «фича», которая может стать причиной невидимости из-под Windows на NTFS разделах файлов, которые создавались в Linux. Предположительно Linux не поддерживает SRT-кэширование (касается только SSD дисков), которое поддерживает Windows, а значит при создании из-под Linux-а файлов на SSD дисках с активным SRT-кэширование кэш не обновляется и после загрузки Windows файлов не обнаруживается. Предлагается отключить SRT-кэширование для SSD диска.

Тема использования NTFS в Linux является довольно актуальной, требует более подробного изучения и дополнительных экспериментов. О появлении новых багов, в ходе использования NTFS разделов в Linux, и, способов их решения, — будем дописывать в этой же статье…

Bizdelnick писал(а): ↑

04.07.2017 12:43

Dremlin.09 писал(а): ↑

04.07.2017 12:36

[Errno 30] Read-only file system

Этого мало. Непонятно, что пытался в этот момент сделать инсталлятор, и о какой вообще файловой системе идёт речь.

ри установке ОС (linux) выдает ошибку вводавыводазаписи . вроде как не достаточно прав. Форточки встают на ура. Куда копать?

С флешки то же самое.

Бэдов нет. ФС — EXT4

runtu@runtu:~$ sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present

***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************

Началось после того, как linux mint свалился

не устанавливается ни один NIXовый дистрибутив

Ошибка—
Возникла проблема при копировании файлов на жёсткий диск:

[Errno 30] Read-only file system

Это часто происходит из-за неисправности CD/DVD диска, привода, или жёсткого диска. Возможно поможет очистка CD/DVD диска, либо запись CD/DVD на более низкой скорости, либо очистка линз CD/DVD привода (соответствующие комплекты для очистки доступны в продаже), возможно жёсткий диск уже очень старый и нуждается в замене, либо необходимо переместить оборудование в более проветриваемое место.

В данный момент ОС Runtu 14.04
live CD
Хард рабочий 100%