Ошибка при установке grub (Решено)

Chips
начальный адрес 0x00009074
Что я и предполагал. Немного теории, как я ее вижу (в чем то, конечно, могу и ошибаться)
Каждый elf файл имеет свой уникальный стартовый адрес, который присваивается ему компилятором.
Одни и те же elf файлы, собранные одинаковыми компиляторами имеет одинаковый стартовый адресс … а вот если они собраны разными компиляторами, то могут и отличаться.
Адрес при запуске elf файла считывается из заголовка ELF по смещению 0x18 (4 байта)
И похоже у тебя компилятор стал присваивать другие стартовые номера - для запуска обычных программ это не критично и на работу не влияет (все вертится в памяти), а вот для grub оказывается. что это имеет значение - почему, не знаю.
В принципе этот стартовый адрес можно менять самому, при компиляции - способ описан ….. но можно и поэкспериментировать и поправить это в готовом файле - никогда этого не делал, что будет не знаю, но исправить легко, например, изменить этот адрес либо, используя hex-редактор либо в ручную.
Опишу в ручную … но hex-редактором проще.
Имеем копию файла kernel.img - ~/TTT/TEST/kernel.img
sudo hexdump -s 0x18 -n 4 ~/TTT/TEST/kernel.img
0000018 9074 0000
objdump -f ~/TTT/TEST/kernel.img | grep адр
начальный адрес 0x00009074
меняем на 9000
printf '\x00\x90' | dd conv=notrunc of=~/TTT/TEST/kernel.img bs=1 seek=$((0x18))
проверяем
hexdump -s 0x18 -n 4 ~/TTT/TEST/kernel.img
0000018 9000 0000
objdump -f ~/TTT/TEST/kernel.img | grep адр
начальный адрес 0x00009000

И попробуй запустить grub-instal …… даже стало интересно. что получится …
Ошибки не исчезают с опытом - они просто умнеют
У меня была мысль что проблема с gcc (я его корявенько собрал отсутствуют 32х разрядные либы) и всё равно думал пере собирать но и этот вариант попробую
Chips
но и этот вариант попробую
Не получиться изменить, как описал - не достаточно изменить только адрес в Header .... забыл, что этот адрес идет и дальше
Проверил (изменил 9000 на 9074) и вот что имеем
objdump -df ~/TTT/TEST/kernel.img
/home/vasek/TTT/TEST/kernel.img:     формат файла elf32-i386
архитектура: i386, флаги 0x00000002:
EXEC_P
начальный адрес 0x00009074
.... а далее идет смещение уже от 9000
Дизассемблирование раздела .text:

00009000 <.text>:
    9000:	89 8e 41 00 00 00    	mov    %ecx,0x41(%esi)
    9006:	89 be 45 00 00 00    	mov    %edi,0x45(%esi)
    900c:	89 86 64 01 00 00    	mov    %eax,0x164(%esi)
    9012:	b9 e0 6c 00 00       	mov    $0x6ce0,%ecx
    9017:	bf 00 90 00 00       	mov    $0x9000,%edi
Так что виноват, поспешил с советом ... но, повторюсь, способ по смене адреса при компиляции имеется
Ошибки не исчезают с опытом - они просто умнеют
vasek
Так что виноват, поспешил с советом … но, повторюсь, способ по смене адреса при компиляции имеется

Я наверное завтра пере соберу gcc и попробую ещё раз мне всё больше кажется что виноват именно он
Chips
мне всё больше кажется что виноват именно он
Стартовый адрес присваивает компилятор, так что скорее всего причина в gcc
Ошибки не исчезают с опытом - они просто умнеют
Заело, как так, не могу изменить бинарник - вообщем, используя hex-редактор внес измения в elf файл, заменил 9000 на 9074 (около 5 изменений) ... и все получилось
readelf -a ~/TTT/TEST/kernel.img
Заголовок ELF:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Класс:                             ELF32
  Адрес точки входа:                 0x9074

Заголовки разделов:
  [Нм] Имя               Тип             Адрес    Смещ   Разм   ES Флг Сс Инф Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00009074 000080 00552c 00 WAX  0   0  1
  [ 2] .rodata           PROGBITS        0000e52c 0055ac 000fcb 00   A  0   0  4
Лишний вывод выкинул
objdump -d ~/TTT/TEST/kernel.img
/home/vasek/TTT/TEST/kernel.img:     формат файла elf32-i386
Дизассемблирование раздела .text:

00009074 <.text>:
    9074:	89 8e 41 00 00 00    	mov    %ecx,0x41(%esi)
    907a:	89 be 45 00 00 00    	mov    %edi,0x45(%esi)
    9080:	89 86 64 01 00 00    	mov    %eax,0x164(%esi)
    9086:	b9 e0 6c 00 00       	mov    $0x6ce0,%ecx
    908b:	bf 74 90 00 00       	mov    $0x9074,%edi
Можешь пробовать .... рекомендую установить hex-редактор bless, открываешь файл kernel.img (копию):
Search - найти и заменить -
в строке - Search for : пишем 74 90 00 00
в строке - Replace with: пишем 00 90 00 00
справа жмем Replace All
сохраняем ... тебе придется запускть от root

Проверяем
readelf -a ~/TTT/TEST/kernel.img
Заголовок ELF:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Класс:                             ELF32
 Адрес точки входа:                 0x9000

Заголовки разделов:
  [Нм] Имя               Тип             Адрес    Смещ   Разм   ES Флг Сс Инф Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00009000 000080 00552c 00 WAX  0   0  1

objdump -d ~/TTT/TEST/kernel.img
/home/vasek/TTT/TEST/kernel.img:     формат файла elf32-i386

Дизассемблирование раздела .text:

00009000 <.text>:
    9000:	89 8e 41 00 00 00    	mov    %ecx,0x41(%esi)
    9006:	89 be 45 00 00 00    	mov    %edi,0x45(%esi)
    900c:	89 86 64 01 00 00    	mov    %eax,0x164(%esi)
.......................
Все вернули на место

EDIT 1 - один минус, НЕ ПРОВЕРИЛ, сделано где то 4 или 5 изменений, но вот все ли эти найденные строки 74 90 00 00 имеют отношение к стартовому адресу - посеръезному необходимо обращаться к структуре формата elf файла и смотреть, что это мы меняли ... но это уже для меня тяжело (не те годы)

EDIT 2 - это все игрушки, а если по серъезному, то нужно приводить в норму компилятор. Изменишь один файл, но останутся не измененными другие файлы, которые могут быть в зависимостях у исправленного файла - это же не проверялось и не известно, как это исправление скажется на установку grub.
Ошибки не исчезают с опытом - они просто умнеют
vasek Gcc пере собрал правда тут вылезла такая бяка

/usr/bin/python gentpl.py Makefile.util.def Makefile.utilgcry.def > Makefile.util.am.new || (rm -f Makefile.util.am.new; exit 1)
mv Makefile.util.am.new Makefile.util.am
 cd . && /bin/sh /home/chip/BUILD/grub/grub.src/grub-bios/build-aux/missing automake-1.15 --gnu Makefile
/home/chip/BUILD/grub/grub.src/grub-bios/build-aux/missing: строка 81: automake-1.15: команда не найдена
WARNING: 'automake-1.15' is missing on your system.
         You should only need it if you modified 'Makefile.am' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'automake' program is part of the GNU Automake package:
         <http://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <http://www.gnu.org/software/autoconf>
         <http://www.gnu.org/software/m4/>
         <http://www.perl.org/>

Что радостно гласит о том что не может найти automake-1.15 хотя у меня установлен automake-1.16. У меня была такая проблема я вот только не помню как её тогда решил пересборка automake не помогла

P.S. Вот яж баран забыл что в скриптие для сборки закоментировал ./autogen.sh
(((((((((((((

sudo grub-install /dev/sda
Выполняется установка для платформы i386-pc.
grub-install: ошибка: некорректная компиляция «/usr/lib/grub/i386-pc/kernel.img»: начальный адрес равен 0x9074 вместо 0x9000: ошибка в ld.gold?.

У кого какие ещё есть мысли?
Такое сообщение об ошибке во всем дереве исходников grub есть только в файле ./util/grub-mkimagexx.c и выдается только в случае если
(!is_relocatable (image_target) && grub_host_to_target_addr (s->sh_addr) != image_target->link_addr)
. Покопаться в исходниках - хорошее поле для деятельности, кто хочет
Chips
Я пробую собрать свой дистр основываясь на Arch только с openrc в место systemd и другим пакетным менеджером
И когда вы поймете, что это за функции и переменные, причина ошибки станет для вас очевидной :) Удачи.
ЗЫ. Может проще заглянуть сюда, чем изобретать велосипед?
Впервые вижу, чтобы програ при запуске считывала, сверяла точки входа и при не совпадении выдавла error.
Провел анализ на наличие таких прог в нашей системе и выяснил, что у меня таких прог 5 штук и все имеют отношение к grub (grub-mkstandalone, grub-mkimage, grub-mkrescue, grub-install, grub-mknetdir), в которых прописаны сообщения
`%s' is miscompiled: its start address is 0x%llx instead of 0x%llx: ld.gold bug?
`%s' is miscompiled: its start address is 0x%llx instead of 0x%llx: ld.gold bug?
Но интересно то, что в самих исходниках этих прог это не прописано.
Далее выяснил, что в исходниках grub имеется всего один файл grub-mkimagexx.c, в котором идет проверка этих точек входа (привожу кусок кода)
  /* .text */
  for (i = 0, s = smd->sections;
       i < smd->num_sections;
       i++, s = (Elf_Shdr *) ((char *) s + smd->section_entsize))
    if (SUFFIX (is_text_section) (s, image_target))
      {
	layout->kernel_size = SUFFIX (put_section) (s, i, layout->kernel_size,
						smd, image_target);
	if (!is_relocatable (image_target) &&
	    grub_host_to_target_addr (s->sh_addr) != image_target->link_addr)
	  {
	    char *msg
	      = grub_xasprintf (_("`%s' is miscompiled: its start address is 0x%llx"
				  " instead of 0x%llx: ld.gold bug?"),
				kernel_path,
				(unsigned long long) grub_host_to_target_addr (s->sh_addr),
				(unsigned long long) image_target->link_addr);
	    grub_util_error ("%s", msg);
	  }
      }
и похоже при компиляции это и попадает в указанные 5 файлов.
Но так и не соображу, для чего это нужно grub? - только одни предположения.

Далее провел эксперимент - подправил свой бинарник /usr/lib/grub/i386-pc/kernel.img в части изменения точки входа - особо не вникал в правилность выполнения правки (важен был результат) и запустил grub-install … в итоге получил это проблемное сообщение
sudo grub-install /dev/sdb
Выполняется установка для платформы i386-pc.
grub-install: ошибка: некорректная компиляция «/usr/lib/grub/i386-pc/kernel.img»: начальный адрес равен 0x9074 вместо 0x9000: ошибка в ld.gold?.

grub-install операция разовая, выполняемая довольно редко, и, в принципе решить проблему попробовать можно, например, настроив стартовый адрес точки входа перед компиляцией ...(возможно это не есть хорошо, не уверен) ... или изменив точку входа только у файла kernel.img в ручную (придется несколько вхождений адреса проверять методом тыка, просто это быстрее, чем изучение теории), НО не понятно как это отразится на работе grub - не зря же идет проверка - вообщем нужно экспериментировать …

Но, самое главное, конечно же, это понять - почему меняется адрес точки входа всех программ.
Повторюсь, этим занимается компилятор … но понятие компилятора это не просто одна программа, например, gcc - это целый комплекс и скриптов и линковщиков и др. Я тонкости этой кухни не знаю, просто меня интересовало в бинарниках всегда совсем другое (их редактирование) …
Но могу только предположить - ты взялся построить свою систему Linux - но в этом построении тоже есть свои правила и нюансы, любое перемешивание кирпичиков может привести к неожиданным результатам.
Спецов, знающих все эти тонкости не много и, думаю, когда ты построишь свою систему, то и сам будешь таким спецом. Это я к тому, что вероятность получения помощи не высока, придется до всего доходить самому и много читать.

Интересно посмотреть несколько выводов (пути поставь свои - у тебя скорее всего эти файлы дублируются)
od -A d -t x1 /usr/lib/grub/i386-pc/kernel.img | grep "74 90 00 00"
file /usr/lib/grub/i386-pc/kernel.img
hexdump -C -n 16 /usr/lib/grub/i386-pc/kernel.img
file /usr/bin/grub-install
hexdump -C -n 16 /usr/bin/grub-install
Ошибки не исчезают с опытом - они просто умнеют
 
Зарегистрироваться или войдите чтобы оставить сообщение.