просто идет нормальная загрузка

До какого момента?

UEFI?

нету

После нескольких стал вылетать почти сразу:
Waiting for /dev to be fully populated...
и смерь

Леновофаны сейчас опять начнут кричать, что лучше ноута с поддержкой линуха нет.

Когда, лог был больше все равно на этом умерало!

Похоже, что при запуске udev вставляет какие-то модули ядра, которые почему-то вызывают падение. Автоперезагрузка при панике включена? Если да, то надо выключить её, чтобы прочитать сообщение об ошибке.

Чтобы можно было что-то сделать, загружаться надо с параметром single. Если не помогает, то с init=/bin/bash. Тогда можно будет зайти рутом в консоль и вообще что-либо сделать.

Также можно попробовать достать логи ядра при падении, используя kdump-ядро.

вранье.

у меня леново, поддержка так себе.

Я не очень в линуксе, надеюсь действовал правильно:

в грабе нажимал «е»

и в пробовал:

single
//лог довольно длинный но вырубается так же
init=/bin/bash
//незнаю что это, просто вставил как строчку -эффекта не увидел
panic=0
panic=30
//никакого эфекта
noapic
apic=off
//туда же :(

init=/bin/bash

//незнаю что это, просто вставил как строчку -эффекта не увидел

Как это эффекта не увидел? Грузиться не должно было, должна была сразу быть консоль рута. Точно прописал в нужную строку (там, где ядро)?

Попробуй ещё дописать «nomodeset vga=0xF00» — может, проблемы с видеокартой, хотя вряд ли.

Вы правы! Тупонул! Теперь есть консоль рута, что дальше можно предпринять?

Поставить любой дистрибутив с текстовым инсталлятором.

Теперь есть консоль рута, что дальше можно предпринять?

Теперь нужны логи ядра в момент падения. Лучший способ их достать — это получить дамп памяти ядра с помощью kdump, а потом с gdb достать из дампа лог. Здесь просто и понятно написано о настройке kdump, только в данном случае падение происходит при загрузке, поэтому надо в /boot/grub/menu.lst прописать параметр init=/bin/bash постоянно (а убрать, когда всё будет сделано).

Сначала надо настроить kdump. Потом при каждой загрузке при входе в консоль выполнять команды:

mount / -o remount,rw
/etc/init.d/kdump start
mount / -o remount,ro # если будут проблемы с этой командой, можно на неё забить
exec /sbin/init

Первый раз система упадёт при загрузке (как обычно), после чего сразу же загрузится новое ядро, команды надо ввести эти:

mount / -o remount,rw
/etc/init.d/kdump start
sync
mount / -o remount,ro
reboot -f

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

Перед тем, как всё это делать, можно убедиться, что ядро действительно падает при запуске udev, введя эти команды:

mount udev /dev -t devtmpfs
udevd --daemon
udevadm settle

Поставить любой дистрибутив с текстовым инсталлятором.

Ты не поверишь, но *внезапно* Дебиан — дистрибутив с текстовым инсталлятором, который, собственно, и поставил ТС.

дальше отрубить запуск иксов, поставить свежие драйвера, потестить запуск иксов

У него до иксов далеко не доходит, если верить сообщениям в этом треде, а падает ещё на udev'е.

Моё предположение — udev пытается воткнуть модуль nouveau, который при включении KMS валит систему. Так что можно ещё попробовать заблеклистить его.

☺

А дальше первой строчки что-то я и не прочитал...

да, уже прочитал. Ну да, можно попробовать чонить типа

nomodeset nouveau.modeset=0

К сожалению этого приложения там нет, как включить интернет (просто dhcp)?

как включить интернет (просто dhcp)?

dhcpcd eth0

или

dhclient eth0

(в зависимости от того, какой из клиентов DHCP установлен)

eth0 заменить на нужное имя интерфейса, если отличается.

/etc/init.d/kdump start
/etc/kdump.conf
После установки они так и не появились О_о

apt-get install kexec-tools
а потом еще пробовал
apt-get install kdump*

После установки они так и не появились О_о

Надо было установить пакет kdump-tools.

/etc/init.d/Kdump-tools start сработал :)

не сносите же убунту. что там не так?

mount udev /dev -t devtmpfs

mount: according to mtab? tmpfs is already mounted on /dev

udevd --daemon

udevd[233]: starting version 175

udevadm settle

ничего

было куча мелких глюков, + я привык к Дебиану... Я ее только ради вайфая поставил, лучше я дрова под дебиан поставлю

если поставлю конечно :)

ничего

Отработало успешно? Это уже интересно. То есть при ручном запуске udev проблема не воспроизводится. Если параметры ядра не менял (кроме init=/bin/bash), то пока что сказать ничего не могу.

kdump настроил? Если да, то попробуй теперь с его помощью достать дамп ядра, как я писал. Для этого надо не забыть написать /etc/kdump.conf (по ссылке это было), добавить параметр ядра «crashkernel=128M@16M», загрузиться в консоль, выполнить 2 набора команд, которые я писал, после этого должен появиться дамп.

Решил, снести свою кубунту 11.10 и поставить Дебиан Тестинг

но зачем? Почему просто не прописать дебиановский репозитарий в /etc/apt/sources.list?

У меня после установки не был создан kdump.conf потому создал сам и внутри написал:
ext4 /dev/sda2

это наверное не правильно, поскольку дамп в /var/crash. не создается как и сам каталог...

И у меня в инит.д не kdump, kdump-tools

и есть

/etc/default/kdump-tools
кажется тот пост очень старый, я пока поищу новые данные как это настроить

это наверное не правильно, поскольку дамп в /var/crash. не создается как и сам каталог...

При падении загрузилось kdump-ядро или перезагрузка пошла через bios? Что, если попробовать каталог создать руками?

И у меня в инит.д не kdump, kdump-tools и есть /etc/default/kdump-tools

Это всё может зависеть от дистрибутива. Попробуй поискать информацию, специфичную именно для Debian.

а какая ж разница между дебианом и убунтой? Тестинг дебиана ничем не лучше убунты.

Убунта - глючный глюкодром и вообще не Linux.

ну да, ну да. На ноуте стоит убунта 11.04, на стационаре - дебиан. Ну и я бы не сказал, что убунта хуже.

Вот опять я :(

В общем на всякий случай переустановил и обновил систему до ядра 3.2 (обновил, через init=/bin/bash), естественно это не помогло...

Теперь по сути:

1) Выделил память для ядра crashkernel = 256M

2) Выполнил набор команд который вы порекомендовали выше ноут не хочет работать с новыми linux :( (комментарий)

3) Ядро заменилось на /boot/vmlinuz-3.2.0-1-amd64 но дамп ядра так и не создался. В каталоге /var/crash/ имеется только файл kexec_cmd (там только строчка с параметрами запуска ядра)

---

Пробовал еще несколько раз выполнить эти операции (бесполезно):

mount / -o remount,rw

[287.434348] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
(но всетаки ФС после этого доступна для записи)

/etc/init.d/kdump-tools start

Starting kdump-tools: Cuold not find an installed debug vmlinux image and DEBUG_KERNEL is not specified in /etc/default/kdump-tools
makedumpfile my be limited to -d 1 ... (warning).
loaded kernel.

mount / -o remount,ro

EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro

exec /sbin/init

как вы и сказали, падение
И запуск vmlinuz-3.2.0-1-amd64 с теме же параметрами (crashkernel = 256M init=/biin/bash)

mount / -o remount,rw

таже ошибка

/etc/init.d/kdump start

тот же ворнинг

sync

1сек раздупия и возвращается консоль.

mount / -o remount,ro

та же ошибка

reboot -f

МАН ничего полезного не говорит как исправить тот ворнинг:

could not find an installed debug vmlinux image and
DEBUG_KERNEL is not specified in /etc/default/kdump-tools
Warning: makedumpfile will be limited to -d 1.
A debug version of the currently booted kernel could not be
found.

МАН ничего полезного не говорит как исправить тот ворнинг:

Надо или собрать своё ядро, взять оттуда несжатый образ vmlinux и подсунуть его kdump'у, или же распаковать уже установленное ядро, чтобы получить vmlinux.

Щас попробую найти как это сделать. Кстати пробовал запускать генту:
- lifeDVD грузится успешно
- mini... грузится только если загружаться с gentoo-nofb nodetect иначе умирает на Waiting for events to be processed, так же как и другие дистрибутивы - просто перезагрузка :(

events == uevents

Щас попробую найти как это сделать.

Тут, например, написано (это если ядро сжато gzip'ом):

http://www.uvm.edu/~bcodding/ticker/archives/31

Суть в том, чтобы найти, откуда начинаются запакованные данные, и распаковать, начиная оттуда. Если ядро сжато не gzip'ом, то надо будет искать другую сигнатуру. И автор по той ссылке не учитывает, что в выхлопе od сигнатура «1f 8b 08» может быть разнесена на 2 разные строки — тогда не найдёт, надо будет искать «1f 8b» или «8b 08» и смотреть, чтобы нужный символ был в соседней строке в конце/начале.

mini... грузится только если загружаться с gentoo-nofb nodetect

А просто gentoo-nofb без nodetect не загружается? Можно, кстати, попробовать загрузить обычную систему с «vga=0xF00 nomodeset» — должно дать такой же эффект, как gentoo-nofb (без nodetect), если он сработает.

Есть сдвиг

Мне удалось выдрать vmlinuz, после чего я прописал его в конфиге и опять выполнил все те команды (все ворнинги связанные с запуском kdump пропали). Но к сожалению в папке где должен быть результат ничего кроме файла kernel_link который является ссылкой на vmlinux не создается.

А просто gentoo-nofb без nodetect не загружается?

Нет, вырубается.

vga=0xF00 nomodeset

тоже нет

Мне удалось выдрать vmlinuz, после чего я прописал его в конфиге и опять выполнил все те команды (все ворнинги связанные с запуском kdump пропали). Но к сожалению в папке где должен быть результат ничего кроме файла kernel_link который является ссылкой на vmlinux не создается.

Точно выполнил всё? После падения должно было запуститься ядро vmlinux через kdump, т.е. консоль рута должна была опять появиться (перезагрузки через bios не должно было быть), и после выполнения в этой консоли /etc/init.d/kdump start должен был как раз создаться дамп. Это всё произошло?

Это всё произошло?

нет падение было через биос

Так лучше я сверюсь:
1) etc/def*/GRUB

GRUB_CMDLINE_LINUX_DEFAULT=«init=/bin/bash crashkernel=256M»

2)etc/def*/kdump-tools

# kdump-tools configuration
# ---------------------------------------------------------------------------
# USE_KDUMP - controls kdump will be configured
# 0 - kdump kernel will not be loaded
# 1 - kdump kernel will be loaded and kdump is configured
# KDUMP_SYSCTL - controls when a panic occurs, using the sysctl
# interface. The contents of this variable should be the
# «variable=value ...» portion of the 'sysctl -w ' command.
# If not set, the default value «kernel.panic_on_oops=1» will
# be used. Disable this feature by setting KDUMP_SYSCTL=" "
# Example - also panic on oom:
# KDUMP_SYSCTL=«kernel.panic_on_oops=1 vm.panic_on_oom=1»
#
USE_KDUMP=1
#KDUMP_SYSCTL=«kernel.panic_on_oops=1»


# ---------------------------------------------------------------------------
# Kdump Kernel:
# KDUMP_KERNEL - A full pathname to a kdump kernel.
# KDUMP_INITRD - A full pathname to the kdump initrd (if used).
# If these are not set, kdump-config will try to use the current kernel
# and initrd if it is relocatable. Otherwise, you will need to specify
# these manually.
#KDUMP_KERNEL=
#KDUMP_INITRD=


# ---------------------------------------------------------------------------
# vmcore Handling:
# KDUMP_COREDIR - local path to save the vmcore to.
# KDUMP_FAIL_CMD - This variable can be used to cause a reboot or
# start a shell if saving the vmcore fails. If not set, «reboot -f»
# is the default.
# Example - start a shell if the vmcore copy fails:
# KDUMP_FAIL_CMD=«echo 'makedumpfile FAILED.'; /bin/bash; reboot -f»
KDUMP_COREDIR=«/var/crash»
#KDUMP_FAIL_CMD=«reboot -f»


# ---------------------------------------------------------------------------
# Makedumpfile options:
# DEBUG_KERNEL - a debug version of the running kernel. If not set,
# kdump-config will use /usr/lib/debug/vmlinux-$(uname -r) if it is
# available. If it is not available, makedumpfile will be limited to
# dumping all pages in memory.
# MAKEDUMP_ARGS - extra arguments passed to makedumpfile (8). The default,
# if unset, is to pass '-c -d 31' telling makedumpfile to use compression
# and reduce the corefile to in-use kernel pages only.
DEBUG_KERNEL=/tmp/kernel-uncompressed/vmlinux
#MAKEDUMP_ARGS="-c -d 31"


# ---------------------------------------------------------------------------
# Kexec/Kdump args
# KDUMP_KEXEC_ARGS - Additional arguments to the kexec command used to load
# the kdump kernel
# Example - Use this option on x86 systems with PAE and more than
# 4 gig of memory:
# KDUMP_KEXEC_ARGS="--elf64-core-headers"
# KDUMP_CMDLINE - The default is to use the contents of /proc/cmdline.
# Set this variable to override /proc/cmdline.
# KDUMP_CMDLINE_APPEND - Additional arguments to append to the command line
# for the kdump kernel. If unset, it defaults to «irqpoll maxcpus=1 nousb»
#KDUMP_KEXEC_ARGS=«»
#KDUMP_CMDLINE=«»
#KDUMP_CMDLINE_APPEND=«irqpoll maxcpus=1 nousb»

# ---------------------------------------------------------------------------
# Architecture specific Overrides:

crashkernel=256M

Судя по документации, надо обязательно писать 2 числа, где второе — размер резервируемой области для ядра: «crashkernel=256M@16M».

нет падение было через биос

Значит, kdump почему-то не сработал. Возможно, это решится исправлением параметра crashkernel. Если нет, то всё гораздо хуже.

«crashkernel=256M@16M»

Memory for crashkernel is not reserved
Please reserve memory by passing «crashkernel=X@Y» parameter to the kernel
Then try loading kdump kernel

Эксперементировал с разными 256@XXM;

пробовал по ману:

2. Kernel Command line parameters - the kernel must be booted with
a crashkernel= command line parameter. Some example crashkernel
parameters:
ia64: crashkernel=384M@256M
x86: crashkernel=64M@16M
x86_64: crashkernel=128M@16M

Ядро: 3.2.0-1-amd64

Точно параметр crashkernel передаётся ядру? В выводе «cat /proc/cmdline» он есть? (это я к тому, что мог не обновиться конфиг grub, тогда надо выполнить update-grub).

Дебиан просто отторгает неумных пользователей:

1. Почему не почитать вначале http://wiki.debian.org/NvidiaGraphicsDrivers

2. Почему не посмотреть вначале http://thinkwiki.org

3. Сколько дистрибутивов ты меняешь в неделю?

Зачем не делать вышеописанное, а потом лить слезы в форуме. Складывается впечатление о невысоком уме топикстартера.

Кроме того, я забыл про http://www.debian.org/releases/stable/i386/index.html.ru

Дебиан просто отторгает неумных пользователей:

может быть, тебе виднее, я сним живу, жил и надеюсь буду жить.

1. Почему не почитать вначале http://wiki.debian.org/NvidiaGraphicsDrivers

И? Как это поможет мне?

2. Почему не посмотреть вначале http://thinkwiki.org

И что там мне смотреть?

3. Сколько дистрибутивов ты меняешь в неделю?

100500
П.С.: тебе вряд ли понять, что такое «основной дистр» и «раздел для экспериментов и установил на посмотреть», но не в этом суть

Зачем не делать вышеописанное, а потом лить слезы в форуме. Складывается впечатление о невысоком уме топикстартера.

складывается впечатление, что кто то просто напросто переписывает стандартные фразы из чужих постов, причем рандомные, лиш бы слово debian было хоть где-то.

Кроме того, я забыл про http://www.debian.org/releases/stable/i386/index.html.ru

Лучше бы и не вспоминал

К сожалению, да, там все есть. Наверное придется поставить ядро помладше, а как появится время собрать свое.

Странно что такие проблемы начались не с 3.0 а с 3.1