Сканер ошибка ввода вывода linux
Обновлено: 04.07.2024
Almaz, надо посмотреть на твой вывод lsusb, возможно что сканер у тебя подключен не на Bus 002 Device 003.
Михаил, а какую модель сканер используешь?
Нифига не получается. Все стопориться на процессе копирования фирмвара. Несмотря на то, что работаю с правами рут, папка даже не хочет открываться:(. жаль, долблюсь уже неделю. Наверное не судьба и придется сканить в винде. Там это попроще как-то. Неужели сложно было сделать так же, как и остальными ЮСБ устройствами, типа принтера.
Я не технарь и копаться в кодах - увольте, нету времени на непрофильную фигню. Неужели трудно написать драйвер как пакет, например? Почему в той же саксевой винде это занимает у меня 3 минуты, а здесь уже неделю и без просвета. Извините, накипело.
Mikalai,о какой папке идет речь? /usr/share/sane/gt68xx/? Как Вы копируете? Из командной строки или при помощи файлового менеджера? Порядок Ваших действий?
Порядок действий указан выше Вами. Ему и следую
Отличная статья! настроил HP Scanjet 2300c в Linux Mint 5. Спасибо!
Зачем столько мучений?
Копируем USB-прошивку, запускаем от рута simple-scan и все.
(xsane:1497): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated
штук 20 сразу. что нить можнопредположить? где можно посмотреть логи?
Этот комментарий был удален автором.
И да, работа останавливается на этапе добавления пользователя в группу "scanner" поскольку такая группа отсутствует. В чём мой промах, и является ли это проблемой?
Андрей, какой Linux у тебя? От рута scanimage видит сканер? Возможно группа scanner не создается по-умолчанию. В принципе можно посмотреть в каких группах состоит пользователь и в правилах udev указать какую-либо из этих групп вместо группы scanner. Посмотреть в каких группах пользователь можно выполнив команду id, от имени пользователя.
Рекомендую пользователя в группу добавлять командой:
sudo usermod -aG scanner `whoami` проверено на ubuntu 10.04
А у меня ваще сканит пол страницивдоль и растягивает до а4
и что бы из железа не подключал к ubunte всё работает через попу и рота в ней суке нет!
Спасибо за статью. Под 7кой мой сканер (той же модели, что в статье) не ставится, приходилось нетбук включать с ХРшкой, чтоб просканировать. А тут всё стало - прелесть)))
Первоначально всё получилось на "ура"! Сканер работал без претензий. После перезагрузки вначале были сбои в работе, не сплошной звук каретки при поступательном движении, а прерывистый, как у струйных принтеров. Стал проверять, оказалось скачал фирмварь на CA вместо TA. Переустановил. Вначале - результат тот же. При движении каретки были слышны стуки в конечных точках и прокрутка зубчатой лентопротяжки (подозреваю наличие именно такого устройства). После этого сканер перестал реагировать на вызов. Из списка usb-устройств не исчез. Утилита поиска его определяет. После команды sudo scanimage -L - мёртвая тишина. Никаких данных не выводится, кроме нового приглашения. Что случилось?
В хрюше проверил - всё нормально.
Помогите решить проблему, заранее спасибо. В линуксе новичок.
Pagan, какая модель сканера у тебя? Тебе нужно в /usr/share/sane/snapscan/ положить firmware для твоего сканера.
В ответ мне пишет
scanimage: sane_start: Device busy
Что мне делать? остановить службу или устройство?
не пойму, как же все тяжко в ubuntu дается
Александр, сложно однозначно сказать почему занято устройство. Возможно запущена программа, использующая сканер. Выяснить, какой программой или процессом занято устройство можно командой fuser. Например: fuser -v /dev/bus/usb/006/003
спасибо за попытку помочь, но после ввода команды ничего не произошло, строка ввода появилась снова без изменений, могу переставить убунту и выложить скрины этапов настройки, просто действительно эта система порадовала своими возможностями и еще даже при значительном снижении головной боли со стороны пользователя (за исключением настройки сканера), вообщем не нужна эта похвала, нужна помощь, может есть конкретный пример настройки на конкретной версии убунту с конкретным сканером, дело в том что я и раньнше в коментах видел беспомощность с этой моделью сканера
Александр, на Ubuntu свежего примера нет. Есть свежий пример для Debian, хотя это не сильно принципиально. Какая модель сканера? Нужен вывод команд: lsusb -v и scanimage -L.
Спасибо, браточик, за пост. Бреду по просторам Никсов вслепую и подробное описание пригодилось, как для чукчи в Париже. Но во время "прошивки" файл не хотел копироваться в папку. Надо было использовать:
sudo chmod 0777 /usr/share/sane/gt68xx/
Осталось звук сделать. Буду искать как.
А как получить права root и вставить 0644. По-подробнее плиз. Открывать какой-то командер или в файловом менеджере (там я не нашел системных папок). Очень благодарен, до этого пункта ваша статья очень помогла.
$ sudo scanimage --test -d genesys:libusb:001:007
scanimage: sane_start: Error during device I/O
Опишем окружение в котором возникла ошибка ввода/вывода:
- ОС: 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. Перед переключением между ОС каждая ОС переводилась в спящий режим с сохранением запущенных программ и открытых файлов.
Не скажу, как и почему стала появляться Ошибка ввода/вывода, - возможно gedit попутал uid/gid (файловые/индексные дескрипторы) и при сохранении в Master File Table (MFT) прописал не то, не тем и не туда, но вот, что получилось после очередного переключения между ОС при совместном редактировании файлов:
Попытка открыть каталог " /media/SATA2/PROFILE/User/Рабочий стол " в Thunar:
Остальное содержимое каталога было не доступно для просмотра/редактирования
Попытка сохранить уже открытый в gedit текстовый файл Test.txt :
При использовании файлового менеджера NAUTILUS удалось открыть каталог /media/SATA2/PROFILE/User/Рабочий стол и удалить " Test.txt ", но вот создать заново Test.txt или создать «Безымянный документ» и переименовать его в «Test.txt» не удалось:
Следующий глюк сопутствовал Ошибкам ввода/вывода, но вот при каких условиях возник не припомню (вероятно при нескольких одновременных попытках монтирования):
Владелец и права на файл Test.txt не известны:
В некоторых манах для лечения предлагалось использовать ntfsfix -b /dev/sdb5 , предварительно отмонтировав его, - но проблема не решилась.
В среде Linux на ДИСК 2 были созданы текстовые файлы " Test_2.txt " и " Test_3.txt " и совершено переключение на Windows XP где эти файлы были не доступны даже для просмотра, хотя после перехода обратно в Linux их можно было просматривать и редактировать.
Проблему с косяком в NTFS разделе на ДИСК 2 удалось решить только с помощью стандартного средства проверки дисков входящего в ОС Windows XP в процессе перезагрузки:
Увидев на экране Deleting index entry . я зразу же понял, что этих файлов нам уже не видать как своих ушей, - разумеется, так и есть.
Существует также ещё один способ монтирования 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, и, способов их решения, - будем дописывать в этой же статье.
Рекомендуемый контент
Вы не любите рекламу!? Напрасно!:) На нашем сайте она вовсе ненавязчивая, а потому для нашего сайта можете полностью отключить AdBlock (uBlock/uBlock Origin/NoScript) и прочие блокировщики рекламы! AdBlock/uBlock может препятствовать нормальной работе системы поиска по сайту, отображению рекомендуемого контента и прочих сервисов Google. Рекомендуем полностью отключить блокировщик рекламы и скриптов, а также разрешить фреймы (aka iframe).
Все-в-одном, что работало нормально некоторое время назад (по крайней мере до 12.04).
] Выход из hp-check -rt выглядит следующим образом:
Мой syslog показывает эти строки после запуска xsane :
Подсказывает / подсказывает кому угодно, чтобы получить мой сканер снова работать?
'Не удалось открыть device'hpaio: / usb / HP_LaserJet_Professional_M1136_MFP? serial = 0000000000H77VXNPR1a': Ошибка во время ввода / вывода устройства. '
У меня была ошибка выше, когда i обновлен ubuntu с 14.04 по 14.10. И я нашел решение, как показано ниже.
Для тех, кто пришел на эту страницу, как и я, хотел решить эту проблему. В итоге я попытался сделать что-то очень простое, что сработало для меня.
Моя система - Ubuntu 12.10. У меня есть сетевой принтер HP MFP CM1312.
- Я установил «HPLIP Toolbox» из программного центра Ubuntu (у меня уже был установлен HPLIP).
- С терминала я запустил «sudo hp-plugin», нажал «Далее» через значения по умолчанию.
Сетевое сканирование работало безупречно.
У меня такая же проблема. Авахи бежит за мной. Это выглядит как общая ошибка в 3.12.6:
Переход на более ранний 3.12.4 работал. Я получил пакеты с панели запуска здесь:
Для сборки пакета (из памяти, но, надеюсь, это помогает):
- Скопируйте файлы tar.gz в /usr/local/src
- sudo aptitude build-dep hplip
- sudo aptitude install devscripts
- tar -xzf hplip_3.12.4.orig.tar.gz
- tar -xzf hplip_3.12.4-1.debian.tar.gz
- mv debian hplip-3.12.4
- cd hplip-3.12.4
- debuild -us -uc
- cd ..
- dpkg -i *.deb
Вот другие ссылки на людей, имеющих одну и ту же проблему:
Теперь попробуйте получить доступ к сканеру, используя «Простой сканирование» через Dash. Работает безупречно.
Спасибо @Nelson Garcia, хотя мой метод немного отличается, ваш пост решил это для меня.
Я хочу перечислить и удалить содержимое каталога на съемном жестком диске. Но я испытал «Ошибка ввода / вывода»:
Мне было интересно, в чем проблема?
Как я могу восстановить или удалить каталог pic и все его содержимое?
Моя ОС - Ubuntu 12.04, а съемный жесткий диск имеет файловую систему ntfs. Другие каталоги, не содержащие или не находящиеся pic на съемном жестком диске, работают нормально.
Последняя часть вывода dmesg после того, как я попытался перечислить содержимое каталога:
Ошибка ввода-вывода может быть аппаратной проблемой (повреждение оперативной памяти или жесткого диска). Это также может означать повреждение файловой системы или ошибку драйвера; так как это NTFS, я не исключаю этого.Ошибки ввода / вывода при попытках доступа к файловой системе обычно означают аппаратные проблемы.
Введите dmesg и проверьте последние несколько строк вывода. Если диск или подключение к нему не удается, это будет отмечено там.
РЕДАКТИРОВАТЬ Вы монтируете его через ntfs или ntfs-3g ? Насколько я помню, устаревший ntfs драйвер не имел поддержки стабильной записи и был в основном заброшен, когда оказалось, что ntfs-3g он значительно более стабилен и безопасен.
Я подключаю съемный жесткий диск к своей Ubuntu 12.04, и он автоматически монтируется. Так я думаю ntfs-3g ? Не " угадай ". Проверьте - вы можете увидеть, как все монтируется, набрав mount команду и глядя на вывод. (1) Я добавил последнюю часть вывода dmesg после того, как попытался составить список содержимого каталога. Я не знаю, как это помогает. (2) Я не могу увидеть, смонтирован ли он с помощью nfts-3g или ntfs, посмотрев на вывод mount : /dev/sdb1 on /media/removable_drive type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096) fuseblk означает, что он использует метод fuser файловая система в пользовательском пространстве, что и ntfs-3g используется. Так что ты хорош в этом отношении.Как утверждает Садхур, это, вероятно, вызвано аппаратными проблемами на диске, и dmesg выходной файл - правильное место, чтобы проверить это.
Вы можете выполнить сканирование поверхности вашего диска из Linux /sbin/badblocks /dev/sda .
Проверьте страницу руководства для более тщательного тестирования основных исправлений (перемещение блоков). Все это не зависит от файловой системы, поэтому является безопасным даже для файловой системы NTFS, поскольку работает на уровне «поверхности диска».
Я лично сделал это для запуска ежемесячно от cron. Конечно, вам нужно проверить, получаете ли вы письма cron в своем почтовом ящике (что по умолчанию часто не так). Эти письма заканчиваются /var/mail/$USER или похожи.
Я создал /etc/cron.d/badblocks :
Спасибо! Для запуска команды, которую вы предложили, это /sbin/badblocks /media/removable_drive в моем случае? Нет. Согласно выводу dmesg вы должны использовать sdb: /sbin/badblocks /dev/sdb или sdc. Я действительно не могу понять, что случилось / вы сделали dmesg Вы можете найти свой /dev/sdВаша файловая система повреждена, для томов NTFS вы должны запустить систему chkdsk под Windows, но восстановить ее практически невозможно. Иногда вам может понадобиться отформатировать диск.
Спасибо! Мои другие каталоги в порядке. Могу ли я не отформатировать весь диск, просто освободить место в каталоге? @ Тим, тебе пришлось скопировать все остальное, отформатировать и скопировать их обратно . я не знаю, можно ли удалить один узел . не знаком со структурой NTFS Перед форматированием попробуйте badblocks комманду в Linux.Решение, которое работает для меня, - понизить ntfs-3g версию с выпуска 2014 года до выпуска 2012 года. Это должно решить вашу проблему с доступом к разделу NTFS. В долгосрочной перспективе это не решение, потому что в конечном итоге вам потребуется запустить последнюю версию.
Хорошо, это хорошо знать. Таким образом, в основном существует окно между 2012 и началом 2016 года, в течение которого привод просто не работал.Я просто хотел добавить свое решение в эту ветку для блага других - я выполнил некоторую работу в своей системе, когда у меня вышел из строя источник питания - я, должно быть, переподключил кабели SATA в неправильном порядке, так как когда я их переключал, все работало снова - в любом случае, не знаю, почему загрузочный диск должен находиться на определенном порте SATA, может быть ответом для кого-то другого.
Никто не упомянул, что делать, если инструменты Linux не работают и доступен только Mac, но не Windows.
Может быть исправлено в OS X с Paragon NTFS
В моем случае gparted сказали пойти найти ПК с Windows, который нигде не было найдено. Но рядом был Mac, для которого доступно это замечательное программное обеспечение. Установил пробную версию, выполнил проверку , затем чинил - и вуаля!
У меня был случай на macos, когда такая ошибка была вызвана использованием sshfs (вроде бы) в сборке инструментария. Помогла установка osxfuse & sshfs через brew.Я просто хотел поделиться своим опытом: во FreeBSD 10.3 я подключил свой внешний жесткий диск с
Внутри жесткого диска я mkdir создал папку, а затем переместил в нее несколько файлов, конечно, с помощью mv команды. Наконец я выполнил следующую команду:
Я не смог избавиться от Jeff каталога на машине с Linux, поэтому я использовал машину с FreeBSD и снова смонтировал жесткий диск на FreeBSD. Но ls , cd и rm команды на FreeBSD генерировать то же самое Input/output error . Похоже, в ntfs-3g пакете FreeBSD была ошибка .
ОБНОВИТЬ
Я перенес все свои данные с внешнего жесткого диска на компьютер с Linux, конечно, поврежденный файл Jeff не мог быть перемещен из-за ошибки ввода-вывода. Затем я переформатировал внешний жесткий диск с обнулением тома и проверкой сбойного сектора следующим образом:
А затем переместил все данные обратно на внешний том. Таким образом, я потерял поврежденный файл с именем Jeff , однако мой внешний жесткий диск очищен от любых ошибок ввода-вывода.
Я объявил, что когда я пытаюсь получить доступ к диску, на котором возникла эта ошибка, он пытался записать последние скопированные файлы, которые были перезаписаны в последний файл, а затем попытка доступа не удалась, потому что уже записанная запись не совпадает с последними скопированными элементами, поэтому происходит сбой. Самый здоровый способ спасти диск - удалить последний элемент или элементы, скопированные в Windows.
Читайте также: