Секреты Манджаро разной степени известности.
Трёхнедельная череда праздников закончилась, температура за окном стремится к минус сорока (привет глобальному потеплению!). Я же, прежде чем вернуться к некомпьютерным вопросам, решил начать ещё одну статейку про Манджаро. Собственно, мне хотелось бы создать здесь мой собственный небольшой сборник секретов-советов, помогающих мне использовать Манждаро. Ни в коем случае не претендую на оригинальность, большинство из написанного здесь было найдено в различных источниках в Сети.
Я просто надеюсь, что вы тоже найдёте здесь что-то полезное для себя.
Редактирование файлов конфигурации в 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 Статья будет постепенно пополняться по мере нахождения — вспоминания — придумывания новых секретов.
Loading
OK after a bit of rummaging around I found a how-to too get rid of this problem at least temporarily it is fairly simple however I don’t have my system set-up with btrfs so I can’t confirm this fix.
either comment out or remove this line:
if [ -n ${have_grubenv} ]; then save_env recordfail; fi
or
if [ -n "${have_grubenv}" ]; then if [ -z "${boot_once}" ]; then save_env
recordfail; fi; fi
in this file
/etc/grub.d/00_header
then run
update-grub
the reason for not editing /boot/grub/grub.cfg directly is that it will be over written every time grub is updated in this case you would only have to «re do» the fix if the grub common packages is updated.
This is the bug on launchpad if you want to add yourself bug #736743
Quoting Colin Watson from the bug report
This is actually a misleading error message: what’s happening is that
GRUB’s btrfs implementation doesn’t implement the file read hook
interface for returning blocklists to calling code. I posted to
grub-devel about this and the upstream maintainer pointed out that,
even aside from multi-device problems, writing to btrfs from GRUB is
fundamentally risky because:the same block may be used by multiple snapshots every tree
which uses a given block will contain its checksum, and so on
recursivelyHowever, btrfs reserves space at the start for the boot loader. This
space is more than GRUB needs to embed itself, and so we could use 1KB
of it for an environment block.In any case, this is not a new problem that arose from using
subvolumes, nor does it prevent booting (you get a spurious «Press any
key to continue» prompt, but if you just ignore it it’ll boot anyway).
Downgrading to wishlist.
Hope this helps
Loading
0 Members and 1 Guest are viewing this topic.
15 October 2022, 06:44:22
My problem on grub boot:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Booting «Artix Linux»
error: sparse file not allowed.
Loading Linux linux-hardened …
452: out of range pointer: 0x0ec03020
Aborted. Press any key to exit.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Kernel in use:
5.19.14-hardened1-1-hardened
I artix-chroot /mnt and sudo grub-install and sudo grub-update (both work and fix the boot issue) the update outputs on one of the last lines: ERROR: mkdir /var/lock/dmraid
otherwise IAM fine.
Except its the 3rd day I have to chroot and update grub…
I think it comes back after pacman updates
Re: Booting via grub: ERROR:sparse file not allowed on hardened-kernel
Reply #1 – 15 October 2022, 16:19:52
Re: Booting via grub: ERROR:sparse file not allowed on hardened-kernel
Reply #2 – 15 October 2022, 21:16:10
I made a research before this thread. Results suggested the same like you to check the GRUB_DEFAULT wich was always set to 0. I also dont use btrfs
Re: Booting via grub: ERROR:sparse file not allowed on hardened-kernel
Reply #3 – 18 October 2022, 01:40:01
Re: Booting via grub: ERROR:sparse file not allowed on hardened-kernel
Reply #4 – 19 October 2022, 22:35:12
Re: Booting via grub: ERROR:sparse file not allowed on hardened-kernel
Reply #5 – 20 October 2022, 12:50:24
Still happening, every ideas is welcomed
- 5.19.16.hardened1-1 is the latest version in world. Are you updated to that ?
- Does it happen with the standard linux kernel ?
- I use rEFInd instead of grub as I think it’s superior. Maybe try that instead. You can start with rEFInd on a USB or CD before actually installing it.
Those would be my ideas.
Re: Booting via grub: ERROR:sparse file not allowed on hardened-kernel
Reply #6 – 20 October 2022, 23:31:57
Anyways say goodbye to grub2 .. maybe I will directly boot the kernel 