-bash: 09,39: command not found

Честно говоря я не знаю, как вам такое исправлять. Когда содержимое отдельных файлов лежит под именами других, да ещё в них мусор, то как это определить то можно?

Ну в rpm-based дистрибутивах можно проверить контрольные суммы файлов, установленных из пакетов (для конфигов это бесполезно) и переставить битые пакеты. В deb- дистрибутивах, вроде, можно было сделать что-то подобное.

Но, в общем случае, это долгая ручная работа, например, если грохнулись настройки ротации логов, то всё будет работать, пока лог-файлы не забьют весь диск, но это вылезет далеко не сразу. Аналогично, если грохнулись настройли syslog'а, то тоже всё будет работать, но в логи писаться не будет, и потом, когда на форуме вас будут просить показать логи для решения той или иной задачи, вы даже не сразу поймёте, что от вас требуют.

А в целом не понятно, как такое могло произойти у вас, я такое видел только при восстановлении ФС с умирающего диска или после приколов vmware.

А в целом не понятно, как такое могло произойти у вас

Ну копировал он с битой ФС.

А в целом не понятно, как такое могло произойти у вас

либо железо битое, либо ТС делал бекап по живому, либо ТС делал проверку без размонтирования. Возможны комбинации и/или другое рукожопие.

Вы правы насчет моего рукожопия и не только. Основная проблема в том что эта система крутится на ARM (Raspberry Pi). Вместо штатной SD карты (на ней оставил только boot) - для ОС используется HDD. Да судя по всему поступил не правильно и копировал все по живой.

Попробую аналогично собрать debian в виртуальной машине и сравнить часть конфигов.

Не подскажите чем можно делать бекап на лету и отправлять его к примеру на яндекс диск?

либо ТС делал бекап по живому

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

А если железо бытое, понятно, что нужно копировать только данные, а всё остальное преставлять нафиг, чтобы потом какие грабли не всплыли.

Я безуспешно пытался допытаться, что именно делал ТС и, главное, зачем. Ваша очередь :-)

Странная битость ФС, от начала # /etc/cron.d/php5: до конца строки -delete верная информация. Размер 576 байт. У ext4 блок обычно 4 кбайт. Получается, что-ли, что ext4 при выделении нового блока под файл не зануляет его, а оставляет после конца файла старое содержимое?

да. этим занулением всегда XFS ругали

Получается, что-ли, что ext4 при выделении нового блока под файл не зануляет его

ну наверное быстрее записать один сектор (512б), а не все 8.

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

ну если командой dd, то может.

PS: вчера не посмотрел очередную серию сериала: смотрел с флешки в FAT, на которую корректно скопировал, но которую вынул ДО окончания umount. В результате серия X записалась наполовину. 20 минут X, потом Y/X вперемешку. Y — это та серия, которая была там раньше.

А ты говоришь — не бывает. С кривыми руками ВСЁ бывает.

Да, один сектор 512 байт, а там 576 байт информации, а потом мусор. Причём, файл явно создавался/записывался разом при установке дистрибутива, это не лог, который постоянно дописывается.

Получается, что ext4/ядро сначала считывает сектор, а потом пишет туда хвост файла. В случае данного файла был записан сектор 512 байт, а следущий сектор был считан и записан, чтобы в нём было 64 байта полезной информации и 448 байт старых данных, а не нулей. Это меня и удивило.

ну если командой dd, то может.

Вот здесь вот http://debianforum.ru/index.php?topic=6445.0 ТС заявлял, что копировал командой ″cp -pri″, а в этом треде, что использовал у ″cp″ опцию ″-a″.

С кривыми руками ВСЁ бывает.

Да, бывает. И что хуже, кривым рукам зачастую сопутствует кривая память и язык, так что невозможно точно узнать что именно делали эти кривые руки :-)) (Это просто наблюдение, а не попытка 5.2.)

а не нулей

я может неправильно тебя распарсил, но ^@^@^@^@ - это как раз нули. В генте такое в /var/log/messages сыпется, бага syslog-ng. пишутся бинарные нули и файл становится двоичным.

thecloneofmyown neverloved # file /var/log/messages
/var/log/messages: data
thecloneofmyown neverloved # cat /var/log/messages | grep -i error
Двоичный файл (стандартный ввод) совпадает
thecloneofmyown neverloved # cat /var/log/messages | strings | grep -i error
Jul 31 19:28:19 localhost /etc/init.d/lm_sensors[2732]: ERROR: lm_sensors failed to start

При просмотре в nano как раз такая же фигня -

Aug 3 11:19:37 ^@^@^@^@^@^@^@^@^@^@^@

Получается, что ext4/ядро сначала считывает сектор, а потом пишет туда хвост файла. В случае данного файла был записан сектор 512 байт, а следущий сектор был считан и записан, чтобы в нём было 64 байта полезной информации и 448 байт старых данных, а не нулей. Это меня и удивило.

скорее не ядро/фс, а само устройство.

Да, бывает. И что хуже, кривым рукам зачастую сопутствует кривая память и язык, так что невозможно точно узнать что именно делали эти кривые руки :-)) (Это просто наблюдение, а не попытка 5.2.)

вангую аппаратный сбой. Например выключение девайса во время работы.

я может неправильно тебя распарсил, но ^@^@^@^@ - это как раз нули.

дело в том, что «мусор» это часто — нули. Например ненужное место в файлах так забивают. EXT4 в курсе, не хранит и не копирует такие блоки (man cp, sparse). Но в данном случае ext4 тут не причём.

Да, точно это нули, а уже у меня mc головного мозга :(. Привык, что в Midnight Commander'е все непечатные символы выводятся точками. А ведь less, nano и т.д. выводя по-другому.

В следующий раз не буду играть в телепата и что-то измышлять без вывода hexdump.