Я ни разу не писал о том, что отсутствует локаль, я писал о том , что при загрузке сервера выходит сообщение "No such file or directory" (это про cp866.uni).
LinuxForum.Fans
Русская локаль в SLES11SP1
Автор: eugene_str
57 сообщений
14416 просмотров
и даже написал о временном решении данной проблемы, если указать в файле /etc/sysconfig/console CONSOLE_UNICODEMAP="/usr/share/kbd/unimaps/cp866.uni", но считаю это плохим решением.
eugene_str
Разница? libc исчез из 11 версии, есть только Glibc, да я могу поставить этот пакет, но мне интересно почему на Glibc комманда localedef таким образом работает, докопаться до сути вот чего хочу.
Цитата с ВИКИ:
...они часто реализуют аналогичную функциональность со Стандартной библиотекой с различной степенью схожести. Например, glibc реализует такие функции как fork в libc.so, но перед вызовом библиотеки потоков объединяются в glibc, хотя это заявлено как отдельная библиотека с собственным флагом линковщика....
Ответ прост, убрали, потому как сделали более новую с большим функционалом. Почему так отрабатывает, по видимому нужно задать ещё доп параметры.
Я ни разу не писал о том, что отсутствует локаль, я писал о том , что при загрузке сервера выходит сообщение "No such file or directory" (это про cp866.uni).
Потому как нет такого файла и я не совсем уверен, что он должен быть, как я Вам писал выше, у меня вообще нет ссылки на него, откуда у Вас появляется линк на него, я могу предположить, но с уверенностью сказать...
если указать в файле /etc/sysconfig/console CONSOLE_UNICODEMAP="/usr/share/kbd/unimaps/cp866.uni", но считаю это плохим решением.
Почему плохим решением? Ну переместите этот файл куда Вам нужно или сделайте сим линк на него, но вопрос остаётся открытытм- ДЛЯ ЧЕГО?? Что это даст? Уберёт ошибки в загрузки, тогда проще вообще стереть строку ссылающуюся на него в файле локали. Вам ведь нужно работоспособность системы, а не без глюченные логи, я так ведь понимаю.
cp866.uni находится в /usr/share/kbd/unimaps/cp866.uni, линков на него нигде руками не создавал.
А решение прописывать полный путь считаю плохим потому, что придется тестировать работу базы на OpenEdge от и до, протестировать в полном объеме очень сложно, а значит есть вероятность возникновение проблем, очень не хочется проблем при работающей базе.
cp866.uni находится в /usr/share/kbd/unimaps/cp866.uni, линков на него нигде руками не создавал.
Смотрите всё просто. Возможно это и есть ответ. Логи загрузки Ваши, гласят о том, что система не может найти этот пакет. Возможно, когда Вы выполняли свою команду по смене локали, каким то образом в её параметрах есть то, что система ссылается на этот файл, для чего он ей нужен, я не знаю, но если нужен, то укажите путь, где ей его искать, как вариант и это будет Вашим решением.
А решение прописывать полный путь считаю плохим потому, что придется тестировать работу базы на OpenEdge от и до, протестировать в полном объеме очень сложно, а значит есть вероятность возникновение проблем, очень не хочется проблем при работающей базе.
Какая разница базе откуда сама ОСь берет локаль? oO Сама база ведь не зависит от локали, тестируйте себе на здоровье. Вам всё равно MC ставить сторонний, так как даже при рабочей локале он кривой родной на Sles 11. Опять же на саму базу это ника кне повлияет и на её тесты.
Я ставил SLES11 ну раз 5 и не только я, данная ситуация моделировалась всегда и у всех кто пробовал, понятно что нужно указать кому то, но вопрос кому указать и где прописать?
eugene_str
Перелопатил весь сервер, прикол в том, что не одно приложение не ссылается на этот файл, он не имеет символьной ссылки, путь к нему нигде не указывается (по крайней мере у меня). Так что далее ступор, я не знаю что вам сказать, разве только вообще убрать напоминание о нём в файле locale и всё (у меня, как я писал выше, нет этой сноски в locale, у Вас есть, поэтому и высыпаются ошибки). Я так понимаю система этот файл сама находит, но каким путём, это уже загадка, тут нужен человек, который бы непосредственно смыслил в работе системе как минимум на уровне разработчика... :(
Спасибо, что столько времени потратили на меня, много для себя полезного узнал, остался еще вариант официально обратиться в службу технической поддержки SUSE.
Прогрепал ситему SLES11SP1 и SLES10SP3 на предмет поиска файлов содержаших текст "cp866.uni":
find / -type f -a –not –regex “/proc/.*” -a –not –regex “/sys/.*” -exec grep -l "cp866.uni" {} \; >list.txt
Вот результат для SLES11SP1:
/var/lib/rpm/Packages
/var/lib/rpm/Basenames
/var/log/boot.omsg
/var/log/boot.msg
/var/log/YaST2/y2log
/usr/bin/emacs-gtk
/usr/bin/emacs-x11
/root/.bash_history
/root/.mc/history
/etc/sysconfig/console
Вот результат для SLES10SP3:
/etc/sysconfig/console
/var/log/YaST2/y2log
/var/log/boot.msg
/var/log/boot.omsg
/var/lib/rpm/Packages
/var/lib/rpm/Basenames
/root/.mc/history
Из сравнения видно, что SLES11SP1 отличается наличием файлов:
/usr/bin/emacs-gtk
/usr/bin/emacs-x11
P.S. - Рою дальше
Смотрю что за emacs по ссылкам http://www.novell.com/products/linuxpackages/server11/i386/emacs-x11.html и http://www.gnu.org/software/emacs/
А вот руководство по GNU Emacs http://www.linux.org.ru/books/GNU/emacs/emacs_toc.html
Косяк нашёл, чуть позже распишу подробности, считаю что ошибка довольно существенна !!!
Ндааа...
eugene_str
Ждём рецензий. Хоть бы намекнули в чём косяк.
Пошел другим путем, если в SLES10SP3 данной ошибки не возникает, то это значит указан путь “/usr/share/kbd/unimaps” где то в конфигурационном файле, или ещё где нибудь, а значит нужно произвести поиск в ситемах SLES11SP1 и SLES10SP3 на предмет содержания во всех файлах текста “/usr/share/kbd/unimaps”, что я и сделал:
find / -type f -a –not –regex “/proc/.*” -a –not –regex “/sys/.*” -exec grep -l “/usr/share/kbd/unimaps” {} \; >path_list.txt
Вот список для SLES10SP3:
/etc/sysconfig/console
/var/log/YaST2/y2log
/var/lib/rpm/Packages
/var/lib/rpm/Dirnames
/var/adm/fillup-templates/sysconfig.console
/bin/loadunimap
/bin/setfont
/root/.mc/history
Вот список для SLES11SP1:
/var/lib/rpm/Packages
/var/lib/rpm/Dirnames
/var/adm/fillup-templates/sysconfig.console
/var/log/YaST2/y2log
/tmp/Tuning_SLES/console
/root/.mc/history
/etc/sysconfig/console
Сравнивая две системы нашел, что в SLES10SP3 присутствуют 2-а файла /bin/loadunimap и /bin/setfont, в содержании которых есть пути “/usr/share/kbd/unimaps”, но которые отсутсвуют в таких же файлах SLES11SP1. Разумный вопрос, почему? Возможно баг, а возможно изменился механизм подгрузки файлов *.uni. Смотрим содержимое “loadunimap” обоих файлов в 2-х системах и, сравнивая, находим интересную деталь:
В SLES10SP3:
“/usr/share/locale kbd -V --version %s from %s
kbd-1.12 C:o: def.uni /usr/share/kbd/unimaps/ %s %s error executing %s
.. %s/%s %s%s%s .gz gzip -d -c .bz2 bzip2 -d -c Cannot write font file header appendseparator appendunicode: illegal unicode %u”
В SLES11SP1:
“/usr/share/locale kbd -V --version_%s from %s
kbd 1.14.1 C:o: def.uni /usr/share/kbd/consoletrans/ .sfm %s %s error executing %s
.. %s/%s %s%s%s .gz gzip -d –c .bz2 bzip2 -d –c Cannot write font file header appendseparator appendunicode: illegal unicode %u
Appendunimap U+ %02x Cannot write font file %s: Error reading input font %s: Bad call of readpsffont”
Тоесть в SLES10SP3 утилита kbd версии kbd-1.12 и путь по умолчанию для uni файлов “/usr/share/kbd/unimaps/”, а в SLES11SP1 утилита kbd версии kbd 1.14.1 и путь по умолчанию “/usr/share/kbd/consoletrans/”. С чего вдруг путь стал “/usr/share/kbd/consoletrans/” для uni файлов? Это явный баг, получившийся либо при компиляции или имеющийся в дистрибутиве утилиты kbd 1.14.1. Следуя данной логике, если я в каталоге “/usr/share/kbd/consoletrans/” укажу линк на “/usr/share/kbd/unimaps/cp866.uni”, то ошибка при загрузке “No such file or directory” должна исчезнуть. Поступаю именно таким образом, и действительно, ошибка исчезла.
loadunimap загружает таблицу перевода unicode-to-font ядра и входит в состав утилиты kbd. Man pages SLES11 и SLES10 говорит о том, что “/usr/share/kbd/unimaps is the default directory for Unicode mappings” , тоесть “/usr/share/kbd/unimaps/” есть директория по умолчанию для файлов uni.
Setfont – функция loadunimap, в SLES11SP3 путь “/usr/share/kbd/unimaps/” так же отсутствует.
Т.о. в утилите kbd 1.14.1 присутствует баг, возможно залечивается в следующих версиях kbd 1.15 и выше, что нужно проверить.
Неоспоримый факт, что loadunimap ищет файл cp866.uni в SLES11 в директории “/usr/share/kbd/consoletrans/”, вместо “/usr/share/kbd/unimaps/” и данный баг в утилите kbd 1.14.1. Если оставить утилиту kbd 1.14.1 в SLES11, то необходимо в директории “/usr/share/kbd/consoletrans/” создавать линк на соответствующий файл “/usr/share/kbd/unimaps/*.uni”, но криво работающая loadunimap настораживает.
Более верное решение данной проблемы, это обновить утилиту kbd до версии kbd 1.15 или выше kbd 1.15.2, но дистрибутив для SLES с новым kbd пока не нашел.
Войдите или зарегистрируйтесь, чтобы ответить.
