LINUX.ORG.RU
решено Форум — Linux-hardware  

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

 


0

3

m2 диск с linux отправился к праотцам, перед этим сохранил backup основной системы на свой рейд. Поставил диск с виндой, hdd диски с linux soft raid отключать не стал, которой и пользовался парой дней. Приехал новый m2 диск и тут возникли проблемы, что raid не виделся при попытке восстановлении backup-а. Поставил debian с нуля и вижу, что винда (?) рейд превратила во что-то не хорошее:

Disk /dev/sda: 10,91 TiB, 12000138625024 bytes, 23437770752 sectors
Disk model: ST12000VE001-38N
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xde49c90a

Device     Boot Start        End    Sectors Size Id Type
/dev/sda1           1 4294967295 4294967295   2T ee GPT

Partition 1 does not start on physical sector boundary.


Disk /dev/sdb: 10,91 TiB, 12000138625024 bytes, 23437770752 sectors
Disk model: ST12000VE001-38N
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: AC9E9194-5A1D-44BD-8ABB-69E6B33355E7

Device     Start   End Sectors Size Type
/dev/sdb1     34 32767   32734  16M Microsoft reserved

Partition 1 does not start on physical sector boundary.

Чего-нить сделать можно с достать бекап и кучу документов? гугел говорит какую-то чушь.

★★★★★

Последнее исправление: vtVitus (всего исправлений: 4)
← Помогите найти driver для MTCH6301
DDR4 vs. DDR5 →
  1 2 →
Ответ на: комментарий от mx__

Я не проверял что там с raid5 но у него есть очевидное отличие: оотвалившйся один диск потом не сможет сделать вид что он и есть актуальный массив. А так, пройди по ссылке на тему то я дал, там именно не запускался сервер с зеркалом из которого пропала половина.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Проверял года-два назад, bookworm со всеми апдейтами.

Плевое дело перепроверить на виртуалке на свежайшем стабильном дебиане (trixie).

То что у кого-то были проблемы с этим в конкретном случае (по ссылку что ты приводил) само по себе ничего не значит, мало ли что там было наверчено.

Что конкретно проверять?

Установить trixie с raid1 mdadm зеркало на / , потом выключить, в выключенном состоянии вытащить один из дисков, и потом запустить?

manul91 ★
()
Ответ на: комментарий от firkax

Я почитал ту тему … беру тайм аут до среды (как бы не забыть), там погляжу на реальных дебиан серваках …

Но в шапке это не так работает. Вытащили винт. Грузится граб, он имеет строку загрузки где указан root и uid раид раздела. Причем этот uid одинаковый для всех дисков так как они в раиде. И эти же uid так же прописаны в /etc/mdadm.conf

Там человек вообще не написал ни вывод blkid ни строки груба для запуска ;(

mx__ ★★★★★
()
Ответ на: комментарий от firkax

Проверил в debian на виртуалке, все работает.

(убрал quiet из kernel line чтобы смотреть на сообщения. Правда несколько медленней забутился с вытащенном диске, висел где-то 15-20 лишних секунд на каком-то local-block скрипте что не бывает если все нормально).

Процесс теста: инсталляция trixie stable с нуля в виртуалке, / на raid1, UEFI подключено (EFI на оба диска подшаманил чтобы бутился с любого).

Сначала пока с рейдом все нормально, ничего не трогаем.

Выключаем виртуалку.

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

Запускаем снова, теперь только с одним диском - все работает.

Расходимся, ложная тревога.

Вот результат после запуска:

root@debian-test:~# dmesg | grep md1
[  116.170130] md/raid1:md1: active with 1 out of 2 mirrors
[  116.170406] md1: detected capacity change from 0 to 36046848
[  177.102806] EXT4-fs (md1): orphan cleanup on readonly fs
[  177.104666] EXT4-fs (md1): mounted filesystem 750be247-574a-4afa-9cc8-bace54e390e2 ro with ordered data mode. Quota mode: none.
[  181.933540] EXT4-fs (md1): re-mounted 750be247-574a-4afa-9cc8-bace54e390e2 r/w.
root@debian-test:~# 
root@debian-test:~# cat /proc/mdstat 
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active (auto-read-only) raid1 sda2[0]
      1950720 blocks super 1.2 [2/1] [U_]
      
md1 : active raid1 sda3[0]
      18023424 blocks super 1.2 [2/1] [U_]
      
unused devices: <none>
root@debian-test:~# cat /etc/mdadm/mdadm.conf 
# mdadm.conf
#
# !NB! Run update-initramfs -u after updating this file.
# !NB! This will ensure that initramfs has an uptodate copy.
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md/0  metadata=1.2 UUID=db7490bc:a8145226:33d0a03e:f92d4dc2
ARRAY /dev/md/1  metadata=1.2 UUID=4cf70a58:2d86b830:eff2f233:bcb9c87e

# This configuration was auto-generated on Sun, 02 Nov 2025 13:55:08 -0500 by mkconf
root@debian-test:~# 
root@debian-test:~# lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
sda       8:0    0   20G  0 disk  
├─sda1    8:1    0  953M  0 part  /boot/efi
├─sda2    8:2    0  1.9G  0 part  
│ └─md0   9:0    0  1.9G  0 raid1 [SWAP]
└─sda3    8:3    0 17.2G  0 part  
  └─md1   9:1    0 17.2G  0 raid1 /
sr0      11:0    1 1024M  0 rom   
root@debian-test:~# efibootmgr -v | grep debian
Boot0001* debian2       HD(1,GPT,6f9e73da-2140-4648-a163-3e62860d9835,0x800,0x1dc800)/File(\EFI\debian\shimx64.efi)
Boot0004* debian        HD(1,GPT,c6367fff-b688-4570-9370-8b6f8723c267,0x800,0x1dc800)/File(\EFI\debian\shimx64.efi)
root@debian-test:~# ls -al /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 100 Nov  2 14:49 .
drwxr-xr-x 8 root root 160 Nov  2 14:47 ..
lrwxrwxrwx 1 root root   9 Nov  2 14:49 3caf28fc-ebb0-4486-9769-5ec78ee31304 -> ../../md0
lrwxrwxrwx 1 root root  10 Nov  2 14:47 5BA0-ED87 -> ../../sda1
lrwxrwxrwx 1 root root   9 Nov  2 14:49 750be247-574a-4afa-9cc8-bace54e390e2 -> ../../md1
root@debian-test:~# cat /etc/fstab 
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/md1 during installation
UUID=750be247-574a-4afa-9cc8-bace54e390e2 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=5BA0-ED87  /boot/efi       vfat    umask=0077      0       1
# swap was on /dev/md0 during installation
UUID=3caf28fc-ebb0-4486-9769-5ec78ee31304 none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
root@debian-test:~# 
root@debian-test:~# cat /boot/grub/grub.cfg | grep linux | grep boot
        linux   /boot/vmlinuz-6.12.48+deb13-amd64 root=UUID=750be247-574a-4afa-9cc8-bace54e390e2 ro  
                linux   /boot/vmlinuz-6.12.48+deb13-amd64 root=UUID=750be247-574a-4afa-9cc8-bace54e390e2 ro  
                linux   /boot/vmlinuz-6.12.48+deb13-amd64 root=UUID=750be247-574a-4afa-9cc8-bace54e390e2 ro single dis_ucode_ldr 
                linux   /boot/vmlinuz-6.12.43+deb13-amd64 root=UUID=750be247-574a-4afa-9cc8-bace54e390e2 ro  
                linux   /boot/vmlinuz-6.12.43+deb13-amd64 root=UUID=750be247-574a-4afa-9cc8-bace54e390e2 ro single dis_ucode_ldr 
root@debian-test:~# hostnamectl 
 Static hostname: debian-test
       Icon name: computer-vm
         Chassis: vm 🖴
      Machine ID: debd53a7af31403fbd3d2d4e249d672d
         Boot ID: f2992371a4bf4c3bb61a84877b341b47
    Product UUID: 5accc1b2-947e-6440-a405-00387bf6301d
    AF_VSOCK CID: 1
  Virtualization: oracle
Operating System: Debian GNU/Linux 13 (trixie)                   
          Kernel: Linux 6.12.48+deb13-amd64
    Architecture: x86-64
 Hardware Vendor: innotek GmbH
  Hardware Model: VirtualBox
 Hardware Serial: VirtualBox-b2c1cc5a-7e94-4064-a405-00387bf6301d
Firmware Version: VirtualBox
   Firmware Date: Fri 2006-12-01
    Firmware Age: 18y 11month 2d
manul91 ★
()
Последнее исправление: manul91 (всего исправлений: 3)
Ответ на: комментарий от mx__

Но в шапке это не так работает. Вытащили винт. Грузится граб, он имеет строку загрузки где указан root и uid раид раздела. Причем этот uid одинаковый для всех дисков так как они в раиде. И эти же uid так же прописаны в /etc/mdadm.conf

В дебиане также, см. выше.

Только те uuid которые в mdadm.conf (с двоеточиями а не с тире) - они другие, в общем только для внутренних нужд mdadm.

В grub и fstab прописан uuid на md тот, который виден через ls -al /dev/disk/by-uuid/ например (он тоже один свой для рейда, uuid партиций/дисков тут непричем). И в шапке должно быть то же самое.

manul91 ★
()
Последнее исправление: manul91 (всего исправлений: 1)
Ответ на: комментарий от manul91

Сделай чтобы системный раздел мог смонтироваться с двумя дисками а какой-нить другой, прописанный в fstab (например /home) был половинным.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Сделай чтобы системный раздел мог смонтироваться с двумя дисками а какой-нить другой, прописанный в fstab (например /home) был половинным.

Сделал: и да, таким образом выкинул меня в emergency mode, соответный md2 inactive. Пришлось делать в еmergency mode

mdadm --run /dev/md2  
exit

Похоже на какой-то race condition или что-то такое из-за говноD, пытается запустить dev-disk-by-uuid…@service прежде чем md ассемблировал рейд. Или недоделали units как надо…

Интересно почему все-таки все работает если половинный рейд на / а не на /home.

Плохо. Надо посмотреть как такое лечится, и исправили ли это в forky

manul91 ★
()
Ответ на: комментарий от firkax

В итоге:

Проапгрейдил до forky. Там из коробки та же самая ситуация.

Начал разбираться.

Оказалось что появились какие-то template-юниты mdadm-last-resort@.service и mdadm-last-resort@.timer, для исправления этого безобразия :)

Однако по дефолту они не инсталированы, существуют только в usr

/usr/lib/systemd/system/mdadm-last-resort@.service

Короче, понадобилось сделать вот что

mkdir -p /etc/systemd/system/mdadm-last-resort@.service.d/
nano /etc/systemd/system/mdadm-last-resort@.service.d/override.conf

(чтобы вставить drop-in

[Install]

WantedBy=multi-user.target

) В итоге имеем

root@debian-test:~# systemctl daemon-reload 
root@debian-test:~# systemctl cat mdadm-last-resort@.service
# /usr/lib/systemd/system/mdadm-last-resort@.service
[Unit]
Description=Activate md array %I even though degraded
DefaultDependencies=no
ConditionPathExists=!/sys/devices/virtual/block/%i/md/sync_action
Documentation=man:mdadm(8)

[Service]
Type=oneshot
ExecStart=/usr/sbin/mdadm --run /dev/%i

# /etc/systemd/system/mdadm-last-resort@.service.d/override.conf
[Install]
WantedBy=multi-user.target

root@debian-test:~#

Делаем тоже самое (инсталируем template сервис) и для таймера

mkdir -p /etc/systemd/system/mdadm-last-resort@.timer.d/
nano /etc/systemd/system/mdadm-last-resort@.timer.d/override.conf
.....

Далее включаем конкретные юниты для всех рейдов поотдельно (md0, md1, md2… ; вроде бы для / лишнее, но лучше перебдеть):

root@debian-test:~# systemctl enable mdadm-last-resort@md2.service
Created symlink '/etc/systemd/system/multi-user.target.wants/mdadm-last-resort@md2.service' → '/usr/lib/systemd/system/mdadm-last-resort@.service'.
...

И то же самое для таймеров:

root@debian-test:~# systemctl enable mdadm-last-resort@md2.timer
Created symlink '/etc/systemd/system/multi-user.target.wants/mdadm-last-resort@md2.timer' → '/usr/lib/systemd/system/mdadm-last-resort@.timer'.
....

После daemon-reload и ребут: теперь все работает, в emergency mode не выкидывает.

P.S. Возможно это и в trixie надо было так, теперь не узнать без переинсталляции.

manul91 ★
()
Последнее исправление: manul91 (всего исправлений: 3)
Ответ на: комментарий от manul91

Я и не писал что там уид раздела, а писал про уид раида. Пока ядра еще нет все грузится как будто бы это просто диски а в грубе просто указано как эти диски искать.

А после загрузки ядра и рамдиска все становится раидом, так как уиды и там и там одианаковые.

mx__ ★★★★★
()
Ответ на: комментарий от manul91

Там не race, просто при ошибке рутового раздела он стартует зеркало принудительно, а для остальных, которые монтируются в другом месте, такого не было.

firkax ★★★★★
()
Ответ на: комментарий от manul91

А я по-другому сделал - в initramfs и независимо от основной системы:

-rwxr-xr-x 1 root root 1115 фев  4  2024 /etc/initramfs-tools/scripts/local-bottom/mdadm

$ cat /etc/initramfs-tools/scripts/local-bottom/mdadm
#!/bin/sh

get_inactives()
{
  ARRAYS=`grep -F inactive /proc/mdstat | awk '{print $1}' | tr '\n' ' '`
}

rm -f /run/count.mdadm.initrd
echo '=============== mdadm finalize begin ==============='
echo 'Current status:'
cat /proc/mdstat | grep -v "^ " | grep .
echo '===================================================='
if grep -F inactive /proc/mdstat >> /dev/null; then
  COUNT=0
  while grep -F inactive /proc/mdstat >> /dev/null && [ 10 -gt $COUNT ]; do
    get_inactives
    echo "[$COUNT] inactive arrays found: $ARRAYS"
    sleep 1
    COUNT=$((COUNT + 1))
  done
  if grep -F inactive /proc/mdstat >> /dev/null; then
    get_inactives
    echo "timed out waiting for inactive arrays: $ARRAYS"
    echo "forcing them to start"
    mdadm --run /dev/md?*
    sleep 3
    if grep -F inactive /proc/mdstat >> /dev/null; then
      get_inactives
      echo "still inactive arrays, giving up: $ARRAYS"
    else
      echo "Everything is fine now."
    fi
  else
    echo "Everything is fine now."
  fi
else
  echo "Everything is fine."
fi
echo '================ mdadm finalize end ================'
sleep 3
firkax ★★★★★
()
Ответ на: комментарий от firkax

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

mx__ ★★★★★
()
Ответ на: комментарий от firkax

Как все это работает разъяснено например тут:

https://utcc.utoronto.ca/~cks/space/blog/linux/SoftwareRaidAssemblySystemd

Посмотрел на bullseye сервак который древнее (и там все точно работает).

Оказывается этот механизм - все эти юниты (и соответно udev script который запускает таймеры) имеют место еще с bullseye:

root@virtgurunew:~# systemctl status mdadm-last-resort@md0.service
● mdadm-last-resort@md0.service - Activate md array md0 even though degraded
     Loaded: loaded (/lib/systemd/system/mdadm-last-resort@.service; static)
     Active: inactive (dead)
       Docs: man:mdadm(8)
root@virtgurunew:~# systemctl cat mdadm-last-resort@md0.service
# /lib/systemd/system/mdadm-last-resort@.service
[Unit]
Description=Activate md array %I even though degraded
DefaultDependencies=no
ConditionPathExists=!/sys/devices/virtual/block/%i/md/sync_action
Documentation=man:mdadm(8)

[Service]
Type=oneshot
ExecStart=/sbin/mdadm --run /dev/%i
root@virtgurunew:~# 
root@virtgurunew:~# systemctl status mdadm-last-resort@md0.timer
● mdadm-last-resort@md0.timer - Timer to wait for more drives before activating degraded array md0.
     Loaded: loaded (/lib/systemd/system/mdadm-last-resort@.timer; static)
     Active: inactive (dead)
    Trigger: n/a
   Triggers: ● mdadm-last-resort@md0.service
root@virtgurunew:~# ll /usr/lib/systemd/system/mdadm*
-rw-r--r-- 1 root root 508 Feb  9  2021 /usr/lib/systemd/system/mdadm-grow-continue@.service
-rw-r--r-- 1 root root 237 Feb  9  2021 /usr/lib/systemd/system/mdadm-last-resort@.service
-rw-r--r-- 1 root root 179 Feb  9  2021 /usr/lib/systemd/system/mdadm-last-resort@.timer
lrwxrwxrwx 1 root root   9 Feb  9  2021 /usr/lib/systemd/system/mdadm.service -> /dev/null
-rw-r--r-- 1 root root 723 Feb  9  2021 /usr/lib/systemd/system/mdadm-shutdown.service
lrwxrwxrwx 1 root root   9 Feb  9  2021 /usr/lib/systemd/system/mdadm-waitidle.service -> /dev/null
root@virtgurunew:~# 
root@virtgurunew:~# 
root@virtgurunew:~# 
root@virtgurunew:~# cat /usr/lib/udev/rules.d/64-md-raid-assembly.rules 
# do not edit this file, it will be overwritten on update

# Don't process any events if anaconda is running as anaconda brings up
# raid devices manually
ENV{ANACONDA}=="?*", GOTO="md_inc_end"
# assemble md arrays

SUBSYSTEM!="block", GOTO="md_inc_end"

# skip non-initialized devices
ENV{SYSTEMD_READY}=="0", GOTO="md_inc_end"

# handle potential components of arrays (the ones supported by md)
ENV{ID_FS_TYPE}=="linux_raid_member", GOTO="md_inc"

# "noiswmd" on kernel command line stops mdadm from handling
#  "isw" (aka IMSM - Intel RAID).
# "nodmraid" on kernel command line stops mdadm from handling
#  "isw" or "ddf".
IMPORT{cmdline}="noiswmd"
IMPORT{cmdline}="nodmraid"

ENV{nodmraid}=="?*", GOTO="md_inc_end"
ENV{ID_FS_TYPE}=="ddf_raid_member", GOTO="md_inc"
ENV{noiswmd}=="?*", GOTO="md_inc_end"
ENV{ID_FS_TYPE}=="isw_raid_member", GOTO="md_inc"
GOTO="md_inc_end"

LABEL="md_inc"

# remember you can limit what gets auto/incrementally assembled by
# mdadm.conf(5)'s 'AUTO' and selectively whitelist using 'ARRAY'
ACTION=="add|change", IMPORT{program}="/sbin/mdadm --incremental --export $devnode --offroot $env{DEVLINKS}"
ACTION=="add|change", ENV{MD_STARTED}=="*unsafe*", ENV{MD_FOREIGN}=="no", ENV{SYSTEMD_WANTS}+="mdadm-last-resort@$env{MD_DEVICE}.timer"
ACTION=="remove", ENV{ID_PATH}=="?*", RUN+="/sbin/mdadm -If $name --path $env{ID_PATH}"
ACTION=="remove", ENV{ID_PATH}!="?*", RUN+="/sbin/mdadm -If $name"

LABEL="md_inc_end"
root@virtgurunew:~# hostnamectl
   Static hostname: virtgurunew
         Icon name: computer-server
           Chassis: server
        Machine ID: 80c196e4211844b6804a5810875c1f2b
           Boot ID: 3cb05a3ed9754bdf89cf95870cccdb19
  Operating System: Debian GNU/Linux 11 (bullseye)
            Kernel: Linux 5.10.0-33-amd64
      Architecture: x86-64
root@virtgurunew:~#

Интересно что mdadm-last-resort юниты и таймеры работают в bullseye без ручной инсталяции, прямо из /lib/systemd/system/mdadm-last-resort@.service (udevd rule запускает таймер)

Но ведь то же самое по дефолту было и в trixie/forky.

Поэтому, что именно сломалось в trixie / forky - по-прежнему не понятно.

Факт, что если в trixie/forky юниты/таймеры проинсталлировать явно чтобы всегда запускались - кустарным способом как я выше сделал - то все начинает работать (хотя теперь думаю нет ли здесь опасность для какой-то race, хотя и в юнитов есть соответный кондишн).

Смотрел правило udev в forky сравнивал с bullseye - вобщем все выглядит аналогично, непонятно почему в forky/trixie не работает. Может регресия какая-то в недрах udev или systemd.

manul91 ★
()
Последнее исправление: manul91 (всего исправлений: 1)
Ответ на: комментарий от firkax

Там не race, просто при ошибке рутового раздела он стартует зеркало принудительно, а для остальных, которые монтируются в другом месте, такого не было.

Ну так выходит по-факту, да.

Однако есть же механизм чтобы для всех рейдов работало (см. прежнее сообщение) - который тем не менее, по непонятных причин не срабатывает.

А тот же самый (навскидку) механизм в bullseye работает однако нормально.

Вобщем мистерия.

manul91 ★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.
  1 2 →
← Помогите найти driver для MTCH6301
Linux-hardware
DDR4 vs. DDR5 →