Во-первых, признание: нет, я не делал резервных копий, которые должен был иметь.
Во-вторых, ситуация:
У меня Dell XPS 9550 с твердотельным диском под управлением Fedora 25.
Я работал над файлом и попытался сохранить его, когда мне сказали, что я пытаюсь сохранить его в файловой системе только для чтения. Оказывается, моя файловая система теперь доступна только для чтения, и повсюду происходят ошибки ввода-вывода.
Я смог сохранить некоторые файлы, отправив их по электронной почте через открытый веб-браузер, но это не помогло, и я не могу перезапустить его. Но у меня все еще есть интересующие файлы, открытые в редакторе. Кажется, я не могу нигде сохранить файлы, но могу скопировать их содержимое. Если бы я только мог найти способ отфильтровать содержимое файла, я мог бы сэкономить месяцы работы.
Но есть некоторые ужасные ограничения. Я попытался вставить USB-накопитель, но, похоже, ни одно устройство не представляет его, и команда mount умирает с ошибкой сегмента. Я могу попробовать ssh к другому компьютеру, но я получаю "ошибку шины", и она умирает. ping , dmesg , ifconfig , ничего из этого не работает. Но у меня есть vim less и ls и я могу создавать новые экземпляры bash .
Нет lynx , нет firefox , нет google-chrome . Там нет DVD-привода.
Похоже, мой SSD умер. Или, может быть, вся материнская плата. У меня в архиве есть ценные документы, у меня есть IP-адрес и сетевое соединение, я могу выполнить несколько случайных команд и еще 3500 на пути, который я могу попробовать.
cat и gcc вроде бы работают. Я могу писать в файлы в /tmp. У меня есть работающий экземпляр ipython который все еще работает.
Итак ... то, что я пробовал до сих пор, провалилось. Но я чувствую, что есть еще тысяча возможностей. Что я не рассматриваю? Как я мог получить эти файлы с моего умирающего компьютера?
Должен быть способ.
ОБНОВЛЕНИЕ: Новые вещи:
- Я потерял соединение с сетью из-за собственной глупости.
- Я написал скрипт на Python для замены
cpиcp -r - Если я не найду какой-либо способ создания записи
/devдля SD-карты или USB-накопителей, мои лучшие ставки для вывода данных - это экран и, возможно, динамики / аудиокабель. - Я пишу сценарий, чтобы попробовать читать файлы и выводить, какие из них доступны для чтения.
Предложения по-прежнему очень приветствуются!
ОБНОВЛЕНИЕ 2: более новые вещи:
- На умирающем компьютере я написал скрипт на Python, который будет поочередно читать файл и пытаться передать эти биты, мигая экраном одного цвета или другого. Сейчас он пытается создать двухбитный код, где красный, зеленый, синий и белый представляют двухбитную пару. Однако это не очень хорошо работает, поэтому я мог бы просто переключиться на два цвета и делать по одному.
- На другом моем ноутбуке (старый надежный Thinkpad, который я отказался от этой новой XPS) я написал сценарий, который читает с веб-камеры с помощью библиотеки OpenCV Python. Идея состоит в том, чтобы он декодировал коды, отправленные другим компьютером. Проблема в том, что частота кадров с камеры составляет примерно 15 кадров в секунду, что означает, что если бы у меня была идеальная, безошибочная передача, моя максимальная скорость передачи данных была бы 30 бит в секунду, то есть 225 байтов в секунду. Это 324 КБ в день.
- На умирающем XPS я могу использовать
tarчтобы упаковать нужные файлы в один архив, который составляет 1,7 МБ. К сожалению,gzip,bzip2,xz,lzopи любые другие утилиты сжатия недоступны. НО, используяzlibмодуль Python, я могу сжать этот файл до 820 КБ. Учитывая этот размер, я мог бы, вероятно, отправить эту вещь через пару дней. - Поскольку этот метод передачи, вероятно, будет очень подвержен ошибкам, я собираюсь реализовать коды Хемминга на XPS, чтобы добавить некоторую коррекцию ошибок при передаче данных.
- Скорее всего, будут осложнения, потому что это то, что происходит, но, по крайней мере, кажется возможным выполнимо получить эти данные!
- Так как это все еще довольно неудачный способ отправки данных, я больше посмотрел на USB-драйверы для последовательного порта. Модули, которые я пытался загрузить (
usb-serial-simple,usb-debug,safe-serial), выдают ошибки ввода -вывода . Я не думаю, что он встроен в ядро, потому что нет устройств /dev /ttyUSB *.
Спасибо за все предложения до сих пор - я знаю, что это даже не вполне определенный вопрос, так как вы, ребята, заранее не знаете, какие программы / файлы можно читать или нет. Все еще открыты для лучших предложений, чем этот видео подход!
ОБНОВЛЕНИЕ 3: Новые вещи
- У меня есть веб-камера PS3 Eye, и после отключения ее автоматического усиления и экспонирования я успешно считываю данные с XPS, хотя и с ошибкой в 1 байт в секунду. Это большой успех - первые данные отфильтрованы! Но скорость слишком медленная, чтобы вывести мои 820 КБ в любое разумное время, и уровень ошибок слишком высок.
- Проблема в том, что запись в терминал происходит слишком медленно. Обновления экрана не похожи на мгновенные, спасибо (я думаю) медлительности эмулятора терминала
urxvtкоторому у меня есть доступ. - Я обнаружил, что у меня есть доступ к компилятору Rust на XPS. Я переписал скрипт передачи, используя Rust, чтобы посмотреть, улучшит ли это скорость обновления терминала, но это не помогло.
- Поскольку я вряд ли смогу увеличить частоту кадров, мне придется постараться увеличить объем данных, получаемых за кадр. Мой текущий подход выглядит примерно так:
Правая половина по-прежнему является тактовым сигналом, который мигает, чтобы отметить появление новых кадров. Но теперь слева - это сетка, где каждая ячейка помечена красным квадратом в углу, а затем зеленая ячейка справа и вниз от красного квадрата мигает и выключается, чтобы указать немного. Красные квадраты должны позволить принимающему компьютеру откалибровать расположение ячеек. У меня пока нет данных, но я над этим работаю.
- Кто-то предложил мне заняться написанием QR-кодов вместо этих специальных цветовых схем. Я тоже собираюсь разобраться в этом и, возможно, реализовать это вместо этого сеточного подхода. Исправление ошибок было бы хорошим преимуществом, а также возможность использовать стандартные библиотеки для декодирования.
- Я узнал, что у меня есть доступ к libasound (звуковая библиотека ALSA), но не к заголовочным файлам, связанным с ним (
alsa/asoundlib.hили что-то еще). Если кто-то знает, как использовать разделяемую библиотеку без заголовков, или может помочь мне написать только правильный заголовок, позволяющий мне выводить аудио, тогда у меня может быть аудио-способ вывода файлов. - С другой стороны, если кто-то может помочь мне манипулировать USB-устройствами без доступа к libusb, то, возможно, я мог бы что-то сделать с этим?
Движение вперед!
ОБНОВЛЕНИЕ 4: аудио выход произведен!
Пользователь Francesco Noferi проделал большую работу, помогая мне использовать библиотеку ALSA, упомянутую в предыдущем обновлении. У компилятора C была проблема, но с помощью компилятора Rust я смог использовать FFI для прямого вызова libasound . Я сейчас воспроизвел кучу своих данных через аудио, и это звучит как музыка для моих ушей! Все еще нужно установить реальный канал связи, но я чувствую себя очень обнадеживающим. На данный момент моя работа в основном заключается в реализации модема, так что, если у кого-то есть какие-либо рекомендации относительно хороших способов сделать это, я весь слух. В идеале модуляция, которую легко реализовать вручную, и демодуляция, для которой есть существующая библиотека, которую я могу использовать. Поскольку это может происходить напрямую через аудиокабель, а не через телефонную сеть, теоретически мы можем сделать намного лучше, чем 56 кбит / с или что-то еще, когда был стандарт, но на практике кто знает, что мы получим.
Спасибо всем, кто следит за этим здесь и на /r /techsupportmacgyver, а также на /r /rust, которые внесли много отличных предложений. Собираюсь внедрить этот "модем" в ближайшее время, а затем я закончу это эпилогом. Я думаю, что я мог бы разместить свой код где-нибудь, чтобы другие отчаянные люди могли использовать его в будущем - может быть, даже хранилище странных инструментов эксфильтрации, которые легко набрать в умирающую машину вручную? Посмотрим что получится.
ОБНОВЛЕНИЕ 5: Мне потребовалось много времени на борьбу с ALSA и моим дешевым USB-устройством захвата звука StarTech (без встроенной линии на принимающем ноутбуке), и многие фальстарты пытались свернуть мой собственный протокол передачи, но, наконец, по совету некоторых Мои друзья-радиолюбители Ham Я реализовал линейный протокол RTTY со скоростью 150 бод, что на практике дает примерно 10 байт в секунду. Это не супер быстро, но это довольно надежно. И я почти закончил передачу своего файла 820 КБ, проверенного с помощью контрольных сумм CRC32 (используя функциональность crc32 из модуля Python zlib , к которому у меня есть доступ). Поэтому я объявляю победу и хочу еще раз поблагодарить! Я потрачу еще немного времени на поиск дополнительных файлов, которые можно будет прочитать и которые я могу передать, но основа на месте. Было весело работать со всеми вами!
ЗАКЛЮЧИТЕЛЬНОЕ ОБНОВЛЕНИЕ:
На умирающей машине:
$ tar cf ./files
$ ./checksum.py ./files.tar 9999999
Part 1 checksum: -1459633665
$ ./zlib_compress.py ./files.tar
$ ./checksum.py ./files.tar.z 9999999
Part 1 checksum: -378365928
$ ./transmit_rust/target/debug/transmit ./files.tar.z
Transmitting files.tar.gz over audio using RTTY
Period size: 2048
Sample rate: 44100
Samples per bit: 294
Sending start signal.
Transmitting data.
nread: 2048
nread: 2048
...
nread: 2048
nread: 208
Transmission complete. Sending hold signal.
На спасательной машине:
$ minimodem --rx -8 --rx-one -R 44100 -S 915 -M 1085 --startbits 3
--stopbits 2 --alsa=1 150 -q > ./files.tar.z
$ ./checksum.py ./files.tar.z
Part 1 checksum: -378365928
$ ./zlib_decompress.py ./files.tar.z
$ ./checksum.py ./files.tar
Part 1 checksum: -1459633665
:-)