Секреты Манджаро разной степени известности.
Трёхнедельная череда праздников закончилась, температура за окном стремится к минус сорока (привет глобальному потеплению!). Я же, прежде чем вернуться к некомпьютерным вопросам, решил начать ещё одну статейку про Манджаро. Собственно, мне хотелось бы создать здесь мой собственный небольшой сборник секретов-советов, помогающих мне использовать Манждаро. Ни в коем случае не претендую на оригинальность, большинство из написанного здесь было найдено в различных источниках в Сети.
Я просто надеюсь, что вы тоже найдёте здесь что-то полезное для себя.
Редактирование файлов конфигурации в KDE
Разработчики KDE некоторое время назад преподнесли пользователям неприятный сюрприз: стало сложнее редактировать системные файлы конфигурации. Особенно неприятно это выглядело поначалу: захочешь ты, например, отредактировать /etc/fstab. Пустяковое, казалось бы, дело! Открываешь dolphin, щёлкаешь правой кнопкой, выбираешь нужное из «Действий root», набираешь пароль… и ничего! Странно! Ладно, открываем терминал, вводим:
sudo kate /etc/fstab
И система сообщает, что kate больше не работает с правами root (и dolphin с ними, как выяснится позже, тоже не работает!). Приехали! Теперь, оказывается, нужно использовать sudoedit… Хорошо, набираем
sudoedit /etc/fstab
…и выпадаем в осадок окончательно! Тот, кто знает, что такое vi или vim — разберётся, а остальные…
Впрочем, хватит ворчать! Выход есть, и даже не один!
- Можно использовать, например, nano:
sudo nano /etc/fstab
Но если вы хотите использовать именно kate, выход всё равно есть!
2. Можно приказать sudoedit использовать kate через соответствующую переменную:
SUDO_EDITOR=kate sudoedit /etc/fstab
… и fstab открывается с помощью kate! И зачем, спрашивается, нужно было огород городить?
3. Чтобы не вводить каждый раз SUDO_EDITOR=kate достаточно просто вставить строчку
SUDO_EDITOR=
"kate"
в свой файл .bashrc или .zshrc (смотря что вы используете — bash или zsh. Всё! Теперь для редактирования fstab нужно будет набрать только
sudoedit /etc/fstab
без всякого вреда для здоровья!
Настройка русского языка в консоли
Современный пользователь «домашнего» Линукса (серверы — вопрос отдельный) редко пользуется «голой» консолью, потребность в этом возникает нечасто. Чаще всего это — проведение аварийно-спасательных работ, но бывают и другие причины. Например, игра Starcraft II хорошо работает в Линуксе под Wine, за одним исключением: при попытке выйти из игры программа зависает, и убрать это зависание можно «убив» соответствующий процесс. Об этом, впрочем, в другой раз. Проблема в том, что, если в системе активна русская локаль, а в консоли не настроены экранные шрифты, то работать в консоли будет не очень удобно. Настройка, впрочем, очень проста, рецепт взят отсюда.
- Нужно установить какой-нибудь подходящий растровый шрифт, например, пакет terminus-font. При установке KDE-версии с помощью manjaro-architect этот пакет устанавливается автоматически.
sudo pacman -S terminus-font
2. Отредактировать файл /etc/vconsole.conf. Вот мой файл:
KEYMAP=ruwin_ct_sh-UTF-8
FONT=ter-u20b
Строка FONT=… определяет используемый шрифт. Все доступные шрифты можно посмотреть командой
ls /usr/share/kbd/consolefonts/
Число определяет матрицу (размер) шрифта, может быть от 14 до 32
Строка KEYMAP=… определяет раскладку клавиатуры. Список доступных русских раскладок можно посмотреть командой
ls /usr/share/kbd/keymaps/i386/qwerty/ru* | grep UTF
Их всего пять:
/usr/share/kbd/keymaps/i386/qwerty/ruwin_alt_sh-UTF-8.map.gz
/usr/share/kbd/keymaps/i386/qwerty/ruwin_alt-UTF-8.map.gz
/usr/share/kbd/keymaps/i386/qwerty/ruwin_cplk-UTF-8.map.gz
/usr/share/kbd/keymaps/i386/qwerty/ruwin_ctrl-UTF-8.map.gz
/usr/share/kbd/keymaps/i386/qwerty/ruwin_ct_sh-UTF-8.map.gz
Всё это — стандартные русские windows-раскладки. Они отличаются клавишей переключения раскладок, я использую переключение по Ctrl-Shift.
Если вы хотите использовать в консоли мышь, нужно запустить службу gpm
sudo systemctl enable gpm.service
На этом всё. Осталось только перезагрузить машину, переключиться в консоль и проверить, что получилось.
Ошибка при загрузке системы «Sparse file not allowed»
Если вы установили систему на раздел btrfs и не используете отдельный раздел для /boot, в самом начале загрузки можете получить сообщение «Sparse file not allowed» и загрузка остановится. Эта ошибка, впрочем, не фатальна: через некоторое время или после нажатия клавиши загрузка продолжится, и вы забудете об этой ошибке до следующей перезагрузки.
К счастью, справиться с этой ошибкой несложно. Рецепт взят отсюда.
Редактируем файл /etc/default/grub:
GRUB_SAVEDEFAULT=false
А затем:
sudo grub-editenv create
sudo update-grub
В 32-х битной системе достаточно только отредактировать файл /etc/default/grub и скомандовать sudo update-grub.
Примечание: данная ошибка — какая-то «плавающая», она как мёд у Винни-Пуха — то есть, то нет… Недавно я в течение трёх дней дважды ставил систему на один и тот же компьютер (правда, с разных образов). В первом случае ошибка после установки отсутствовала, во втором — опять появилась…
Если свежеустановленный Манджаро не грузится…
Эта ошибка обычно появляется у тех, кто любит часто переустанавливать разные операционные системы (например, различные дистрибутивы Линукс). Она возникает только если загрузка компьютера происходит в режиме UEFI (а не BIOS или Legaсy).
Поначалу всё идёт прекрасно, система нормально устанавливается, устанавливается grub, установщик гордо рапортует о том, что установка завершена, вы спокойно перезагружаете компьютер, и тут… ничего не происходит. Компьютер не видит загрузчик новой системы, о чём и сообщает вам чёрным по белому, а если загрузка и происходит, то грузится совсем не то, что вам нужно.
В чём проблема? Если установка системы и загрузчика прошли правильно, то возможная причина — в особенностях UEFI вашего компьютера. Если я не ошибаюсь, после установки системы UEFI сохраняет загрузочную запись для новой ОС, но, во-первых, количество сохраняемых записей ограничено, и, во-вторых, может наступить момент, когда новую запись сделать будет уже невозможно. При этом установщик ОС не будет выдавать никаких сообщений об ошибках. При этом нужно сказать, что всё может зависеть от конкретной реализации UEFI в вашей конкретной материнской плате.
Что же можно сделать? Помочь нам может утилита efibootmgr. В Манджаро она установлена по умолчанию. Достаточно всего лишь дать команду:
sudo efibootmgr
В ответ мы увидим что-то вроде:
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0003,0002
Boot0000* manjaro
Boot0001* Hard Drive
Boot0002* UEFI: Built-in EFI Shell
Boot0003* CD/DVD Drive
Звёздочками обозначены активные записи. Как видите, в моём компьютере нет лишних загрузочных записей, но если вы видите здесь следы, например, от давно удалённых дистрибутивов Линукс, то есть повод удалить ненужное. Главное — не удалите запись своей рабочей системы. Сейчас программа подсказывает нам, что запись manjaro является текущей, нетрудно догадаться, что трогать её не нужно. А вот удалить лишнее, особенно если вы хотите установить что-нибудь новенькое, не помешает. Всё решается простой командой:
sudo efibootmgr —bootnum 0003 —delete-bootnum
Вместо 0003 поставьте номер вашей ненужной записи. Теперь, если мы правильно определили причину ошибки, установка системы пройдёт нормально.
Провести такую чистку можно как из установленной системы, так и загрузившись с установочного диска, но в этом случае строчка BootCurrent будет иметь значение 0002, а не 0000. Будьте внимательны!
Если новая система у вас уже установлена, вы можете попытаться переустановить загрузчик. Если речь идёт о Манджаро, то вы можете воспользоваться уже известным нам Manjaro Architect. Нужно будет только примонтировать нужные разделы (корневой каталог и раздел efi (обычно — /boot/efi) и сделать chroot (отдельный пункт в меню Архитектора)). Остаётся только дать две команды:
grub-install —target=x86_64-efi —efi-directory=/boot/efi
update-grub
Программа efibootmgr имеет и другие возможности: вы можете, например, добавлять загрузочные записи, менять порядок загрузки и т.д., но это уже другая история.
Нужно ли отключать создание дампов памяти?
Некоторое время назад, запуская на своём компьютере XComII, я обратил внимание, что временами игра начинает очень активно использовать диск, а также заметил, что свободное место на диске уменьшилось сразу на несколько гигабайт. Проведя некоторые розыскные мероприятия я обнаружил в папке /var/lib/systemd/coredump четыре актива общим объёмом в 4 гигабайта. После этого стало понятно, почему игра порой так подтормаживала (создать архив размером в один гигабайт — задача не из лёгких даже для мощного компьютера) и появилось желание задать разработчикам игры несколько неудобных вопросов, ведь дампы памяти система создаёт при возникновении серьёзных ошибок.
И тут же у меня возник другой вопрос: можно ли отключить создание дампов памяти? Как отмечает Арчвики, они создаются прежде всего для разработчиков, обычный пользователь, даже продвинутый, вряд ли сможет их использовать. Кроме того, создание дампов памяти может повлиять на производительность системы, наличие свободного места на диске и даже безопасность (дампы могут содержать важную информацию). Арчвики предлагает несколько способов отключить эту функцию, но окончательное слово, конечно, за пользователем (хорошо это или плохо, но в Линуксе именно пользователь может и должен решать многие вопросы, связанные с работой системы), так что думайте сами, решайте сами…
Итак, чтобы отключить создание дампов памяти можно, например создать файл /etc/sysctl.d/50-coredump.conf с такой строчкой:
kernel.core_pattern=|/bin/false
а затем дать команду
sysctl -p /etc/sysctl.d/50-coredump.conf
чтобы данная настройка начала действовать. После этого можно очистить каталог /var/lib/systemd/coredump.
С другой стороны, если какая-то программа постоянно приводит к возникновению ошибок, может быть лучше сменить программу??
PS Статья будет постепенно пополняться по мере нахождения — вспоминания — придумывания новых секретов.
Редактировать конфигурационные файлы при помощи Kate можно следующим образом:
kate /etc/fstab
При нажатии в Kate Ctrl+S будет запрос пароля от root пользователя.
Да, теперь уже можно. Только зачем было придумывать эти ограничения — до сих пор понять не могу. Странно же, nano можно использовать, а kate — нельзя было… И сейчас sudo kate не работает…
Извините, вопрос от весьма начинающего. Установил Manjaro Linux на новый hdd с таблицей разделов gpt. Потом на оставшемся после установки и ничем незанятом пространстве винта в GParted создал два пустых ext4 раздела. В Thunar эти разделы увиделись, но запись на них (copy/paste из любых других источников) невозможна8( Вероятно, нужно править мой fstab, но в этом я полный пномпень(( Пожалуйста, помогите разрулить мне, чайнику, эту проблему, заранее спасибо8)
Извините, долго не заглядывал на сайт. Если вопрос ещё актуален: скорее всего здесь у вас просто нет прав доступа.
Монтировали ли вы разделы при установке? Если эти разделы не прописаны в fstab:
1. Создаём папку для монтирования, например, в домашнем каталоге.
Даём команду:
sudo nano /etc/fstab
затем добавляем строчку типа:
/dev/sd* /home/maxim/disk1 ext4 defaults,noatime 0 0
Вместо /dev/sd* поставьте ваше имя устройства, имена можно получить командой lsblk -f.
Вместо /home/maxim/disk1 — путь к вашей папке.
Сохранитесь и перезагрузитесь.
Вообще, почитайте об fstab на Арчвики, там всё подробно.
О правах доступа: Чтобы записывать в папку, нужно иметь права доступа на неё.
Можно сделать командой:
sudo chown -R maxim:users /home/data
Вместо maxim подставьте своё имя пользователя, вместо /home/data — имя папки.
Это можно сделать и из файлового менеджера, но я не работал в Thunar.
В KDE (Dolphin) можно выделить папку, в контекстном меню выбрать Действия root — Установить владельцем активного пользователя, ввести пароль root.
или чтото делаю не так или метод не работает
Что именно не работает?
Итак, чтобы отключить создание дампов памяти можно, например создать файл /etc/sysctl.d/50-coredump.conf с такой строчкой:
kernel.core_pattern=|/bin/false
—-
Нужно делать так как нужно. А как не нужно, делать не нужно! ©
Маны говорят нам, что в системах основанных на systemd, за это отвечает спецуёвый transient сервис, который конфигурируется в файле /etc/systemd/coredump.conf и в котором достаточно раскомментировать парочку строчек и отредактировать. Вот так:
Storage=none
ProcessSizeMax=0
И… и всё! В следующий раз, после того как приложение упадёт в корку, systemd запустит сервис systemd-coredump[какое-то-число].service и тот, согласно конфигу ничего не будет писать на диск.
Читайте маны, они рулез! ©:
man systemd-coredump
man coredump.conf
man coredumpctl
Можно и так сделать. Арчвики предлагает целых четыре варианта отключения дампа. Нужно ли использовать systemd, чтобы не дать systemd-coredump записать дамп на диск, если можно просто изменить нужный параметр ядра? Вопрос, я думаю, не принципиален.