Ошибка ввода вывода флешка linux

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1]   Вверх

Linux и NTFS: Ошибка ввода/вывода

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендуемый контент

А тут же ж мог быть рекомендуемый контент от гугла 🙂 Для отображения рекомендуемого контента необходимо в браузере разрешить выполнение JavaScript скриптов, включая скрипты с доменов googlesyndication.com и doubleclick.net

Вы не любите рекламу!? Напрасно!:) На нашем сайте она вовсе ненавязчивая, а потому для нашего сайта можете полностью отключить AdBlock (uBlock/uBlock Origin/NoScript) и прочие блокировщики рекламы! AdBlock/uBlock может препятствовать нормальной работе системы поиска по сайту, отображению рекомендуемого контента и прочих сервисов Google. Рекомендуем полностью отключить блокировщик рекламы и скриптов, а также разрешить фреймы (aka iframe).

Источник

Исправление ошибки «Запрос не был выполнен из-за ошибки ввода/вывода на устройстве» при подключении флешки

Почему появляется сбой ввода-вывода и как его устранить

Появление этого сообщения говорит о наличии проблемы либо аппаратной, либо программной. Если с аппаратной причиной все предельно ясно (выходят из строя ячейки памяти), то с программными неполадками не все так однозначно. Поэтому прежде чем приступать к одному из методов устранения неисправности, следует проверить вашу флешку одним из предложенных в этой статье способов. Затем, в зависимости от полученных результатов, выбирайте подходящий вариант решения.

Способ 1: Форматирование в другую файловую систему (потеря данных)

Одна из наиболее частых причин появления проблемы с вводом-выводом на флешке — сбой файловой системы. Происходит такое по множеству причин: некорректное извлечение, деятельность вирусов, ошибки в операционной системе и т. д. Самым простым решением такого рода проблемы является форматирование носителя, желательно в другую файловую систему.

Внимание! Данный способ сотрет все данные, которые хранятся на флешке! Если вы хотите сохранить файлы, обратите внимание на способы 2 и 3!

Затем подключите накопитель заново. Проблема будет решена.

Самый простой способ не всегда самый подходящий – например, пользователям, желающим сохранить свои файлы, он не поможет.

Способ 2: Создание образа флешки и последующее форматирование (сохранение данных)

В большинстве случаев, наблюдая сообщение об ошибке ввода-вывода на флешке, вы не сможете получить доступ к хранящимся на ней данным обычными средствами. Однако существует способ, который поможет спасти хотя бы часть файлов — это создание образа флешки: виртуальной копии структуры файловой системы и всей информации на ней. Один из простейших методов создать образ – использовать утилиту HDD Raw Copy Tool.

Этот способ более сложный, однако в его случае вероятность сохранить файлы очень высока.

Способ 3: Восстановление флешки посредством утилиты chkdsk

В системе Windows присутствует утилита командной строки chkdsk, которая способна помочь справиться с проблемой появления ошибки ввода-вывода.

Этот способ тоже не представляет собой ничего сложного, однако среди остальных он реже всех помогает.

Если все описанные выше способы не дают результата, вероятнее всего, вы столкнулись с физической неисправностью накопителя: механическим повреждением, выходом из строя части блоков памяти или проблемами с контроллером. В таком случае, если на нем хранились критично важные данные, посетите сервисный центр. Кроме того, вам могут помочь инструкции по восстановлению работоспособности для специфичных производителей: Kingston, Verbatim, A-Data, Transcend.

Помимо этой статьи, на сайте еще 12342 инструкций.
Добавьте сайт Lumpics.ru в закладки (CTRL+D) и мы точно еще пригодимся вам.

Отблагодарите автора, поделитесь статьей в социальных сетях.

Источник

Проблема с копированием файла на флеш-карту

Все просто, скачал образ с игрой для ps3, весит он 8 гигов. Копирую его на флешку, и линукс уже не может это осилить.

В общем и сам вопрос. Почему я не могу совершить элементарную операцию по копированию файлов? Ошибка, что я получаю http://joxi.ru/L21Ko1YhgwOMNr

Если что, я ламер, который установил линукс пару лет назад, чтобы познать эту систему.

Так же проблема появлялась и ранее, когда файл гига на 4 копировался минут 10-15. Это реально боль какая-то. При старте копирования скорость максимально высокая, а с каждой секундой все меньше и меньше. Уже находил подобные темы на этом форуме, но как-то они мне не помогли

Файловая система на носителе не FAT случаем?

Какая ФС на флешке?

У FAT32 ограничение — более 4 гибибайт файлы в принципе не поддерживаются. В новых версиях Windows флешки потому по умолчанию форматируют или в NTFS, или в exFAT.

Если флешка только под Linux, можешь ext4 использовать на ней.

Я даже больше скажу: нтфс имеет смысл использовать ТОЛЬКО если предпологаеться использование ее для обмена файлами с компьютером под управлением винды.

Вероятно, да. Под macOS можно флешку в HFS+ отформатировать — Linux умеет и с этой ФС работать.

Источник

Использование утилиты fsck для исправления ошибок файловой системы в Linux

Оригинал: How to Use ‘fsck’ to Repair File System Errors in Linux
Автор: Marin Todorov
Дата публикации: 1 октября 2018 года
Перевод: А. Кривошей
Дата перевода: июль 2019 г.

Файловые системы отвечают за организацию хранения данных. Так или иначе, со временем файловая система может быть повреждена и некоторые ее части могут быть недоступны. Если ваша файловая система имеет такое несоответствие, рекомендуется проверить ее целостность.

Это можно выполнить с помощью системной утилиты fsck (file system consistency check). Эта проверка может быть выполнена автоматически во время загрузки или запущена вручную.

В этой статье мы рассмотрим утилиту fsck и ее использование, чтобы помочь вам исправить дисковые ошибки.

Когда нужно использовать fsck в Linux

Существуют разные сценарии, когда вам понадобится запустить fsck. Вот несколько примеров:

Система не загружается.
Файлы в системе поврежденны (часто вы можете увидеть ошибку ввода/вывода).
Подключенный диск (включая флэшки/SD-карты) не работает должным образом.

Опции fsck

Команда Fsck должна быть запущена с привилегиями суперпользователя (root). Вы можете использовать ее с разными аргументами. Их использование зависит от вашего конкретного случая. Ниже вы увидите некоторые из наиболее важных опций:

Как запустить fsck для исправления ошибок файловой системы Linux

Чтобы запустить fsck, вам нужно убедиться, что раздел, который вы собираетесь проверить, не смонтирован. Для этой статьи я буду использовать мой второй диск /dev/sdb, смонтированный в /mnt.

Вот что произойдет, если я попытаюсь запустить fsck на смонтированном разделе.

Чтобы избежать этого, размонтируйте раздел с помощью команды:

Теперь fsck можно запустить безопасно.

Понимание кодов выхода fsck

После запуска fsck она вернет код выхода. Эти коды можно увидеть в руководстве fsck, выполнив:

Иногда в файловой системе можно найти ошибки. В таких случаях вы захотите, чтобы 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 linux

Здравствуйте, не определяется флешка transed 16gb в ubuntu linux вывод команды lsusb

Что-то у меня спойлеры не отобразились((

В windows 7 флешка определяется и сразу пропадает

У transcend есть специальный «лечащий» софт, попробуй, может повезёт.

И используй теги code, твою кашу читать невозможно.

В конце июля 2011 года добавлен парный тег

для создания спойлера в новостях с целью сокращения занимаемого ими места на главной странице.

Спойлеры только в новостях работают вроде.

Спойлеры только в новостях работают вроде.

И спойлерами, как таковыми, не являются.

Я вроде поправил теперь можно понять, что написанно Вот что пишет, при попытке создать раздел Ошибка ввода/вывода во время чтения на /dev/sdb

В смысле в GParted пишет

На счёт тега code спасибо, сам что-то не сообразил. А не может дать ссылку на этот софт, а то беглый поиск выдаёт всякую ерунду.

На «родном» сайте несколько версий: onlinerecovery

Их я пробовал, не видно флешку и это понятно, так как она то подключается, то отключается.

Закоротить ножки контроллера пробовалось?

По первой из приведённых мною ссылок сходить не судьба.

Зверек скорее мертв… Тем более что его поведение аналогично во всех ОСях. По простому выброси и забудь. Если охота поиздеваться то сперва попробуй софт для восстановления от самого трансценда… Когда совсем уже нечего будет терять попробуй китайские проги «для восстановления» иногда они даже помогают но как правило все равно не на долго. Так что проще просто и выбросить и купить новую.

я что то сначала не заметил ссылку, спасибо за совет, завтра попробую это проделать, потом отпишусь по результатам

Источник

I tried with gparted, it didn’t work. I found a SDFormatter, tool for windows that did the full erase.

I have a SD card and want to install Debian onto it. The dd process takes about 45 minutes, after that I quit it. In my Windows machine, it shows up in drive list but there’s also an undefined error while try formatting or even opening. gparted just tells me

/dev/mmcblk0: unrecognised disk label

I issued

dd if='deb.iso' of=/dev/mmcblk0 bs=512k
dd: error writing „/dev/mmcblk0“: I/O error
0+1 data in
0+0 data out
copied 0 Bytes (0 B), 10,098 s, 0,0 kB/s

After that I tried

root@kali:~# lsblk -o NAME,FSTYPE,MOUNTPOINT,SIZE,RO
NAME    FSTYPE MOUNTPOINT   SIZE RO
sda                       465,8G  0
├─sda1  ext4   /          450,1G  0
├─sda2                        1K  0
└─sda5  swap   [SWAP]      15,7G  0
sr0                        1024M  0
mmcblk0                    29,5G  0

mmcblk0 is the one i have problems with. Last,I tried

root@kali:~# mkdosfs -F 32 -v /dev/mmcblk0
mkfs.fat 3.0.26 (2014-03-07)
/dev/mmcblk0 has 4 heads and 16 sectors per track,
hidden sectors 0x0000;
logical sector size is 512,
using 0xf8 media descriptor, with 61896704 sectors;
drive number 0x80;
filesystem has 2 32-bit FATs and 32 sectors per cluster.
FAT size is 15105 sectors, and provides 1933326 clusters.
There are 32 reserved sectors.
Volume ID is 2df52746, no volume label.
mkdosfs: failed whilst writing reserved sector 

I have absolutely no idea why it won’t work.

I tried with gparted, it didn’t work. I found a SDFormatter, tool for windows that did the full erase.

I have a SD card and want to install Debian onto it. The dd process takes about 45 minutes, after that I quit it. In my Windows machine, it shows up in drive list but there’s also an undefined error while try formatting or even opening. gparted just tells me

/dev/mmcblk0: unrecognised disk label

I issued

dd if='deb.iso' of=/dev/mmcblk0 bs=512k
dd: error writing „/dev/mmcblk0“: I/O error
0+1 data in
0+0 data out
copied 0 Bytes (0 B), 10,098 s, 0,0 kB/s

After that I tried

root@kali:~# lsblk -o NAME,FSTYPE,MOUNTPOINT,SIZE,RO
NAME    FSTYPE MOUNTPOINT   SIZE RO
sda                       465,8G  0
├─sda1  ext4   /          450,1G  0
├─sda2                        1K  0
└─sda5  swap   [SWAP]      15,7G  0
sr0                        1024M  0
mmcblk0                    29,5G  0

mmcblk0 is the one i have problems with. Last,I tried

root@kali:~# mkdosfs -F 32 -v /dev/mmcblk0
mkfs.fat 3.0.26 (2014-03-07)
/dev/mmcblk0 has 4 heads and 16 sectors per track,
hidden sectors 0x0000;
logical sector size is 512,
using 0xf8 media descriptor, with 61896704 sectors;
drive number 0x80;
filesystem has 2 32-bit FATs and 32 sectors per cluster.
FAT size is 15105 sectors, and provides 1933326 clusters.
There are 32 reserved sectors.
Volume ID is 2df52746, no volume label.
mkdosfs: failed whilst writing reserved sector 

I have absolutely no idea why it won’t work.

Ошибка при получении информации о файле «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, и, способов их решения, — будем дописывать в этой же статье…

16GB Flash / ошибка ввода/вывода

badblock прогнал, но не думаю, что он тут к месту, ибо это не жд, потому что он ничего не дал

После попытки dd if=/dev/zero of=/dev/sdb , даже с указанием блока

Хотя изначально я снял dd полностью весь sdb, потом все 3 раздела. т.е. в данный момент у меня есть все 4 образа с флешки, ибо не очень хочется восстанавливать данные как после проблем с посыпавшимся жд пару лет назад, который, емнип, так же пропадал offline device из системы

Что с ней делать? Есть вариант попробовать

Бери утилиту и перепрошивай из-под венды, да, обычно помогает.

Или есть еще какие варианты?

Кхм. Флешка стояла в ноуте как основная с системой, записей там было немного-немало

PS: Кстати, сначала была проблема с одним из архивов, который не распаковывался в tmpfs, в связи с чем — фиг знает, решилось заменой самого архива на более старый. Через какое-то время(дни) резко вылетел браузер, и пошли ошибки ввода/вывода, как будто флешка была переподключена. После этого была предпринята попытка fsck по всем разделам, но процесс вешается на статус D (htop показал) на некоторое время. И затем уже начались действия по восстановлению данных.

PS: Ноут работал как сервер 24/7, перезагружался раз в месяц в во время цикла разряда/заряда батареи, которая кстати была недавно полностью разряжена(ввиду того, что не прописал правила для выключения при низком заряде), сейчас не заряжается, но с этим потом разберемся, хотя сдается мне еще и это стало добавкой.

Источник

SD-карта ошибка ввода-вывода

Выполнение fsck.fat /dev/block/mmcblk0p1 , устройство моей неисправной SD-карты, я получаю это:

Это означает, что файлы постоянно нечитабельны?

Выполнение fsck возвращает следующее:

ddrescue ничего не может сохранить. Вывод df :

Обновление: ситуация становится более странной. На моей машине Windows кажется, что вся SD-карта читаема. Однако копирование файлов является чрезвычайно медленным со случайными возвратами к регулярной скорости передачи. Мне удалось скопировать файлы, что я был главным образом после (фотографии, сделанные после моего последнего резервного копирования), но после определенного момента Windows Explorer не продолжится в копировании, неважно, сколько времени я ожидал.

Я вернулся к Ubuntu и к моему удивлению, fsck.fat на самом деле работал успешно. Выполнение его несколько раз дает некоторую комбинацию следующего: Has a large number of bad entries. (128/133) , Free cluster summary wrong (42991 vs. really 43267) , Orphaned long file name part , Contains a free cluster (144584). Assuming EOF. , Start does point to root directory. Deleting dir. ddrescue работает хорошо прямо сейчас, таким образом, я позволю ему продолжать бежать на данный момент.

Любопытно это походит на спящий режим и неспящий режим, или приостановку и возобновление, и ожидание могло бы позволить Ubuntu ddrescue спасите изрядное количество.

1 ответ

Как правило, ошибки ввода-вывода означают, что система столкнулась с неисправимой аппаратной ошибкой. Любые файлы на объеме ошибочного луга ввода-вывода нужно считать потерянными.

После этих слов восстановление данных все еще возможно (хотя немного трудно). К счастью, существует несколько утилит, которые могут выручить Вас:

• ddrescue
  Ddrescue является специальной утилитой, которая может использоваться для чтения как можно больше из дефектных объемов. Если бы Вы выполняете это, я настоятельно рекомендовал бы, чтобы Вы записали в файл изображения и отделались от этого для любых других операций восстановления (если кто-либо даже возможен).
• photorec
  В то время как его имя подразумевает, что это только для фотографий, photorec может часто использоваться для восстановления намного больше с диска, если дано шанса. Это, вероятно, не сможет восстановить данные из любых erroring секторов Вашего устройства, но это смогло спасать некоторые вещи.
• dd
  DD (шутливо известный как РазрушительДанных) является встроенной утилитой большинства — если не все — современные системы Linux. В худшем случае можно попытаться использовать dd сделать изображение Вашего флеш-накопителя, который мог бы позволить еще некоторым усовершенствованным средствам восстановления (или для файлового менеджера) работать успешно. Убедитесь, что Вы указываете право команд, иначе Вы изучите точно, почему это известно как Разрушитель Данных.

Если восстановление невозможно, Вы можете восстанавливать карту при помощи dd и другие утилиты для перезаписи всего диска с нулями. Это, как было известно, (в некоторых редких случаях) на самом деле возвращало диск жить (хотя, теряя содержание диска в прогрессе). Однако это — почти всегда лучшая идея просто получить новый диск. После того как диск перестал работать, он теряет любое подобие доверия, которое он когда-либо имел.

Источник

«Ошибка ввода / вывода» при доступе к каталогу

Я хочу перечислить и удалить содержимое каталога на съемном жестком диске. Но я испытал «Ошибка ввода / вывода»:

Мне было интересно, в чем проблема?

Как я могу восстановить или удалить каталог pic и все его содержимое?

Моя ОС — Ubuntu 12.04, а съемный жесткий диск имеет файловую систему ntfs. Другие каталоги, не содержащие или не находящиеся pic на съемном жестком диске, работают нормально.

Последняя часть вывода dmesg после того, как я попытался перечислить содержимое каталога:

Ошибки ввода / вывода при попытках доступа к файловой системе обычно означают аппаратные проблемы.

Введите dmesg и проверьте последние несколько строк вывода. Если диск или подключение к нему не удается, это будет отмечено там.

РЕДАКТИРОВАТЬ Вы монтируете его через ntfs или ntfs-3g ? Насколько я помню, устаревший ntfs драйвер не имел поддержки стабильной записи и был в основном заброшен, когда оказалось, что ntfs-3g он значительно более стабилен и безопасен.

Как утверждает Садхур, это, вероятно, вызвано аппаратными проблемами на диске, и dmesg выходной файл — правильное место, чтобы проверить это.

Вы можете выполнить сканирование поверхности вашего диска из Linux /sbin/badblocks /dev/sda .

Проверьте страницу руководства для более тщательного тестирования основных исправлений (перемещение блоков). Все это не зависит от файловой системы, поэтому является безопасным даже для файловой системы NTFS, поскольку работает на уровне «поверхности диска».

Я лично сделал это для запуска ежемесячно от cron. Конечно, вам нужно проверить, получаете ли вы письма cron в своем почтовом ящике (что по умолчанию часто не так). Эти письма заканчиваются /var/mail/$USER или похожи.

Я создал /etc/cron.d/badblocks :

Ваша файловая система повреждена, для томов NTFS вы должны запустить систему chkdsk под Windows, но восстановить ее практически невозможно. Иногда вам может понадобиться отформатировать диск.

Решение, которое работает для меня, — понизить ntfs-3g версию с выпуска 2014 года до выпуска 2012 года. Это должно решить вашу проблему с доступом к разделу NTFS. В долгосрочной перспективе это не решение, потому что в конечном итоге вам потребуется запустить последнюю версию.

Я просто хотел добавить свое решение в эту ветку для блага других — я выполнил некоторую работу в своей системе, когда у меня вышел из строя источник питания — я, должно быть, переподключил кабели SATA в неправильном порядке, так как когда я их переключал, все работало снова — в любом случае, не знаю, почему загрузочный диск должен находиться на определенном порте SATA, может быть ответом для кого-то другого.

Никто не упомянул, что делать, если инструменты Linux не работают и доступен только Mac, но не Windows.

Может быть исправлено в OS X с Paragon NTFS

В моем случае gparted сказали пойти найти ПК с Windows, который нигде не было найдено. Но рядом был Mac, для которого доступно это замечательное программное обеспечение. Установил пробную версию, выполнил проверку , затем чинил — и вуаля!

Я просто хотел поделиться своим опытом: во FreeBSD 10.3 я подключил свой внешний жесткий диск с

Внутри жесткого диска я mkdir создал папку, а затем переместил в нее несколько файлов, конечно, с помощью mv команды. Наконец я выполнил следующую команду:

Затем я смонтировал жесткий диск на машине Linux с ядром 4.4.0-78-generic. Теперь, когда я перечисляю содержимое жесткого диска, каталог, созданный во FreeBSD, назван Jeff , как показано ниже:

Также при попытке удалить Jeff каталог я получаю следующее сообщение об ошибке:

Я не смог избавиться от Jeff каталога на машине с Linux, поэтому я использовал машину с FreeBSD и снова смонтировал жесткий диск на FreeBSD. Но ls , cd и rm команды на FreeBSD генерировать то же самое Input/output error . Похоже, в ntfs-3g пакете FreeBSD была ошибка .

ОБНОВИТЬ

Я перенес все свои данные с внешнего жесткого диска на компьютер с Linux, конечно, поврежденный файл Jeff не мог быть перемещен из-за ошибки ввода-вывода. Затем я переформатировал внешний жесткий диск с обнулением тома и проверкой сбойного сектора следующим образом:

А затем переместил все данные обратно на внешний том. Таким образом, я потерял поврежденный файл с именем Jeff , однако мой внешний жесткий диск очищен от любых ошибок ввода-вывода.

Я объявил, что когда я пытаюсь получить доступ к диску, на котором возникла эта ошибка, он пытался записать последние скопированные файлы, которые были перезаписаны в последний файл, а затем попытка доступа не удалась, потому что уже записанная запись не совпадает с последними скопированными элементами, поэтому происходит сбой. Самый здоровый способ спасти диск — удалить последний элемент или элементы, скопированные в Windows.

Источник

Не определяется флешка в ubuntu linux

Здравствуйте, не определяется флешка transed 16gb в ubuntu linux вывод команды lsusb

Что-то у меня спойлеры не отобразились((

Я в этой простыне не очень разобрался и не уверен, но похоже, что флешка — всё. Попробуй через gparted залезть, может и побольше скажет.

В windows 7 флешка определяется и сразу пропадает

У transcend есть специальный «лечащий» софт, попробуй, может повезёт.

И используй теги code, твою кашу читать невозможно.

В конце июля 2011 года добавлен парный тег

для создания спойлера в новостях с целью сокращения занимаемого ими места на главной странице.

Спойлеры только в новостях работают вроде.

Спойлеры только в новостях работают вроде.

И спойлерами, как таковыми, не являются.

Я вроде поправил теперь можно понять, что написанно Вот что пишет, при попытке создать раздел Ошибка ввода/вывода во время чтения на /dev/sdb

В смысле в GParted пишет

На счёт тега code спасибо, сам что-то не сообразил. А не может дать ссылку на этот софт, а то беглый поиск выдаёт всякую ерунду.

На «родном» сайте несколько версий: onlinerecovery

Их я пробовал, не видно флешку и это понятно, так как она то подключается, то отключается.

Закоротить ножки контроллера пробовалось?

По первой из приведённых мною ссылок сходить не судьба.

Зверек скорее мертв… Тем более что его поведение аналогично во всех ОСях. По простому выброси и забудь. Если охота поиздеваться то сперва попробуй софт для восстановления от самого трансценда… Когда совсем уже нечего будет терять попробуй китайские проги «для восстановления» иногда они даже помогают но как правило все равно не на долго. Так что проще просто и выбросить и купить новую.

я что то сначала не заметил ссылку, спасибо за совет, завтра попробую это проделать, потом отпишусь по результатам

Источник

Проблема с копированием файла на флеш-карту

Все просто, скачал образ с игрой для ps3, весит он 8 гигов. Копирую его на флешку, и линукс уже не может это осилить.

Легкие файлы он копирует на носитель без труда, а вот тяжелые для него неподъемная ноша. Проблемы были и каждый раз после того, как я фильмы размером 1 — 6 гигов копировал на флешку, но получал в ответ что-то непонятное.

В общем и сам вопрос. Почему я не могу совершить элементарную операцию по копированию файлов? Ошибка, что я получаю http://joxi.ru/L21Ko1YhgwOMNr

Если что, я ламер, который установил линукс пару лет назад, чтобы познать эту систему.

Так же проблема появлялась и ранее, когда файл гига на 4 копировался минут 10-15. Это реально боль какая-то. При старте копирования скорость максимально высокая, а с каждой секундой все меньше и меньше. Уже находил подобные темы на этом форуме, но как-то они мне не помогли

Файловая система на носителе не FAT случаем?

Какая ФС на флешке?

У FAT32 ограничение — более 4 гибибайт файлы в принципе не поддерживаются. В новых версиях Windows флешки потому по умолчанию форматируют или в NTFS, или в exFAT.

Если флешка только под Linux, можешь ext4 использовать на ней.

Я даже больше скажу: нтфс имеет смысл использовать ТОЛЬКО если предпологаеться использование ее для обмена файлами с компьютером под управлением винды.

Вероятно, да. Под macOS можно флешку в HFS+ отформатировать — Linux умеет и с этой ФС работать.

Источник

Первое подключение

[ 7477.086526] usb 1-5: USB disconnect, device number 8
[ 7479.523033] usb 1-5: new high-speed USB device number 9 using ehci-pci
[ 7479.642204] usb 1-5: New USB device found, idVendor=8564, idProduct=1000
[ 7479.642211] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 7479.642215] usb 1-5: Product: Mass Storage Device
[ 7479.642219] usb 1-5: Manufacturer: JetFlash
[ 7479.642222] usb 1-5: SerialNumber: 2367432475
[ 7479.642693] usb-storage 1-5:1.0: USB Mass Storage device detected
[ 7479.643152] scsi host6: usb-storage 1-5:1.0
[ 7480.691525] scsi 6:0:0:0: Direct-Access     JetFlash Transcend 16GB   1.00 PQ: 0 ANSI: 6
[ 7480.691969] sd 6:0:0:0: Attached scsi generic sg1 type 0
[ 7480.693585] sd 6:0:0:0: [sdb] 30867456 512-byte logical blocks: (15.8 GB/14.7 GiB)
[ 7480.693986] sd 6:0:0:0: [sdb] Write Protect is off
[ 7480.693990] sd 6:0:0:0: [sdb] Mode Sense: 23 00 00 00
[ 7480.694360] sd 6:0:0:0: [sdb] Write cache: disabled, read cache: disabled, doesn't support DPO or FUA
[ 7480.697951]  sdb: sdb1 sdb2 sdb3
[ 7480.700621] sd 6:0:0:0: [sdb] Attached SCSI removable disk

При проблемах

[ 2822.924734] usb 1-5: reset high-speed USB device number 3 using ehci-pci
[ 2823.043961] sd 6:0:0:0: Device offlined - not ready after error recovery
[ 2823.043974] sd 6:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
[ 2823.043978] sd 6:0:0:0: [sdb] tag#0 CDB: Write(10) 2a 00 00 00 08 00 00 00 20 00
[ 2823.043981] blk_update_request: I/O error, dev sdb, sector 2048
[ 2823.043984] Buffer I/O error on dev sdb1, logical block 0, lost async page write
[ 2823.043997] Buffer I/O error on dev sdb1, logical block 1, lost async page write
[ 2823.043999] Buffer I/O error on dev sdb1, logical block 2, lost async page write
[ 2823.044001] Buffer I/O error on dev sdb1, logical block 3, lost async page write
[ 2823.044017] sd 6:0:0:0: rejecting I/O to offline device
[ 2823.044020] sd 6:0:0:0: killing request
[ 2823.044024] sd 6:0:0:0: rejecting I/O to offline device
[ 2823.044026] sd 6:0:0:0: [sdb] killing request
[ 2823.044046] sd 6:0:0:0: [sdb] FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[ 2823.044048] sd 6:0:0:0: [sdb] CDB: Write(10) 2a 00 00 00 1a d0 00 00 08 00
[ 2823.044049] blk_update_request: I/O error, dev sdb, sector 6864
[ 2823.044051] Buffer I/O error on dev sdb1, logical block 602, lost async page write

Видны проблемы с секторами.

badblock прогнал, но не думаю, что он тут к месту, ибо это не жд, потому что он ничего не дал

Checking blocks 0 to 15433727
Checking for bad blocks (read-only test): ;done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

После попытки dd if=/dev/zero of=/dev/sdb , даже с указанием блока

dd: ошибка записи '/dev/sdb': Ошибка ввода/вывода
84097+0 записей получено
84096+0 записей отправлено
43057152 байт (43 MB, 41 MiB) скопирован, 105.311 s, 409 kB/s

после dd fdisk флешку не видит. lsusb по крайней мере еще видит ее

Bus 001 Device 007: ID 8564:1000 Transcend Information, Inc. JetFlash

и в dmesg куча

[ 5516.738029] sd 6:0:0:0: rejecting I/O to offline device

Переподключение, fdisk говорит, что там как было 3 раздела, так и осталось, т.е. dd вообще не пишет на нее

Хотя изначально я снял dd полностью весь sdb, потом все 3 раздела. т.е. в данный момент у меня есть все 4 образа с флешки, ибо не очень хочется восстанавливать данные как после проблем с посыпавшимся жд пару лет назад, который, емнип, так же пропадал offline device из системы

Что с ней делать? Есть вариант попробовать

Бери утилиту и перепрошивай из-под венды, да, обычно помогает.

Или есть еще какие варианты?

Кхм. Флешка стояла в ноуте как основная с системой, записей там было немного-немало

Filesystem created:       Fri Sep  2 23:57:38 2016
Lifetime writes:          282 GB
Block count:              9141248
Block size:               1024
Free blocks:              722283
Inode count:              571392
Free inodes:              408630
Filesystem state:         clean
Last write time:          Mon Jan 14 23:15:38 2019

По сравнению с жд на стаце, который очень мало юзается

Filesystem created:       Thu Oct  2 21:48:36 2014
Lifetime writes:          1938 GB
Block count:              157286382
Block size:               4096
Free blocks:              27653042
Inode count:              4531200
Free inodes:              4366450
Filesystem state:         clean
Last write time:          Sun Feb 10 07:35:06 2019

Хотя записано было мало всего-то 15Гб за год.

Filesystem created:       Fri Sep  2 23:57:38 2016
Lifetime writes:          266 GB
Block count:              9141248
Block size:               1024
Free blocks:              3348418
Inode count:              571392
Free inodes:              410010
Filesystem state:         clean
Last write time:          Thu Jan 18 13:51:05 2018

PS:
Кстати, сначала была проблема с одним из архивов, который не распаковывался в tmpfs, в связи с чем — фиг знает, решилось заменой самого архива на более старый. Через какое-то время(дни) резко вылетел браузер, и пошли ошибки ввода/вывода, как будто флешка была переподключена. После этого была предпринята попытка fsck по всем разделам, но процесс вешается на статус D (htop показал) на некоторое время. И затем уже начались действия по восстановлению данных.

PS:
Ноут работал как сервер 24/7, перезагружался раз в месяц в во время цикла разряда/заряда батареи, которая кстати была недавно полностью разряжена(ввиду того, что не прописал правила для выключения при низком заряде), сейчас не заряжается, но с этим потом разберемся, хотя сдается мне еще и это стало добавкой.

I tried with gparted, it didn’t work. I found a SDFormatter, tool for windows that did the full erase.

I have a SD card and want to install Debian onto it. The dd process takes about 45 minutes, after that I quit it. In my Windows machine, it shows up in drive list but there’s also an undefined error while try formatting or even opening. gparted just tells me

/dev/mmcblk0: unrecognised disk label

I issued

dd if='deb.iso' of=/dev/mmcblk0 bs=512k
dd: error writing „/dev/mmcblk0“: I/O error
0+1 data in
0+0 data out
copied 0 Bytes (0 B), 10,098 s, 0,0 kB/s

After that I tried

root@kali:~# lsblk -o NAME,FSTYPE,MOUNTPOINT,SIZE,RO
NAME    FSTYPE MOUNTPOINT   SIZE RO
sda                       465,8G  0
├─sda1  ext4   /          450,1G  0
├─sda2                        1K  0
└─sda5  swap   [SWAP]      15,7G  0
sr0                        1024M  0
mmcblk0                    29,5G  0

mmcblk0 is the one i have problems with. Last,I tried

root@kali:~# mkdosfs -F 32 -v /dev/mmcblk0
mkfs.fat 3.0.26 (2014-03-07)
/dev/mmcblk0 has 4 heads and 16 sectors per track,
hidden sectors 0x0000;
logical sector size is 512,
using 0xf8 media descriptor, with 61896704 sectors;
drive number 0x80;
filesystem has 2 32-bit FATs and 32 sectors per cluster.
FAT size is 15105 sectors, and provides 1933326 clusters.
There are 32 reserved sectors.
Volume ID is 2df52746, no volume label.
mkdosfs: failed whilst writing reserved sector 

I have absolutely no idea why it won’t work.