В случае с Xen+SolusVM, например, если VPS-ка на Xen PV, то ребут будет происходить мягкий - как будто по shutdown-у. А если же вот Xen HVM, то ребут будет как по питанию.
Так что варианты возможны.
Смотрите-ка, вы написали аж 4 фразы, которые не несут в себе никакого смысла, кроме стеба и издевательств. Не жалко потерянного времени и усилий нажатия кнопочек?
Все равно всем спасибо, что в процессе натолкнули на верный путь.
Спасибо за ответы.
Вы, конечно, не поверите, но проверка смарта и статуса массива выполняется каждые 30 минут. Два диска сбойнули одновременно скорее всего из-за перегрева.
Сейчас сделал
hdparm --write-sector 1927675136 --yes-i-know-what-i-am-doing /dev/sdb
Но меня настораживает, что
hdparm --read-sector 1927675136 /dev/sdb
перед этим не выдавал сообщение об ошибке, а считывал сектор (нули выдавал).
Сообщение из dmesg о блоке - 1927675136 это именно блок с таким номером, его не надо высчитывать исходя из разбивки диска по партициям?---------- Добавлено 31.05.2012 в 21:25 ----------...
Да, и еще - если сделать dd с одного диска на другой, а потом поменять физически кабелями их местами - такой вариант прокатит?
То есть делаем dd с /dev/sdb на /dev/sda, выключаем машину, выкидываем диск /dev/sdb, на его место подключаем /dev/sda и грузимся.---------- Добавлено 31.05.2012 в 21:47 ----------Похоже, все-таки путаница между блоками и секторами получается.
Ядро выдает: kernel: raid1: sdb: unrecoverable I/O read error for
block 1927675136
hdparm --read-sector 1927675136 /dev/sdb считывает нормально.
Как по номеру блока (1927675136) вычислить сектор для его перезаписи через hdparm?---------- Добавлено 31.05.2012 в 22:15 ----------ну и сам себе отвечу...
Прогнал тест smartctl, нашел сбойный блок (через hdparm не читался), перезаписал, запустил ребилд.
Посмотрим.
А как его принудительно запустить?
ТС молчит, потому что еще сервер не падал в очередной раз. Упадет - ядро откачу, по результатам работы обязательно отпишусь.
Moskovitter добавил 07.10.2011 в 22:08
Еще есть подозрение, что Solus-ы накосячили в релизе 1.8, сейчас вышло обновление:
Ага. Спасибо. Напишу по результатам работы.
Ну подскажите тогда уж напоследок, как корректно старое ядро поставить.
Если просто
rpm -i kernel-xen-2.6.18-238.19.1.el5.x86_64.rpm
то
package kernel-xen-2.6.18-274.3.1.el5.x86_64 (which is newer than kernel-xen-2.6.18-238.19.1.el5.x86_64) is already installed
rpm -ivh --replacepkgs, как я понимаю, перезапишет. А вот как рядом поставить? Чтобы два было.
Moskovitter добавил 05.10.2011 в 14:21
Это ожидаемо выдает только ядро из ветки 5.7:
kernel-xen.x86_64 2.6.18-274.3.1.el5 installed
Взял ядро http://vault.centos.org/5.6/updates/x86_64/RPMS/kernel-xen-2.6.18-238.19.1.el5.x86_64.rpm
Посмотрим, что с ним получится.
А предыдущего ядра нет. Пару недель все адекватно работало с текущим, которое было установлено в момент запуска сервера.
Moskovitter добавил 05.10.2011 в 13:54
Да, это тоже интересно проверить. Пока у меня на руках только один репорт kernel panic`а и связать pid, который привел к падению с vm-номером виртуалки сейчас уже не получится.
Теперь сделал скрипт, который сохраняет pid-ы виртуалок. Если завалится еще раз - можно будет понять какая именно вызвала панику.
Ну что ж, давайте попробуем. На какое откатываться рекомендуете?
И да, # yum downgrade kernel-xen:
Package kernel-xen-2.6.18-274.el5.x86_64 is allowed multiple installs, skipping
