[РЕШЕНО]Grub сообщение EndEntire file path: ... /EndEntire после выбора загрузки системы

jim945, спорить и что то доказывать я не собираюсь. Но повторюсь: в бинарниках chainloader (chain.mod) упоминание о /EndEntire отствует, имеется упоминание только о cannot load image, упоминание о /EndEntire присутсвует только в бинарниках EFI. Проверяется это легко.
Поэтому и предположил, что в итоговом сообщении участвуют как chainloader так и EFI .... один chainloader такого лога выдать не может.
Ошибки не исчезают с опытом - они просто умнеют
В общем, установке федоры выяснил следующее:
1. При загрузке windows из своего основного grub, появляется аналогичное сообщение, но оно очень быстро пропадает
2. При загрузке windows из-под grub, который был установлен вместе с федорой, появляется сообщение, и также очень быстро пропадает, но появляется только его последняя часть /EndEntire ("EndEntire file path: /ACPI(80341d0,0)/PCI (1,1)/PCI (0,0)/UnknownMessaging..." в сообщении нет)
3. При добавлении в grub.cfg федоры строку выбора efi файла моей системы, и при выборе моей арч системы, появляется сообщение, на секунд 5-8 (долго, как и было раньше), и только его последняя часть /EndEntire ("EndEntire file path: /ACPI(80341d0,0)/PCI (1,1)/PCI (0,0)/UnknownMessaging..." в сообщении нет)
4. При копирования grub.cfg из grub федоры в мой основной grub, и при выборе моей арч системы, появляется сообщение, так же на 5-8 секунд, и в полном выводе (т.е. в точности, как и было раньше)

То есть:
а) /EndEntire появляется в любом из моих четырёх случаев и, что при загрузке из основного grub и что из grub федоры, системы на этом этапе грузятся одинаково, и если я решу проблему с "EndEntire file path: /ACPI(80341d0,0)/PCI (1,1)/PCI (0,0)/UnknownMessaging", то скорее система грузиться быстрее не станет
б) "EndEntire file path: /ACPI(80341d0,0)/PCI (1,1)/PCI (0,0)/UnknownMessaging..." в моих 4-х случаях случался только тогда, когда я грузил и grub и efi моей системы из одного boot раздела.
Вообще, учитывая пункт (а.), и что система и так нормально грузиться, я занимаюсь решением проблемы ради решения проблемы и, по сути, можно не обращать внимание на это сообщение, либо скрыть этот вывод что, например может скрипт из /etc/grub.d/00_header. (Я правда точно не знаю, что именно там скрывает вывод, может знающие тут подскажут)
Я дальше ещё попробую понять в чём причина этого сообщения, но к нему, я думаю, можно относиться как к простому уведомлению, что grub встретил что-то непонятное, но при этом никак не влияющее ни на скорость загрузки из grub, ни на систему в целом
Стоит ли писать в заголовке РЕШЕНО, если, по сути, изначальная проблема не решена, а просто пришёл к выводу, что сообщение ни на что не влияет, и что его можно спокойно игнорировать?
vlad1.96
пришёл к выводу, что сообщение ни на что не влияет, и что его можно спокойно игнорировать?
В части вывода EndEntire file path: - это просто сообщение, ни на что не влияющее ... это просто вывод информации о диске (из вывода, например, узнаем, что используется раздел 1, который начинается с 2048 сектора ... и др.).
В части причины появления этого сообщения - могу и ошибаться, так что не пинайте … есть предположение, что это связано с используемым bootx64.efi - есть два типа этого файла, в одном имеется упоминание о EndEntire, а в другом нет ... и от используемого типа этого файла будет зависеть появление сообщения.
Сам EFI не использую, так что проверить не могу. Предположение сделал на основании того, что имеющийся у меня файл bootx64.efi, входящий в самосборный Grub2 (собирал давно из исходников) содержит упоминание EndEntire … а вот bootx64.efi, входящий в systemd (/usr/lib/systemd/boot/efi/systemd-bootx64.efi) не содержит упоминание EndEntire

Все это одни предположения, возможно я и не прав, нужно проверять, что используется в твоем случае …. и плюс к этому - не известно еще, как влияет на это использование UKI
Проверить это предположение можно только экспериментируя с разными типами bootx64.efi (лучше конечно смотреть что прописано в исходниках) ... плюс к этому не ясно - связано ли это с использование UKI.
Повторюсь - это все мои фантазии, так что не нужно ругать.

Конечно, РЕШЕНО писать не стоит - смысл/причина сообщения до конца не ясен.
Ошибки не исчезают с опытом - они просто умнеют
vasek
В части вывода EndEntire file path: - это просто сообщение, ни на что не влияющее … это просто вывод информации о диске (из вывода, например, узнаем, что используется раздел 1, который начинается с 2048 сектора … и др.).

Было бы в чём пинать :) Как я понимаю, Вы тут один из самых активных и хорошо эрудированны в системах, насколько я могу судить

По поводу systemd-boot: он у меня был установлен изначально и сейчас стоит параллельно как запасной вариант. При установке grub, его bootx64.efi скорее всего перезаписал последний, но тем не менее ни сообщений, ни каких-то других изменений не последовало, если опять загружаться из него. Ещё одна особенность, если говорить про UKI и его влияние, то в том же systemd-boot, в отличии от grub, этап между загрузчиком и появлением первых сообщений инициализации ядра происходит мгновенно (на grub, как я выше писал 5-7 секунд)

В любом случаем стоит попробовать поменять между grub моей системы и установленной федорой bootx64.efi файл местами, и как минимум ещё попробовать обратно заменить bootx64.efi от systemd-boot обратно.

Возвращаясь обратно, мне не совсем ясно значение сообщения: PCI (0,0)/UnknownMessaging. Как я понимаю, от одного из устройств на PCI шине grub получил непонятное для него сообщение?
vlad1.96
не совсем ясно значение сообщения: PCI (0,0)/UnknownMessaging. Как я понимаю, от одного из устройств на PCI шине grub получил непонятное для него сообщение?
Похоже что то не понравилось, но чтобы понять смысл этого сообщения нужно смотреть исходники (конечно понимая их смысл).
Но скорее всего ничего крамольного нет. Повторюсь, сам EFI не использую, поэтому практически мало что об этом знаю. Но проведя не большой анализ выяснили следующее:
- это сообщение выдает файл /usr/lib/grub/x86_64-efi/kernel.img и что интересно, этот же файл выдает сообщение EndEntire
strings /usr/lib/grub/x86_64-efi/kernel.img | grep -E 'EndEntire|UnknownMessaging'
/EndEntire
/UnknownMessaging(%x)
- файл /usr/lib/grub/x86_64-efi/kernel.img принадлежит пакету Grub2 … и как пишут в DOC про этот файл
It is rarely used directly, but is built into all core images.
И снова настораживает использование UKI ...

PS - не ужели так важно использование UKI? - пользы от него особой нет ... с какой целью его используешь?

EDIT - не нужно цитировать пост польностью, только необходимое - легче читается.
Ошибки не исчезают с опытом - они просто умнеют
vasek
- это сообщение выдает файл /usr/lib/grub/x86_64-efi/kernel.img и что интересно, этот же файл выдает сообщение EndEntire
strings /usr/lib/grub/x86_64-efi/kernel.img | grep -E 'EndEntire|UnknownMessaging'
/EndEntire
/UnknownMessaging(%x)
- файл /usr/lib/grub/x86_64-efi/kernel.img принадлежит пакету Grub2 … и как пишут в DOC про этот файл
It is rarely used directly, but is built into all core images.
И снова настораживает использование UKI …
Да, интересная штука получается)

Это не только с UKI высвечивается, но и с Windows тоже, так что я начинаю думать, что EndEntire, сам по себе в принципе высвечивается при любой загрузке путём chainloading
Я поставил memtest86+, правда уже успел поверх сконфигурировать 00_header, который скрывает вывод...уберу 00_header, посмотрю что на нём показывает.
Ну и ещё закину EFI системы на другой диск и запущу из основного grub оттуда. Если вывод будет как, когда из grub федоры запускался, тогда хоть точно буду знать, что PCI (0,0)/UnknownMessaging
связан именно с тем, что и grub и EFI системы грузятся из одного раздела и что-то там не поделили

PS - не ужели так важно использование UKI? - пользы от него особой нет … с какой целью его используешь?

Какой-то практической нужды нет, просто увидел, что и mkinitcpio включила поддержку, и в федоре заявили о внедрении, вот и решил посмотреть, что это такое
При загрузке из systemd-boot и с записью в UEFI проблем не было, а с grub просто появились вопросы.
Так что особой нужды нет, но был интерес почему появляется этот вывод)
vlad1.96
но и с Windows тоже, так что я начинаю думать, что EndEntire, сам по себе в принципе высвечивается при любой загрузке путём chainloading
Ничего у меня не высвечивается при загрузке Windows 11.
Не надо думать, лишнего.
В общем да, что при UKI, что при запуске windows, что при запуске memtest, при запуске всех 3-х высвечивается EndEntire и дальнейшее сообщение
Когда грузил UKI c другого диска, то опять выводился длинный вывод, но уже с иным содержанием, где уже видно, что, по крайней мере grub не встречает неизвестных сообщений на месте устройства
"/EndEntire
file path: /ACPI(a0341d0,0) /PCI(3,1) /PCI (2,0) /PCI (0,6) /PCI(0,0) /Sata(1, ffff ,0)/HD (1,800, 12c000, 4082a34a37739744,2,2)/File (\EFI)/File (arch-linux-lqx.efi)
/EndEntire"

Можно, конечно, чтобы ещё кто-то проверил, скачав себе, например тот же memtest86+, поставив в grub(убрав, при этом 00_header, если сконфигурирован, либо какие-то ещё маскировщики вывода), чтобы исключить, например мои личные проблемы:

if [ "$grub_platform" = "efi" ]; then
	menuentry "Memtest86" {
		search --set=root --no-floppy --fs-uuid <<свой UUID>>
		chainloader /EFI/memtest86/memtestx64.efi
	}
fi
Но тогда необходимо это зафиксировать, например замедленной съёмкой, т.к. на таком приложении сообщение проходит очень быстро

Пока я думаю, что причина этому сообщению именно то, что grub запускает chainloading сам по себе, и этим сообщением просто информирует какой следующий efi файл он после себя запускает.
А в doc к тому файлу из пакета grub2, может имелось ввиду, что редко использовался в практическом плане...тут я точно не могу ответить, т.к. уже начинаю додумывать
RusWolf
vlad1.96
но и с Windows тоже, так что я начинаю думать, что EndEntire, сам по себе в принципе высвечивается при любой загрузке путём chainloading
Ничего у меня не высвечивается при загрузке Windows 11.
Не надо думать, лишнего.
При моём опыте:
а) У Windows это сообщение проходит быстро, буквально доли секунды
б) стандартный grub-mkconfig вместе с 00_header может маскировать этот вывод

Если зашли сюда, чтобы помочь, то можете поспособствовать этому и, например сказать, не сгенерированный ли файл grub.сfg?
А если сгенерирован, то убрать часть с 00_header и ещё раз проверить

Просто так сложно отвечать на утвердительные сообщения, в которых мало какой-либо информативности, а так хоть можно будет с чем-то работать
 
Зарегистрироваться или войдите чтобы оставить сообщение.