Добавить диск для расширения LVM Raid5
Загрузка образа ядра в оперативную память системы — это работа загрузчика; только загрузчик точно знает, откуда взялся образ ядра. Если система загружается из сети, образ ядра может вообще не присутствовать в системе в виде файла.
Номер версии и отметка времени компиляции, сообщаемые uname -a, могут помочь в идентификации файла образа ядра. Ту же информацию можно прочитать из файла образа ядра с помощью команды file:
$ uname -a
Linux hostname 4.9.80-atom #1 SMP Mon Feb 5 13:26:54 EET 2018 x86_64 GNU/Linux
$ file /boot/vmlinuz-4.9.80-atom
/boot/vmlinuz-4.9.80-atom: Linux kernel x86 boot executable bzImage, version 4.9.80-atom (user@hostname) #1 SMP Mon Feb 5 13:26:54 EET 2018, RO-rootFS, swap_dev 0x3, Normal VGA
В системах UEFI можно просмотреть загрузочную переменную UEFI BootCurrent, чтобы узнать, какой из параметров загрузки NVRAM был выбран. Но это не очень убедительное доказательство, так как вариант загрузки мог быть отредактирован после того, как произошла загрузка, и если он указывает на загрузчик, который может предлагать несколько вариантов загрузки, это все равно будет неоднозначно.
Единственным надежным доказательством, которое я знаю, будет использование системы с микросхемой TPM и загрузчиком, -поддерживающим TPM :, который будет хранить криптографически стойкий хэш ядра, первоначально загруженного в соответствующий регистр PCR TPM.. Затем вы сможете следовать тем же правилам, пересчитать хэш и посмотреть, совпадает ли он; если нет, то кто-то подделал либо ядро, либо значение регистра PCR. И прошивка всегда будет заполнять другой регистр PCR хэшем фактически используемого загрузочного кода, поэтому вы также можете увидеть любое вмешательство в загрузчик.
(Регистры PCR реализованы таким образом, что вы не можете просто установить для них значение по вашему выбору :новое значение всегда будет криптографически стойким хэшем старого значения + любых введенных новых данных, поэтому установка Зарегистрировать PCR на конкретное известное значение, когда оно уже имеет какое-то другое значение, отличное от -нуля, будет чрезвычайно сложно.)
TrustedGRUB — это версия загрузчика GRUB с поддержкой TPM -. Однажды я экспериментировал со [старой версией, основанной на GRUB Legacy] (https://sourceforge.net/p/trustedgrub/wiki/Home/] .В настоящее время существует новая реализация, основанная на GRUB 2 , но пока она поддерживает загрузку в устаревшем -стиле. Я не тестировал его, потому что все доступные мне для тестирования системы с поддержкой TPM -теперь основаны на UEFI -.
Мои записи, сделанные во время работы над этим, находятся здесь:https://wiki.archlinux.org/index.php/User:Ctag/Notes#Growing_LVM_Raid5
Я добавил новый диск и перешел на Raid6.
Если я правильно помню, проблема заключается как в том, что новый диск на несколько секторов меньше остальных, так и в том, что накладные расходы на необходимые метаданные LVM/raid немного увеличиваются при добавлении нового диска (, поэтому идентичный диск тоже не сработает ). Способ решить обе проблемы — недоиспользовать все диски на несколько секторов, оставив место для метаданных, а также для будущих несоответствий дисков.
# pvs -a -o +pv_pe_count,pv_pe_alloc_count
PV VG Fmt Attr PSize PFree PE Alloc
/dev/mapper/cryptslow1 cryptvg lvm2 a-- <1.82t 20.00m 476931 476931
/dev/mapper/cryptslow2 cryptvg lvm2 a-- <1.82t 20.00m 476931 476931
/dev/mapper/cryptslow3 cryptvg lvm2 a-- <2.73t <931.52g 715395 476931
/dev/mapper/cryptslow4 cryptvg lvm2 a-- <1.82t <1.82t 476927 0
См. выше, новый диск имеет только «476927» экстентов, а не «476931»? Это проблема. Нам нужно заставить LVM выделять только меньшее число (или меньше )экстентов, чтобы конфигурация RAID5 могла использовать этот новый диск.
# lvresize -r -l -10 /dev/cryptvg/raid
fsck from util-linux 2.34
/dev/mapper/cryptvg-raid: clean, 913995/240320512 files, 686703011/961280000 blocks
resize2fs 1.45.3 (14-Jul-2019)
Resizing the filesystem on /dev/mapper/cryptvg-raid to 976742400 (4k) blocks.
The filesystem on /dev/mapper/cryptvg-raid is now 976742400 (4k) blocks long.
Size of logical volume cryptvg/raid changed from <3.64 TiB (953860 extents) to <3.64 TiB (953850 extents).
Logical volume cryptvg/raid successfully resized.
# pvs -a -o +pv_pe_count,pv_pe_alloc_count
PV VG Fmt Attr PSize PFree PE Alloc
/dev/mapper/cryptslow1 cryptvg lvm2 a-- <1.82t 20.00m 476931 476926
/dev/mapper/cryptslow2 cryptvg lvm2 a-- <1.82t 20.00m 476931 476926
/dev/mapper/cryptslow3 cryptvg lvm2 a-- <2.73t <931.52g 715395 476926
/dev/mapper/cryptslow4 cryptvg lvm2 a-- <1.82t <1.82t 476927 0
Теперь мы можем продолжить добавление нашего нового диска, и на этот раз он будет работать.