LINUX.ORG.RU

Debian mix, lilo -> grub = полурабочая система


0

0

Доброго времени суток.

Стоял Debian микс, в качестве загрузчика был lilo. К нему на bugtracking были
претензии на тему проблем загрузки новых ядер. Дабы не сталкиваться с
подобным, решил, как советуют, поменять lilo на grub.

Действия были такие.

1. Установил grub, удалил lilo.
2. Перезагрузил машину, убедился, что grub не переписал mbr, из-за чего машина не грузится.
3. Неправильно "восстановил" mbr, из-за чего полетела таблица разделов.
4. Восстановил таблицу testdisk'ом.
5. С помощью Debian live lenny засунул grub в mbr командой grub-install /dev/hda
6. Паника ядра.
7. Экспериментальным путём нашёл, что она связана с ld.so.cache.
8. Делаю из Live cd системы ldconfig -r /mnt, в /mnt смонтирован только
корень из 6 разделов - /, boot, usr, tmp, var. home
9. Система грузится, работает почти всё, кроме xmms, которая стала выдавать
Segmentation fault. Раньше всё работало.
10. Команда ldconfig из рабочей системы делает нерабочую, ldconfig из Live CD оживляет её заново с теми же симптомами.


Собственно вопросы.

1. А с чего это изменение загрузчика так повлияло на ld.so.conf?
2. А что, собственно, происходит? Почему ldconfig из системы умерщвляет её,
а ldconfig из live CD оживляет?

Заранее спасибо за ответы.

anonymous

8. Делаю из Live cd системы ldconfig -r /mnt, в /mnt смонтирован только корень из 6 разделов - /, boot, usr, tmp, var. home.

После этого вас улдивляет что половина либов не по попала в ld.so.cache? Примонтируйте ещё /usr в /mnt/usr.

Паника ядра и ld.so - это всё-таки немного странно. Вернуть старое ядро не помогает?

Насчет xmms - сделать корку (ulimit -c unlimited перед запуском) и посмотреть gdb `which xmms` core.XXXX в гдб сделать backtrace.

gena2x ★★★
()
Ответ на: комментарий от gena2x

>8. Делаю из Live cd системы ldconfig -r /mnt, в /mnt смонтирован только корень из 6 разделов - /, boot, usr, tmp, var. home.

>9. Система грузится, работает почти всё, кроме xmms, которая стала выдавать

Дак usr он монтировал. Следуя вашему подходу, получается что у автора есть ещё одни раздел (не usr), который он не монтирует с LiveCD, и поэтому либы их этого раздела не попадют в cache и система работает.

Автору топика:

>7. Экспериментальным путём нашёл, что она связана с ld.so.cache.

какие вы ставили эксперименты? Может чего подуляли?

P.S. Не сломалось --- не чини :)

mky ★★★★★
()
Ответ на: комментарий от mky

То есть не монтировал usr, и получается что в usr находятся либы, которые портят ld.so.cache...

mky ★★★★★
()

Может у вас в системе ldconfig с ошибкой? И создает "битый" кеш? Попробуйте прочитать его "ldconfig --print-cache".

mky ★★★★★
()
Ответ на: комментарий от gena2x

>После этого вас улдивляет что половина либов не по попала в ld.so.cache? Примонтируйте ещё /usr в /mnt/usr.

Так работает же! А вот ldconfig из рабочей (!) системы делает её нерабочей. Вот это странно.

>Вернуть старое ядро не помогает?

От ядра не зависит. К тому же, пока на старом.

>gdb `which xmms` core.XXXX в гдб сделать backtrace.

Звиняюсь, но не программист.

anonymous
()
Ответ на: комментарий от mky

>Дак usr он монтировал.

Нет, только корень.

>какие вы ставили эксперименты? Может чего подуляли?

Chroot давал segmentation failed после установки grub в mbr. Переименовал /etc в /et (chroot заработал), и постепенно добавлял все файлы из /et в созданный /etc. При добавлении ld.so.cache выдаётся ошибка о каких-то там символах. При удалении из /etc этого файла и запуска ldconfig -r /mnt система начала грузиться.

>Не сломалось --- не чини :)

Так сломалось же ;) Потом, правда, починили, но lilo уже как мёртв.

anonymous
()
Ответ на: комментарий от gena2x

Я думаю, что у вас в системе есть несколько битых либов(или иных бинарников) или неправильно отработал testdisk или что вы там запускали. для того чтобы в этом убедиться необходимо найти или не найти битые файлы проверить их md5 и переустановить соотв. пакеты,. Если падает xmms - это отличный шанс выснить правильна ли моя догадка: испортился либо сам xmms либо его либы, для того чтобы это выяснить я просил вас сделать backtrace.

gena2x ★★★
()

Новый вопрос: а почему это в папке /lib лежат библиотеки удалённой libc6-2.3.6, когда в системе установлена версия libc6-2.7? И что это за папка /lib/tls, которая отсутствует в libc6-2.7, и в которой полно старых симлинков на старые либки, которые, судя по всему, попадают в ld.so.cache?

anonymous
()
Ответ на: комментарий от gena2x

А что искать-то? Или просто файлик выложить?

Переустановка xmms не помогла.

anonymous
()
Ответ на: комментарий от anonymous

С удалением /lib/tls ldconfig в системе отрабатывает нормально. xmms падает ;) Пока других видимых проблем нет.

В общем вопрос теперь - каким образом и зачем файлы старой glibc остаются в системе?

anonymous
()
Ответ на: комментарий от anonymous

Ну раз вам дебианщики не отвечают, то напишу. libc-2.3.6 это libc от debian stable, а libc-2.7 это от debian testing. Старая версия libc остается от старых прог, которые не работают с 2.7.

Соверую вам проверить целостность файлов, вроде для этого использовался debsums, или скриптом по данным из каталога /var/lib/dpkg/info.

mky ★★★★★
()
Ответ на: комментарий от mky

Эээ, господин хороший glibc сохраняет обратную совместимость, нет нужды хранить две копии, да и не встанет в дебиане два пакета libcсшных.

В tls какая-то устаревшая фигня хранится :)

gena2x ★★★
()
Ответ на: комментарий от gena2x

Да нет, /lib/tls входит в состав libc6-2.3.6, но её нет в libc6-2.7. Кроме того, в /lib есть версии либок старой libc. То есть получается, что часть старой libc6 осталась в системе. И не мешала работать, до некоторого времени ;)

anonymous
()

>5. С помощью Debian live lenny засунул grub в mbr командой grub-install /dev/hda
Здесь, видимо, начало проблемы. Если grub ставился прямо с CD, без chroot'а в установленную систему, то очень легко ошибиться с нумерацией диска.

>8. Делаю из Live cd системы ldconfig -r /mnt, в /mnt смонтирован только

корень из 6 разделов - /, boot, usr, tmp, var. home
Это было страшно. Как минимум, надо было смонтировать /usr как уже сказали выше.

>10. Команда ldconfig из рабочей системы делает нерабочую, ldconfig из Live CD оживляет её заново с теми же симптомами.

А вот это странно. Но есть вопрос: что Вы называете "нерабочей системой"? Т.е. какие симптомы?

fractaler ★★★★★
()
Ответ на: комментарий от fractaler

>Если grub ставился прямо с CD, без chroot'а в установленную систему, то очень легко ошибиться с нумерацией диска.

С какой нумерацией? /dev/hdx?

>Но есть вопрос: что Вы называете "нерабочей системой"?

Любая команда вызывает ошибки тика /lib/tls/какая-то_либа не содержит описания символов из /lib/libc6.so.чего-то_там. Помогает только грубая перезагрузка.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.