CentOS 7 кирпичится после обновления.

В приведённом архиве находится файл, содержащий файловую систему ext2. На этой файловой системе есть вот эти файлы:

rhdd3
rpms
rpms/x86_64
rpms/x86_64/kmod-hpvsa-1.2.16-102.rhel7u0.x86_64.rpm
rpms/x86_64/repodata
rpms/x86_64/repodata/repomd.xml
rpms/x86_64/repodata/40cc5ca18f1b2704da7cdafdbc1ab62df6f1d21d94a7bc0cf252187a2e187dcf-primary.xml.gz
rpms/x86_64/repodata/d95fc0541c1fa07b63e30a99930d7ed406df045d98546016e74d7eec50aff68c-filelists.sqlite.bz2
rpms/x86_64/repodata/2d1d3f18173d8b94deb711f0cb19445ef19bae5961db90b85f64780b76172a43-primary.sqlite.bz2
rpms/x86_64/repodata/5a409c028bc59b1b213d91660a904654895a1a080ef194ec0b78938f3b014f65-filelists.xml.gz
rpms/x86_64/repodata/207d712f74869b8ad8d35129f6ff7e122a67ec4688ba6c8e50a0aeb9fa71cf53-other.sqlite.bz2
rpms/x86_64/repodata/e4cc44fa4fc1fa74bbd9b553b38b3dfaec6ae97b6a52f7243d60a2414608644c-other.xml.gz

.
./etc
./etc/depmod.d
./etc/depmod.d/hpvsa.conf
./lib
./lib/modules
./lib/modules/3.10.0-123.el7.x86_64
./lib/modules/3.10.0-123.el7.x86_64/extra
./lib/modules/3.10.0-123.el7.x86_64/extra/hpvsa
./lib/modules/3.10.0-123.el7.x86_64/extra/hpvsa/hpvsa.ko

Так что если при yum -y update у тебя обновляется ядро в системе, то под новое ядро нет попросту модуля (драйвера).

Ищи исходники этого модуля и собирай его под новое ядро, либо если есть старое ядро, то грузись с него.

Всё так просто, большое спасибо, сам бы не подумал там посмотреть :)

Я очень извиняюсь за тупой вопрос. А реально исключить ядро из обновлений? Никогда не задавался такой целью

yum update --exclude=kernel*

или, если на постоянной основе, в /etc/yum.conf

exclude=kernel* redhat-release*

ext3

ext3 не имеет никаких преимуществ перед ext4, при этом имеет недостатки. Более того, сейчас для них используется один и тот же драйвер. Но это так, к слову.

При установке центоса использовал этот драйвер

Если у тебя нет необходимости держать на этом сервере винду, то ты изначально сделал всё неправильно. Это не raid, а так называемый fakeraid, подвид software raid, где всю работу делает не железка, а процессор, задачей же fakeraid, как железки, просто обеспечить начальную загрузку винды с массива, после чего «драйвер» будет управлять массивом в полностью программном режиме. В линуксе, где есть встроенные средства работы с программным рейдом и где загрузчики умеют загружать систему с программного рейда, подобное просто не нужно и при установке следовало просто настроить программный рейд через mdadm.

и при установке следовало просто настроить программный рейд через mdadm

Забыл только упомянуть, что перед началом установки режим рейда в контроллёре надо отключить, тогда диски станут видны установщику без стороннего драйвера и из них можно будет собрать рейд средствами уже самого установщика.

А какой в этом смысл, если в железке есть железный контроллер? тогда уж лучше поставить винду, чем заниматься таким извратом. Про фейкрейд не знал, спасибо, это удручает :(

А какой в этом смысл, если в железке есть железный контроллер?

Дык в том и дело, что нету там полноценного контроллера.

извратом

Soft raid — это нормально, все этим занимаются :) Именно поэтому нет дешёвых аппаратных рейдов — не потому что это такое уж дорогое железо, а потому что в бюджетном урезанном варианте (без батарейки, кэша и т.д.) его прямым конкурентом стал бы soft raid, а конкурировать с БЕСПЛАТНО он бы не смог.

А какой в этом смысл, если в железке есть железный контроллер?

Я понимаю, что диды собирали и всё такое, но попоратные рейды вообще-то прямо противопоказаны при использовании серьёзных файловых систем, которые имеют встроенные менеджеры томов и контроль целостности данных. Время «железных»* контроллеров постепенно заканчивается.

* - в некоторых из них может оказаться целый линукс с MD RAID.

Там же weak-updates в /etc/depmod.d/hpvsa.conf
Должно работать и с новым ядром.

yum-plugin-versionlock

Добавь себе репозиторий https://downloads.linux.hpe.com/SDR/project/spp/

Будешь получать драйверы для свежих сборок ядра, mkinitrd будет их паковать в initramfs.