Многие SD-карты довольно хрупкие. У меня пи 2 года, и основные сбои были связаны с повреждением SD-карты по той или иной причине.
Мне интересно, есть ли какая-то разработка, чтобы "усилить" SD-карту при загрузке. Я помню что-то подобное в прошлом проекте, где uboot выбирал между 12 тарболами, если у любого из них была неверная контрольная сумма crc32. Затем он повторно скопирует проверенный файл всем остальным, которые были изменены после успешной загрузки.
Я хотел бы использовать свой пи в «постоянной» настройке, и было бы здорово, если бы он мог работать, даже не перепрошивая карту.
Есть ли какая-то разработка, уже проделанная таким образом? Хотя общая идея довольно тривиальна, заставить uboot работать должным образом, как правило, довольно болезненный процесс, которого я хотел бы избежать.
РЕДАКТИРОВАТЬ :
После некоторого более глубокого копания кажется, что то, что я предполагал, могло быть невозможным или возможным таким образом, чтобы дать какое-либо значимое преимущество. Здесь процесс загрузки описан . Код, над которым я работал, работал на первом уровне загрузки, поскольку на моей плате была программируемая вспышка для этого. С пи, это хранится в ПЗУ с завода. Все остальное исходит от SD-карты, поэтому, если карта повреждена, загрузчик второго этапа имеет столько же шансов быть уничтоженным, как и любой другой раздел.
Возможно, для этой цели можно злоупотребить загрузчиком ПЗУ, но сложно сказать, как это сделать. Код также кажется проприетарным.
Изменить 2:
Фактическое объяснение процесса загрузки конфликтует в зависимости от источников. Я постараюсь прочитать больше об этом
Вы не должны испытывать частую драматическую коррупцию, даже если власть иногда теряется.
Если файловая система имеет ненулевое значение в шестом столбце
/etc/fstab, она будет проверена, чтобы выяснить, нужно ли сканировать ее на наличие ошибок перед ее монтированием. Обычные дистрибутивы pi (должны) имеют этот набор для/dev/mmcblk0p1корневого раздела файловой системы (на Raspbian,mmcblk0p2). Для файловых систем ext4 (таких как root fs) это означает, что это происходит независимо от каждого N монтирования; значение N см. в разделе «Максимальное количество монтирования» в выходных данных изtune2fs -l /dev/[partition]; Вы можете отрегулировать это значение, используяtune2fs -c(см.man tune2fs).Он также будет сканироваться, если файловая система не была правильно размонтирована. Это сделано с
e2fsck. В большинстве случаев все будет хорошо. Однако есть вероятность, что вы можете потерять данные из-за коррупции; доказательства этого будут оставлены в/lost+found. Если это возможно (и это обычно так), файловая система все равно останется в пригодном для использования, не поврежденном состоянии. Тогда возникает вопрос, был ли потерян какой-то критический компонент в исправлении, но, опять же, это было бы очень необычно.Причина того, что это вряд ли повлияет на что-то критическое, заключается в том, что большая часть этого материала, хотя и технически не только для чтения, не меняется в обычном порядке. Система имеет тонны данных
/binи/libзагружается в память в любой заданный момент, но нет никакого намерения изменять их источник на диске, поэтому нет шансов, что диск не синхронизируется с этими несуществующими изменениями.Хотя я не знаю, каковы правила для первого раздела vfat, содержащего ядро и прошивку (поскольку он не отформатирован как ext), я бы предположил, что возможна некоторая аналогичная проверка, и в любом случае логика последнего абзаца применяется - этот материал меняется только для системных обновлений. На самом деле, если вы хотите быть по-настоящему параноиком, вы можете смонтировать его только для чтения, за исключением обновлений (или вообще не монтировать, так как это не нужно после завершения нормальной загрузки).
После всего этого, вы почти никогда не будете испытывать серьезного искажения, если вы действительно часто бросаете кости, сокращая власть (и даже в этом случае это должно быть нечасто). Если вы часто сталкиваетесь с коррупцией, значит что-то очень серьезно не так. Здесь было, по крайней мере, несколько человек, сообщавших о проблемах с коррупцией, даже при использовании файловой системы только для чтения , что немного сбивает с толку. Это подразумевает, что повреждение произвольно вызвано неисправным оборудованием или программной ошибкой.
И действительно, я думаю, что была такая ошибка, которая могла повлиять на pis произвольно, начиная с 2013 года и до середины конца 2014 года (предполагая, что ОС обновляется). У меня есть предчувствие, у нас было меньше "Моя SD-карта повреждена!" посты за последние 4-6 месяцев (но не примечание. Я не сделал никакого реального учета, чтобы подтвердить это).
источник
Возможно, вы захотите использовать флэш-накопитель USB / жесткий диск USB.
Они более надежны, чем SD-карты
Вот тема, которая описывает, как это сделать
источник
Самовосстановление является проблемой любого дистрибутива Linux, где fsck находится в файловой системе, наиболее подверженной повреждению. Это проблема raspbian для почти всех дистрибутивов Linux - в наши дни они любят помещать все [включая / boot в случае Ubuntu !! ??] на один большой раздел ext4.
Доступный только для чтения корневой раздел делает чудеса для избежания проблемы уничтожения загрузки, когда Linux сталкивается с проблемами файловой системы, прежде чем у него появится возможность запустить fsck.
Но даже корень чтения / записи, который редко обновляется, является огромным шагом вперед.
Raspbian отлично работает на корне только для чтения. Для настройки требуется немного усилий, и, конечно, вы должны быть готовы к «mount -o remount, rw /» перед любыми изменениями в корневой файловой системе.
источник