Я только что обновил и получил ядро 3.2.0-44 на моем настольном компьютере Dell T3400. Когда я перезагружался по мере необходимости, он висел на экране XUbuntu с движущейся панелью ... полоса перестала двигаться, и больше ничего не происходило (я сдался через 5 минут).
Я принудительно выключил и использовал загрузчик grub 3.2.0-44-generic в режиме восстановления. Выбор fsck сообщает "Время последнего монтирования суперблока в будущем" ... и "ИСПРАВЛЕНО", выбор dpkg сообщает об отсутствии битых пакетов, а выбор возобновления выполняется незадолго до зависания. Последние сообщенные сообщения:
swapon:/dev/disk/by-uuid/613f8c15-413f-4339-81b4-a3b2b092480f: swapon failed: device or resource busy
swapon terminated with status 255
init ctl: Event failed
и DAHDI затем распечатывает некоторые вещи с последним «dahdi_transcode:», затем он зависает. С одной попытки (но только одной из нескольких) примерно через 15 секунд я получил еще одно сообщение, которое начиналось с:
rcu_sched detected stalls on CPU/taksk: { 1}
( РЕДАКТИРОВАТЬ Каждые несколько попыток я получаю rcu_sched, обнаруживающий остановку, и в большинстве случаев это происходит, когда он начинает бесконечно сбрасывать кучу отладочной информации ... слишком быстро, чтобы иметь смысл. Но как только он замерз с rcu_sched, фактически сообщающим, что dahdi_transcode был фактической задачей, которая была зависла. Я не знаю, насколько это точно поскольку память может быть повреждена чем-то ранее в процессе загрузки)
Тест памяти Grub прошел нормально. И я могу загрузить предыдущее ядро (3.2.0-43-generic) ОК.
Есть какие-нибудь мысли или подсказки о том, как это исправить?
Больше информации, поскольку это похоже на проблему раздела подкачки (все из общей загрузки 3.2.0-43):
[ 1111] my / etc / fstab:
# /etc/fstab: static file system information.
#
# Use 'blkid -o value -s UUID' to print the universally unique identifier
# for a device; this may be used with UUID= as a more robust way to name
# devices that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# / was on /dev/sda1 during installation
UUID=c88a26e8-a137-4910-9601-6274caebc1f4 / ext4 errors=remount -ro,user_xattr 0 1
# swap was on /dev/sda5 during installation
UUID=613f8c15-413f-4339-81b4-a3b2b092480f none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0
и "fdisk -l" показывает:
Disk /dev/sda: 250.0 GB, 250000000000 bytes
255 heads, 63 sectors/track, 30394 cylinders, total 488281250 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xa42d04a3
Device Boot Start End Blocks Id System
/dev/sda1 * 63 476214794 238107366 83 Linux
/dev/sda2 476214795 488279609 6032407+ 5 Extended
/dev/sda5 476214858 488279609 6032376 82 Linux swap / Solaris
где gparted показывает, что sda5 находится в пределах sda2
Так как похоже, что инициализация dahdi_transcode зависла при загрузке ядра 3.2.0-44, я перезагрузился в ядро 3.2.0-43 и удалил все модули dahdi с помощью Ubuntu Software Center, а затем перезагрузился в ядро 3.2. .0-44-родовой. Это сделал, больше не зависать во время загрузки. Поскольку я не использую свой настольный компьютер для телефонии, это решение работает для меня.