2つのRAID 1アレイを設定していますが、mdadm
正常に動作しているようですが、確認してみると次lsblk
のような内容が表示されます。
sda 8:0 0 5,5T 0 disk
└─md127 9:127 0 5,5T 0 raid1
├─data-crypt-1 253:5 0 5,5T 0 crypt
│ └─myVg-data 253:6 0 5,5T 0 lvm
├─md127p1 259:5 0 182,4G 0 md
└─md127p2 259:6 0 1,2T 0 md
sdb 8:16 0 5,5T 0 disk
└─md127 9:127 0 5,5T 0 raid1
├─data-crypt-1 253:5 0 5,5T 0 crypt
│ └─myVg-data 253:6 0 5,5T 0 lvm
├─md127p1 259:5 0 182,4G 0 md
└─md127p2 259:6 0 1,2T 0 md
sdc 8:32 0 5,5T 0 disk
└─md126 9:126 0 5,5T 0 raid1
sdd 8:48 0 5,5T 0 disk
└─md126 9:126 0 5,5T 0 raid1
私の配列のこのパーティション(?)は何ですかmd127p1
?md127p2
削除する必要がありますか?では、どのように削除しますか?
アレイを邪魔しないようで、期待どおりに再同期されるようです。しかし、たとえば、誰かがmd127p1
何かをマウントして書き込むと、その中のデータdata-crypt-1
(ドライブ全体にわたって)が破損するのではないかと心配されます。
編集する:
再起動して再組み立てしても問題は解決しません(実際に問題の場合)。
sudo wipefs --no-act /dev/md127
# DEVICE OFFSET TYPE UUID LABEL
# md127 0x0 crypto_LUKS ba3eab9b-db06-4053-9eb8-4e674931148c
dmesg
md126
間で若干異なる動作を報告しますmd127
。 「バックグラウンド再構成」を確認する方法がわかりません。
dmesg | grep "md12[67]"
# [ 3.072445] md/raid1:md127: not clean -- starting background reconstruction
# [ 3.072445] md/raid1:md127: active with 2 out of 2 mirrors
# [ 3.107577] md127: detected capacity change from 0 to 6001039835136
# [ 3.112944] md127: AHDI p1 p2 p3
# [ 4.072578] md/raid1:md126: active with 2 out of 2 mirrors
# [ 4.105528] md126: detected capacity change from 0 to 6001039835136
# [ 175.221344] md127: AHDI p1 p2 p3
# [ 252.627169] md127: AHDI p1 p2 p3
# [ 337.950292] md127: AHDI p1 p2 p3
そしてudevadm
次のように報告しました。
udevadm info /dev/md127p1
# P: /devices/virtual/block/md127/md127p1
# N: md127p1
# L: 100
# S: disk/by-id/md-name-XYZ:data-array-1-part1
# S: disk/by-id/md-uuid-94gd622:d96sf22:9fb73768:dae5367e-part1
# S: md/XYZ:data-array-1p1
# E: DEVLINKS=/dev/md/XYZ:data-array-1p1 /dev/disk/by-id/md-name-XYZ:data-array-1-part1 /dev/disk/by-id/md-uuid-94gd622:d96sf22:9fb73768:dae5367e-part1
# E: DEVNAME=/dev/md127p1
# E: DEVPATH=/devices/virtual/block/md127/md127p1
# E: DEVTYPE=partition
# E: MAJOR=259
# E: MD_DEVICES=2
# E: MD_DEVICE_ev_sda_DEV=/dev/sda
# E: MD_DEVICE_ev_sda_ROLE=0
# E: MD_DEVICE_ev_sdb_DEV=/dev/sdb
# E: MD_DEVICE_ev_sdb_ROLE=1
# E: MD_DEVNAME=XYZ:data-array-1
# E: MD_LEVEL=raid1
# E: MD_METADATA=1.2
# E: MD_NAME=XYZ:data-array-1
# E: MD_UUID=94gd622:d96sf22:9fb73768:dae5367e
# E: MINOR=5
# E: PARTN=1
# E: SUBSYSTEM=block
# E: SYSTEMD_WANTS=mdmonitor.service
# E: TAGS=:systemd:
# E: USEC_INITIALIZED=337999178
udevadm info /dev/md127p2
# P: /devices/virtual/block/md127/md127p2
# N: md127p2
# L: 100
# S: disk/by-id/md-name-XYZ:data-array-1-part2
# S: disk/by-id/md-uuid-94gd622:d96sf22:9fb73768:dae5367e-part2
# S: md/XYZ:data-array-1p2
# E: DEVLINKS=/dev/disk/by-id/md-name-XYZ:data-array-1-part2 /dev/disk/by-id/md-uuid-94gd622:d96sf22:9fb73768:dae5367e-part2 /dev/md/XYZ:data-array-1p2
# E: DEVNAME=/dev/md127p2
# E: DEVPATH=/devices/virtual/block/md127/md127p2
# E: DEVTYPE=partition
# E: MAJOR=259
# E: MD_DEVICES=2
# E: MD_DEVICE_ev_sda_DEV=/dev/sda
# E: MD_DEVICE_ev_sda_ROLE=0
# E: MD_DEVICE_ev_sdb_DEV=/dev/sdb
# E: MD_DEVICE_ev_sdb_ROLE=1
# E: MD_DEVNAME=XYZ:data-array-1
# E: MD_LEVEL=raid1
# E: MD_METADATA=1.2
# E: MD_NAME=XYZ:data-array-1
# E: MD_UUID=94gd622:d96sf22:9fb73768:dae5367e
# E: MINOR=6
# E: PARTN=2
# E: SUBSYSTEM=block
# E: SYSTEMD_WANTS=mdmonitor.service
# E: TAGS=:systemd:
# E: USEC_INITIALIZED=337999612
hexdump
示す:
sudo hexdump -C -n 512 /dev/md127
# *
# *
# 000001c0 7c e8 03 4d 62 32 d5 66 37 75 6b e9 12 6d 16 cc ||..Mb2.f7uk..m..|
# 000001d0 96 9e 6f 3d 32 e0 e7 fe 7f f4 9c a1 59 03 19 47 |..o=2.......Y..G|
# 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
# *
また、一部のコンピュータでは、「ゴースト」パーティションが表示されないという事実も発見されました。特に私のDietPiコンピュータでは、そのパーティションは表示されませんでした。私のUbuntuコンピュータに表示されます。さらに、DietPiシステムの1つで両方のアレイ(md126とmd127)が作成されたことを確認しました。
答え1
したがって、これはランダムに偽造されたパーティションテーブルを誤った場合に見えます。
以下は、Atari / AHDIパーティションテーブル(partedを使用して作成)の例です。
# hexdump -C -n 512 /dev/loop0
000001c0 00 00 00 03 20 00 01 4c 4e 58 00 00 08 00 00 00 |.... ..LNX......|
000001d0 08 00 01 4c 4e 58 00 00 18 00 00 00 60 00 00 50 |...LNX......`..P|
000001e0 41 52 54 45 44 41 54 41 52 49 00 50 41 52 54 45 |ARTEDATARI.PARTE|
000001f0 44 41 54 41 52 49 00 00 00 01 00 00 00 01 fa 70 |DATARI.........p|
したがって、興味深いビットは、block/partitions/atari.c#L27-L32に示すように、オフセット0x1c0/0x1d0ラインのGEM、BGM、LNX、SWP、RAWの1つです。
static inline int OK_id(char *s)
{
return memcmp (s, "GEM", 3) == 0 || memcmp (s, "BGM", 3) == 0 ||
memcmp (s, "LNX", 3) == 0 || memcmp (s, "SWP", 3) == 0 ||
memcmp (s, "RAW", 3) == 0 ;
}
以下は LUKS2 ヘッダーの例です。
# hexdump -C -n 512 /dev/loop1
00000000 4c 55 4b 53 ba be 00 02 00 00 00 00 00 00 40 00 |LUKS..........@.|
00000010 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00 |........sha256..|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 a4 43 6c 13 63 6b 33 da |.........Cl.ck3.|
00000070 c8 f5 1d 7d 82 b3 9e dc 15 b2 ff 55 d2 4c 3e 8c |...}.......U.L>.|
00000080 62 08 ec 0f 56 b2 bc 89 86 f0 e8 c0 e6 a2 d8 12 |b...V...........|
00000090 56 93 68 2f 83 82 e6 90 18 57 7b 23 34 d7 96 92 |V.h/.....W{#4...|
000000a0 ab ad 67 a5 d9 7d dd 6c 32 36 37 36 35 63 39 32 |..g..}.l26765c92|
000000b0 2d 34 34 37 34 2d 34 36 37 64 2d 62 39 62 62 2d |-4474-467d-b9bb-|
000000c0 64 36 30 36 63 61 64 31 32 61 62 64 00 00 00 00 |d606cad12abd....|
000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001c0 55 85 e9 50 c2 46 1e 16 27 a7 ce a5 9d e9 46 17 |U..P.F..'.....F.|
000001d0 fb 30 9a ae 53 74 39 8a c5 2c d2 21 4b 86 ad 20 |.0..St9..,.!K.. |
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
したがって、同じ0x1c0 / 0x1d0行にランダムなデータがある場合があります。
私の考えでは、GEM、BGM、LNX、SWP、RAWのいずれかをランダムに転がしてカーネルのパーティションテーブルのように見えたので、奇妙なパーティションを見つけたようです.
良いニュースは、LUKS2ヘッダーの場合、このオフセットがヘッダーチェックサムを表すように見えることです。 LUKS2ヘッダーで何かを変更するたびに完全に変更されるため、たとえば、別のパスワードフレーズを追加するだけです。 (実際に必要でない場合は削除してください。)
# cryptsetup luksAddKey /dev/loop1
Enter any existing passphrase:
Enter new passphrase for key slot:
Verify passphrase:
実行後の同じLUKS2ヘッダーcryptsetup luksAddKey
:
# hexdump -C -n 512 /dev/loop1
00000000 4c 55 4b 53 ba be 00 02 00 00 00 00 00 00 40 00 |LUKS..........@.|
00000010 00 00 00 00 00 00 00 05 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00 |........sha256..|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 a4 43 6c 13 63 6b 33 da |.........Cl.ck3.|
00000070 c8 f5 1d 7d 82 b3 9e dc 15 b2 ff 55 d2 4c 3e 8c |...}.......U.L>.|
00000080 62 08 ec 0f 56 b2 bc 89 86 f0 e8 c0 e6 a2 d8 12 |b...V...........|
00000090 56 93 68 2f 83 82 e6 90 18 57 7b 23 34 d7 96 92 |V.h/.....W{#4...|
000000a0 ab ad 67 a5 d9 7d dd 6c 32 36 37 36 35 63 39 32 |..g..}.l26765c92|
000000b0 2d 34 34 37 34 2d 34 36 37 64 2d 62 39 62 62 2d |-4474-467d-b9bb-|
000000c0 64 36 30 36 63 61 64 31 32 61 62 64 00 00 00 00 |d606cad12abd....|
000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001c0 2a 11 50 fd 0b 8a 05 b6 67 1a e5 2f 2b a7 de d5 |*.P.....g../+...|
000001d0 2c b3 17 7c a5 21 b5 a1 5a f3 86 5c 96 9e 16 c0 |,..|.!..Z..\....|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
ご覧のとおり、0x1c0/0x1d0行のデータは以前とはまったく異なるため、幸運な場合は偽のパーティションテーブルも消えます(パーティションテーブルを読み直した後)。今後タイトルを変更すると戻ってくる可能性があるので、見守るべきことです。
luksFormat
以前のLUKS1ヘッダーは、このオフセットにランダムなデータを格納せず、次のように0に設定するため、LUKS2を使用すると仮定します。
000001c0 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
したがって、以前の LUKS1 ヘッダー形式では、これらの問題はまったく発生しません。