- Как сменить locale в Debian или пишем кириллицей в консоли linux
- Поддержка русского языка в консоли
- Содержание
- Почему в консоли квадратики вместо русских букв?
- Как же правильно лечить больного?
- Кому интересно — «откуда ноги растут».
- Решение для ubuntu 15.10 и более поздних
- Вредные советы
- Ubuntu. Русификация консоли в 2016 году
- Лирическое вступление
- Поворот не туда
- Начнём сначала
- Продолжаем разговор
- Тёплые потроха
- Вносим исправления
Как сменить locale в Debian или пишем кириллицей в консоли linux
Я знаю что кириллица в логах Linux – это самый страшный грех для айтишника, но иногда это просто необходимость. Одна из таких необходимостей возникает при создании централизованного хранения log-файлов различных операционных систем. Microsoft всегда в своих log`ах применяет кириллицу и поэтому если мы хотим получать log-файлы и от Win-серверов, то стоит смириться, что в log`ах будет кирилица.
Для того, чтобы эти логи нормально отображались нам и нужно явно указать locale в Debian, Ubuntu или какой Linux-дистрибутив Вы используете.
Проблемы отображения кириллических символов в Linux не существует. Есть проблема у русской версии Windows. Весь мир и Linux в том числе, работает в кодировке UTF -8, когда русская версия Microsoft использует CP1251. Такая ситуация сложилось исторически благодаря компании «Парус», которая взяла на себя обязательства по локализации всех операционных систем Windows. Выбрали они почему-то кодировку CP1251, которая применяется до сих пор. Использование этой «неправильной» кодировки в наши дни обусловлено сохранением совместимости всех версий ОС.
Чтобы добавить кириллицу, чтобы Linux сервер нормально отображал русские буквы, нужно объяснить ему, что необходимо работать в той же кодировке, что и Windows.
Для того, чтобы управлять локалью в Linux, необходим пакет locales, который должен быть у Вас установлен. В большинстве случаев пакет locales уже будет у Вас установлен, поэтому для проформы просто проверяем этот факт.
Посмотреть установленную locale linux можно командой:
Для ручного указания кодировке в Linux Mint, Debian или ubuntu нужно отредактировать конфигурационный файл /etc/locale.gen :
Команду sudo не нужна, если Вы зашли как суперпользователь. Это относится к Linux Mint и Ubuntu, так как Debian ничего не знает о команде sudo.
В этом файле необходимо найти строчку и расскомментировать с той locale, которая Вам нужна. Для добавления кириллицы нужно раскомментировать строчки с UTF-8 или CP1251 .
- если хотим указать, чтобы ОС работала в UTF -8, раскомментирум:
- если хотим указать, чтобы ОС работала в CP1251, раскомментирум:
Стоит обратить внимание, что первые 2 символа (в нашем примере это ru) говорят нам о языке локализации (кириллица).
После этого переопределяем настройки locales командой:
Команда locale-gen позволяет запустить скрипт /etc/locale.gen и перечитывает все кодировки для консоли.
Чтобы увидеть кириллицу в консоли Linux, остается только перелогиниться.
Источник
Поддержка русского языка в консоли
Содержание
В 15.10 изменена система загрузки (sustemd) и описанное ниже средство не помогает. Смотрите раздел Решение для ubuntu 15.10 и более поздних.
Почему в консоли квадратики вместо русских букв?
Многие замечали, что из версии в версию в Ubuntu у некоторых слетают русские фонты в консоли (куда можно попасть нажав CTRL+ALT+F1 — F6, а CTRL+ALT+F7 возвращает в графическую среду). Озаботившись причинами почему это происходит я (Sly_tom_cat) облазил кучу мест в поисках решения. Залез и в initrd и смотрел в скрипты upstart и в UDEV… что ни правил — не помогает. Особо порадовал комментарий разработчиков в одном из скриптов Udev 1) . Cуть там примерно такова: «надо бы делать как-то так, но мы попробовали — у нас не вышло. Так что, делаем как получится, а если юзерам нужны нормальные фонты — пускай выполнят setupcon и все будет Ok»
Но все-таки нет такого решения, которого не найти в Интернете. Причем нашел я его даже по русски 2)
Как же правильно лечить больного?
Оказывается, всего навсего, нужно включить поддержку фреймбуфера на этапе инициализации ядра. Это в свою очередь разрешит выполнение нужных скриптов, которые загрузят фонты на самом раннем этапе инициализации ядра.
Для этого:
1. в любом текстовом редакторе с правами рута нужно в файл /etc/initramfs-tools/initramfs.conf добавить строчку FRAMEBUFFER=Y. Это также можно сделать выполнив следующие команды:
2. Обновить образ рамдиска периода инициализации ядра (initrd):
Поле этих манипуляций наконец начнут работать настройки сделанные командой 3) :
Кириллическими фонтами будет показываться все с самого начала — т.е. даже запрос на проверку дисков (возникающий в процессе инициализации ядра) будет выводится кириллицей, а не квадратами.
Возможно потребуется так же настроить и клавиатуру (раскладки, переключение раскладок и compose-key) 4) :
Кому интересно — «откуда ноги растут».
Покопавшись глубже можно обнаружить следующее:
В initrd/scripts/init-top/ лежат скрипты выполняющиеся в самом начале процесса инициализации ядра. И там мы видим все, что могло бы потребоваться для поддержки «правильных» фонтов
Но, если заглянуть в файлы console_setup, keymap и framebuffer то в самом начале скрипта мы увидим такую строчку:
А покопавшись в скриптах инициализации можно понять, что OPTION обрабатывается так, что если значение переменной (что ей присвоено) не задано или не Y, то выполнение самого скрипта пропускается. Т.е. в нашем случае, если FRAMEBUFFER не равно Y, то ни один из скриптов, отвечающих за поддержку фонтов и раскладок клавиатуры, попросту не будут выполнятся в процессе инициализации ядра.
Но без FRAMEBUFFER не возможно загрузить шрифты с поддержкой национальных символов!
Примечательно то, что настройки раскладок клавиатуры все-таки будут применены в процессе загрузки ОС (уже после инициализации ядра). За это отвечает скрипт console-setup системы инициализации upstart, а вот консольные фонты скрипты upstart не настраивают.
Однако, это совсем не объясняет почему подобная проблема возникает не у всех. И как оказывается — она вылезает у любителей оптимизации системы, да еще и у пользователей серверной версии Ubuntu…
Что можно увидеть в любой инструкции по повышению скорости загрузки ОС?
Правильно — «уберите заставку при загрузке»: в файле /etc/default/grub в переменной GRUB_CMDLINE_LINUX_DEFAULT значение splash замените на nosplash или просто уберите) и выполните sudo update-grub. Ну, а пользователи серверной версии Ubuntu по умолчанию обделены таким «счастьем», как графическая заставка во время загрузки.
Так вот, оказывается, разработчики решили, что фреймбуфер нужен для рисования заставки и … и только для этого. Больше (оказывается) он никому, ни зачем, не нужен. Поэтому, если заставку рисуем — то фреймбуфер разрешаем (а то как же — без него же не нарисовать заставку), а если заставку не рисуем, то и фреймбуфер включать незачем, не включаем…. Нет, позже, после инициализации ядра, фреймбуфер все-таки где-то активируется, но поезд уже ушел — фонты на этапе иницализации ядра не загрузились…. «а кому надо — те пусть вызывают setupcon …»
Решение для ubuntu 15.10 и более поздних
В Ubuntu 15.10 имеется неисправленный баг с настройкой локали https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1511975. Поэтому для настройки русского языка необходимо проделать следующее 1.
(настройки в файле /etc/default/console-setup)
(настройки в файле /etc/default/keyboard)
Заменить последнюю строку
Вредные советы
Поиск в сети порой дает много костыльных советов на данную тему. Особенно часто встречаются два из них:
1. костыль из костылей: «Прописать setupcon в /etc/rc.local» — мало того что это костыль, да еще и не помогает иногда 🙁
2. совсем эпический по своей дебильности костыль — персональный пакет для русского языка в консоли — console-cyrillic . …вызывает полное недоумение идея — «под каждый язык на свете создавать персональный пакет для консоли», когда по дефолту в UTF8 кодировке и основных консольных шрифтах есть все, что нужно для поддержки практически любого языка (по крайней мере европейского).
Если вам попадаются такие советы, не поленитесь — объясните людям их глубокое заблуждение и отправьте на эту страницу.
Источник
Ubuntu. Русификация консоли в 2016 году
Для меня было некоторым откровением узнать, что в 2016 году, в одном из крупных дистрибутивов GNU/Linux существуют проблемы с локализацией. А точнее, с локализацией текстовой консоли. Кто пользуется текстовой консолью в 2016 году? Не надо забывать, что есть множество дистрибутивов, базирующихся на Ubuntu и не все из них используют графическое окружение. Назову два примера: Ubuntu Server и Clonezilla.
Выглядит проблема так:
И присутствует в текущем релизе Ubuntu 15.10 и в бета-версии Ubuntu 16.04. Тем, кому интересно узнать причины проблемы и как можно её решить — прошу под хабракат.
Лирическое вступление
Всё началось с Clonezilla. Это такой Linux Live CD/USB с программой Clonezilla для копирования дисков. Делаю, я, значит, себе загрузочную флешку с различными утилитами и, по-возможности, включаю русификацию, там где это возможно, так как хочу поделиться флешкой с коллегами, а они не все хорошо владеют английским. Только-что закончил настраивать GParted Live. Думаю, что всё должно быть похоже — оба дистрибутива поддерживают live-config. Задаю параметры для русификации — добавляю к параметрам ядра следующие значения:
locales=ru_RU.UTF-8
keyboard-layouts=us,ru
keyboard-options=grp:ctrl_shift_toggle,lctrl_shift_toggle
Первый параметр задаёт язык, на котором система будет с нами общаться и кодировку. Второй параметр задаёт раскладки клавиатур, которые мы будем использовать. И третий задаёт способ переключения раскладок клавишами CTRL+SHIFT. На самом деле, язык и раскладку можно выбрать после запуска Clonezilla, но нельзя выбрать две раскладки и способ переключения — будет только русская или только английская клавиатура. Эти параметры корректно отработали в GParted Live и я ожидаю такого же поведения от Clonezilla. Но… после загрузки вместо русских символов отображаются чёрные квадратики:
Вспоминаю, что Clonezilla предлагает две ветки дистрибутива: стабильная базируется на Debian и альтернативная на Ubuntu. Альтернативная содержит несвободное ПО, такое как прошивка (firmware) некоторого оборудования (например, WiFi-карт), поэтому, я скачал её — для большей универсальности.
Ради хохмы качаю стабильную версию, основанную на Debian, запускаю с русской локалью — всё отображается корректно.
Подозрения падают на родительский дистрибутив — Ubuntu 15.10. Как раз у меня такой, думаю я и переключаюсь на текстовую консоль (Ctrl+Alt+F1) и запускаю `date`:
На-ка, говорит Убунта.
Поворот не туда
Здравый смысл подсказывает — бери стабильную Clonezilla и работай дальше. Но. Впереди выходные, Dota 2 меня «отпустила», а память подсказывает что проблемы с локализацией текстовой консоли в Ubuntu существуют давно, решаются с переменным успехом и хочется всё-таки разобраться.
Гуглим проблему и обнаруживаем, что с подобным сталкиваются начиная с Ubuntu 11.10. Есть несколько решений разной степени полезности, самое популярное — включить опцию FRAMEBUFFER=y для initramfs и пересобрать initrd командой update-initramfs. Со словами «только бы не думать, и наша возьмет!» добавляю строку FRAMEBUFFER=y в конец файла initramfs.conf, обновляю образ initrd и перезагружаюсь:
После перезагрузки изменений нет, всё те-же квадратики вместо кириллицы. На форумах многие так же жалуются на то, что этот способ им не помог.
Начнём сначала
Откатил все изменения назад, пораскинул мозгами. За настройку консоли в Ubuntu отвечает пакет console-setup, который хранит настройки в /etc/default/console-setup и применяет их через команду setupcon. Настройки можно изменить просто отредактировав файл или через dpkg-reconfigure console-setup. Проверяем настройки консоли:
cat /etc/default/console-setup
ACTIVE_CONSOLES=»/dev/tty2″
CHARMAP=»UTF-8″
CODESET=»guess»
FONTFACE=»Fixed»
FONTSIZE=»8×16″
В текстовой консоли даём команду setupcon. Даже на глаз видно, что шрифт изменился и теперь консоль отображает кириллицу:
Значит, в системе есть всё для отображения кириллицы, но при загрузке эти настройки не применяются. Посмотрим, что находится внутри пакета console-setup:
Помимо уже упомянутых двух файлов (console-setup и setupcon) интерес представляет файл console-font.conf, устанавливаемый в /etc/init/. Этот файл представляет из себя скрипт systemd, системы начальной загрузки linux, заменившей system v init. Посмотрим на содержимое:
Судя по заголовку и описанию это похоже на то, что надо — установка шрифта консоли при загрузке системы. Задача по установке шрифта перекладывается на скрипт /lib/udev/console-setup-tty. Приведу самые интересные части этого скрипта:
Я пока пропустил все функции, которые определены внутри скрипта, чтобы обратить внимание на самое важное. Первый комментарий говорит, что скрипт основан на setupcon, но урезан, чтобы соответствовать правилу udev. Допустим. Ниже идёт включение файла настроек (. /etc/default/console-setup). Дальше идёт проверка первого параметра, переданного скрипту, как раз с таким параметром (fbcon) скрипт вызывается из /etc/init/сonsole-font.conf. Для каждой активной консоли (указаны в /etc/default/console-setup) делается проверка на возможность записи в неё и, для каждой консоли вызывается функция setup_font. При этом, автор скрипта пишет, что к моменту вызова скрипта консоли должны быть созданы, а если нет, то тест на запись в консоль не сработает и эта консоль останется не настроенной. А пользователь сам может вызвать setupcon потом. Возьмём это на заметку и рассмотрим функцию setup_font из файла /lib/udev/console-setup-tty:
Вооот. Вот он косяк. Переменная $FONT у нас не задана, срабатывает строка
Напомню настройки консоли:
CHARMAP=»UTF-8″
CODESET=»guess»
FONTFACE=»Fixed»
FONTSIZE=»8×16″
Переменные $CODESET, $FONTFACE, $FONTSIZE берутся напрямую из файла конфигурации и больше не изменяются. Выходит, что FONT=»/etc/console-setup/guess-Fixed8x16.psf». Посмотрим, какие шрифты у нас есть в /etc/console-setup/:
Таким образом, скрипт неправильно обрабатывет CODESET=«guess». Он должен был «догадаться» об используемом наборе символов. Так же неправильно обрабатывается FONTSIZE=«8×16», вероятно, должна оставаться бОльшая из цифр или последняя цифра. Но и это ещё не всё… Наш шрифт сжат и имеет расширение .gz. Как оказалось, команда setfont, которая вызывается дальше, сама добавит расширение .gz если не найдёт файл *.psf и загрузит шрифт. Но вот проверка на наличие файла с именем $FONT
не пройдёт и, переменная $SETFONT_ARGS останется пустой — соответственно, блок, непосредственно устанавливающий шрифт,
не будет выполнен.
Зная эту информацию, мы можем подстроиться под систему и вручную задать $CODESET=«Uni2» и
$FONTSIZE=«16» или, вместо этого задать переменную $FONT=«Uni2-Fixed16.psf». Кроме того, нам нужно файл шрифта распаковать:
После перезагрузки шрифт будет установлен, но при смене шрифта через dpkg-reconfigure console-setup нам придётся опять вносить исправления вручную.
Продолжаем разговор
Вспоминаем про скрипт setupcon, который был упомянут в комментариях и на котором базируется /lib/udev/console-setup-tty. Смотрим, что у него внутри:
Скрипт содержит код для Linux и FreeBSD, всё что относится к BSD можно смело пропускать. Я оставил только самое интересное — обработку $CODESET и $FONTSIZE. Как раз в этом скрипте есть обработка ситуации, когда $CODESET не задана или имеет значение ‘guess’. В этом случае, $CODESET принимает значение, зависящее от $CHARMAP. В нашем случае $CODESET=Uni2.
$FONTSIZE так же проверяется на незаданное значение или ‘guess’ и жестко устанавливается в ’16’, если это так. Если $FONTSIZE задан как 8x* или *x8, то знак ‘x’ и восьмёрка отбрасывается, и остаётся только одна цифра (высота шрифта). Например, было ‘8×14′ — останется ’14’, а от ’15×8′ останется ’15’. Если $FONTSIZE задан как две цифры ‘*x*’:
(a — первая цифра, b — вторая), то бОльшая цифра переставляется вперёд:
Например, было ’10×20′ — стало ’20×10′, а ’22×11′ меняться не будет. Посмотрим, как называются шрифты, доступные в системе:
Сходится. Теперь, если добавить такую обработку параметров $CODESET и $FONTSIZE в скрипт /lib/udev/console-setup-tty, а так же добавить в этот скрипт проверку на существование сжатого файла *.psf.gz (а заодно и *.acm.gz):
то скрипт отработает правильно.
Тёплые потроха
Продолжаем потрошить скрипты. Ищем, откуда (из какого пакета) растут ноги у /lib/udev/console-setup-tty:
Скачиваем и распаковываем пакет keyboard-configuration:
Смотрим, в каких скриптах используется файл настроек /etc/default/console-setup:
Из них интерес представляют только:
Все они содержат код, похожий на тот, что мы разобрали выше — из /lib/udev/console-setup-tty, без корректной обработки $CODESET и $FONTSIZE. А эти два файла
отличаюся только одной строкой:
OPTION=FRAMEBUFFER
Знакомая опция, подумал я… Три интересующих нас скрипта расположены в папке initramfs-tools. Пакет initramfs-tools отвечает за сборку образа initrd, который загружается в память при загрузке ядра и используется им в тот момент, пока не доступна основная файловая система. В initrd обычно содержатся модули ядра, необходимые для его работы на нашем оборудовании и для подключения файловых систем, а так же, скрипты инициализации и их конфигурационные файлы. Собирается образ скриптом update-initramfs, который, в итоге, вызывает скрипт mkinitramfs. Как всегда, посмотрим что внутри у mkinitramfs:
Здесь всё выглядит довольно сложно, я попробую показать с примерами. Этот блок проходит по всем файлам в /usr/share/initramfs-tools/scripts/ и подпапках, и ищет внутри них строку, содержащую ‘OPTION=’. Например, в файле /usr/share/initramfs-tools/scripts/init-top/console_setup есть строка
OPTION=FRAMEBUFFER
Если ‘OPTION’ отсутствует или не задана — файл (скрипт) копируется в initrd. Если ‘OPTION’ присутствует, берут значение этой опции как имя переменной и проверяют установлена ли она и не равна ли ‘n’. В нашем примере проверяется переменная $FRAMEBUFFER. Эту переменную мы устанавливали в FRAMEBUFFER=y в самом начале, в файле initramfs.conf. Так как само значение переменной FRAMEBUFFER в скриптах, относящихся к setup-console не используется, оно действует как триггер и можем задать ему любое значение, не обязательно ‘y’. Даже ‘no’ или ‘none’ отработает так же как ‘y’. Итак, если FRAMEBUFFER определена и не равна ‘n’, скрипт будет помещён в образ initrd. Таких скриптов 8:
Этими скриптами запускается и настраивается фреймбуфер (framebuffer) — грубо говоря, текстовая консоль переводится в графический режим. После этого появляется возможность отрисовывать в ней изображения и нестандартные шрифты. Вот как раз console_setup и устанавливает шрифт для консоли. Вероятно, из-за того, что пользователь может выбрать нестандартный шрифт, этот скрипт привязан к запуску фреймбуфера и без установленого параметра ‘FRAMEBUFFER=y’ не добавляется в initrd.
Таким образом, при активации фреймбуфера, так же будет происходить настройка консоли с установкой шрифта, но на более раннем этапе.
Но вернёмся к нашим скриптам из keyboard-configuration
Скрипт …/init-top/console_setup копируется в образ initrd при установленном параметре ‘FRAMEBUFFER=y’.
Скрипт …/panic/console_setup копируется в initrd всегда, т. к. не содержит заданную переменную ‘OPTION’. Скрипты из каталога panic вызываются функцией panic из скрипта init (который включает функции из файла /usr/share/initramfs-tools/scripts/functions). Сама же функция panic вызывается в случае, когда скрипт инициализации init не может продолжить выполнение (не найдена корневая файловая система и т.п.). Значит, скрипт…/panic/console_setup предназначен для настройки консоли в режиме panic, чтобы вывести сообщения в родной для пользователя кодировке.
Скрипт …/hooks/console_setup вызывается из скрипта mkinitramfs, при создании образа initrd:
Этот скрипт занимается тем, что копирует файлы, необходимые для настройки консоли (файл шрифта, таблицу перекодировки шрифта (acm) и файл раскладки клавиатуры (keymap)) в initrd. Соответственно, даже если мы исправим init-top/console_setup, но забудем внести изменения в hooks/console_setup, настройка консоли на этом этапе не произойдёт из-за отсутствия необходимых файлов.
Вносим исправления
Теперь, зная каким образом происходит настройка консоли и где допущены ошибки, можно внести правки в код. Качаем исходный код пакета keyboard-configuration, так же, скачаем все зависимости для пересборки пакета:
Но вместо keyboard-configuration у нас скачался пакет console-setup, из которого, как оказалось собирается несколько deb-файлов, в том числе console-setup и keyboard-configuration. Заходим в корень исходников, и смотрим в каких файлах используется переменная FONT:
После их изучения, понятно что нам интересны только
Первые три надо исправить, а последний нам послужит донором, так как содержит код, обрабатывающий $CODESET и $FONTSIZE.
Исправление заключается в добавлении следующего кода:
в каждый из файлов, после подключения конфигурационного файла и проверок, например:
Так же нужно добавить проверку на сжатый файлы:
После внесения правок можем пересобрать пакет — заходим в корень исходников и выполняем:
dpkg-buildpackage -uc -b
Устанавливаем исправленный пакет и запрещаем ему обновления, иначе Ubuntu заменит его текущим (неисправленным) пакетом из репозитория:
Всё, теперь при загрузке ОС будет корректно настраиваться текстовая консоль.
Скачать патч и исправленный пакет можно на странице с багрепортом на ланчпаде. Там же можно увеличить приоритет ошибки, зарегистрировавшись и нажав «This bug affects me».
Обновлено 20.04.2016:
Сегодня, 20.04.2016, за один день до релиза, исправление вошло сначала в proposed, а затем, и в release ветку Ubuntu Xenial.
Для этого пришлось приложить некоторые усилия. В частности — создать на launchpad’е ветку пакета console-setup, внести в неё исправления и предложить (propose) эту ветку для слияния с релизной. Так же, я посмотрел кто последний загружал пакет console-setup и отправил ему просьбу рассмотреть ошибку и исправления. Через 2 недели исправленный пакет был рассмотрен, одобрен и принят в релиз. Спасибо тебе, Mathieu Trudel-Lapierre!
Источник