grub-efi-autoupdate завершается ошибкой

[serj66]

Всем здравствуйте.
Собственно вопрос уже обсуждался в теме "После установки Simply8.2 Grub2 оказался в "локальных/устаревших" пакетах" https://forum.altlinux.org/index.php?topic=40496.msg320579#msg320579, но безрезультативно и был задвинут в последнюю очередь т.к. вроде и так всё работало. Как случайно выяснилось (хорошо хоть не в пожарном порядке) биос категорически перестал видеть загрузочные носители - невозможна загрузка ни с флешки (в т.ч. виндузятной аварийной) ни с dvd, только при переключении в legacy. Печально, что в случае чего наступает швах, да и если переустанавливать то как теперь?
Кратко напомню суть: при шаманском обновлении grub2 -> grub (2.02) был последний раз, когда всё сработало нормально

Код: [Выделить]

Updating grub in /boot/efi
Выполняется установка для платформы x86_64-efi.
Установка завершена. Ошибок нет.потом много раз прилетали обновления grub и каждый раз заканчивались либо так

Код: [Выделить]

Выполняется установка для платформы x86_64-efi.
Could not delete variable: No space left on device
grub-install: ошибка: efibootmgr failed to register the boot entry: Требуется блочное устройство.либо так

Код: [Выделить]

Выполняется установка для платформы x86_64-efi.
Could not prepare Boot variable: No space left on device
grub-install: ошибка: efibootmgr failed to register the boot entry: Ошибка ввода/вывода.grub-efi-autoupdate завершается так-же, да и биос стал стартовать заметно дольше прежнего.
df от юзера и рута показывают разные выводы

Спойлер

$ df
Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
udevfs             5,0M            0  5,0M            0% /dev
runfs              3,9G         1,3M  3,9G            1% /run
/dev/sda12          40G         7,1G   31G           19% /
tmpfs              3,9G          16M  3,9G            1% /dev/shm
tmpfs              3,9G            0  3,9G            0% /sys/fs/cgroup
/dev/sda2          256M          30M  227M           12% /mnt/sda2
/dev/sda3          496M         287M  210M           58% /mnt/sda3
/dev/sda1         1000M         314M  687M           32% /mnt/sda1
tmpfs              3,9G         8,0K  3,9G            1% /tmp
/dev/sda13          52G         2,3G   47G            5% /home
/dev/sda6           98G          16G   82G           17% /mnt/sda6
/dev/sda5           98G          43G   55G           44% /mnt/sda5
/dev/sda7          596G         174G  392G           31% /mnt/sda7
/dev/sda8           25G          11G   14G           45% /mnt/sda8
tmpfs              790M         8,0K  790M            1% /run/user/500

# df
Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
udevfs             5,0M            0  5,0M            0% /dev
runfs              3,9G         1,3M  3,9G            1% /run
/dev/sda12          40G         7,1G   31G           19% /
tmpfs              3,9G          16M  3,9G            1% /dev/shm
tmpfs              3,9G            0  3,9G            0% /sys/fs/cgroup
/dev/sda2          256M          30M  227M           12% /mnt/sda2
/dev/sda3          496M         287M  210M           58% /mnt/sda3
/dev/sda1         1000M         314M  687M           32% /mnt/sda1
tmpfs              3,9G         8,0K  3,9G            1% /tmp
/dev/sda13          52G         2,3G   47G            5% /home
/dev/sda6           98G          16G   82G           17% /mnt/sda6
/dev/sda9          253M         4,8M  248M            2% /boot/efi
/dev/sda5           98G          43G   55G           44% /mnt/sda5
/dev/sda7          596G         174G  392G           31% /mnt/sda7
/dev/sda8           25G          11G   14G           45% /mnt/sda8
tmpfs              790M         8,0K  790M            1% /run/user/500
#

fstab

Спойлер

proc      /proc         proc   nosuid,noexec,gid=proc      0 0
devpts      /dev/pts      devpts   nosuid,noexec,gid=tty,mode=620   0 0
tmpfs      /tmp         tmpfs   nosuid            0 0
UUID=eaacbd74-9986-443f-9604-1f26ba733f2e   /   ext4   relatime   1   1
UUID=5AD9-2EFB   /boot/efi   vfat   umask=0,quiet,showexec,iocharset=utf8,codepage=866   1   2
UUID=7fef94af-d995-40c9-bbcb-bd8684b3da37   /home   ext4   nosuid,relatime   1   2
UUID=e2b2852b-645b-4c5c-af89-cf4705563bc5   swap   swap   defaults   0   0
UUID=E67E0B027E0ACB6F   /mnt/sda5   ntfs-3g ro,locale=ru_RU.UTF-8,nofail,comment=x-gvfs-show,dmask=0,fmask=0111 0 0
UUID=cc04daa6-6a36-4373-a601-ab03c8063099   /mnt/sda7   ext3 defaults 0 0
UUID=5CF40516F404F454   /mnt/sda8   ntfs-3g ro,locale=ru_RU.UTF-8,nofail,comment=x-gvfs-show,dmask=0,fmask=0111 0 0
UUID=C0DA0D24DA0D17F4   /mnt/sda6   ntfs-3g locale=ru_RU.UTF-8,nofail,comment=x-gvfs-show,dmask=0,fmask=0111 0 0
UUID=9007-5F4F   /mnt/sda2   vfat ro,showexec,quiet,codepage=866,iocharset=utf8,umask=0 0 0
UUID=D808-5B53   /mnt/sda3   vfat ro,showexec,quiet,codepage=866,iocharset=utf8,umask=0 0 0
UUID=2E5806B15806783B   /mnt/sda1   ntfs-3g ro,locale=ru_RU.UTF-8,nofail,comment=x-gvfs-show,dmask=0,fmask=0111 0 0

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

[serj66]

Наконец-то я его починил. В тот же день, когда я написал первый пост, вечером сдох биос, уже окончательно, и все проблемы вероятно были связаны с его постепенным угасанием. При включении запускались только вентиляторы и шпиндели дисководов, монитор и клавиатура нет - компьютер молчит. CLEAR CMOS SW+HW без результата, вероятно чип помер физически и ничего тут уже не поделать - пришлось подыскать новую маму с таким-же чипсетом, теперь всё работает.
В связи с этим подскажите пожалуйста (т.к. я мало знаком с EFI) - это просто невезуха или чип не выдержал циклы перезаписи:
1. выходило 6 обновлений биос - с этим всё понятно, идёт перезапись
2. в первый год-два после каждого обновления Вин8 (на Вин10 такого уже не было) слетала загрузка Альта - рефинд -> альт -> цус -> установить загрузчик
3. обновления груб (было достаточно много и на SL7 и на SL8)
по пп 2 и 3 идёт-ли перезапись в режиме ефи? Меня терзают сомнения - оставить всё как есть и ждать очередной кончины, или снести всё и установить в режиме легаси - виндовс в глубоком резерве и запускается 1-2 раза в год для обновления, мне не сложно делать это через биос.
Не бросайте в одиночестве - такое спросить больше не у кого.

[Speccyfighter]

вечером сдох биос, уже окончательно,
CLEAR CMOS SW+HW без результата,
В связи с этим подскажите пожалуйста (т.к. я мало знаком с EFI) - это просто невезуха или чип не выдержал циклы перезаписи:
по пп 2 и 3 идёт-ли перезапись в режиме ефи?
Меня терзают сомнения - оставить всё как есть и ждать очередной кончины, или снести всё и установить в режиме легаси - виндовс в глубоком резерве и запускается 1-2 раза в год для обновления, мне не сложно делать это через биос.
Не бросайте в одиночестве - такое спросить больше не у кого.

Насколько понимаю эту кухню:
В nvram сохраняются переменные. Если гарбаж коллектор не подчищает их, то nvram переполняется и плата накрывается медным тазом. И выход один, замена системной платы. Есть парни которые такие убитые uefi bios-ом платы ремонтировали, но таких парней можно пересчитать по пальцам одной руки.
У меня даже после обновления uefi bios, загрузка системы, без разницы 32 или 64 бит, стоит через legacy mode (mbr). Но ограничение на винчестер в 2Tb. Почитайте где-то тут, походите по ссылкам:
https://forum.altlinux.org/index.php?topic=13216.810

[Speccyfighter]

Да, и ещё, почитайте также тут:
https://forum.altlinux.org/index.php?topic=32361.msg329111#msg329111

[serj66]

Speccyfighter
говорила-же мне мама "Не ходи ты в лес за грибами - купи шампиньонов в магазине". Так нет ведь, попёрся с дуру за приключениями. Ну ничего, получил платный урок повышения квалификации за не очень большие деньги. Сомнения переросли в уверенность, что надо выделить пару дней и прекратить все эти сомнительные новомодные эксперименты.
Спасибо за советы и направление поиска информации.

[serj66]

Да, и ещё, почитайте также тут:
https://forum.altlinux.org/index.php?topic=32361.msg329111#msg329111

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

[Speccyfighter]

Да, и ещё, почитайте также тут:
https://forum.altlinux.org/index.php?topic=32361.msg329111#msg329111

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

Мозг правильно делает что не верит.
И с разу предупреждаю:
Мои познания о UEFI BIOS и инициализации системы в нём, а тем более через Legacy mode, сильно туманны.

Вот классическая таблица разделов на винчестере ноутбука с не-UEFI BIOS, - четыре первичных раздела оканчиваются сигнатурой MBR с хэкс-кодом 55 aa

Таблица разделов после установки XP и sysv-xfce

Код: [Выделить]

# hexdump -s 446 -C mbr-orig.bin
000001be  00 01 01 00 07 ef ff ff  3f 00 00 00 b1 62 a9 03  |........?....b..|
000001ce  80 ef ff ff 83 ef ff ff  00 68 a9 03 00 08 80 02  |.........h......|
000001de  00 ef ff ff 83 ef ff ff  00 70 29 06 00 e0 ff 0b  |.........p).....|
000001ee  00 ef ff ff 05 ef ff ff  00 50 29 12 00 30 78 00  |.........P)..0x.|
000001fe  55 aa                                             |U.|
00000200

Таблица разделов после удаления раздела C: средствами инсталлятора Windows XP

Код: [Выделить]

# hexdump -s 446 -C mbr-del-c-xp.bin
000001be  00 ef ff ff 83 ef ff ff  00 68 a9 03 00 08 80 02  |.........h......|
000001ce  00 ef ff ff 83 ef ff ff  00 70 29 06 00 e0 ff 0b  |.........p).....|
000001de  00 ef ff ff 05 ef ff ff  00 50 29 12 00 30 78 00  |.........P)..0x.|
000001ee  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001fe  55 aa                                             |U.|
00000200


Основываясь на наших представления об этом, пытаемся посмотреть эту же таблицу разделов в MBR, но уже на ноутбуке с UEFI BIOS на примере Lenovo G50-80 с UEFI BIOS:

Сбрасываем дамп в 512 байт в файл

Код: [Выделить]

# dd if=/dev/sda of=/root/mbr-uefi.bin bs=512 count=1
1+0 записей получено
1+0 записей отправлено
512 байт скопировано, 0,000525857 s, 974 kB/s


Код: [Выделить]

# du -b mbr-uefi.bin
512 mbr-uefi.bin

Пропускаем 446 байт кода загрузчика и смотрим что в таблице разделов.

Код: [Выделить]

# hexdump -s 446 -C mbr-uefi.bin
000001be  00 00 02 00 ee ff ff ff  01 00 00 00 2f 60 38 3a  |............/`8:|
000001ce  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001fe  55 aa                                             |U.|
00000200
и всё что мы видим, это одна (!!!) запись в 16 байт. Все остальные байты нулевые и заканчиваются сигнатурой MBR.

Вы не поверите, но это альт лежащий на винчестере с GPT таблицей и грузящийся через MBR (Legacy mode)

Код: [Выделить]

# sfdisk -l /dev/sda | grep 'Тип\|sda1 \|sda8\|sda9\|sda10'
Тип метки диска: gpt
Устр-во       начало     Конец   Секторы Размер Тип
/dev/sda1       2048    534527    532480   260M EFI
/dev/sda8  315979776 463421951 147442176  70,3G Microsoft basic data
/dev/sda9  463781888 819761151 355979264 169,8G Microsoft basic data
/dev/sda10 860719104 882443519  21724416  10,4G Microsoft basic data

Но в данный момент, я не могу ответить, какой гад изменил идентификаторы разделов.
Но это не влияет на загрузку системы через MBR

Код: [Выделить]

# parted -l | grep 'Табл\|Имя\|^ 8\|^ 9\|^10'
Таблица разделов: gpt
Номер  Начало  Конец  Размер  Файловая система  Имя                           Флаги
 8     162GB   237GB  75,5GB  ext4                                            legacy_boot, msftdata
 9     237GB   420GB  182GB   ext4                                            msftdata
10     441GB   452GB  11,1GB  linux-swap(v1)                                  msftdata

Для Unix-ов важен тип файловой системы.

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

Спаниель умный пёс. Он сразу сообразил, что в этой свалившейся с небес халяве есть подвох.
Чтобы установить загрузчик в MBR, нужно сначала оказаться в загруженной системе, когда UEFI BIOS уже переключен в Legacy mode.
Ни разу это не делал, но мню так:
- Переключить UEFI BIOS в Legacy mode
- Загрузиться с лайва в Legacy mode (Не efi mode !!!)
- Забиндить, зачрутиться
- Установить загрузчик в MBR
И перед этим проверить конфигурационный файл grub.

Гибридная флешка x86_64 при Legacy mode будет иметь в BIOS boot device menu два режима загрузки когда UEFI BIOS переключен в Legacy mode: MBR/Legacy и UEFI. Флешки с i586 умеют грузиться только через MBR.

Если в системе своих кастомных изменений нет, то можно и переустановкой системы.
Но чтобы облегчить себе весь последующий геморрой, лучше сразу снять список пакетов которые были установлены в системе:
Установка пакетов из списка
https://forum.altlinux.org/index.php?topic=32361.msg234696#msg234696

Можно и diff-ом пройтись по списку всех пакетов в системе и списку пакетов в образе, а в сам список пакетов, загнать только те имена пакетов, которые доустанавливались после установки системы с образа.
Список пакетов из инсталляционного образа например можно получить так:
Как получить список имён пакетов из файла-списка прилагающегося к установочному образу на сервере
https://forum.altlinux.org/index.php?topic=32361.msg319000#msg319000

Скажем так:
Я бы не решился ответить в каком из вариантов геморроя будет меньше. В любом случае систему нужно представлять себе достаточно хорошо.

[Speccyfighter]

Speccyfighter
говорила-же мне мама "Не ходи ты в лес за грибами - купи шампиньонов в магазине". Так нет ведь, попёрся с дуру за приключениями. Ну ничего, получил платный урок повышения квалификации за не очень большие деньги. Сомнения переросли в уверенность, что надо выделить пару дней и прекратить все эти сомнительные новомодные эксперименты.
Спасибо за советы и направление поиска информации.

Можно себя утешить что вы далеко не первый у кого UEFI BIOS накрыл системную плату. Но это конечно слабое утешение.

После того как обновил BIOS с устранением опасной ошибки в UEFI BIOS, система на первой загрузке, буквально матом выругалась про не могу что-то там записать (так тебе и надо сволочь ). Это наверное надо было через фото сохранить для истории. И сейчас это уже кануло в лету.

[Rider]

в принципе при достаточно прямом биосе в EFI нет ничего страшного.
Я вот уже из BIOS обновляю из linux'а и это работает только в EFI режиме:

# fwupdmgr refresh
Получение метаданных https://cdn.fwupd.org/downloads/firmware.xml.gz
Получение...    [***************************************]
Получение подписи https://cdn.fwupd.org/downloads/firmware.xml.gz.asc
# fwupdmgr update
Downloading 0.1.10.1 for XPS 15 9560 System Firmware...
Получение микропрограммы https://fwupd.org/downloads/9c9702786bd6883845c0a1c49216a9af735efe70-firmware_XPS9560_Precision5520_1.10.1.cab
Получение...    [***************************************]
Updating 0.1.10.1 on XPS 15 9560 System Firmware...
Распаковка…  [***************************************]
Аутентификация…[***************************************]
failed to run update_prepare() on upower: Cannot install update when not on AC power

ой.. .забыл питание подключить ;)

Но где они, прямые BIOS'ы?

[Speccyfighter]

serj66, если проблема UEFI всё ещё интересует:

Можно почитать тут, сообщения #12 #15 и #16
UEFI problem: Could not prepare boot variable: No space left on device
https://bbs.archlinux.org/viewtopic.php?id=182978

В сообщении #12 ссылка:
https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Requirements_for_UEFI_variable_support
Читать со слов
If EFI Variables support does not work
(Если поддержка переменных EFI не работает)
начиная с пункта 2, который говорит о переменной ядру efi_no_storage_paranoia

Документация по параметрам ядра
https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt
предупреждает об этом параметре предельно грозно (вольным переводом):
Используя этот параметр ты можешь использовать более 50% хранилища переменных efi. Используй этот параметр только если ты действительно уверен, что твой UEFI does sane gc и полностью соответствует спецификации, иначе твоя плата может стать кирпичом.
(Что такое gc?)

ИМХО:
Этот параметр ядра я бы использовал только если плата уже стала кирпичом.

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

[serj66]

если проблема UEFI всё ещё интересует

спасибо, поизучаю, но попозже когда появится свободное время, и наверно в большей степени для подтверждения что всё очень плохо и без парабелума не прожить. Поэтому при подборе новой материнки помимо прочих параметров искал именно с ним - двухрежимную uefi only + legacy only.
https://www.gigabyte.com/Motherboard/GA-H81M-S2PV-rev-30#ov
Смешно, но пока копм был в коме, пользовался старым резервным Celeron 1.7GHz на Gigabyte - лет 15 пенсионеру, а тарахтит ещё не плохо.
Сейчас готовлюсь к "переезду", к чёртовой бабушке все эти ефи. Вопрос даже не в деньгах, а в потерянном времени и лишних хлопотах.
Что касается опытов с ленововским кирпичом, то это вряд-ли - это же надо опять всё-всё-всё переставлять обратно, включая БП т.к. они замутили там 14-пиновый разъём. Да и процессор, я конечно уже не раз переставлял, но процедура всё-равно нервительная, учитывая что это самая дорогущая деталь. Пусть пока полежит, а там посмотрим.
P.S. оказывается как всё плохо с этой ефи, "а мужики-то и не знают" (из какой то старой рекламы)

[Speccyfighter]

если проблема UEFI всё ещё интересует

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

Всё что увидел, для этого и выбросил, чтобы обрисовать всю серьёзность проблемы.

Смешно, но пока копм был в коме, пользовался старым резервным Celeron 1.7GHz на Gigabyte - лет 15 пенсионеру, а тарахтит ещё не плохо.

Ни разу не смешно. Классика никуда не пишет и не должна. Всё чего она касается, это RTC. Классика проста как кирпич, но и надёжна как кирпич.

Сейчас готовлюсь к "переезду", к чёртовой бабушке все эти ефи. Вопрос даже не в деньгах, а в потерянном времени и лишних хлопотах.

И в деньгах тоже. Система убила железо пользователя, а пользователя развели на бабки. Здесь важен сам факт, а количество денег уже не играет никакой роли.

P.S. оказывается как всё плохо с этой ефи,

Всё не плохо с ефи, - херово.
Насколько понимаю, в современном ядре есть функция, которая не даёт переполнять nvram (efi_no_storage_paranoia ?) чтобы микросхема окончательно не перешла в режим read only. Но Торвальдс отвечает только за ядро и не обязан расписывать километровые хауту для более высокоуровнего системного софта и брать на себя чужую работу и чужие обязанности. Торвальдс отвечает только за ядро которое предоставляет функции. Как сделать этот сёрфинг с переменными в nvram в такой катастрофичной ситуации, это задача системных Линукс-программистов, на которую они по большому счёту поклали.
Хорошая документация, в такой серьёзной ситуации, должна равеевать туман, а не порождать ещё больше вопросов. По крайней мере до тех пор, пока эта проблема не будет решена окончательно и везде.

[serj66]

Скажем так:
Я бы не решился ответить в каком из вариантов геморроя будет меньше.

наконец-то урвал свободного времени, чтобы отписаться, к тому-же возникла дополнительная причина.
Не стал экспериментировать и установил заново в легаси: ставится система быстро, много изменений у меня там нет и всё что надо удалить/добавить я храню в текстовом файле т.к. приходится администрировать 3 основных и 2 резервных компьютера, а основные конфиги я перед переездом сгоняю в tar и потом разворачиваю в новой системе. Да и виндовс радостно сообщила, что цифровая лицензия осталась на старой материнке и чтобы её восстановить мне надо было ещё до краха связать данное устройство со своей учёткой майкрософт (очень своевременное напоминание). Вобщем держать эти консервы смысла не было и я сделал разметку заново. Я читал ссылку выше про загрузчик и был готов к худшему, но автомат справился, правда установил его не на /dev/sda а /dev/disk/by-id , но при этом всё прекрасно работает

Спойлер

# Automaticaly update grub on device(s)
# NB: don't put /dev/mdX there but rather '/dev/sda /dev/sdb '!
#GRUB_AUTOUPDATE_DEVICE='/dev/disk/by-id/wwn-0x5000c50064b4ad85 '
# Use '--force' option for grub-install
#GRUB_AUTOUPDATE_FORCE='yes'

# Automaticaly update config file on kernel install/removal
# default: true
GRUB_AUTOUPDATE_CFG=true

# Automaticaly updated config filename
# default: /boot/grub/grub.cfg
GRUB_AUTOUPDATE_CFGNAME=/boot/grub/grub.cfg

# How to handle /boot/vmlinuz* symlinks:
# 'yes','true' - include in config
# 'no','false' - skip in config
# 'default'    - include only /boot/vmlinuz in config
# default: default
GRUB_VMLINUZ_SYMLINKS=default

# Whether to add failsafe entries:
# 'yes','true' - add for all kernels
# 'no','false' - skip for all kernels
# 'default'    - add failsafe entry only for /boot/vmlinuz
# default: default
GRUB_VMLINUZ_FAILSAFE=default

# Preload specific grub modules
#GRUB_PRELOAD_MODULES=''

# Set normal timeout
#GRUB_TIMEOUT=5

# Set hidden timeout (do not show menu)
#GRUB_HIDDEN_TIMEOUT=3

# Show timeout counter when hidden
#GRUB_HIDDEN_TIMEOUT_QUIET=TRUE

GRUB_CMDLINE_LINUX_DEFAULT='resume=/dev/disk/by-uuid/b441009f-d1b0-954a-88b1-b699397c1bc2 panic=30 quiet splash'
GRUB_CMDLINE_LINUX='failsafe vga=normal'
GRUB_TERMINAL_OUTPUT='gfxterm'
GRUB_GFXMODE='800x600'
GRUB_DEFAULT='saved'
GRUB_SAVEDEFAULT=true
GRUB_WALLPAPER=/usr/share/plymouth/themes/slinux/grub.jpg
GRUB_COLOR_NORMAL=white/dark-gray
GRUB_COLOR_HIGHLIGHT=black/white

# This is especially important as EFI Boot Manager label
GRUB_DISTRIBUTOR="ALT Linux"

# This defines /boot/efi/EFI subdir name
GRUB_BOOTLOADER_ID="altlinux"
GRUB_THEME=/boot/grub/themes/slinux/theme.txt
GRUB_AUTOUPDATE_DEVICE='/dev/disk/by-id/wwn-0x5000c50064b4ad85 '
GRUB_AUTOUPDATE_FORCE='yes'

При обновлении груб после установки подтянулся интересный пакет libefivar:

Library to manage UEFI variables
Library to allow for the simple manipulation of UEFI variables.

и к этой lib нашёлся соответствующий tools - efivar:

Tools to manage UEFI variables
efivar provides a simple command line interface to the UEFI variable facility.

Спойлер

NAME
       efivar - Tool to manipulate UEFI variables

SYNOPSIS
       efivar [OPTION...]

DESCRIPTION
       -L, --list-guids
              list guids efivar knows about

       -l, --list
              list current variables

       -p, --print
              print variable specified by --name

       -n, --name=<guid-name>
              variable to manipulate, in the form 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0000

       -a, --append
              append to variable specified by --name

       -f, --fromfile=<file>
              use data from <file>

       -t, --attributes=<attributes>
              attributes to use on append

   Help options:
       -?, --help
              Show this help message

       --usage
              Display brief usage message

интересно, в какой степени это может обеспечивать manipulation и будет-ли от этого польза, ведь "не все йогурты одинаково полезны". В легаси сработал только ключ -L, --list-guids:

Спойлер

$ efivar -L
{00000000-0000-0000-0000-000000000000} {zero} efi_guid_zero zeroed sentinal guid
{ff3e5307-9fd0-48c9-85f1-8ad56c701e01} {sha384} efi_guid_sha384 SHA-384
{826ca512-cf10-4ac9-b187-be01496631bd} {sha1} efi_guid_sha1 SHA-1
{a7717414-c616-4977-9420-844712a735bf} {rsa2048_sha256_cert} efi_guid_rsa2048_sha256_cert RSA 2048 with SHA-256 Certificate
{82988420-7467-4490-9059-feb448dd1963} {lenovo_me_config} efi_guid_lenovo_me_config Lenovo ME Configuration Menu
{c1c41626-504c-4092-aca9-41f936934328} {sha256} efi_guid_sha256 SHA-256
{126a762d-5758-4fca-8531-201a7f57f850} {lenovo_boot_menu} efi_guid_lenovo_boot_menu Lenovo Boot Menu
{0b6e5233-a65c-44c9-9407-d9ab83bfc8bd} {sha224} efi_guid_sha224 SHA-224
{67f8444f-8743-48f1-a328-1eaab8736080} {rsa2048_sha1} efi_guid_rsa2048_sha1 RSA 2048 with SHA-1
{605dab50-e046-4300-abb6-3dd810dd8b23} {shim} efi_guid_shim shim
{3f7e615b-0d45-4f80-88dc-26b234958560} {lenovo_diag} efi_guid_lenovo_diag Lenovo Diagnostics
{665d3f60-ad3e-4cad-8e26-db46eee9f1b5} {lenovo_rescue} efi_guid_lenovo_rescue Lenovo Rescue and Recovery
{8be4df61-93ca-11d2-aa0d-00e098032b8c} {global} efi_guid_global EFI Global Variable
{3b8c8162-188c-46a4-aec9-be43f1d65697} {ux_capsule_guid} efi_guid_ux_capsule_guid Firmware update localized text image
{446dbf63-2502-4cda-bcfa-2465d2b0fe9d} {x509_sha512} efi_guid_x509_sha512 SHA512 hash of X.509 Certificate
{721c8b66-426c-4e86-8e99-3457c46ab0b9} {lenovo_setup} efi_guid_lenovo_setup Lenovo Firmware Setup
{7076876e-80c2-4ee6-aad2-28b349a6865b} {x509_sha384} efi_guid_x509_sha384 SHA384 hash of X.509 Certificate
{ade9e48f-9cb8-98e6-31af-b4e6009e2fe3} {redhat_2} efi_guid_redhat_2 Red Hat Maybe
{e2b36190-879b-4a3d-ad8d-f2e7bba32784} {rsa2048_sha256} efi_guid_rsa2048_sha256 RSA 2048 with SHA-256
{3bd2a492-96c0-4079-b420-fcf98ef103ed} {x509_sha256} efi_guid_x509_sha256 SHA256 hash of X.509 Certificate
{3cc24e96-22c7-41d8-8863-8e39dcdcc2cf} {lenovo} efi_guid_lenovo Lenovo
{4aafd29d-68df-49ee-8aa9-347d375665a7} {pkcs7_cert} efi_guid_pkcs7_cert PKCS7 Certificate
{a5c059a1-94e4-4aa7-87b5-ab155c2bf072} {x509_cert} efi_guid_x509_cert X.509 Certificate
{a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380} {lenovo_diag_splash} efi_guid_lenovo_diag_splash Lenovo Diagnostic Splash Screen
{093e0fae-a6c4-4f50-9f1b-d41e2b89c19a} {sha512} efi_guid_sha512 SHA-512
{7facc7b6-127f-4e9c-9c5d-080f98994345} {lenovo_2} efi_guid_lenovo_2 Lenovo
{c57ad6b7-0515-40a8-9d21-551652854e37} {shell} efi_guid_shell EFI Shell
{77fa9abd-0359-4d32-bd60-28f4e78f784b} {microsoft} efi_guid_microsoft Microsoft
{d719b2cb-3d3a-4596-a3bc-dad00e67656f} {security} efi_guid_security EFI Security Database
{bc7838d2-0f82-4d60-8316-c068ee79d25b} {lenovo_msg} efi_guid_lenovo_msg Lenovo Vendor Message Device
{0abba7dc-e516-4167-bbf5-4d9d1c739416} {redhat} efi_guid_redhat Red Hat
{3c5766e8-269c-4e34-aa14-ed776e85b3b6} {rsa2048} efi_guid_rsa2048 RSA 2048
{f46ee6f4-4785-43a3-923d-7f786c3c8479} {lenovo_startup_interrupt} efi_guid_lenovo_startup_interrupt Lenovo Startup Interrupt Menu
$

это, насколько я понимаю, и есть тот самый мусор, оставшийся после альта и виндовс которые запускались в ефи и успели оставить следы жизнедеятельности (из-за этих следов теперь по DVI сигнал появляется только после начала загрузки ядра, а биос и груб можно увидеть только по VGA, хотя с начала работало). А вот при переключении биос в ефи и загрузке в лив можно увидеть -l, --list:

Спойлер

[altlinux@localhost ~]$ efivar -l
1b838190-4625-4ead-abc9-cd5e6af18fe0-HiiDB
7b77fb8b-1e0d-4d7e-953f-3980a261e077-AfterReadyToBoot
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootCurrent
8be4df61-93ca-11d2-aa0d-00e098032b8c-LangCodes
8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLangCodes
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-SetupHandles
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-AmiGopPolicySetupData
8be4df61-93ca-11d2-aa0d-00e098032b8c-ErrOutDev
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOptionSupport
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConInDev
560bf58a-1e0d-4d7e-953f-2980a261e031-PNP0510_0_VV
560bf58a-1e0d-4d7e-953f-2980a261e031-PNP0501_1_VV
560bf58a-1e0d-4d7e-953f-2980a261e031-PNP0501_0_VV
560bf58a-1e0d-4d7e-953f-2980a261e031-PNP0400_0_VV
560bf58a-1e0d-4d7e-953f-2980a261e031-PNP0604_0_VV
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOutDev
6b9cfdf4-fcd2-4ea2-d796-7fd06c91f491-ME VAR SHADOW
dd41adf5-4368-4654-b1ca-46a6b98d9e84-EasySmartFanAddress
dd41adf5-4368-4654-b1ca-46a6b98d9e84-EasyHealthAddress
dd41adf5-4368-4654-b1ca-46a6b98d9e84-EasyVoltageAddress
8be4df61-93ca-11d2-aa0d-00e098032b8c-USB_POINT
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-UsbMassDevValid
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-UsbMassDevNum
8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndicationsSupported
e6a01b2b-a795-41f0-85a0-53acaab21d97-SetupXtuBufferAddress
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-NBPlatformData
01368881-c4ad-4b1d-b631-d57a8ec8db6b-OA3MSDMvariable
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-SetupPlatformData
83a8a2a2-dc50-4f8d-8e48-ebc8f89c1566-FIDLOC
e6c2f70a-b604-4877-85ba-deec89e117eb-PchS3Peim
4bafc2b4-02dc-4104-b236-d6f1b98d9e84-S3SS
8be4df61-93ca-11d2-aa0d-00e098032b8c-SetupMode
8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot
8be4df61-93ca-11d2-aa0d-00e098032b8c-SignatureSupport
964e5b21-6459-11d2-8e39-00a0c969723b-EDD30
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0004
87f22dcb-7304-4105-bb7c-317143ccc23b-MrcS3Resume
b05e6b5f-6ed8-4015-b5c5-b1049faf3e5b-Profile-2
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-Setup
b05e6b5f-6ed8-4015-b5c5-b1049faf3e5b-Profile-3
b05e6b5f-6ed8-4015-b5c5-b1049faf3e5b-Profile1
4c19049f-4137-4dd3-9c10-8b97a83ffdfa-MemoryTypeInformation
4c19049f-4137-4dd3-9c10-8b97a83ffdfa-PreviousMemoryTypeInformation
b05e6b5f-6ed8-4015-b5c5-b1049faf3e5b-Profile-1
b05e6b5f-6ed8-4015-b5c5-b1049faf3e5b-Profile0
c020489e-6db2-4ef2-9aa5-ca06fc11d36a-AcpiGlobalVariable
af9ffd67-ec10-488a-9dfc-6cbf5ee22c2e-AcpiGlobalVariable
b80a8e5b-c02a-4a31-ae12-58e46e803e89-HardwareConfigData
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0003
d1405d16-7afc-4695-bb12-41459d3695a2-NetworkStackVar
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-UsbSupport
c811fa38-42c8-4579-a9bb-60e94eddfb34-AMITSESetup
8be4df61-93ca-11d2-aa0d-00e098032b8c-Timeout
8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLang
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-BiosSetupType
8be4df61-93ca-11d2-aa0d-00e098032b8c-Lang
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-HswMitAttrib
2a64d079-aceb-4ad9-afd5-252e35ba994a-EasyTuneSetupAddress
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-AdvMitAttrib
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-MemMitAttrib
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-ProcMitAttrib
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrder
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0002
45cf35f6-0d6e-4d04-856a-0370a5b16f53-DefaultBootOrder
3c4ead08-45ae-4315-8d15-a60eaa8caf69-DefaultLegacyDevOrder
a56074db-65fe-45f7-bd21-2d2bdd8e9652-OldLegacyDevOrder
a56074db-65fe-45f7-bd21-2d2bdd8e9652-LegacyDevOrder
8be4df61-93ca-11d2-aa0d-00e098032b8c-ErrOut
5a47386b-4c41-43b6-a140-824b0260ca8d-Ps2KeyboardDetectRecord
09b5c46a-0f41-4cee-84ff-f3660a0b08d6-Ps2MouseDetectRecord
560bf58a-1e0d-4d7e-953f-2980a261e031-PNP0510_0_NV
560bf58a-1e0d-4d7e-953f-2980a261e031-PNP0501_1_NV
560bf58a-1e0d-4d7e-953f-2980a261e031-PNP0501_0_NV
560bf58a-1e0d-4d7e-953f-2980a261e031-PNP0400_0_NV
560bf58a-1e0d-4d7e-953f-2980a261e031-PNP0604_0_NV
40312829-7891-4abd-b200-0c541b061939-MemCeil.
a31b27a4-cae6-48ff-8c5a-294221e6f389-PchInitPei
de565cd0-b278-4d59-8681-d23578dcad48-OemIdCheck
01f33c25-764d-43ea-aeea-6b5a41f3f3e8-SbAslBufferPtrVar
e1e2a446-0365-4c65-919c-0371c3f9f5ff-PegGen3PresetSearchData
ec87d643-eba4-4bb5-a1e5-3f3e36b20da9-NumOfPState
1456cc6e-22ac-5289-33ba-2e13bbdabaee-CPUS3APICID
01368881-c4ad-4b1d-b631-d57a8ec8db6b-FPDT_Variable
e6c2f70a-b604-4877-85ba-deec89e117eb-PchInit
78ce2354-cfbc-4643-aeba-07a27fa892bf-WdtPersistentData
dde1bc72-d45e-4209-ab85-14462d2f5074-HobRomImage
01368881-c4ad-4b1d-b631-d57a8ec8db6b-MonotonicCounter
4599d26f-1a11-49b8-b91f-858745cff824-StdDefaults
[altlinux@localhost ~]$

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

[Speccyfighter]

Скажем так:
Я бы не решился ответить в каком из вариантов геморроя будет меньше.

...
Я читал ссылку выше про загрузчик и был готов к худшему, но автомат справился, правда установил его не на /dev/sda а /dev/disk/by-id , но при этом всё прекрасно работает

Код: [Выделить]

...
GRUB_AUTOUPDATE_DEVICE='/dev/disk/by-id/wwn-0x5000c50064b4ad85 '
...


Это не имеет значения. Важно что этот симлинк указывает на /dev/sda

это, насколько я понимаю, и есть тот самый мусор, оставшийся после альта и виндовс которые запускались в ефи

Меня сильно настораживает, когда что-то без моего ведома начитает сохраняться у меня на компьютере и даже не на жёстком диске, а в nvram.
Классика, при всех её недостатках, никогда не подводит.

Здесь (забудьте слово ЦРУ, но запомните слово: взлом )
https://wikileaks.org/ciav7p1/cms/page_26968084.html
одна из ключевых фраз, это
However, the manpage does not tell you everything you need to know about nvram.
Тем не менее, manpage не сообщает вам все, что вам нужно знать о nvram.
Пока вы не знаете от точки до точки как это работает, вы в потенциальной опасности. И здесь уже неважно, закрытый это код или открытый.
Это конечно моё ИМХО, но вся эта идея с nvram, мне как минимум кажется странной. Но это уже моё личное мнение.

[klark973]

Стоило тогда повесить багу. Попытаюсь исправить это таском #234689. Там всего-то делофф.

2Rider: Посмотрел сабж внимательнее и обнаружил, что в Debian dpkg-reconfigure это тоже умеет определять для авто-обновления grub.