Почему apt upgrade изменяет мой x-www- браузер на google-chrome-stable?

Нам нужно разделить вашу проблему на две части:

1. Восстановите массив для отсутствующего суперблока / dev / sda .
2. Обработка поврежденных данных на / dev / sdc

Восстановление массива

Я предполагаю, что блок размером 4 КБ, не восстановленный из / dev / sda, был суперблоком, потому что ваш раздел начинался с 1 МБ (2048 секторов) ), а суперблок начался в +8 секторах раздела (2056 секторов), точно на отметке 2056 сектора, где существует плохой сектор. Предполагается, что REST данных на этом диске не поврежден на 100%.

Проблема с - accept-clean в целом заключается в том, что вам нужно быть предельно осторожным, чтобы параметры точно соответствовали тому, что использовалось во время создания массива. Изменения в значениях по умолчанию с даты создания вашего массива вторник, 28 августа 17:44:52 2012 являются здесь вашим ВРАГОМ. Версия метаданных, предположение о растровом изображении (устройства размером более 100 ГБ теперь получают их автоматически), макет рейда и т. Д.

Если вы не совсем уверены, я настоятельно рекомендую клонировать ВСЕ 4 диска в другое место (в крайнем случае вы можете даже использовать один диск с 4 разделами каждый по 1 ТБ / 1953122952 секторов) и попытаться повторно -соберите это вместо этого. Поскольку / dev / sda начинает выходить из строя так же, как / dev / sdc , и вы, вероятно, купили все свои диски одновременно, возможно, даже две полные копии данных, на случай, если у вас возникнет еще один сбой диска при попытке восстановления (зависит от того, насколько ценными вы считаете свои данные).

Если Предположим, очистка работает с тестовой копией, у вас есть хорошие возможности для перемещения ее в другое место.

Вот вам некоторая справка по сценарию, обобщающая то, что вы дали выше (обратите внимание, что - изучите отчеты в единицах секторов для некоторых значений, но - создание принимает единицы измерения KiB).

#!/bin/bash
# Facts we know about your array, from your mdadm -E output.
num_devices=4
num_spares=0
chunk_size=512 # KiB
data_offset=1024 # KiB
drive_size=976561152 # KiB
uuid=87fdc598:a995d0f7:41123bcf:e2760aeb
metadata_ver=1.2
name=itake:0
bitmap=none
original_device_order=(/dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1)
# I assume you recovered:
# /dev/sda to /dev/sde
# /dev/sdc to /dev/sdf
# If not, adjust as needed.
#
# Read all the way to the bottom of my response first, because you
# MIGHT want to use 'missing' in place of /dev/sdf1 initially.
new_device_order=(/dev/sde1 /dev/sdb1 /dev/sdf1 /dev/sdd1)

mdadm --create /dev/md0 \
--level 5 --layout left-symmetric
-n $num_devices -x $num_spares \
--uuid $uuid \
--metadata $metadata_ver \
--chunk $chunk_size
--size $drive_size \
--data-offset $data_offset \
--name $name \
--bitmap $bitmap \
${new_device_order[@]}  

Очистка массива (вариант 1)

Мы знаем, что / dev / sdc имели поврежденные сектора в середине области данных, и в качестве немного более ядерного варианта вы можете передать отсутствует вместо / dev / sdf1 во время создания массива, а затем выполните mdadm --add / dev / md0 / dev / sdf1 для принудительной перестройки из другого устройства на / dev / sdf1 .

Очистка массива (вариант 2)

Теперь нам нужно исправить тот факт, что части / dev / sdc исчезли, а их место на / dev / sdf , есть просто обнуленные блоки.

echo repair >/sys/devices/virtual/block/md0/md/sync_action

В конце вы должны его починить, но я не уверен на 100% в поведении, которое будет предпринято для восстановления этих блоков.