Есть 2 записи в файле grub.cfg (первый мой на основе генератора grub2-1.9.8, а второй сгенерен автоматом 1.9.9 при установке ядра): menuentry "System" --class gnu-linux --class gnu --class os { load_video insmod part_msdos insmod xfs set root='(hd0,msdos1)' search --no-floppy --fs-uuid --set 2450351c-a421-4b97-a6cf-d1eb1cd0532a echo 'Loading System ...' linux /vmlinuz root=UUID=f344e551-b323-4634-81b2-fccfe6858bf6 ro panic=30\ splash=silent echo 'Loading initial ramdisk ...' initrd /initrd.img } menuentry "ALT Linux 5.9.9 Ark Server, with Linux 2.6.38-un-def-alt7" --class gnu-linux --class gnu --class os { load_video insmod gzio insmod part_msdos insmod xfs set root='(hd0,msdos1)' search --no-floppy --fs-uuid --set=root 2450351c-a421-4b97-a6cf-d1eb1cd0532a echo 'Loading Linux 2.6.38-un-def-alt7 ...' linux /vmlinuz-2.6.38-un-def-alt7 root=UUID=f344e551-b323-4634-81b2-\ fccfe6858bf6 ro failsafe vga=normal panic=30 splash=silent echo 'Loading initial ramdisk ...' initrd /initrd-2.6.38-un-def-alt7.img } Причем vmlinuz - это ссылка на vmlinuz-2.6.38-un-def-alt7, а initrc.img - ссылка на initrd-2.6.38-un-def-alt7.img. При этом при выборе первого пункта ядро не может нормально загрузиться (или не может найти ядра процессора при старте, или отказ ещё каких-то устройств на этапе запуска udev в системе), а через некоторое время проходит hard reset. При выборе второго варианта загрузка идёт нормально и система работает адекватно. В версии 1.9.8 таких проблем не наблюдаю. Также идёт ругань на параметр vga= как на несуществуюший (при любой загрузке) и на отсутствие какого-то параметра (из текста неясно на что) (при выборе первого варианта).
Та же проблема и с 2.6.39-un0-def-alt0.1. Видел на двух машинах: с i7 975 и с i7 960, материнки от разных фирм.
Grub работает _до_ загрузки ядра. Если загрузка ядра началась, то grub точно не виноват. Могу лишь предположить нерабочий initrd или сбившиеся ссылки (грузится не то ядро или не тот initrd, что вы думаете). Посмотрите.
initrd генерится единожды при установке ядра, да и само ядро сжато, а это в один раз произошло, а в другой раз нет (ядро одно и то же загружалось). Да и странно было видеть, как ядро линукса банально не видит ядра процессора, то есть шёл медленный перебор строк (пример из обычной загрузки): May 25 15:46:07 comp kernel: [ 0.176683] NMI watchdog enabled, takes one hw-pmu counter. May 25 15:46:07 comp kernel: [ 0.192535] Booting Node 0, Processors #1 May 25 15:46:07 comp kernel: [ 0.300576] NMI watchdog enabled, takes one hw-pmu counter. May 25 15:46:07 comp kernel: [ 0.312474] #2 May 25 15:46:07 comp kernel: [ 0.420426] NMI watchdog enabled, takes one hw-pmu counter. May 25 15:46:07 comp kernel: [ 0.432402] #3 May 25 15:46:07 comp kernel: [ 0.540383] NMI watchdog enabled, takes one hw-pmu counter. May 25 15:46:07 comp kernel: [ 0.552330] #4 May 25 15:46:07 comp kernel: [ 0.660311] NMI watchdog enabled, takes one hw-pmu counter. May 25 15:46:07 comp kernel: [ 0.672262] #5 May 25 15:46:07 comp kernel: [ 0.780223] NMI watchdog enabled, takes one hw-pmu counter. May 25 15:46:07 comp kernel: [ 0.792188] #6 May 25 15:46:07 comp kernel: [ 0.900176] NMI watchdog enabled, takes one hw-pmu counter. May 25 15:46:07 comp kernel: [ 0.912117] #7 May 25 15:46:07 comp kernel: [ 1.020084] NMI watchdog enabled, takes one hw-pmu counter. May 25 15:46:07 comp kernel: [ 1.024027] Brought up 8 CPUs May 25 15:46:07 comp kernel: [ 1.024220] Total of 8 processors activated (51814.26 BogoMIPS). Дошел до строки с "#3" - и hard reset. Тут ещё даже initrd не задействован (насколько я понял процесс загрузки). Как будто grub2 криво раскрыл ядро и образ ФС в памяти и всё пошло не так.
т.е. баг появляется с некоторой вероятностью?
Да, причина падения непонятна. Обнаружена уже на двух совершенно разных компьютерах (в плане железа) и каждый раз после смены grub2. До этого таких проблем ни разу не было.
Повторил загрузку через пункт System (из #1). Загрузилась система нормально, только опять сообщения grub о необходимости замены vga=791 на gfxboot=... (записать не успел), "Press any key to continue...", ожидание несколько секунд и продолжение загрузки дальше (а к чему тогда "Press any key..."?) без эксцессов. Кстати, заработало сохранение состояния (чего раньше не замечалось в 1.98). То есть какая-то нестабильная работа загрузчика.
Прошу прощения, пропустил часть сообщения в описании. Повторил загрузку через пункт System (из #1). Загрузилась система нормально, только опять сообщения grub на ошибку в параметре --set (невнятное), о необходимости замены vga=791 на gfxboot=... (записать не успел), "Press any key to continue...", ожидание несколько секунд и продолжение загрузки дальше (а к чему тогда "Press any key..."?) без эксцессов. Кстати, заработало сохранение состояния (чего раньше не замечалось в 1.98-alt23.20100804). То есть какая-то непонятная работа загрузчика. Мой /etc/sysconfig/grub2: GRUB_AUTOUPDATE_CFG=true GRUB_AUTOUPDATE_CFGNAME=/boot/grub/grub.cfg GRUB_VMLINUZ_SYMLINKS=default GRUB_VMLINUZ_FAILSAFE=default GRUB_CMDLINE_LINUX_DEFAULT='panic=30 splash=silent' GRUB_CMDLINE_LINUX='failsafe vga=normal' GRUB_TERMINAL_OUTPUT='gfxterm' GRUB_GFXMODE='800x600' GRUB_DEFAULT='saved' GRUB_SAVEDEFAULT=true GRUB_WALLPAPER="/etc/bootsplash/themes/current/images/silent-800x600.jpg" GRUB_COLOR_NORMAL="yellow/blue" GRUB_COLOR_HIGHLIGHT="white/cyan" GRUB_AUTOUPDATE_DEVICE="(hd0)"
а у меня на свежеустановленной P6 GRUB выдал sparse file not allowed и тоже any key. Это не связано ?
BTW, у вас в конфиге grub не включен nmi_watchdog, а из лога ядра видно, что он включен. Ядро грузилось с другими параметрами?
(В ответ на комментарий №9) > BTW, у вас в конфиге grub не включен nmi_watchdog, а из лога ядра видно, что он > включен. Ядро грузилось с другими параметрами? Все параметры прописаны в секции загрузки ядра, я сам ничего не включал, особенно watchdog. Похоже, что ядро само запускает его. Параметры ядра из лога: Command line: BOOT_IMAGE=/vmlinuz-un-def root=UUID=b5357695-1bd6-456e-a122-ad4b793276c3 ro panic=30 splash=silent vga=791
Забираю.
1) воспроизводится ли с grub2-pc-2.00 и нынешними ядрами? 2) а не включен ли watchdog в BIOS случайно?
ping, прошу по возможности проверить 2.00-alt3 из http://git.altlinux.org/tasks/83727/ и учесть http://www.altlinux.org/Grub#.D0.9A.D0.B0.D0.BA_.D1.83.D1.81.D1.82.D0.B0.D0.BD.D0.BE.D0.B2.D0.B8.D1.82.D1.8C_GRUB.3F
oops, reassign back to myself
Created attachment 5622 [details] Файлы grub2-pc-2.00-alt3 Файлы, используемые при обновлении grub2-pc-1.99-alt9 до grub2-pc-2.00-alt3. Загрузка идёт из первого пункта меню.
Обновление прошло без проблем, система перезагрузилась с новым загрузчиком. Проблем при загрузке не обнаружено. Только графическая тема загрузчика по ощущениям сильнее (чем с 1.99-alt9) подтормаживает при выборе пунктов меню: # rpm -qa|grep branding branding-simply-linux-notes-6.990.0-alt1 branding-simply-linux-release-6.990.0-alt1 branding-simply-linux-xfce-settings-6.990.0-alt1 branding-simply-linux-alterator-6.990.0-alt1 branding-simply-linux-bootloader-6.990.0-alt1 branding-simply-linux-indexhtml-6.990.0-alt1 branding-simply-linux-graphics-6.990.0-alt1 branding-simply-linux-slideshow-6.990.0-alt1 branding-simply-linux-bootsplash-6.990.0-alt1 branding-simply-linux-menu-6.990.0-alt1 # Видеокарта "03:00.0 VGA compatible controller: NVIDIA Corporation GF104 [GeForce GTX 460] (rev a1) (prog-if 00 [VGA controller])".
Тогда предлагаю на сейчас закрыть как WORKSFORME (поскольку никаких специальных действий не предпринималось, кроме обновления до 2.00), если вылезет -- REOPEN.
С версией 2.00-alt2 (что сейчас в Сизифе) вылезло другое: почему-то у меня /usr/lib/grub - это символьная ссылка и указывает на /boot/grub (версия grub2-pc-1.99-alt9). В результате при установке на i586-машины затираются файлы /usr/lib/grub/i386-pc/*.mod, которые на самом деле лежат в /boot/grub/i386-pc/. Приходится вручную удалять ссылку и переустанавливать пакет. С x64-машинами такого не происходит.
(In reply to comment #18) > почему-то у меня /usr/lib/grub - это символьная ссылка и указывает > на /boot/grub (версия grub2-pc-1.99-alt9). Очень интересно, а есть хотя бы один хост, где она ещё присутствует? Сделайте там rpm -V grub2-pc, потому как происхождение такой ссылки пока непонятно -- в пакетах нет ни её, ни разницы по архитектурам: $ rpm -qlvp grub2-pc-2.00-alt2.i586.rpm| grep /usr/lib/grub$ drwxr-xr-x 2 root root 0 Nov 5 15:44 /usr/lib/grub $ rpm -qlvp grub2-pc-1.99-alt9.i586.rpm | grep /usr/lib/grub$ drwxr-xr-x 2 root root 0 May 12 15:33 /usr/lib/grub $ rpm -qlvp grub2-1.99-alt7.i586.rpm | grep /usr/lib/grub$ drwxr-xr-x 2 root root 0 Jul 1 2011 /usr/lib/grub Обновление с p6 и p5 с переездом с lilo я проверял (на x86_64). Заглянул в grub-install.in, grub-mkconfig*.in -- вызовов ln(1) нет как класса. Пока всё же похоже на ручную "оптимизацию", поскольку /usr/lib/grub содержит единственный подкаталог i386-pc, который оттуда копируется в /boot/grub/i386-pc (который пакету не принадлежит). Только если подтвердится -- просьба завести отдельный баг, к исходному в любом разе без отношения. Объезд сделать можно, но для rpm4 переходы между симлинками и каталогами -- больная тема, особенно неожиданные.
(В ответ на комментарий №19) > (In reply to comment #18) > > почему-то у меня /usr/lib/grub - это символьная ссылка и указывает > > на /boot/grub (версия grub2-pc-1.99-alt9). > Очень интересно, а есть хотя бы один хост, где она ещё присутствует? Сделайте > там rpm -V grub2-pc, потому как происхождение такой ссылки пока непонятно -- в > пакетах нет ни её, ни разницы по архитектурам: Обнаружено на 5 i586-машинах. Две их них клоны друг друга. Ещё три я ставил с нуля: загружался с флешки с Сизифом (на то время), монтировал винты внутрь и использовал rpm+apt в chroot винта. #rpm -V grub2-pc S.5....T c /etc/sysconfig/grub2 ....L... /usr/lib/grub # rpm -q grub2-pc grub2-pc-1.99-alt9 # Все машины за эти годы (часть с 2004, часть с 2006, часть с 2007) пережили переезды загрузчика lilo->grub->grub2->grub2-pc.
