стоит ожидать появление первого аппаратного обеспечения, не поддерживающего X11
Это как ?
И X11 и Wayland используют kms. Для X11 есть DDX драйвер modesetting его можно использовать если нет специфичного драйвера. Врядли из ядра выкинут kms, совместимость с userspace тоже ломать не будут.
Можно. Но для надежного перезапуска ddrescue в цикле это не подходит. Так как неисправные HDD/SSD могут в процессе подглючивания при пере-подключении в очередной раз определиться как другая модель и с другим SN. И соответственно путь в /dev/disk/by-id тоже изменится.
Поэтому реализовал в скрипте другой метод. Для SATA устройств - номер порта. Для USB - ID VID:PID
Можно просто удалять PCIe девайс и делать рескан, диск под новым номером проявится.
Это не работает для неисправных дисков. Сегодня еще раз проверил. Затем комп вообще зависает.
Вот вчера принесли комп HP с SSD M.2 NVMe Kioxia. На бэдах отваливается, при этом пропадает содержимое /sys/class/nvme* и даже выгрузка и повторная подгрузка модулей nvme nvme_core не помогает. Но при этом комп продолжает работать (кроме nvme подсистемы), а не зависает намертво как с Kimtigo.
При этом при подключении через USB3 мост обрабатывает ошибку и читает дальше.
Скрины
Чаще всего у диска проблема с полной шиной (Привет Кингстон)
Не встречал такого. Все ссд и SATA и PCI-E отваливались строго на определенных секторах. Если попытаться прочитать именно битый сектор - сразу отвалится. То есть дело в том что прошивка диска зависает вместо обработки ошибки.
То есть нужно тогда делать аппаратное отключение питания для M.2 слота. Можно наверно через какой нибудь райзер сделать. Но из за глюков по шине PCI-E комп может вообще зависнуть. Некоторые SSD вешали систему.
Сфотографировал. Слишком мелкие контакты. Щупами туда лезть я не буду.
Фото
По сути для ускорения процесса копирования, даже если удастся как то задействовать PERST#, и это сработает - это ничего не даст. Так как большую часть времени занимает ожидание обработки ошибки прошивкой SSD, ядром Linux и процессом ddrescue
В плане софта возможно еще есть потенциал куда дорабатывать.
Единственное правильное решение это расковырять прошивку SSD и отключить контроль ошибок. Но это решение не универсальное.
Правильно ли я понял, что отключение-включение нужно после каждой неудачи чтения битого блока, что приводит к тому, что данные могут вычитываться очень долго?
Долго это ждать пока ddrescue поймет что не читается. Опция --timeout=0 не помогает.
А передергивание по питанию быстро происходит. Тут проблема в том что передернуть не дожидаясь ddrescue можно, но тогда в map файле этот сектор как битый не будет отмечен и позиция не поменяется.
Почему бы просто не использовать #PERST ?
А как именно его использовать ?
Линукс делает reset но это не помогает. Возможно какой то другой reset.
sd 6:0:0:0: [sdd] tag#5 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
sd 6:0:0:0: [sdd] tag#5 CDB: Read(10) 28 00 00 89 1c 00 00 01 00 00
scsi host6: uas_eh_device_reset_handler start
usb 4-3: reset SuperSpeed Gen 1 USB device number 108 using xhci_hcd
scsi host6: uas_eh_device_reset_handler success
sd 6:0:0:0: [sdd] tag#5 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
sd 6:0:0:0: [sdd] tag#5 CDB: Test Unit Ready 00 00 00 00 00 00
scsi host6: uas_eh_device_reset_handler start
usb 4-3: reset SuperSpeed Gen 1 USB device number 108 using xhci_hcd
scsi host6: uas_eh_device_reset_handler success
sd 6:0:0:0: Device offlined - not ready after error recovery
sd 6:0:0:0: [sdd] tag#5 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT cmd_age=41s sd 6:0:0:0: [sdd] tag#5 CDB: Read(10) 28 00 00 89 1c 00 00 01 00 00
blk_update_request: I/O error, dev sdd, sector 8985600 op 0x0:(READ) flags 0x0 phys_seg 32 prio class 0
Как насчет такой схемы для свежего, не поддерживаемого в Win7 железа.
На железе непосредственно работает линукс, и использует современную встроенную в процессор видеокарту Intel/AMD.
Семерка запускается в виртуальной машине. И туда проброшены все USB устройства. А также дискретная видеокарта, для которой есть драйвера под Win7.
Чисто гипотетически вроде бы не должно быть проблем. Кроме того что вывод с дискретной видеокарты должен быть на отдельный монитор, либо через переключатель или монитор с несколькими портами.
Еще вариант, можно использовать 2 монитора и 2 комплекта клавиатура+мышь. Второй пробросить в виртуальную машину с Win7. Тогда один комп будет для двух рабочих мест. Одно с линукс, второе с Win7.
Я с этими утилитами не работал. Их нельзя распространять. И навскидку есть еще одна проблема. Для них также как для драйверов NVIDIA нужно собирать модуль. Для разных поколений видеокарт разные версии MODS. Для старых версий нужны старые версии ядра Linux. То есть тогда придется добавлять еще несколько версий ядра специально для MODS.
Опубликовал новый вариант скрипта ddrescue-loop v0.2ddrescue-loop-v0.2.gz С поддержкой восстановления с USB и Power-off and power-on cycle посредством USB Relay Module LCUS-1 CH340 либо uhubctl
Подразумевается подключение питания на USB/SATA диск через контакты реле COM и NC Чтобы в выключенном состоянии питание проходило. А при подаче команды на включение реле - питание отключалось.
На али нашел такое устройство LCUS-1 5V USB Relay Module CH340
Можно попробовать раздербанить USB3 A - Type-C кабель, вытащить жилку питания и подключить док станцию AgeStar 31CBNV1C через него.
Реле определяется как COM-порт и управляется записью в него 16-ричной последовательности A0 01 01 A2 для подачи питания на реле, A0 01 00 A1 для отключения
Управление железкой через bash: echo -e «\xA0\x01\x01\xA2» > /dev/ttyUSB0 echo -e «\xA0\x01\x00\xA1» > /dev/ttyUSB0
uhubctl работает на моей плате для USB2.0. uhubctl -l 1-1 -a 0 uhubctl -l 1-1 -a 1
Также работает стандартное извлечение udisksctl power-off -b /dev/sdc Но непонятно как потом обратно включить.
НО это все к сожалению не помогает в случае с неисправным NVMe SSD!
SSD Kimtigo на контроллере Maxio MAP1202 подключаю через док станцию AgeStar 31CBNV1C на контроллере JMicron JMS583 USB-NVMe
После blk_update_request: I/O error, dev sdc, sector 1077232 op 0x0:(READ) flags 0x4000 phys_seg 129 prio class 0 sd 6:0:0:0: rejecting I/O to offline device
Помогает только отключение-включение переключателем на док станции.
Не помогает и usbreset 152d:0583 Resetting USB to PCIE Bridge ... ok
scsi host6: uas_eh_device_reset_handler start usb 1-1.3: reset high-speed USB device number 37 using ehci-pci scsi host6: uas_eh_device_reset_handler success scsi 6:0:0:0: Device offlined - not ready after error recovery
Извлечение udisksctl power-off -b /dev/sdc работать перестает.
Это не для постоянно работающих машин. Для запуска на непродолжительное время для тестов. Для проверки работоспособности образов, диагностики клиентских Windows (с проблемами запуска) прямо с SSD.
Еще модификация строки запуска. Вернул размер сектора 4K, но добавил -c 8 то есть читать по 8 секторов за раз. По умолчанию 128 и с этим значением прошивка SSD сильно тупила. 32K за раз отрабатывает стабильно.
Теперь можно задавать таймаут больше чем установлен по умолчанию в ядре Linux. Оказалось что это позволяет ядру дожидаться ответа диска вместо оправок команды ataN: hard resetting link
-act 200 показывает себя хорошо случае с этим SSD Western Digital SSD 240GB.
Софт для копирования есть, но платный. Даже WdMarwel копирует, ибо есть режим без инициализации диска. Проверил только что на Слетевшем A400 (Satafirm S11).
Так удалось хотя бы начало диска скопировать ? Пробовали анализировать то что получилось c помощью например DMDE ?
Это как ?
И X11 и Wayland используют kms. Для X11 есть DDX драйвер modesetting его можно использовать если нет специфичного драйвера. Врядли из ядра выкинут kms, совместимость с userspace тоже ломать не будут.
Статья Восстановление данных с M.2 NVMe SSD. Скрипт ddrescue-loop v0.2
Можно. Но для надежного перезапуска ddrescue в цикле это не подходит. Так как неисправные HDD/SSD могут в процессе подглючивания при пере-подключении в очередной раз определиться как другая модель и с другим SN. И соответственно путь в /dev/disk/by-id тоже изменится.
Поэтому реализовал в скрипте другой метод. Для SATA устройств - номер порта. Для USB - ID VID:PID
Это не работает для неисправных дисков. Сегодня еще раз проверил. Затем комп вообще зависает.
Вот вчера принесли комп HP с SSD M.2 NVMe Kioxia. На бэдах отваливается, при этом пропадает содержимое
/sys/class/nvme*и даже выгрузка и повторная подгрузка модулей nvme nvme_core не помогает. Но при этом комп продолжает работать (кроме nvme подсистемы), а не зависает намертво как с Kimtigo.При этом при подключении через USB3 мост обрабатывает ошибку и читает дальше.
Скрины
Не встречал такого. Все ссд и SATA и PCI-E отваливались строго на определенных секторах. Если попытаться прочитать именно битый сектор - сразу отвалится. То есть дело в том что прошивка диска зависает вместо обработки ошибки.
Проверил. Вставил в M.2. Один из этих Kimtigo.
Загрузил Linux с флешки. Запустил dmesg -Wt и ddrescue
Сначала ddrescue зависла. В dmesg одно сообщение
Через минуту завис комп полностью.
Думаю что бесперспективно пытаться через PCI-E глючные SSD читать.
Именно эти диски не проверял. Так как их прислали отдельно от моноблоков где они стояли.
Но другие вели себя так: после ошибки пропадает из системы и до отключения включения компа не работает.
Вот например такой Kingston RBUSNS8154P3128GJ3 Выдавал в dmesg вот это. И после этого ничего не сделать до отключения включения всего ноутбука.
То есть нужно тогда делать аппаратное отключение питания для M.2 слота. Можно наверно через какой нибудь райзер сделать. Но из за глюков по шине PCI-E комп может вообще зависнуть. Некоторые SSD вешали систему.
Сфотографировал. Слишком мелкие контакты. Щупами туда лезть я не буду.
Фото
По сути для ускорения процесса копирования, даже если удастся как то задействовать PERST#, и это сработает - это ничего не даст. Так как большую часть времени занимает ожидание обработки ошибки прошивкой SSD, ядром Linux и процессом ddrescue
В плане софта возможно еще есть потенциал куда дорабатывать.
Единственное правильное решение это расковырять прошивку SSD и отключить контроль ошибок. Но это решение не универсальное.
Долго это ждать пока ddrescue поймет что не читается. Опция --timeout=0 не помогает.
А передергивание по питанию быстро происходит. Тут проблема в том что передернуть не дожидаясь ddrescue можно, но тогда в map файле этот сектор как битый не будет отмечен и позиция не поменяется.
А как именно его использовать ?
Линукс делает reset но это не помогает. Возможно какой то другой reset.
Как насчет такой схемы для свежего, не поддерживаемого в Win7 железа.
На железе непосредственно работает линукс, и использует современную встроенную в процессор видеокарту Intel/AMD.
Семерка запускается в виртуальной машине. И туда проброшены все USB устройства. А также дискретная видеокарта, для которой есть драйвера под Win7.
Чисто гипотетически вроде бы не должно быть проблем. Кроме того что вывод с дискретной видеокарты должен быть на отдельный монитор, либо через переключатель или монитор с несколькими портами.
Еще вариант, можно использовать 2 монитора и 2 комплекта клавиатура+мышь. Второй пробросить в виртуальную машину с Win7. Тогда один комп будет для двух рабочих мест. Одно с линукс, второе с Win7.
Я с этими утилитами не работал. Их нельзя распространять. И навскидку есть еще одна проблема. Для них также как для драйверов NVIDIA нужно собирать модуль. Для разных поколений видеокарт разные версии MODS. Для старых версий нужны старые версии ядра Linux. То есть тогда придется добавлять еще несколько версий ядра специально для MODS.
У вас на картинке с пингвином в мусорном баке плата под AMD AM3 или FM1/FM2 возможно. Это никак не 2006г вообще.
Опубликовал новый вариант скрипта ddrescue-loop v0.2 ddrescue-loop-v0.2.gz
С поддержкой восстановления с USB и Power-off and power-on cycle посредством USB Relay Module LCUS-1 CH340 либо uhubctl
Подразумевается подключение питания на USB/SATA диск через контакты реле COM и NC Чтобы в выключенном состоянии питание проходило. А при подаче команды на включение реле - питание отключалось.
Реле пока не пришло. Работу скрипта проверил
Вручную отключая питание переключателем на докстанции после
ddrescue: Can't reopen input file: No such device or addressТакже добавил поддержку uhubctl. Возможно будет полезно для восстановления с флешек. Нужно проверять.
На али нашел такое устройство LCUS-1 5V USB Relay Module CH340
Можно попробовать раздербанить USB3 A - Type-C кабель, вытащить жилку питания и подключить док станцию AgeStar 31CBNV1C через него.
Спасибо за наводку.
uhubctl работает на моей плате для USB2.0.
uhubctl -l 1-1 -a 0uhubctl -l 1-1 -a 1
Также работает стандартное извлечение
udisksctl power-off -b /dev/sdcНо непонятно как потом обратно включить.
НО это все к сожалению не помогает в случае с неисправным NVMe SSD!
SSD Kimtigo на контроллере Maxio MAP1202 подключаю через док станцию AgeStar 31CBNV1C на контроллере JMicron JMS583 USB-NVMe
После
blk_update_request: I/O error, dev sdc, sector 1077232 op 0x0:(READ) flags 0x4000 phys_seg 129 prio class 0sd 6:0:0:0: rejecting I/O to offline device
Помогает только отключение-включение переключателем на док станции.
Не помогает и
usbreset 152d:0583Resetting USB to PCIE Bridge ... ok
scsi host6: uas_eh_device_reset_handler startusb 1-1.3: reset high-speed USB device number 37 using ehci-pci
scsi host6: uas_eh_device_reset_handler success
scsi 6:0:0:0: Device offlined - not ready after error recovery
Извлечение
udisksctl power-off -b /dev/sdcработать перестает.Это не для постоянно работающих машин. Для запуска на непродолжительное время для тестов. Для проверки работоспособности образов, диагностики клиентских Windows (с проблемами запуска) прямо с SSD.
Еще модификация строки запуска. Вернул размер сектора 4K, но добавил
-c 8то есть читать по 8 секторов за раз. По умолчанию 128 и с этим значением прошивка SSD сильно тупила. 32K за раз отрабатывает стабильно.Разумеется. Еще получаю сразу
--mftdomain файл.mapи сначала по нему вычитываю. После этого можно уже запустить DMDE и посмотреть что там есть.Продолжаю. Перезапустил с размером сектора 16K, вместо 4K. Побыстрее пошло
-b 16Kiddrescue-loop -ata 6 -loop 9999 -act 200 /dev/loop0 WD240.log -b 16Ki -O -P -m domain.map -u -r -1 -nИсправление v0.1.1
Теперь можно задавать таймаут больше чем установлен по умолчанию в ядре
Linux. Оказалось что это позволяет ядру дожидаться ответа диска вместо
оправок команды
ataN: hard resetting link-act 200показывает себя хорошо случае с этим SSD Western Digital SSD 240GB.Так удалось хотя бы начало диска скопировать ? Пробовали анализировать то что получилось c помощью например DMDE ?