Установка OEM преобразовывается в регулярную установку. Где файлы?
Фон: установка OEM Ubuntu 18.04 на Dell Latitude. Обратите внимание, что это не установка Ubuntu OEM, скорее Ubuntu 18.04 было установлено мной использующий опцию "Install as OEM".
При исследовании меню пользователь нажал на что-то, что после следующей начальной загрузки изменило установку OEM в регулярную установку с именем пользователя кроме oem. Ему предложили с обычным экраном установки и заполнил его в меру своих способностей. Ни в каком месте было там предупреждение, что данные будут потеряны. Система была сразу закрыта, и у меня есть диск, теперь смонтированный только для чтения на моем рабочем столе.
Теперь, когда это преобразовывается в регулярную установку, как можно было бы пойти о восстановлении данных, в которых был /home/oem/? Отметьте это extundelete ничто не мог найти удаленным на диске, но я действительно вижу что пользовательское /opt/ каталог с приложениями сторонних производителей все еще неповрежден.
Я использовал autopsy для сканирования диска и я действительно вижу, что существует файл (не каталог) назван /home/oem/ но его содержание не кажется полезным: https://pastebin.com/XXCiu7Bb
Я также попытался открыть раздел с testdisk (Инструмент Photorec), но также и там я вижу файл /home/oem но не каталог /home/oem/ который я знаю, чтобы быть корневым каталогом пользователя OEM. Возможно я создал этот файл случайно на ранней стадии процесса восстановления, в то время как это было все еще в ноутбуке, но теперь у меня есть диск, смонтированный только для чтения на другом компьютере. Да я знаю, что некоторые данные, возможно, были потеряны из-за диска, монтируемого чтение-запись.
Как я мог бы восстановить какие-либо файлы, которые пользователь имел в установке OEM? Я был бы доволен чем-либо от /home/oem/ каталог, который больше не существует, но главным образом текст и файлы ODT, если это возможно.
2 ответа
Хорошие новости сначала
Хорошие новости - то, если бы Пользователь, OEM была удалена и новый пользователь, был создан в, он - место затем, скелетные созданные файлы, надо надеяться, были бы тем же размером как скелетные файлы, удаленные от Пользователя OEM. Затем, если бы новый пользователь не создал новых файлов помимо этого, новые файлы, созданные Пользователем, то OEM, надо надеяться, все еще была бы на диске в заброшенных секторах. Надо надеяться, единственные потерянные файлы OEM были бы скелетными файлами OEM, просто замененными новыми пользовательскими файлами скелета в относительно тех же местоположениях. Подчеркивание, "надо надеяться"....
И теперь, "Но..."
Это, конечно, была бы большая работа для восстановления данных. Если Вы интересуетесь .odt файлы необходимо будет сначала найти, что строка символов представляет .odt файл. Например:
$ ll Double*
-rw-rw-r-- 1 rick rick 192599 Mar 18 2018 Double suspend.odt
$ head "Double suspend.odt" -c 400
PK��rL^�2
'mimetypeapplication/vnd.oasis.opendocument.textPK��rL���A�#�#Thumbnails/thumbnail.png�PNG
Таким образом, я мог grep мой жесткий диск (Вы не можете использовать этот метод хотя) для всех файлов со строкой"mimetypeapplication/vnd.oasis.opendocument.textPK":
$ time grepall "mimetypeapplication/vnd.oasis.opendocument.textPK"
Binary file /usr/share/cups/data/form_english_in.odt matches
Binary file /usr/share/cups/data/form_russian_in.odt matches
Binary file /usr/share/doc/fonts-sil-abyssinica/documentation/AbyssinicaSILGraphiteFontFeatures.odt matches
Binary file /usr/lib/libreoffice/share/template/common/internal/idxexample.odt matches
(... SNIP ...)
60.47user 22.74system 2:23.48elapsed 58%CPU (0avgtext+0avgdata 20788maxresident)k
61233744inputs+0outputs (0major+8533minor)pagefaults 0swaps
real 2m25.881s
user 1m0.507s
sys 0m22.759s
Теперь вместо использования grep необходимо было бы использовать инструмент, который ищет каждый байт жесткого диска, является ли это частью файла или нет. Примером были бы инструменты в закрытые Вопросы и ответы:
Затем существуют другие инструменты:
Наконец, если Вы только что записали новую Microsoft DOS 1.0 и потеряли единственную копию ассемблерного кода, Вы могли использовать сервис восстановления данных. Для которого можно погуглить. Наконец рассмотрите эту статью:
Давайте быстро запустимся с общей цели среды OEM: это позволяет создание и настройку единственной машины или маленький пакет машин за один раз. Это (относительно) подобно понятию Windows режима аудита. Типичный рабочий процесс OEM был бы похож на это:
- OEM загружает устройство и устанавливает режим OEM на устройстве.
- OEM настроит устройство, установит любые приложения, драйверы загрузки, и так далее.
- После конфигурации OEM подготовит устройство конечному пользователю к поставке. Система закроет вниз / перезапуск. [Я предполагаю, что это было шагом, который пользователь выполнил, инициировав эту всю ситуацию.]
- Если устройство будет "золотым ведущим устройством" и будет частью большего пакета устройств, то устройство будет отображено и клонировано к другим устройствам.
- Подготовленное устройство поставляется конечным пользователям.
- Пользователь получает подготовленное устройство, включает его и проходит установку OOBE (имя пользователя, пароль, и т.д.).
Большинство домашних или небольших семинаров, предлагающих установку Ubuntu, использовало бы установку OEM на основе для каждого устройства без любой обработки изображений. Конечный пользователь получил бы устройство, и на первой начальной загрузке они будут запрошены создать свою учетную запись и настроить все.
Так, что происходит с oem пользователь, когда устройство подготовлено к поставке? Ну, когда устройство подготовлено к поставке, оно начинает много задач, которые удаляют пользователя OEM, и готовит среду (удаляющий пакеты, обновляя systemd файлы единицы, и так далее). Все сценарии для подготовки расположены в /usr/sbin/oem-config*, и может быть просмотрен здесь. Пользователь - они выведенный назад в Повсеместность (экраны установки), где они проходят установку учетной записи.
Плохие новости здесь - то, что все эти задачи довольно интенсивны записью. Много из (недавно-) освобожденные блоки, который был занят /home/oem будет теперь использоваться для конфигураций нового пользователя и изменений, внесенных новой системой и конфигурациями OOBE.
Так как все это сказано, Вы ведете тяжелый бой, пытающийся восстановить эти данные. Потерянные файлы являются (относительно) маленькими, и как таковой очень легки быть перезаписанным, когда новая учетная запись создается. Инструменты как photorec/testdisk и autopsy вероятно, были бы Ваши лучшие выборы, поскольку Вы уже попробовали. Если эти инструменты ничего не могут восстановить, вероятно, нет намного больше, который может быть сделан, сохраняют для некоторых очень дорогих и/или очень мощных средств восстановления, к которым у людей обычно нет доступа.
Вы действительно упоминали существование a /home/oem файл, а также папка. Это может заставлять инструменты восстановления данных становиться немного перепутанными - файл не может иметь субфайлов, таким образом, любые попытки соединить дерево файла перестанут работать в этой точке. При выполнении инструмента восстановления диска, убедиться искать любые файлы, которые являются "осиротевшими" или иначе не принадлежат определенному каталогу.
Я собираюсь вернуться к своей рекомендации из комментариев использования photorec. Вместо того, чтобы фокусироваться на разделе - или восстановление уровня файловой системы как testdisk, это пытается вытянуть и восстановить отдельные файлы при игнорировании структуры файловой системы или каталога. Это является субоптимальным (пути, и потенциально имена файлов потеряны), но восстановление необработанных данных лучше, чем восстановление ничего. Я подозреваю autopsy имеет подобное "разное" выходное мусорное ведро, но я не достаточно знаком с инструментом, чтобы сказать Вам, где искать это.
Если photorec не может восстановить сами файлы, вероятно, что они были (главным образом) перезаписаны во время фазы персонализации, инициируемой пользователем. В этом случае могло бы быть лучше предоставить услуги эксперта судебно-медицинской экспертизы данных с доступом к необходимым инструментам и ноу-хау для восстановления данных как это.