- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Raistlin, во! естественно что паника это баг ядра, просто мы по разному смотрим на вещи, вы хотите закрыть баг, а мне было бы интересно найти его природу, и я не исключаю, что эта природа идёт из одной и той же виртуалки.
nano /boot/grub/menu.lst
поставьте дефолтным предыдущее ядро, с которым работало всё корректно в таком случае.
А предыдущего ядра нет. Пару недель все адекватно работало с текущим, которое было установлено в момент запуска сервера.
Moskovitter добавил 05.10.2011 в 13:54
Raistlin, во! естественно что паника это баг ядра, просто мы по разному смотрим на вещи, вы хотите закрыть баг, а мне было бы интересно найти его природу, и я не исключаю, что эта природа идёт из одной и той же виртуалки.
Да, это тоже интересно проверить. Пока у меня на руках только один репорт kernel panic`а и связать pid, который привел к падению с vm-номером виртуалки сейчас уже не получится.
Теперь сделал скрипт, который сохраняет pid-ы виртуалок. Если завалится еще раз - можно будет понять какая именно вызвала панику.
В данном случае возможно. Однако, с большой долей вероятности баг будет повторяться, хотя и реже.
Взял ядро http://vault.centos.org/5.6/updates/x86_64/RPMS/kernel-xen-2.6.18-238.19.1.el5.x86_64.rpm
Посмотрим, что с ним получится.
yum list kernel-xen
yum install то, что вам нужно. Устанавливаем наиболее близкую версию ядра. Так же контролируем (во избежание) содержимое menu.lst
Ну подскажите тогда уж напоследок, как корректно старое ядро поставить.
Если просто
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
yum list kernel-xen
yum install то, что вам нужно. Устанавливаем наиболее близкую версию ядра. Так же контролируем (во избежание) содержимое menu.lst
Это ожидаемо выдает только ядро из ветки 5.7:
kernel-xen.x86_64 2.6.18-274.3.1.el5 installed
Moskovitter,
что там?
ls -la /boot
nano /etc/yum.repos.d/CentOS-Vault.repo
ставим там enabled=1 напротив Base и Updates
сохраняем
yum install kernel-xen-2.6.18-238.19.1.el5
Raistlin добавил 05.10.2011 в 14:34
UPD: не напротив, а в секциях, там нужно нолик заменить на единичку выше описка.
nano /etc/yum.repos.d/CentOS-Vault.repo
Ага. Спасибо. Напишу по результатам работы.
То кого осчастливили 1000$ ? Если не секрет конечно ?
Предлагаю откатывать сам XEN конкретней bridge-utils - там проблема с эмуляцией сети и не обязательно решается откатом ядра.
Удачи :)