On Thu, Aug 07, 2008 at 12:53:24PM +0400, Aleksey E. Birukov wrote: > Нужно было временно установить MySQL4 на удаленный сервер. > 64bit-ную версию я не нашел -- пришлось поставить 32bit-ную.
Почему ж было не спросить здесь? > Get:4 ftp://ftp.altlinux.org i586/classic libMySQL41.32bit 4.1.21-alt5.1 Там же рядышком с заменой i586 на x86_64 -- нужная... Интересно, возможно ли каким-либо способом понадёжней заблокировать такой сценарий? Например, объявить важной не просто glibc, а для архитектуры, под которую собран apt. > Можно ли починить сервер удалённо? Это было практически невозможно. > Если нельзя, то какие действия оптимально нужно сделать для > исправления ситуации? Организовать добирание туда кого-то с rescue/livecd и сливание /etc и прочих данных с последующим reinstall... On Thu, Aug 07, 2008 at 01:23:08PM +0400, Aleksey E. Birukov wrote: > Что, вообще, с системой случилось? Вы её угробили. Это ценный опыт, но лучше в будущем при таких "нужно временно" и столкновении с необычным выводом apt: - чтоб что-то начинало чесаться - заодно можно спросить на #altlinux или в community@ - если совсем некогда, проверить на стенде - если совсем-совсем некогда, то подумать, важнее ли результат возможной необходимости восстановления системы с нуля PS: ещё из той же оперы -- засунуть бинарно-несовместимую glibc с --nodeps (мой второй убитый линукс). А этот же самый фокус тоже проходил, только в процессе формирования системы -- взял не тот sources.list из уже готовых и проигнорировал необычность вывода apt. Правда, система строилась всё равно заново и там этот опыт стоил всего часа или двух на повторение процесса... On Thu, Aug 07, 2008 at 02:12:58PM +0400, Nikolay A. Fetisov wrote: > > Может бинарные версии файлов загрузить? > Можно _попробовать_ загрузиться с установочного диска в режиме > восстановления, смонтировать убитую систему и переписать в неё > файлы из пакетов со снесёнными библиотеками. Перейти через > chroot в систему, запустить ldconfig. По-идее, должно помочь. > Затем, после перезагрузки, восстановить конфигурацию APT и > переустановить библиотеки. Это требует довольно заметной квалификации и наличия возможности загрузиться с 64-битного livecd/rescue _на том конце_. > Далее изучать литературу в области OpenVZ, который позволяет > держать 32-битные контейнеры в 64-битной системе и избегать > подобных стрессов. +1 On Thu, Aug 07, 2008 at 02:31:17PM +0400, Pavlov Konstantin wrote: > > нужно завести привычку: держать ash-static и rpm-static на > > "ответственной" сситеме. Записал в todo. > Да ну, просто надо понимать что делаешь и если не очень, то тестировать. Ой да. On Thu, Aug 07, 2008 at 01:01:33PM +0300, Dmitriy Kruglikov wrote: > > Все... к ssh больше не коннектится. Вопрос об удалённом > > восстановлении снят. Можете ли что-нибудь посоветовать > > по оптимальному восстановлению системы? > Ваши настройки сохранились однозначно ... > Стало быть, нужно добраться до диска и бережно его скопировать ... > Установить систему начисто, а настройки потом перелить поверх. Только стоит по возможности аккуратнее проверить, где ещё могут быть нужные данные. Навскидку стоит заархивировать и унести: /etc /home /var /usr/local PS: ещё когда-то завёл привычку время от времени делать рутом rpm -qa | sort > ~/BAK/rpm-qa.YYYYMMDD или rpm -qa --qf='%{NAME}\n' | sort > ~/BAK/rpm-qa.YYYYMMDD -- тогда на корневой ФС остаются в виде текстовых данных списки, пригодные для скармливания apt (во втором случае -- вообще без дополнительной обработки). Ещё хорошо делать fdisk -l, только это лучше держать на других системах. -- ---- WBR, Michael Shigorin <[EMAIL PROTECTED]> ------ Linux.Kiev http://www.linux.kiev.ua/ _______________________________________________ Sysadmins mailing list Sysadmins@lists.altlinux.org https://lists.altlinux.org/mailman/listinfo/sysadmins