Отправьте копию вывода сценария в файл
Кажется, что Вы уже убили mdadm суперблок. Если это раньше было там и было форматом 1.1 или 1.2, то, скорее всего, файловая система является при смещении 2 048 секторами. Можно работать e2fsck /dev/sdc1?offset=2048 вынудить это искать файловую систему, запускающуюся при том смещении. Если это находит его затем, можно изменить таблицу разделов для указания туда, где файловая система на самом деле запускается. Можно использовать parted /dev/sdc и unit s управляйте для использования единиц секторов. print таблица, отметьте запуск и сектор конца, затем rm раздел, затем воссоздайте его с mkpart и используйте тот же сектор конца, но добавьте смещение к сектору запуска.
Если 2048 не работает, Вы могли бы также попробовать 1985.
Возможно, ваш сценарий производит вывод в stdout и stderr , и вы получаете только один из этих потоков, выводимых в ваш файл журнала.
./ my_script.sh | tee log.txt действительно выводит все на терминал, но выводит только stdout в файл журнала.
./ my_script.sh> log.txt 2> & 1 будет делать наоборот, сбрасывая все в файл журнала, но ничего не отображая на экране.
Хитрость заключается в том, чтобы объединить два с tee :
./myscript.sh 2>&1 | tee log.txt
Это перенаправляет stderr ( 2 ) в stdout ( 1 ), затем направляет stdout в tee , который копирует его на терминал и в файл журнала.
Эквивалент zsh multios будет выглядеть так:
./myscript.sh >&1 > log.txt 2>&1
То есть перенаправить stdout как на исходный stdout, так и на log.txt (внутренне через канал на что-то, что работает как tee ] ), а затем перенаправить stderr на него (на конвейер к внутреннему tee -подобному процессу).
nohup позволяет продолжить работу, даже если консоль умирает или закрывается, полезно для длительных резервных копий и т. Д., Но здесь мы используем его автоматическое ведение журнала.
nohup myscript.sh & ; tail -f nohup.out