4

Пожалуйста, опубликуйте свои мысли, идеи или что-нибудь, что вы можете придумать. Мне было бы очень интересно посмотреть, что кто-нибудь еще думает.


Общая проблема


Когда я устанавливаю простое Java-приложение (которое я написал) для запуска при загрузке (в фоновом режиме) через /etc/init.d/, оно работает на liveUSB, на котором я его явно устанавливаю. Когда я делаю копию этой флешки, она никогда не загружается успешно. При загрузке копии liveUSB приложение Java всегда будет зависать, когда процесс загрузки liveUSB достигает моего сценария. Мой сценарий, который делает именно то, что он должен делать, даже каждые 5 минут и будет работать вечно, пока вы не выключите машину.

  1. Мой сценарий блокирует все остальное
  2. Ничто не загружается за пределы моего сценария
  3. Вы не можете отменить мой скрипт
  4. Нет графического интерфейса
  5. Единственный текст, который вы видите, это вывод командной строки из моего скрипта

Настройка и тестирование - все идет хорошо :)


У меня Linux liveUSB с 3 разделами. Простое стандартное изображение Xubuntu загружается.

  • sda1> 2 Гб хранения
  • sda2> 2 Гб система
  • sda3> Осталось гб за каспера

Я создал простое Java-приложение, которое запускается в фоновом режиме при запуске. Чтобы получить это далеко, я следовал за этими шагами:

  1. Скомпилированное Java-приложение в классы
  2. Размещенные файлы классов в /home /user /folder /
  3. Скопировал мой скрипт startup.sh в /etc/init.d/
  4. Пока внутри /etc/init.d/
    • Набрал «update-rc.d startup.sh start 20 2 5. Stop 20 0 1 6».
    • Это обновленные уровни запуска успешно
  5. Теперь я могу перезапустить / перезагрузить / выключить любую операцию, и все работает отлично!

Копия - вот где это становится сложно!


При создании копии этой флешки я выполняю следующие шаги:

  1. Гора sda2
    • скопируйте все из этой папки в /home /user /Desktop /tmp-system /
  2. Гора sda3
    • скопируйте все из этой папки в /home /user /Desktop /tmp-casper /
  3. Зайдите в /home /user /Desktop /tmp-system /
    • Введите "tar -cvf system.tar."
  4. Зайдите в /home /user / рабочий стол /tmp-casper /
    • Введите "tar -cvf casper.tar."
  5. Размонтируйте
    • sda2
    • sda3
  6. Подключите пустой USB (например, SDB)
    • Настроить разделы (То же, что и карта, с которой вы копируете)
    • Разбить на перегородки
      • tar -xvf system.tar ... в sdb2
      • tar -xvf casper.tar ... в sdb3

Тестирование - вот где все идет не так!


  1. Подключите недавно созданный LiveUSB к компьютеру
  2. Загрузка с USB
  3. Все начинает нормально загружаться
  4. Java-приложение, которое я написал, запускается
    • Процесс загрузки зависает навсегда
    • Нет доступных подсказок cmd
    • Нет графического интерфейса
    • Это как если бы поток работал (и это так! Вывод можно просматривать каждые 5 минут - именно так и должно быть)

Решение Попытки и Gotchas


1

Я могу смонтировать скопированный liveUSB, отредактировать файл startup.sh, чтобы не запускать мое Java-приложение, и оно все равно не загрузится (как я и подозревал?).


2

Если я использую "dd if = sda of = sdb", копия liveUSB будет работать отлично. Однако это не приемлемое решение. Если бы я скопировал флешку 16 ГБ с dd на флешку 64 ГБ, это превратило бы флешку 64 ГБ в 16 ГБ. Это также значительно усложнит изменение значений, которые необходимо изменить в каждом разделе.


3

Протестировано множество вариаций файла startup.sh и самого приложения Java. Все из которых выдают одну и ту же ошибку.


4

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


5

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


6

Я также смонтировал sda2 & sdb2, используя cp для копирования всего непосредственно с одного на другое, затем следовал тому же для sda3 & sdb3. Это приводит к той же ошибке.


ДОПОЛНИТЕЛЬНЫЕ ТОЧКИ


  1. Раздел sda3 зашифрован с помощью cryptsetup
  2. В system.tar есть 2 файла (это будет sdb2, пришедший из sda2), значение которого будет изменено после его записи на USB.
    • Эти два значения не вызывали никаких проблем в прошлом и всегда менялись каждый раз при создании нового liveUSB
  3. В файле casper.tar есть 1 файл (это будет sdb3, пришедший из sda3), значение которого будет изменено после его записи на USB.
    • Это значение не вызывало никаких проблем в прошлом и всегда менялось с каждым новым созданным liveUSB.

Процесс проверки контрольной суммы


Оригинальное живое изображение USB

Работает liveUSB> sda empty usb> sdb

шаги:

  1. Смонтировать, скопировать и контрольную сумму sda2
    • Набрал "mount /dev /sda2 /media /sda2"
    • Наберите "tar -C /media /sda2 -cvf ~ /Desktop /system.tar."
    • Набрал "find. -Type f -exec sha1sum {} ';' > /tmp/sda2_checksum.txt "
    • Набрал "umount /media /sda2"
  2. Смонтировать, скопировать и контрольную сумму sda3
    • Набрал "mount /dev /sda3 /media /sda3"
    • Наберите "tar -C /media /sda3 -cvf ~ /Desktop /casper.tar."
    • Набрал "find. -Type f -exec sha1sum {} ';' > /tmp/sda3_checksum.txt "
    • Набрал "umount /media /sda3"
  3. Создать разделы для SDB
  4. Смонтировать, написать & контрольную сумму sdb2
    • Набрал "mount /dev /sdb2 /media /sdb2"
    • Наберите "tar -C /media /sdb2 -xvf ~ /Desktop /system.tar"
    • Набрал "find. -Type f -exec sha1sum {} ';' > /tmp/sdb2_checksum.txt "
    • Набрал "umount /media /sdb2"
  5. Смонтировать, написать и контрольную сумму SDB3
    • Набрал "mount /dev /sdb3 /media /sdb3"
    • Наберите "tar -C /media /sdb3 -xvf ~ /Desktop /casper.tar"
    • Набрал "find. -Type f -exec sha1sum {} ';' > /tmp/sdb3_checksum.txt "
    • Набрал "umount /media /sdb3"
  6. Сравнить контрольные суммы
    • sort /tmp/sda2_checksum.txt -o /tmp/sda2_checksum.txt.sort
    • sort /tmp/sda3_checksum.txt -o /tmp/sda3_checksum.txt.sort
    • sort /tmp/sdb2_checksum.txt -o /tmp/sdb2_checksum.txt.sort
    • sort /tmp/sdb3_checksum.txt -o /tmp/sdb3_checksum.txt.sort
  7. Результаты

sda2 & sdb2

Напечатано "diff sda2_checksum.txt.sort sdb2_checksum.txt.sort"

45d44
< 2ddf9802c9c15ac6e4575cc9de32e3530eae6b7d  ./efi/boot/grub.cfg
82d80
< 59bb2775a8e7e499e0590b7b8c2492eb250fb7d8  ./syslinux/txt.cfg
154a153
> ae6c127713e01fc5fb4a2e4e28f6bbddc6bd6af5  ./efi/boot/grub.cfg
158a158
> b78090b66b4e3fa04ca9d466ee78c9060adf744e  ./syslinux/txt.cfg

Эти 2 файла содержат 1 значение в каждом изменяемом файле. Все остальное тоже самое. Результаты именно такие, какими они должны быть.

sda3 & sdb3

Напечатано "diff sda3_checksum.txt.sort sdb3_checksum.txt.sort"

Идентично - имейте в виду, что это оригинальное изображение LiveUSB.

Я опубликую дальнейшие результаты сравнения, поскольку я работаю через следующий раздел.



СЛЕДУЮЩИЕ ШАГИ - План действий

Начиная с образа liveUSB без скриптов, которые нужно запустить.


Шаг 1 - Успех / Неудача?

УСПЕХ - контрольные суммы совпадают, как они должны


  1. Обновите Java на liveUSB с 6 до 7
  2. Воссоздать гудрон
  3. Создать новый liveUSB из tar's
  4. Тест живого USB

Шаг 2 - Успех / Неудача?

УСПЕХ - контрольные суммы совпадают, как они должны


  1. Создать /home /user /folder /
  2. Скопируйте файлы классов для Java-приложения в /home /user /folder /
  3. Воссоздать гудрон
  4. Создать новый liveUSB из tar's
  5. Тест живого USB

Шаг 3 - Успех / Неудача?

УСПЕХ - контрольные суммы совпадают, как они должны


  1. Добавьте startup.sh в /etc/init.d/
  2. Без вызова update-rc.d
  3. Воссоздать гудрон
  4. Создать новый liveUSB из tar's
  5. Тест живого USB

Шаг 4 - Успех / Неудача?

УСПЕХ - контрольные суммы совпадают, как они должны

(Я никогда не делал это так успешно раньше) - однако значение, которое нужно записать, еще не вставлено в раздел casper (sda3).


  1. Введите "update-rc.d startup.sh start 21 2 5."
  2. Воссоздать гудрон
  3. Создать новый liveUSB из tar's
  4. Тест живого USB

Шаг 5 - Успех / Неудача?

УСПЕХ - контрольные суммы совпадают, как они должны

Я не могу поверить, что это сработало! Что приводит меня к ... (Проще говоря, это хорошо) Почему мир не работал раньше?

- случайно это была Версия 13, которая работала.


  1. Загрузись вживуюUSB
  2. Вставьте значение для перезаписи в casper (sda3) перед созданием tar
    • Пока работает с liveUSB
    • Отредактируйте файл конфигурации в /home/user/folder/config.properties
  3. Отключение liveUSB
  4. Воссоздать гудрон
  5. Создать новый liveUSB из tar's
  6. Тест живого USB


ИЗОБРАЖЕНИЕ ПОЛНОЕ !!

Я еще не закончил с этим!

* Процесс записи на USB никогда не менялся.

Почему это не сработало раньше?

  1. Тар метод? - Только небольшое изменение ...
    • Из "tar -cvf casper.tar."
    • TO "tar -C /media /sda3 / -cvf ~ / Desktop / casper.tar.
    • Разве эти строки не выполняют одно и то же?
    • Я буду проверять это вскоре по дороге. - Я подозреваю, что нет никакой разницы.
  2. Разрезать процедуру на отдельные этапы?
    • До:
      • В соответствии с СЛЕДУЮЩИМИ ШАГАМИ - он же План действий, я выполнил бы все эти шаги, прежде чем создать новый образ.
    • После:
      • СЛЕДУЮЩИЕ ШАГИ - иначе План действий был точно выполнен
    • Может ли это быть разница?
    • Я буду проверять это вскоре по дороге.
  3. Может ли удаление больших (или маленьких) файлов из каталога / home / в разделе casper (sda3) вызвать какое-то повреждение?
    • Я понятия не имею..?
    • Я буду проверять это вскоре по дороге.


Дальнейшее тестирование - я хочу мой ответ!

Начиная с оригинального живого изображения USB.

  1. Обновите Java на liveUSB с 6 до 7
  2. Создать /home /user /folder /
  3. Скопируйте файлы классов для Java-приложения в /home /user /folder /
  4. Добавьте startup.sh в /etc/init.d/
  5. Введите "update-rc.d startup.sh start 21 2 5."
  6. Отредактируйте файл конфигурации в /home/user/folder/config.properties

Все сразу шаг в этот раз. - Это будет работать?


Тест 1 - Успех / Неудача?

ПОТЕРПЕТЬ ПОРАЖЕНИЕ!


  1. Старый метод дегтя

Тест 2 - Успех / Неудача?


  1. Старый метод дегтя
  2. Удаленный сгенерированный файл в /boot /
    • Этот файл создается моим скриптом, когда записывается раздел casper (sda3), содержит только идентификатор для проверки, не влияющий на процесс загрузки.

Тест 3 - Успех / Неудача?


  1. Новый метод tar

Тест 4 - Успех / Неудача?


  1. Новый метод tar
  2. Удаленный сгенерированный файл в /boot /
    • Этот файл создается моим скриптом, когда записывается раздел casper (sda3), содержит только идентификатор для проверки, не влияющий на процесс загрузки.

Результаты


Я буду тестировать в следующем порядке:

Тест 1 -> Тест 3 -> Тест 4 -> Тест 2

Если Тест 1 работает ... Я пойду выпрыгнуть из окна! - Я понятия не имею, почему это сработало бы сейчас, потому что я проверял это много раз и каждый раз получал неудачные ботинки. - Возможно, процесс cp или tar был как-то поврежден.

Когда тест 1 не проходит: если тест 3 работает ... - Метод tar вызывал ошибку. - Я не понимаю, что было бы не так со старым методом tar по сравнению с новым методом tar.

TBC ...

2 ответа2

2

Учитывая ваше описание проблемы, я подозреваю, что происходит нечто иное, чем вы описываете. В любом случае попробуйте это:

# sda2
mount /dev/sda2 /mnt/tmp
tar -C /mnt/tmp -cf ~/Desktop/sda2.tar .
umount /dev/sda2 
# ... repeat for sda3 ...
# do your create partition shenanigans
mount /dev/newsda2 /mnt/tmp
tar -C /mnt/tmp -xpf ~/Desktop/sda2.tar
umount /dev/newsda2
# repeat ...
# test ..

Если это работает, то, скорее всего, ваш /home смонтирован noexec или является какой-то файловой системой fubar, потому что проблема заключалась в удалении бита выполнения.

Если это не работает, отредактируйте скрипт запуска, чтобы получить отладочную информацию, такую как вывод mount, содержимое системного журнала и т.д., И поищите там помощь.

Вы также можете сгенерировать контрольные суммы для каждого файла и сравнить копию с оригиналом:

find . -type f -exec sha1sum {} ';' > /tmp/sda2_checksums.txt

для каждого смонтированного раздела & diff файлы /tmp/*_checksums.txt

0

В ответ на «Попытки решения и ошибки № 2» относительно использования команды dd:

Использование команды dd для клонирования исходного Live USB не превращает флешку 64 ГБ в флешку 16 ГБ. Это будет сделано только в том случае, если вы решите не перераспределять флешку 64 ГБ после использования команды dd. Вы можете изменить размер раздела, чтобы восстановить все оставшееся свободное (нераспределенное) пространство, оставшееся на флешке 64 ГБ после использования команды dd.

Вы можете изменить разделы, используя один из редакторов разделов GParted или Parted Magic, чтобы восстановить любой объем свободного пространства от 16 ГБ до 64 ГБ на клонированной флэш-карте USB после использования команды dd.

В результате команда dd не превращает флешку 64 ГБ в флешку 16 ГБ, используя GParted или Parted Magic после запуска команды dd, чтобы вернуть оставшуюся часть флешки 64 ГБ.

Используйте программу Linux Disk Utility для вашего дистрибутива Linux, чтобы проверить пространство раздела как свободное или выделенное.

Вы можете узнать GParted из учебника «Программное обеспечение для создания разделов GParted - Полное руководство» по адресу: http://www.dedoimedo.com/computers/gparted.html

Информацию о Parted Magic можно найти по адресу: https://en.wikipedia.org/wiki/PartedMagic, но по моему опыту я бы порекомендовал GParted, так как Parted Magic был полным дистрибутивом инструментов, если вы не предпочитаете более поздний подход из того, что вы узнали. об этом.

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .