HowTo, linux

Fedora/CentOS: Не работает vpn подключение по pptp

How_to_vpn_workИногда нам нужно подключится по протоколу PPTP к рабочему vpn (корпоративная сеть). А соединения не происходит и система показывается, что произошел сбой при попытке подключиться.

В логах наблюдается что-то подобное.

май 06 17:45:37 localhost.localdomain pppd[17294]: Connection terminated.
май 06 17:45:37 localhost.localdomain pppd[17294]: LCP: timeout sending Config-Requests

Можно запустить wireshark и посмотреть, что на каждый lcp-запрос есть lcp-ответ.

2018-05-06-19:10:05_358x148

Можно просто попробовать включить данный протокол поскольку firewalld не имеет правила по-умолчанию, которое позволяет системе принимать нужные пакеты. А именно в gre инкапсулируются пакеты lcp, которые отвечают за настройку соединения).

В интернетах часто рекомендуют делать нативное правило как-то так.

$ sudo firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p gre -j ACCEPT
$ sudo firewall-cmd --direct --add-rule ipv6 filter INPUT 0 -p gre -j ACCEPT
$ sudo firewall-cmd --reload

Не делайте так — потом этими правилами сложнее управлять.

Попробуем разрешить подключения более элегантно, используя имеющиеся абстракции.

Сначала добавим временные правила чтобы проверить работоспособность и проверим, что протокол добавился в нужную зону.

$ sudo firewall-cmd --zone=home --add-protocol=gre
$ sudo firewall-cmd --zone=home --query-protocol=gre

Система должна сказать yes. Если попытка подключения прошла успешно, то стоит добавить правила на постоянной основе.

Не забудьте указать нужную зону через параметр —zone как в первом, так и во втором случае.

$ sudo firewall-cmd --permanent --zone=home --add-protocol=gre
$ sudo firewall-cmd --permanent --zone=home --query-protocol=gre
$ sudo firewall-cmd --reload

Дальше могут быть проблемы с авторизацией, но это совсем другая история.

Литература

linux

Linux: определяем тип файла

2018-04-28-22:37:39_718x635В попытках открыть csv-файл от одной организации я увидел картину из скриншота. В файле должны были быть табличные данные, а оказалась какая-то белиберда с отсылкой к VBA. Очевидно, что там что-то из msоffice, но как узнать это точно?

Для определения типа файла по его сигнатуре в unix-подобных операционных системах существует утилита file (man 1 file).

 $ file test.csv
test.csv: Composite Document File V2 Document, Little Endian, Os: Windows, Version 5.2, Code page: 1251, Author: , Last Saved By: , Name of Creating Application: Microsoft Excel, Create Time/Date: Sat Apr 28 10:33:01 2018, Last Saved Time/Date: Sat Apr 28 10:45:37 2018, Security: 0

Видно, что тип файла Composite Document File V2 Document. Но какой именно это формат? У экселя их очень много. Есть отличная утилита unoconv из поставки openoffice/libreoffice.

 $ sudo dnf install unoconv
 $ mv test.csv test
$ unoconv --format=ods test

Сразу возникает вопрос: зачем мы убрали у файла расширение? Это особенность утилиты: она использует расширение файла для определения типа, а если расширения нет, то опирается на метаинформацию. Поэтому нам потребовалось убрать расширение.

Теперь все хорошо и нормально открывается.

HowTo, linux

Управление цветом в Linux

01-introЕсть такая штука под названием «уветовые профили». Казалось бы все о них слышали, но немногие умеют их использовать и понимают, зачем это вообще надо.

То, что мы воспринимаем как свет — это лишь электромагнитные колебания с длиной волны от 380-400 нм до 760-780 нм. В этом диапазоне смешались все цвета от красного к филетовому.

02-spectrum
https://ru.wikipedia.org/wiki/Свет

Когда мы видим радугу, то мы видим весь спектр цветов. А вот несовершенные электронные приборы могут отобразить лишь определенные цвета радуги. Называется это цветовым охватом — множество доступных для восприятия человеческим глазом цветов, которые способно воспроизвести устройство. У всей техники разные диаграммы цветопередачи.

Именно поэтому для каждого устройства в системе нужно задать цветовой профиль, который как раз и описывает диапазон цветового охвата.

Почему это важно? Можно пояснить на примере двух инженеров у одного из которых линейка метрическая, а у второго дюймовая. Если один другому скажет, что нужно начертить линию длиной два, то случится нечто странное: линия будет иметь длину два, но в той системе измерений, в которой работает человек.

То же самое с техникой. Если для нас цвето RGB(200, 0, 0) — это красный с каким-то уровнем насыщенности, то для принтера он может быть совершенно другим. Поэтому перед печатью все должно быть сконвертировано с учетом цветового профили устройства.

Подводя итог: цветовой профиль — это правила конвертации цвета из общепризнанной цветовой модели в ту, с которой работает ваша техника.

Когда мы просто печатаем текст на компьютере, то нас не сильно волнует, как это се конвертируется, но когда при печати фотографии мы получим цвета, которых на экране не видели, то пора что-то менять. 🙂

Читать далее

HowTo, linux

Fedora: гибернация

Вы закрываете крышку ноутбука и он выключается. «Но то не то что я ожидаю!» — воскликните вы. Да. Так и есть. Потому что уже много времени подряд гибернация работает из рук вон плохо. Эдакое бедствие в линупсе.

Сначала рассмотрим теорию, а после — практику сна базе дистрибутива Fedora 26.

Основные режимы энергосбережения, которые чаще всего упоминаются пользователями::

  • ждущий режим — это когда отключается питание внешних устройств, но при этом сохраняется питание памяти, что позволяет относительно быстро восстанавливать рабочее состояние системы  В спецификации аппаратного обеспечения указано пять уровней энергосохранения. И разработчики различных операционных систем часто выбирают различающиеся между собой уровни.
  • Спящий режим — это особая разновидность выключения компьютера при котором слепок содержимого оперативной памяти сохраняется на диске. При повторной загрузке ОС проверяет, есть ли слепок памяти. И если да, то восстанавливает слепок в оперативную память и начинает с того места, на котором вы остановились ранее.
  • гибридный спящий режим — это тот же ждущий режим при котором содержимое оперативной памяти сохраняется в энергонезависимой памяти на случай отключения питания (windows-only)

И если со ждущим режимом все более-менее понятно и он работает в большинстве современных дистрибутивов, то со спящим режимом не все так гладко. Попытавшись увести систему в спячку и нажав на кнопку питания для пробуждения вы просто заново загрузите систему.

Предупреждение: все описанные ниже манипуляции требуют физической перезагрузки компьютера для того, чтобы ядро восприняло новые параметры.

Читать далее

HowTo, linux

No Bootable Device после обновления дистрибутива

1 - no bootable deviceИменно таким неприятным сообщением может встретить вас ноутбук или стационарный компьютер после казалось бы удачно прошедшего обновления дистрибутива.

Почему? Потому что обновился grub-efi, а скрипт, который добавит запись о новом образе для загрузки не записал должным образом.

$ efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,2001,2002,2003
Boot0001* Linux	PciRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x0)/NVMe(0x1,00-00-00-00-00-00-00-00)/HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\fedora\shimx64-fedora.efi)A01 ..
Boot0002* Unknown Device: 	HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\fedora\shim.efi)RC
Boot2001* EFI USB Device	RC
Boot2002* EFI DVD/CDROM	RC
Boot2003* EFI Network	RC

Увы, снять показания я смог только после восстановления работоспособности системы, поэтому на листинге, который приведен выше, мы видим корректный образ под меткой Boot0001 и тот, который был перед обновлением под меткой Boot0002. На разных системах это может выглядеть совершенно различным образом.

Что делать в случае, когда система совершенно не хочет загружаться?

Следует сделать несколько шагов для восстановления работоспособности (не стоит забывать, что для возможности расширенной работы с uefi на многих биосах должен быть установлен административный пароль — только тогда будут видны все элементы меню).

  • зайти в BIOS
  • найти пункт выбора доверенного uefi-файла
  • указать нужный файл на диске (в случае с fedora — это shimx64-fedora.efi)

 

linux

Linux: произвольное падение приложений на mono

53395Столкнулся со странной проблемой: без сторонней помощи стал закрываться RepetierHost. Ему было все равно печатал он модель, слайсил или просто был открытым. Сам хост я всегда открывал на отдельном воркспейсе и поначалу грешил на то, что какие-то проблемы могут быть у cinnamon, который сейчас использую как дефолтный стол. Если оставить хост отрытым и не менять рабочие столы, не запускать никаких приложений, то все нормально и приложение не отваливалось. Гугл ничего не смог сказать мне про систематический вылеты. Откат на предыдушие версии не помог — они так же вылетали.

Добавил в repetierHost строки, которые перенаправляли лог запуска в файл и он стал выглядеть вот так.

#!/usr/bin/env bash
cd /home/penguin/.soft/RepetierHost
env LANG=en_US.utf8 mono RepetierHost.exe -home {$HOME}.soft/RepetierHost &> {$HOME}/log&

После пары запусков я таки поймал в лог креш приложения. Да, не обращаете внимание на то, что принудительно используется локаль en_US — это решает проблему слайсера Slic3r, который по каким-то причинам отказывается работать с группами объектов названными символами, отличными от латинских.

/usr/bin/slic3r --load "slic3r_settings.ini" --print-center 100.00,100.00 -o "composition.gcode" "composition.amf"
Wide character at /usr/lib64/perl5/vendor_perl/Encode.pm line 212.

В amf-файле все группы должны иметь латинские имена, а repetier генерирует имена в текущей локали.

Пойманный трейс выглядит следующим образом.

Stacktrace:

at <unknown> <0xffffffff>
at (wrapper managed-to-native) System.Windows.Forms.X11Keyboard.Xutf8LookupString (intptr,System.Windows.Forms.XEvent&,byte[],int,intptr&,System.Windows.Forms.XLookupStatus&) <0x000a4>
at System.Windows.Forms.X11Keyboard.LookupString (System.Windows.Forms.XEvent&,int,System.Windows.Forms.XKeySym&,System.Windows.Forms.XLookupStatus&) <0x000bb>
at System.Windows.Forms.X11Keyboard.EventToVkey (System.Windows.Forms.XEvent) <0x0003f>
at System.Windows.Forms.X11Keyboard.ToUnicode (int,int,string&) <0x0034f>
at System.Windows.Forms.X11Keyboard.TranslateMessage (System.Windows.Forms.MSG&) <0x0011f>
at System.Windows.Forms.XplatUIX11.TranslateMessage (System.Windows.Forms.MSG&) <0x00027>
at System.Windows.Forms.XplatUI.TranslateMessage (System.Windows.Forms.MSG&) <0x00024>
at System.Windows.Forms.Application.RunLoop (bool,System.Windows.Forms.ApplicationContext) <0x00d6b>
at System.Windows.Forms.Application.Run (System.Windows.Forms.ApplicationContext) <0x00047>
at System.Windows.Forms.Application.Run (System.Windows.Forms.Form) <0x00037>
at RepetierHost.Program.Main (string[]) <0x0003f>
at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) <0x000d1>

Native stacktrace:

mono(+0xc3794) [0x55d10cc73794]
mono(+0x11a8ce) [0x55d10ccca8ce]
mono(+0x3c633) [0x55d10cbec633]
/lib64/libpthread.so.0(+0x115c0) [0x7f4b23cea5c0]
/lib64/libc.so.6(strlen+0x26) [0x7f4b23788fe6]
/lib64/libX11.so.6(_XimLocalUtf8LookupString+0xde) [0x7f4b1870b8fe]
[0x4249f8b5]

Debug info from gdb:

[New LWP 5108]
[New LWP 5112]
[New LWP 5116]
[New LWP 5117]
[New LWP 5118]
[New LWP 5119]
[New LWP 5121]
[New LWP 5122]
[New LWP 5123]
warning: File "/usr/bin/mono-sgen-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /usr/bin/mono-sgen-gdb.py
line to your configuration file "/home/penguin/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/penguin/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
info "(gdb)Auto-loading safe path"
warning: File "/usr/bin/mono-sgen-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007f4b23ce9fdb in waitpid () from /lib64/libpthread.so.0
Id   Target Id         Frame
* 1    Thread 0x7f4b247fa780 (LWP 5104) "mono" 0x00007f4b23ce9fdb in waitpid () from /lib64/libpthread.so.0
2    Thread 0x7f4b1c3ff700 (LWP 5108) "mono" 0x00007f4b23ce6460 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
3    Thread 0x7f4b1cb62700 (LWP 5112) "Finalizer" 0x00007f4b23ce8957 in do_futex_wait.constprop () from /lib64/libpthread.so.0
4    Thread 0x7f4b0c301700 (LWP 5116) "Timer-Scheduler" 0x00007f4b23ce6809 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
5    Thread 0x7f4b18044700 (LWP 5117) "Timer-Scheduler" 0x00007f4b23ce6809 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
6    Thread 0x7f4b06eef700 (LWP 5118) "Threadpool work" 0x00007f4b23ce6809 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
7    Thread 0x7f4b06cee700 (LWP 5119) "Threadpool work" 0x00007f4b23ce6809 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
8    Thread 0x7f4b05af4700 (LWP 5121) "Threadpool work" 0x00007f4b23ce6809 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
9    Thread 0x7f4b06241700 (LWP 5122) "Threadpool work" 0x00007f4b237f801d in poll () from /lib64/libc.so.6
10   Thread 0x7f4b04c93700 (LWP 5123) "Threadpool work" 0x00007f4b23ce6809 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0

Thread 10 (Thread 0x7f4b04c93700 (LWP 5123)):
#0  0x00007f4b23ce6809 in pthread_cond_timedwait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0
#1  0x000055d10cd6b9ab in worker_thread ()
#2  0x000055d10cd661d6 in start_wrapper ()
#3  0x000055d10ce1af4a in inner_start_thread ()
#4  0x00007f4b23ce06ca in start_thread () at /lib64/libpthread.so.0
#5  0x00007f4b23803f7f in clone () at /lib64/libc.so.6

Thread 9 (Thread 0x7f4b06241700 (LWP 5122)):
#0  0x00007f4b237f801d in poll () at /lib64/libc.so.6
#1  0x000055d10cd6d2f2 in poll_event_wait ()
#2  0x000055d10cd6e136 in selector_thread ()
#3  0x000055d10cd661d6 in start_wrapper ()
#4  0x000055d10ce1af4a in inner_start_thread ()
#5  0x00007f4b23ce06ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f4b23803f7f in clone () at /lib64/libc.so.6

Thread 8 (Thread 0x7f4b05af4700 (LWP 5121)):
#0  0x00007f4b23ce6809 in pthread_cond_timedwait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0
#1  0x000055d10cd6b9ab in worker_thread ()
#2  0x000055d10cd661d6 in start_wrapper ()
#3  0x000055d10ce1af4a in inner_start_thread ()
#4  0x00007f4b23ce06ca in start_thread () at /lib64/libpthread.so.0
#5  0x00007f4b23803f7f in clone () at /lib64/libc.so.6

Thread 7 (Thread 0x7f4b06cee700 (LWP 5119)):
#0  0x00007f4b23ce6809 in pthread_cond_timedwait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0
#1  0x000055d10cd6b9ab in worker_thread ()
#2  0x000055d10cd661d6 in start_wrapper ()
#3  0x000055d10ce1af4a in inner_start_thread ()
#4  0x00007f4b23ce06ca in start_thread () at /lib64/libpthread.so.0
#5  0x00007f4b23803f7f in clone () at /lib64/libc.so.6

Thread 6 (Thread 0x7f4b06eef700 (LWP 5118)):
#0  0x00007f4b23ce6809 in pthread_cond_timedwait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0
#1  0x000055d10cd6b9ab in worker_thread ()
#2  0x000055d10cd661d6 in start_wrapper ()
#3  0x000055d10ce1af4a in inner_start_thread ()
#4  0x00007f4b23ce06ca in start_thread () at /lib64/libpthread.so.0
#5  0x00007f4b23803f7f in clone () at /lib64/libc.so.6

Thread 5 (Thread 0x7f4b18044700 (LWP 5117)):
#0  0x00007f4b23ce6809 in pthread_cond_timedwait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0
#1  0x000055d10ce19a7d in mono_thread_info_sleep ()
#2  0x000055d10cd6a91e in monitor_thread ()
#3  0x000055d10cd661d6 in start_wrapper ()
#4  0x000055d10ce1af4a in inner_start_thread ()
#5  0x00007f4b23ce06ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f4b23803f7f in clone () at /lib64/libc.so.6

Thread 4 (Thread 0x7f4b0c301700 (LWP 5116)):
#0  0x00007f4b23ce6809 in pthread_cond_timedwait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0
#1  0x000055d10cdefb3f in _wapi_handle_timedwait_signal_handle ()
#2  0x000055d10ce06304 in wapi_WaitForSingleObjectEx ()
#3  0x000055d10cd659d8 in mono_wait_uninterrupted.isra.18.constprop ()
#4  0x000055d10cd65aa3 in ves_icall_System_Threading_WaitHandle_WaitOne_internal ()
#5  0x00000000420b2604 in  ()
#6  0x0000000000000002 in  ()
#7  0x0000000000000001 in  ()
#8  0x0000000000000064 in  ()
#9  0x00007f4b1c6a7bb0 in  ()
#10 0x0000000000000063 in  ()
#11 0x00007f4b08001960 in  ()
#12 0x00007f4b1c6a7bb0 in  ()
#13 0x00007f4b0c300660 in  ()
#14 0x00007f4b0c3005d0 in  ()
#15 0x00000000420b23d0 in  ()
#16 0x0000000000000000 in  ()

Thread 3 (Thread 0x7f4b1cb62700 (LWP 5112)):
#0  0x00007f4b23ce8957 in do_futex_wait.constprop () at /lib64/libpthread.so.0
#1  0x00007f4b23ce8a04 in __new_sem_wait_slow.constprop.0 () at /lib64/libpthread.so.0
#2  0x00007f4b23ce8aaa in sem_wait@@GLIBC_2.2.5 () at /lib64/libpthread.so.0
#3  0x000055d10cd877bb in finalizer_thread ()
#4  0x000055d10cd661d6 in start_wrapper ()
#5  0x000055d10ce1af4a in inner_start_thread ()
#6  0x00007f4b23ce06ca in start_thread () at /lib64/libpthread.so.0
#7  0x00007f4b23803f7f in clone () at /lib64/libc.so.6

Thread 2 (Thread 0x7f4b1c3ff700 (LWP 5108)):
#0  0x00007f4b23ce6460 in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0
#1  0x000055d10cde963f in thread_func ()
#2  0x00007f4b23ce06ca in start_thread () at /lib64/libpthread.so.0
#3  0x00007f4b23803f7f in clone () at /lib64/libc.so.6

Thread 1 (Thread 0x7f4b247fa780 (LWP 5104)):
#0  0x00007f4b23ce9fdb in waitpid () at /lib64/libpthread.so.0
#1  0x000055d10cc73870 in mono_handle_native_sigsegv ()
#2  0x000055d10ccca8ce in mono_arch_handle_altstack_exception ()
#3  0x000055d10cbec633 in mono_sigsegv_signal_handler ()
#4  0x00007f4b23cea5c0 in <signal handler called> () at /lib64/libpthread.so.0
#5  0x00007f4b23788fe6 in strlen () at /lib64/libc.so.6
#6  0x00007f4b1870b8fe in _XimLocalUtf8LookupString () at /lib64/libX11.so.6
#7  0x000000004249f8b5 in  ()
#8  0x0000000000000000 in  ()

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

Ок. Теперь уже проще гуглить. Ответ был найден на форуме arch-linux в ветке, которая посвящена keepass: это оказался баг в библиотеке WinForms, который не сильно важен для разработчиков и никто фиксить его пока не будет (оригинальный репорт).

Временное решение — добавить опцию —verify-all в качестве аргумента mono.

env LANG=en_US.utf8 mono --verify-all RepetierHost.exe -home {$HOME}.soft/RepetierHost

С этой опцией вылетов не наблюдается, но случаются фризы приложения.

linux

Fedora перестает грузиться на UEFI после обновения (и показывает MOK)

Никогда бы не подумал, но вчера столкнулся с проблемой при которой после обновления fedora начисто отказалась загружаться постоянно выдавая при старте окно MokManager с просьбой добавить ключи или хеши с secureboot.

Что меня больше всего удивило так это то, что efibootmgr -v выдавал кучу записей загрузчиков shim.efi с некорректными uuid разделов на которых они размещены.

$ efibootmgr -v
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0007,0002,2001,2002,2003
Boot0000* Fedora    HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\Fedora\shim.efi)
Boot0001* Fedora    HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0002* Linux    PciRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x0)/NVMe(0x1,00-00-00-00-00-00-00-00)/HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)A01 ..
Boot0003* Fedora    HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0004* Fedora    HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0005* Fedora    HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0006* Fedora    HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0007* Fedora    HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot2001* EFI USB Device    RC
Boot2002* EFI DVD/CDROM    RC
Boot2003* EFI Network    RC

Конечно в данном листинге уже все верно поскольку он был сделан на рабочей машине, но в оригинальном листинге в идентификаторе HD были прописаны несуществующие uuid разделов. И подобных записей было далеко за 20 штук.

К сожалению мне неизвестна причина по которой система прописывает неверные данные, но мне нужно было оживить машину. Для этого следует сначала зайти в chroot окружение убитой системы.

Далее нам потребуется удалить все записи загрузчика с неверными данными. Это записи вида Boot0ХХХ.

Сначала надо переустановить grub-efi и shim как это рекомендует документация.

# dnf reinstall grub-efi shim

Теперь удаляем невалидные записи. Для их удаления нам потребуется выполнять команду

# efibootmgr -B -b XXXX
  • -B — удалить запись
  • -b XXXX — выбрать активной запись XXXX

В качестве XXXX будут выступать идентификаторы неугодных записей (не трогайте записи, которые начинаются не с нуля — они системные). И конечно же перед каждым удалением следите за состоянием записей (efibootmgr -v).

Последним шагом будет добавление правильной записи.

efibootmgr -c -w -L Fedora -d /dev/nvme0n1 -p 1 -l '\EFI\Fedora\shim.efi'
  • -c — создать запись
  • -w — сделать запись в mbr если это требуется
  • -L Fedora — метка новой записи в загрузчике
  • -d /dev/nvme0n1 — жесткий диск на котором размещен efi-раздел (у вас может быть /dev/sda или любой другой)
  • -p 1 — номер раздела на диске (если efi у вас это /dev/sda1, то 1, sda2 — 2 и т.д.)
  • -l ‘\EFI\Fedora\shim.efi’ — расположение файла загрузчика относительно корня диска efi (а не корня файловой системы в которую он подмонтирован). Обратите внимание, что тут нам обязательно надо указать загрузчик shim.efi, а не что-то другое.

После завершения можно перезагружаться и пробовать войти в систему. Mok Manager больше не должен появляться. Если это не так, то где-то вы допустили ошибку.

Литература