Вы здесь

[РЕШЕНО] Система не уходит в shoutdown \ reboot

Вопрос в следующем, система, как я думаю, после выключения процессов на определенном init левле перестает что-либо делать.

Как-то заметил что было написано Nothing to stop in this init level, go to next. чтото-типа такого, после этого ничего не происходит, приходится убивать систему зажатием power кнопки.

В чем может быть проблема ?

Включить поддержку acpi в ядре и use-флагах.
P.S. Видеокарта какая? У меня, помнится, с картой от NVidia была похожая проблема пока не включил USE=acpi при сборке x11-drivers/nvidia-drivers.
P.S.S. Покажите

ls -lR /etc/runlevels 

Я Gentoo & Funtoo

видео radeon mobility x1400
для нее стоит x11-drivers/xf86-video-radeonhd 1.2.5

также стоит
sys-power/acpid 1.0.10_p4

попробую поставить USE=acpi, если поможет, сообщу.
Спасибо за быстрый ответ

ls -lR /etc/runlevels

Покажите

zgrep ACPI /proc/config.gz

Я Gentoo & Funtoo

# zgrep ACPI /proc/config.gz
gzip: /proc/config.gz: No such file or directory

Тогда

grep ACPI /usr/src/linux/.config

Я Gentoo & Funtoo

Lupo Alberto написал:
Тогда

grep ACPI /usr/src/linux/.config

http://dpaste.org/SAno/

sdxkokc написал:
# zgrep ACPI /proc/config.gz
gzip: /proc/config.gz: No such file or directory

Советую включить в ядре опции

CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y

Это позволит извлекать конфигурационный файл и просматривать опции загруженного ядра.

Я Gentoo & Funtoo

Lupo Alberto написал:
Это позволит извлекать конфигурационный файл и просматривать опции загруженного ядра.

Ни ересь типа /usr/src/linux/.config, ни /proc/config.{gz,bz2,...} не освобождают от необходимости складывания в /boot/ резервных копий конфигов ядра.

:wq
--
Live free or die

Anarchist написал:
Ни ересь типа /usr/src/linux/.config, ни /proc/config.{gz,bz2,...} не освобождают от необходимости складывания в /boot/ резервных копий конфигов ядра.

Разумеется. Особенно это важно, если вы не единственный пользователь этой системы или подразумевается, что в дальнейшем её будет обслуживать другой человек.
Для себя эту задачу я решил несколько иначе, в скрипт периодического бэкапа добавил

...
kernel_config="$targetdir/backup-$dt/config-`uname -r`"
        echo "OK, creating $kernel_config ..."
        cp /proc/config.gz $kernel_config.gz
        gzip -d $kernel_config
...

P.S. Скрипт писался давно, в начале linux-карьеры, поэтому далёк от идеала. Возможно теперь будет повод исправить :)

Я Gentoo & Funtoo

Lupo Alberto написал:
sdxkokc написал:
# zgrep ACPI /proc/config.gz
gzip: /proc/config.gz: No such file or directory

Советую включить в ядре опции

CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y

Это позволит извлекать конфигурационный файл и просматривать опции загруженного ядра.

# cat .config | grep CONFIG_IKCONFIG
CONFIG_IKCONFIG=y

Возможно, это и не важно, но...
У вас установлен sys-apps/dbus?

Я Gentoo & Funtoo

Lupo Alberto написал:
Возможно, это и не важно, но...
У вас установлен sys-apps/dbus?

конечно, 1.3.0

Проверьте

/etc/init.d/dbus status

Если не запущен, попробуйте добавить его в загрузку

rc-update add dbus default

Я Gentoo & Funtoo

Lupo Alberto написал:
Проверьте

/etc/init.d/dbus status

Если не запущен, попробуйте добавить его в загрузку

rc-update add dbus default

При включении (по крайней мере и моему опыту --- глобальном) соответствующего флага оно само загрузится по зависимости (естественно, если не забыть про etc-update).

:wq
--
Live free or die

запущен

sdxkokc написал:
В чем может быть проблема ?

Помню, было такое...

Проблема скорее всего в конфигурации ядра.

У меня:

$ zgrep -i acpi /proc/config.gz 
# Power management and ACPI options
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
...

До включения этой опции симптомы были те же.

ЗЫ: Используй more/less/vi(m)-style поиск по make menuconfig.

ЗЗЫ: Зря ты отключил /proc/config.gz.

:wq
--
Live free or die

если дело в acpi, то его неплохо бы включиь и в bios ;-)

Сейчас соберу ядро с поддержкой

CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y

посмотрим, поможет или нет ;)

вот после этого дальше никаких действий не происходит...

http://i026.radikal.ru/0909/f9/72db8799850d.jpg

пересобрал ядро, сейчас попробую ребутнуться

zgrep ACPI /proc/config.gz теперь есть :)
http://dpaste.com/89494/

У меня точно такая же проблема. От себя скажу что появилась она после перехода на тестовую ветвь.

No fear, use flags.

Загрузитесь в "чистую", т. е. без запуска Х-сервера, консоль. Получается ли сейчас выключить/перегрузить компьютер?

Я Gentoo & Funtoo

Нет не получается.

No fear, use flags.

Попробуйте посмотреть здесь . Возможно, вы не одиноки и ваша проблема уже решена.

Я Gentoo & Funtoo

Мда! Это наверное очень весело давать ссылку на пустой поиск.

No fear, use flags.

Совершенно не хотел подшутить или обидеть. Ещё вчера выдавало страниц десять ссылок.
Вообще-то, я намекал, что можно пользоваться поиском. Попробуйте такой вариант .

Я Gentoo & Funtoo

аналогичная проблема :(

Да я чайник ;)

Вот что помогло мне.
Открываем файл

/etc/inittab

Находим такой текст

# Further system initialization, brings up the boot runlevel.
rc::bootwait:/sbin/rc boot
l0:0:wait:/sbin/rc shutdown.
l1:S1:wait:/sbin/rc single 

Дописываем l0s:0:wait:/sbin/halt -dhip между двумя последними командами. Должно получиться

# Further system initialization, brings up the boot runlevel.
rc::bootwait:/sbin/rc boot
l0:0:wait:/sbin/rc shutdown.
l0s:0:wait:/sbin/halt -dhip
l1:S1:wait:/sbin/rc single 

Теперь можно выключаться. Переходим к перезагрузке, строка

l6:6:wait:/sbin/rc reboot

Под ней пишем

l6r:6:wait:/sbin/reboot -dk

No fear, use flags.

У меня работает и перезагрузка, и выключение компьютера.
И файл /etc/inittab изначально имеет приведённый вами вид, без какого-либо редактирования с моей стороны.

%egrep -v '^#|^$' /etc/inittab
id:3:initdefault:
si::sysinit:/sbin/rc sysinit
rc::bootwait:/sbin/rc boot
l0:0:wait:/sbin/rc shutdown
l0s:0:wait:/sbin/halt -dhip
l1:S1:wait:/sbin/rc single
l2:2:wait:/sbin/rc nonetwork
l3:3:wait:/sbin/rc default
l4:4:wait:/sbin/rc default
l5:5:wait:/sbin/rc default
l6:6:wait:/sbin/rc reboot
l6r:6:wait:/sbin/reboot -dk
su0:S:wait:/sbin/rc single
su1:S:wait:/sbin/sulogin
c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:2345:respawn:/sbin/agetty 38400 tty2 linux
c3:2345:respawn:/sbin/agetty 38400 tty3 linux
c4:2345:respawn:/sbin/agetty 38400 tty4 linux
c5:2345:respawn:/sbin/agetty 38400 tty5 linux
c6:2345:respawn:/sbin/agetty 38400 tty6 linux
ca:12345:ctrlaltdel:/sbin/shutdown -r now
x:a:once:/etc/X11/startDM.sh

P.S. Возможно, дело в используемой версии

%equery b /etc/inittab
 * Searching for /etc/inittab ...        
sys-apps/sysvinit-2.86-r12 (/etc/inittab)

Я Gentoo & Funtoo

Нет не в этом дело

localhost # equery b /etc/inittab
 * Searching for /etc/inittab ...
sys-apps/sysvinit-2.86-r12 (/etc/inittab)

Проблема заключалась в том что при обновлении системы некоторые конфигурационные файлы тоже надо обновлять. /etc/inittab относиться к таковым.

No fear, use flags.

+1 обновил вчера конфиги - все встало на свои места :)

Да я чайник ;)

действительно, именно этот способ помог, спасибо

Может это поможет?

grep REBOOT /boot/config-2.6.30-gentoo-r5-rev4
CONFIG_X86_REBOOTFIXUPS=y

Маловероятно, что проблема в этом, у меня, например, выключение-перезагрузка работают, но:

%zgrep REBOOT  /proc/config.gz
# CONFIG_X86_REBOOTFIXUPS is not set

Я Gentoo & Funtoo

Там же написано, что это для одного единственного крайне специфичного чипсета.

Почитал пост, но указанные советы мне не помогли. Перешел с ядра 2.26 на 2.30, acpi включено, конфиги обновил, на двух разных машинах одно и тоже, после reboot или halt, система останавливается на hosthame stopped и дальше никаких движений, только грубый сброс питания. В логах ничего подозрительного не нашел. Параллельно стоит старое (2.26) ядро, при загрузке с ним все в порядке. Сейчас обновляюсь -uDN world, может какой пакет криво стоит. Кто подскажет, после hostname stopped какой следующий процесс останавливаться должен, может в нем причину искать буда.

буду честен, я не знаю, почему у меня все работает