[devel] GRUB и сородичи

[devel] GRUB и сородичи

[Ildar Mulyukov]

On 19.12.2006 23:05:22, bugzilla-daemon@ wrote:
> https://bugzilla.altlinux.org/show_bug.cgi?id=6914
> 
> ------- Additional Comments From gns@altlinux.org  2006-12-19 20:05
> а почему это висит на grub2, если не работает в grub?

	Здравствуйте, коллеги.
мой вопрос - о судьбе grub и grub2. Сейчас наблюдаю следующую ситуацию:
1. grub в, видимо, неподдерживаемом состоянии. Хотя он ещё  
функциональный, gfxmenu у него уже давно не работает. Неровен час,  
остальное начнёт отваливаться...
2. grub2 свежеустановленный имеет настолько мало документации, что даже  
установить его мне не удалось. В частности, grub-install не работает  
вообще. В установке на ощупь я продвинулся лишь до того, чтобы  
установить его на floppy.
3. alterator-bootloader поддерживает только lilo. Следовательно,  
доступных способов установки grub2 мне просто не известно.
4. Правильно ли я понял, что grub устарел в пользу grub2?

С уважением, Ильдар.
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] GRUB и сородичи

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

Здравствуйте Ildar Mulyukov
  В сообщении от Wednesday 20 December 2006 08:04 Ildar Mulyukov 
 >
 > 4. Правильно ли я понял, что grub устарел в пользу grub2?
grub устарел, но grub2 ещё не готов. Мне во всяком случае не удалось 
настроить grub2. Насчёт документации, насколько я понял, для 
пользователя в grub2 ничего особо меняться не должно. Если я не прав, 
поправьте меня.
http://www.gnu.org/software/grub/grub-2.en.html 
http://translate.google.com/translate?hl=ru&sl=en&u=http://www.gnu.org/software/grub/grub-2.en.html&sa=X&oi=translate&resnum=1&ct=result&prev=/search%3Fq%3Dgrub2%26hl%3Dru%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26sa%3DG

-- 
С уважением Xихин Руслан

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и сородичи

[Anton Farygin]

Ildar Mulyukov wrote:
> On 19.12.2006 23:05:22, bugzilla-daemon@ wrote:
>> https://bugzilla.altlinux.org/show_bug.cgi?id=6914
>>
>> ------- Additional Comments From gns@altlinux.org  2006-12-19 20:05
>> а почему это висит на grub2, если не работает в grub?
> 
> 	Здравствуйте, коллеги.
> мой вопрос - о судьбе grub и grub2. Сейчас наблюдаю следующую ситуацию:
> 1. grub в, видимо, неподдерживаемом состоянии. Хотя он ещё  
> функциональный, gfxmenu у него уже давно не работает. Неровен час,  
> остальное начнёт отваливаться...
> 2. grub2 свежеустановленный имеет настолько мало документации, что даже  
> установить его мне не удалось. В частности, grub-install не работает  
> вообще. В установке на ощупь я продвинулся лишь до того, чтобы  
> установить его на floppy.
> 3. alterator-bootloader поддерживает только lilo. Следовательно,  
> доступных способов установки grub2 мне просто не известно.
> 4. Правильно ли я понял, что grub устарел в пользу grub2?

Ильдар, на мой взгляд всё-таки grub не устарел в пользу grub2.

Безусловно его надо обновлять и фиксить.

Но вот основная задача - сборка его на x86_64 пока не выполнима по
причине сломанного флага -m32 в нашей сборочной среде для x86_64.


Вообще, IMHO надо вместо lilo использовать grub по умолчанию, ибо тот же
xen без него не работает.


Rgds,
Rider

Re: [devel] GRUB и сородичи

[Andrii Dobrovol`s`kii]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

Anton Farygin пишет:
> Ildar Mulyukov wrote:
> 
> Вообще, IMHO надо вместо lilo использовать grub по умолчанию, ибо тот же
> xen без него не работает.
> 
Лучше не надо. Xen нужен не всем. А те, кому он нужен, могут
установить нестандартный загрузчик.
> 
> Rgds,
> Rider
-- 
Rgrds,
Andriy
*********************************************************************
email: dobr at iop dot kiev dot ua            Kyiv, Ukraine
Phone: (380-44)   525-7824            Department of Gas Electronics
Fax:   (380-44)   525-2329             Institute of Physics of NASU
*********************dobrATjabber.iop.kiev.ua************************


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и сородичи

[Михаил Якушин]

[-- Attachment #1.1: Type: text/plain, Size: 1924 bytes --]

Ildar Mulyukov wrote:
> On 19.12.2006 23:05:22, bugzilla-daemon@ wrote:
>> https://bugzilla.altlinux.org/show_bug.cgi?id=6914
>>
>> ------- Additional Comments From gns@altlinux.org  2006-12-19 20:05
>> а почему это висит на grub2, если не работает в grub?
> 
Если очень надо, я как наиболее заинтересованное лицо в grub,  могу и
первый взять.
> 	Здравствуйте, коллеги.
> мой вопрос - о судьбе grub и grub2. Сейчас наблюдаю следующую ситуацию:
> 1. grub в, видимо, неподдерживаемом состоянии. Хотя он ещё  
> функциональный, gfxmenu у него уже давно не работает. Неровен час,  
> остальное начнёт отваливаться...
Ужас. Ещё раз повторюсь что  grub меня сильно интересует.
> 2. grub2 свежеустановленный имеет настолько мало документации, что даже  
> установить его мне не удалось. В частности, grub-install не работает  
> вообще. В установке на ощупь я продвинулся лишь до того, чтобы  
> установить его на floppy.
Да по grub2 есть документация у них на wiki.

У меня на 3х машинах работает. Устанавливается странно, но однозначно
через grub-install.
> 3. alterator-bootloader поддерживает только lilo. Следовательно,  
> доступных способов установки grub2 мне просто не известно.
> 4. Правильно ли я понял, что grub устарел в пользу grub2?
Нет, потому что в отличее от grub2 grub работает нормально.

> 
> С уважением, Ильдар.

Про конфиги:
В grub2 поменялся конфиг. Мой конфиг в аттаче. в общем по моему примеру
можно представить как он должен выглядеть.
Про x86_64(собственно из за чего все началось с grub2):
У меня он целиком собрал после доводки напильником, но я не тестил.

Про grub2 в целом.
Он страшно кривой. Конечно с ним что xen что стандартные ядра грузятся,
но например редактирование перед загрузкой работает криво.
Зато там есть поддержка lvm2 и softraid что любопытно.
Вобщем как перестанет падать и глючить можно будет сказать что grub
устарел, но пока нет.



[-- Attachment #1.2: grub.cfg --]
[-- Type: text/plain, Size: 196 bytes --]

set default=0 
set timeout=15

menuentry "Linux-2.6.18-alt2" {
set root=(hd0,1)
linux /boot/vmlinuz-2.6.18-std-smp-alt2 root=/dev/hda1 vga=788
initrd /boot/initrd-2.6.18-std-smp-alt2.img 
}

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] GRUB и сородичи

[Michael Shigorin]

On Wed, Dec 20, 2006 at 11:09:18AM +0300, Anton Farygin wrote:
> Вообще, IMHO надо вместо lilo использовать grub по умолчанию,
> ибо тот же xen без него не работает.

Ой не знаю, достаточно осознанно сидел и на том, и на том.
В последнее время сполз на lilo по ряду причин (про часть
или все из них мне позже говорили, что "вроде и в grub
починили", но обычно это было уже неинтересно):

* установка на root raid1 (raid-extra-boot=mbr-only)
* возможность тестовой загрузки другого ядра
  (lilo -R/rebooting в сочетании с panic=xx)
* более "деревянное" и IMHO поддерживаемое upstream

При этом в grub нравится то, что больше шансов выкарабкаться
из почти безнадёжной ситуации.  Впрочем, обычно стараюсь держать
другое средство загрузки, как тот же LiveCD, поскольку обычно 
последующие операции тоже быстрее/лучше/надёжнее выполнять 
стоя на чём-то другом, чем негрузящийся корень.

Это для сервера, для десктопа куда приоритетнее, "к чему красивые
менюшки прикручены", наверное (мне лично без разницы).

PS: ну и естественно, умолчания в ряду ALM2.x тоже сыграли.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] GRUB и сородичи

[Pavlov Konstantin]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

On Wednesday 20 December 2006 23:59, Michael Shigorin wrote:
> Ой не знаю, достаточно осознанно сидел и на том, и на том.
> В последнее время сполз на lilo по ряду причин (про часть
> или все из них мне позже говорили, что "вроде и в grub
> починили", но обычно это было уже неинтересно):
>
> * установка на root raid1 (raid-extra-boot=mbr-only)

А это разве работает? А при выдергивании любого из дисков?
В тот раз, когда я ставил raid1+grub (месяца 4 назад, вроде бы), vsu@ говорил, 
что в lilo это не работает. Сам понимаешь, не доверять ему я не могу. :)

Если это действительно работает, то, конечно, очень хорошо.

-- 
Pavlov Konstantin,
ALT Linux Team,
VideoLAN Team,
jid: thresh@altlinux.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и LILO

[Michael Shigorin]

On Thu, Dec 21, 2006 at 01:04:56AM +0300, Pavlov Konstantin wrote:
> > Ой не знаю, достаточно осознанно сидел и на том, и на том.
> > В последнее время сполз на lilo по ряду причин (про часть
> > или все из них мне позже говорили, что "вроде и в grub
> > починили", но обычно это было уже неинтересно):
> > * установка на root raid1 (raid-extra-boot=mbr-only)
> А это разве работает? А при выдергивании любого из дисков?

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

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] GRUB и сородичи

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

* Pavlov Konstantin <thresh@> [061221 01:06]:
> > * установка на root raid1 (raid-extra-boot=mbr-only)
> А это разве работает? А при выдергивании любого из дисков?
> В тот раз, когда я ставил raid1+grub (месяца 4 назад, вроде бы), vsu@ говорил, 
> что в lilo это не работает. Сам понимаешь, не доверять ему я не могу. :)
Всё работает, я лично проверял месяца три назад.

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и LILO

[Anton Gorlov]

Michael Shigorin пишет:

> Последний раз проверял летом -- насколько помню, именно
> выдёргиванием дисков; работало.  Надо бы ещё раз проверить,
> впрочем скоро всё равно придётся.
> 

Раотает.. главное не забыть добавить чтото типа
disk=/dev/hda
bios=0x80
disk=/dev/hdc
bios=0x80

Чтоб загрузиться можно было с любого из...

Re: [devel] GRUB и сородичи

[Epiphanov Sergei]

В сообщении от Wednesday 20 December 2006 11:09 Anton Farygin написал(a):
> Но вот основная задача - сборка его на x86_64 пока не выполнима по
> причине сломанного флага -m32 в нашей сборочной среде для x86_64.

А можно хотя бы в двух словах, почему сломано? Нагуглить ответа я не смог.

-- 
С уважением, Епифанов Сергей

Re: [devel] GRUB и сородичи

[Anton Farygin]

Epiphanov Sergei wrote:
> В сообщении от Wednesday 20 December 2006 11:09 Anton Farygin написал(a):
>> Но вот основная задача - сборка его на x86_64 пока не выполнима по
>> причине сломанного флага -m32 в нашей сборочной среде для x86_64.
> 
> А можно хотя бы в двух словах, почему сломано? Нагуглить ответа я не смог.
> 

Это уже обсуждалось. Потому что не собрано до конца:
1) glibckernheaders должны включать заголовки для x86 на x86_64
2) glibc должен быть собран biarch
3) gcc наверное тоже надо как-то этак собрать


Rgds,
Rider

Re: [devel] GRUB и сородичи

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

On Thu, Dec 21, 2006 at 01:13:06PM +0300, Anton Farygin wrote:
> Epiphanov Sergei wrote:
> > В сообщении от Wednesday 20 December 2006 11:09 Anton Farygin написал(a):
> >> Но вот основная задача - сборка его на x86_64 пока не выполнима по
> >> причине сломанного флага -m32 в нашей сборочной среде для x86_64.
> > 
> > А можно хотя бы в двух словах, почему сломано? Нагуглить ответа я не смог.
> > 
> Это уже обсуждалось. Потому что не собрано до конца:
> 1) glibckernheaders должны включать заголовки для x86 на x86_64
> 2) glibc должен быть собран biarch
> 3) gcc наверное тоже надо как-то этак собрать

Я бы сказал что не сломано а не реализовано:
- Каждый пакет с .h-файлами должен содержать специальную магию (в каждом
  файле) для того чтобы эти заголовки можно было использовать для biarch.
- В glibc/gcc нужно специальным образом раскладывать файлы.
- В rpm нужно бэкпортить код для поддержки установки одноимённых пакетов
  под разные архитектуры.

Думаю что проще исправить сборку любого пакета чем реализовывать всё это.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и сородичи

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

On Thu, Dec 21, 2006 at 02:30:14PM +0300, Dmitry V. Levin wrote:
> On Thu, Dec 21, 2006 at 01:13:06PM +0300, Anton Farygin wrote:
> > Epiphanov Sergei wrote:
> > > В сообщении от Wednesday 20 December 2006 11:09 Anton Farygin написал(a):
> > >> Но вот основная задача - сборка его на x86_64 пока не выполнима по
> > >> причине сломанного флага -m32 в нашей сборочной среде для x86_64.
> > > 
> > > А можно хотя бы в двух словах, почему сломано? Нагуглить ответа я не смог.
> > > 
> > Это уже обсуждалось. Потому что не собрано до конца:
> > 1) glibckernheaders должны включать заголовки для x86 на x86_64
> > 2) glibc должен быть собран biarch
> > 3) gcc наверное тоже надо как-то этак собрать
> 
> Я бы сказал что не сломано а не реализовано:
> - Каждый пакет с .h-файлами должен содержать специальную магию (в каждом
>   файле) для того чтобы эти заголовки можно было использовать для biarch.

Видимо, всё-таки не каждый, а содержащий arch-specific заголовки, каковых
существенно меньше (помимо заголовков ядра (которые, кстати, в последних
kernel-headers-* уже biarch) и gcc/glibc, вспоминается разве что glib, где
эти куски лежат отдельно в %_libdir).

> - В glibc/gcc нужно специальным образом раскладывать файлы.

Как я понял, в gcc это получается почти автоматически при наличии во время
его сборки правильной glibc.  Собственно, нашему gcc сейчас не хватает
только файлов 32/libgcc.* и соответствующего куска в specs (правда, я не
смотрел, что должно происходить в районе всяких libstdc++ и прочих ещё
менее нужных частей).

> - В rpm нужно бэкпортить код для поддержки установки одноимённых пакетов
>   под разные архитектуры.

Либо делать отдельные пакеты 32bit-* для нужных библиотек, которые
собирать только для x86_64.

> Думаю что проще исправить сборку любого пакета чем реализовывать всё это.

Как предполагается исправлять сборку пакета, который активно использует,
например, i386 asm (тот же grub)?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и сородичи

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2411 bytes --]

On Thu, Dec 21, 2006 at 03:10:21PM +0300, Sergey Vlasov wrote:
> On Thu, Dec 21, 2006 at 02:30:14PM +0300, Dmitry V. Levin wrote:
> > On Thu, Dec 21, 2006 at 01:13:06PM +0300, Anton Farygin wrote:
> > > Epiphanov Sergei wrote:
> > > > В сообщении от Wednesday 20 December 2006 11:09 Anton Farygin написал(a):
> > > >> Но вот основная задача - сборка его на x86_64 пока не выполнима по
> > > >> причине сломанного флага -m32 в нашей сборочной среде для x86_64.
> > > > 
> > > > А можно хотя бы в двух словах, почему сломано? Нагуглить ответа я не смог.
> > > > 
> > > Это уже обсуждалось. Потому что не собрано до конца:
> > > 1) glibckernheaders должны включать заголовки для x86 на x86_64
> > > 2) glibc должен быть собран biarch
> > > 3) gcc наверное тоже надо как-то этак собрать
> > 
> > Я бы сказал что не сломано а не реализовано:
> > - Каждый пакет с .h-файлами должен содержать специальную магию (в каждом
> >   файле) для того чтобы эти заголовки можно было использовать для biarch.
> 
> Видимо, всё-таки не каждый, а содержащий arch-specific заголовки, каковых
> существенно меньше

Их несущественно меньше.  Для такого пакета как grub особенно.

> (помимо заголовков ядра (которые, кстати, в последних
> kernel-headers-* уже biarch)

У нас ещё нет последних kernel-headers по умолчанию (вместо
glibc-kernheaders и пр.).

> > - В glibc/gcc нужно специальным образом раскладывать файлы.
> 
> Как я понял, в gcc это получается почти автоматически при наличии во время
> его сборки правильной glibc.

Нет, помимо 32-битного glibc нужны 32-битные куски gcc.

> Собственно, нашему gcc сейчас не хватает
> только файлов 32/libgcc.* и соответствующего куска в specs (правда, я не
> смотрел, что должно происходить в районе всяких libstdc++ и прочих ещё
> менее нужных частей).

И crt*; грубо говоря, нужен весь /usr/lib/gcc/i586-alt-linux/4.1.1/

> > - В rpm нужно бэкпортить код для поддержки установки одноимённых пакетов
> >   под разные архитектуры.
> 
> Либо делать отдельные пакеты 32bit-* для нужных библиотек, которые
> собирать только для x86_64.

В SuSE так делают, кажется.

> > Думаю что проще исправить сборку любого пакета чем реализовывать всё это.
> 
> Как предполагается исправлять сборку пакета, который активно использует,
> например, i386 asm (тот же grub)?

Собирать эти куски нативно на i386 и потом использовать.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и сородичи

[Anton Farygin]

Dmitry V. Levin wrote:
> On Thu, Dec 21, 2006 at 03:10:21PM +0300, Sergey Vlasov wrote:
>> On Thu, Dec 21, 2006 at 02:30:14PM +0300, Dmitry V. Levin wrote:
>>> On Thu, Dec 21, 2006 at 01:13:06PM +0300, Anton Farygin wrote:
>>>> Epiphanov Sergei wrote:
>>>>> В сообщении от Wednesday 20 December 2006 11:09 Anton Farygin написал(a):
>>>>>> Но вот основная задача - сборка его на x86_64 пока не выполнима по
>>>>>> причине сломанного флага -m32 в нашей сборочной среде для x86_64.
>>>>> А можно хотя бы в двух словах, почему сломано? Нагуглить ответа я не смог.
>>>>>
>>>> Это уже обсуждалось. Потому что не собрано до конца:
>>>> 1) glibckernheaders должны включать заголовки для x86 на x86_64
>>>> 2) glibc должен быть собран biarch
>>>> 3) gcc наверное тоже надо как-то этак собрать
>>> Я бы сказал что не сломано а не реализовано:
>>> - Каждый пакет с .h-файлами должен содержать специальную магию (в каждом
>>>   файле) для того чтобы эти заголовки можно было использовать для biarch.
>> Видимо, всё-таки не каждый, а содержащий arch-specific заголовки, каковых
>> существенно меньше
> 
> Их несущественно меньше.  Для такого пакета как grub особенно.

Помимо grub вылезает ещё кусочек пакетов...

по памяти - wine на x86_64 для 32bit, плагин для firefox, позволяющий
запускать 32bit linux плагины... и т.д.

> 
>> (помимо заголовков ядра (которые, кстати, в последних
>> kernel-headers-* уже biarch)
> 
> У нас ещё нет последних kernel-headers по умолчанию (вместо
> glibc-kernheaders и пр.).

лично сам отрывал biarch из linux-libc-headers.. в общем это не так
сложно ;)

> 
>>> - В glibc/gcc нужно специальным образом раскладывать файлы.
>> Как я понял, в gcc это получается почти автоматически при наличии во время
>> его сборки правильной glibc.
> 
> Нет, помимо 32-битного glibc нужны 32-битные куски gcc.
> 
>> Собственно, нашему gcc сейчас не хватает
>> только файлов 32/libgcc.* и соответствующего куска в specs (правда, я не
>> смотрел, что должно происходить в районе всяких libstdc++ и прочих ещё
>> менее нужных частей).
> 
> И crt*; грубо говоря, нужен весь /usr/lib/gcc/i586-alt-linux/4.1.1/
> 
>>> - В rpm нужно бэкпортить код для поддержки установки одноимённых пакетов
>>>   под разные архитектуры.
>> Либо делать отдельные пакеты 32bit-* для нужных библиотек, которые
>> собирать только для x86_64.
> 
> В SuSE так делают, кажется.

Да, и по моему не только в SuSE. Это вообще распространённый подход.

> 
>>> Думаю что проще исправить сборку любого пакета чем реализовывать всё это.
>> Как предполагается исправлять сборку пакета, который активно использует,
>> например, i386 asm (тот же grub)?
> 
> Собирать эти куски нативно на i386 и потом использовать.

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

Rgds,
Rider

Re: [devel] GRUB и сородичи

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

On Thu, Dec 21, 2006 at 03:50:52PM +0300, Anton Farygin wrote:
> Dmitry V. Levin wrote:
[...]
> > У нас ещё нет последних kernel-headers по умолчанию (вместо
> > glibc-kernheaders и пр.).
> 
> лично сам отрывал biarch из linux-libc-headers.. в общем это не так
> сложно ;)

Да, отрывать действительно несложно. :)

[...]
> >>> - В rpm нужно бэкпортить код для поддержки установки одноимённых пакетов
> >>>   под разные архитектуры.
> >> Либо делать отдельные пакеты 32bit-* для нужных библиотек, которые
> >> собирать только для x86_64.
> > 
> > В SuSE так делают, кажется.
> 
> Да, и по моему не только в SuSE. Это вообще распространённый подход.

В SuSE действительно так делают, а в FC делают иначе.
Кто ещё так делает?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и сородичи

[Epiphanov Sergei]

В сообщении от Thursday 21 December 2006 15:22 Dmitry V. Levin написал(a):
> On Thu, Dec 21, 2006 at 03:10:21PM +0300, Sergey Vlasov wrote:
> > On Thu, Dec 21, 2006 at 02:30:14PM +0300, Dmitry V. Levin wrote:
> > > On Thu, Dec 21, 2006 at 01:13:06PM +0300, Anton Farygin wrote:
...
> > (помимо заголовков ядра (которые, кстати, в последних
> > kernel-headers-* уже biarch)
>
> У нас ещё нет последних kernel-headers по умолчанию (вместо
> glibc-kernheaders и пр.).
>
> > > - В glibc/gcc нужно специальным образом раскладывать файлы.
> >
> > Как я понял, в gcc это получается почти автоматически при наличии во
> > время его сборки правильной glibc.
>
> Нет, помимо 32-битного glibc нужны 32-битные куски gcc.

А почему такое жёсткое разделение? Невозможно проверсти повторную сборку под 
32бит и запаковать?

> > Собственно, нашему gcc сейчас не хватает
> > только файлов 32/libgcc.* и соответствующего куска в specs (правда, я не
> > смотрел, что должно происходить в районе всяких libstdc++ и прочих ещё
> > менее нужных частей).
>
> И crt*; грубо говоря, нужен весь /usr/lib/gcc/i586-alt-linux/4.1.1/

А что мешает собирать этот кусок? Собрали же как-то 64-битную платформу на 
32-битной. ;)

> > > - В rpm нужно бэкпортить код для поддержки установки одноимённых
> > > пакетов под разные архитектуры.
> >
> > Либо делать отдельные пакеты 32bit-* для нужных библиотек, которые
> > собирать только для x86_64.
>
> В SuSE так делают, кажется.

Кстати, кто сейчас на x86_64, как используете 32-битную glibc? Она прописана 
в базе rpm или просто валяются библиотеки? Если в базе, то нет ли 
перечечений по программам?

> > > Думаю что проще исправить сборку любого пакета чем реализовывать всё
> > > это.
> >
> > Как предполагается исправлять сборку пакета, который активно использует,
> > например, i386 asm (тот же grub)?
>
> Собирать эти куски нативно на i386 и потом использовать.

То есть собирать у себя пакет статически и потом просто завернуть в оболочку 
x86_64?

Думал, можно обойтись малой кровью. :( Интересно, а что мешает попробовать 
собрать grub без этого ключа? Программирование на asm?

Прошу прощения за странные вопросы.

-- 
С уважением, Епифанов Сергей

Re: [devel] GRUB и сородичи

[Led]

В сообщении от 21 декабря 2006 16:12 Epiphanov Sergei написал(a):

> Кстати, кто сейчас на x86_64, как используете 32-битную glibc? Она
> прописана в базе rpm или просто валяются библиотеки? Если в базе, то нет ли
> перечечений по программам?

В базе, пересечений нет, с Allow-Duplicated

-- 
Led.

Re: [devel] GRUB и сородичи

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2399 bytes --]

On Thu, Dec 21, 2006 at 05:12:19PM +0300, Epiphanov Sergei wrote:
> В сообщении от Thursday 21 December 2006 15:22 Dmitry V. Levin написал(a):
> > On Thu, Dec 21, 2006 at 03:10:21PM +0300, Sergey Vlasov wrote:
> > > On Thu, Dec 21, 2006 at 02:30:14PM +0300, Dmitry V. Levin wrote:
[...]
> > > > - В glibc/gcc нужно специальным образом раскладывать файлы.
> > >
> > > Как я понял, в gcc это получается почти автоматически при наличии во
> > > время его сборки правильной glibc.
> >
> > Нет, помимо 32-битного glibc нужны 32-битные куски gcc.
> 
> А почему такое жёсткое разделение? Невозможно проверсти повторную сборку под 
> 32бит и запаковать?

Такой biarch придумали.

> > > Собственно, нашему gcc сейчас не хватает
> > > только файлов 32/libgcc.* и соответствующего куска в specs (правда, я не
> > > смотрел, что должно происходить в районе всяких libstdc++ и прочих ещё
> > > менее нужных частей).
> >
> > И crt*; грубо говоря, нужен весь /usr/lib/gcc/i586-alt-linux/4.1.1/
> 
> А что мешает собирать этот кусок?

Этот кусок есть в нативном 32-битном пакете, но его нельзя поставить
одновременно с нативным 64-битным пакетом - нужно переразбивать пакеты.

> Собрали же как-то 64-битную платформу на 32-битной. ;)

Кувалдой и сопутствующими материалами.

> > > > - В rpm нужно бэкпортить код для поддержки установки одноимённых
> > > > пакетов под разные архитектуры.
> > >
> > > Либо делать отдельные пакеты 32bit-* для нужных библиотек, которые
> > > собирать только для x86_64.
> >
> > В SuSE так делают, кажется.
> 
> Кстати, кто сейчас на x86_64, как используете 32-битную glibc?

Либо в hasher'е, либо в контейнере.

> Она прописана 
> в базе rpm или просто валяются библиотеки? Если в базе, то нет ли 
> перечечений по программам?

Есть.

> > > > Думаю что проще исправить сборку любого пакета чем реализовывать всё
> > > > это.
> > >
> > > Как предполагается исправлять сборку пакета, который активно использует,
> > > например, i386 asm (тот же grub)?
> >
> > Собирать эти куски нативно на i386 и потом использовать.
> 
> То есть собирать у себя пакет статически и потом просто завернуть в оболочку 
> x86_64?

Зачем статически?

> Думал, можно обойтись малой кровью. :( Интересно, а что мешает попробовать 
> собрать grub без этого ключа? Программирование на asm?

Сергей сказал, что там есть i386 asm.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и сородичи

[Epiphanov Sergei]

В сообщении от Thursday 21 December 2006 17:39 Dmitry V. Levin написал(a):
> On Thu, Dec 21, 2006 at 05:12:19PM +0300, Epiphanov Sergei wrote:
> > В сообщении от Thursday 21 December 2006 15:22 Dmitry V. Levin 
написал(a):
> > > On Thu, Dec 21, 2006 at 03:10:21PM +0300, Sergey Vlasov wrote:
> > > > On Thu, Dec 21, 2006 at 02:30:14PM +0300, Dmitry V. Levin wrote:
>
> [...]
>
> > > > > - В glibc/gcc нужно специальным образом раскладывать файлы.
> > > >
> > > > Как я понял, в gcc это получается почти автоматически при наличии во
> > > > время его сборки правильной glibc.
> > >
> > > Нет, помимо 32-битного glibc нужны 32-битные куски gcc.
> >
> > А почему такое жёсткое разделение? Невозможно проверсти повторную сборку
> > под 32бит и запаковать?
>
> Такой biarch придумали.

Наша задумка? Жалко...

> > > > Собственно, нашему gcc сейчас не хватает
> > > > только файлов 32/libgcc.* и соответствующего куска в specs (правда,
> > > > я не смотрел, что должно происходить в районе всяких libstdc++ и
> > > > прочих ещё менее нужных частей).
> > >
> > > И crt*; грубо говоря, нужен весь /usr/lib/gcc/i586-alt-linux/4.1.1/
> >
> > А что мешает собирать этот кусок?
>
> Этот кусок есть в нативном 32-битном пакете, но его нельзя поставить
> одновременно с нативным 64-битным пакетом - нужно переразбивать пакеты.

Провести бы переразбивку... А то тянет на VmWare и другие программы. ;)

> > Кстати, кто сейчас на x86_64, как используете 32-битную glibc?
> > Она прописана
> > в базе rpm или просто валяются библиотеки? Если в базе, то нет ли
> > перечечений по программам?
>
> Есть.

Так я и понял. Тогда непонятно на wiki, которую я прочитал раз десять, как у 
автора обе версии ужились в apt.

> > > > > Думаю что проще исправить сборку любого пакета чем реализовывать
> > > > > всё это.
> > > >
> > > > Как предполагается исправлять сборку пакета, который активно
> > > > использует, например, i386 asm (тот же grub)?
> > >
> > > Собирать эти куски нативно на i386 и потом использовать.
> >
> > То есть собирать у себя пакет статически и потом просто завернуть в
> > оболочку x86_64?
>
> Зачем статически?

Ну, чтобы не искать 32-битные glibc, libstdc++ и иже с ними. И не бояться, 
что grub помашет ручкой на прощание. Или все нужные ему библиотеки ввернуть 
в пакет grub вместе с их зависимостями?

> > Думал, можно обойтись малой кровью. :( Интересно, а что мешает
> > попробовать собрать grub без этого ключа? Программирование на asm?
>
> Сергей сказал, что там есть i386 asm.

Вот только насколько оно привязано именно к i386 и к 32-битному полю?.. 
Неужели так жёстко, что сборка под 64-бит рушит сам процесс работы grub? 
Жаль, не на чем проверить...

-- 
С уважением, Епифанов Сергей

Re: [devel] GRUB и сородичи

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

On Thu, Dec 21, 2006 at 05:39:06PM +0300, Dmitry V. Levin wrote:
> > > > Как предполагается исправлять сборку пакета, который активно использует,
> > > > например, i386 asm (тот же grub)?
> > >
> > > Собирать эти куски нативно на i386 и потом использовать.
> > 
> > То есть собирать у себя пакет статически и потом просто завернуть в оболочку 
> > x86_64?
> 
> Зачем статически?

А в каком виде тащить туда glibc и прочие куски?

> > Думал, можно обойтись малой кровью. :( Интересно, а что мешает попробовать 
> > собрать grub без этого ключа? Программирование на asm?
> 
> Сергей сказал, что там есть i386 asm.

Вообще, если выкинуть патч gfxboot, этого асма там остаётся не очень
много, а вот засовывания указателей в int и обратно - очень :(

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [jt] GRUB и сородичи

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

On Thu, Dec 21, 2006 at 06:15:04PM +0300, Epiphanov Sergei wrote:
> В сообщении от Thursday 21 December 2006 17:39 Dmitry V. Levin написал(a):
> > On Thu, Dec 21, 2006 at 05:12:19PM +0300, Epiphanov Sergei wrote:
> > > В сообщении от Thursday 21 December 2006 15:22 Dmitry V. Levin 
> написал(a):
> > > > On Thu, Dec 21, 2006 at 03:10:21PM +0300, Sergey Vlasov wrote:
> > > > > On Thu, Dec 21, 2006 at 02:30:14PM +0300, Dmitry V. Levin wrote:
> >
> > [...]
> >
> > > > > > - В glibc/gcc нужно специальным образом раскладывать файлы.
> > > > >
> > > > > Как я понял, в gcc это получается почти автоматически при наличии во
> > > > > время его сборки правильной glibc.
> > > >
> > > > Нет, помимо 32-битного glibc нужны 32-битные куски gcc.
> > >
> > > А почему такое жёсткое разделение? Невозможно проверсти повторную сборку
> > > под 32бит и запаковать?
> >
> > Такой biarch придумали.
> 
> Наша задумка? Жалко...

Нет, biarch нехорошие люди придумали.
Мы, конечно, тоже ничего, но не настолько. :)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и сородичи

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

On Thu, Dec 21, 2006 at 06:15:04PM +0300, Epiphanov Sergei wrote:
> > > Думал, можно обойтись малой кровью. :( Интересно, а что мешает
> > > попробовать собрать grub без этого ключа? Программирование на asm?
> >
> > Сергей сказал, что там есть i386 asm.
> 
> Вот только насколько оно привязано именно к i386 и к 32-битному полю?.. 
> Неужели так жёстко, что сборка под 64-бит рушит сам процесс работы grub? 
> Жаль, не на чем проверить...

Собственно загрузчик (/boot/grub/stage*) всегда собирается с -m32, и
с этой частью особых проблем нет (кроме необходимости костылей в
configure для объезда невозможности линковки с -m32, а также
исправления нескольких ошибок в Makefile.am).  Проблема в
невозможности собрать /usr/sbin/grub (кстати, а почему он лежит в
/usr?), в результате grub нечем установить на диск при запущенной
системе.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и сородичи

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]

On Thu, Dec 21, 2006 at 06:42:43PM +0300, Sergey Vlasov wrote:
> On Thu, Dec 21, 2006 at 06:15:04PM +0300, Epiphanov Sergei wrote:
> > > > Думал, можно обойтись малой кровью. :( Интересно, а что мешает
> > > > попробовать собрать grub без этого ключа? Программирование на asm?
> > >
> > > Сергей сказал, что там есть i386 asm.
> > 
> > Вот только насколько оно привязано именно к i386 и к 32-битному полю?.. 
> > Неужели так жёстко, что сборка под 64-бит рушит сам процесс работы grub? 
> > Жаль, не на чем проверить...
> 
> Собственно загрузчик (/boot/grub/stage*) всегда собирается с -m32, и
> с этой частью особых проблем нет (кроме необходимости костылей в
> configure для объезда невозможности линковки с -m32, а также
> исправления нескольких ошибок в Makefile.am).

Т.е. там не нужен -m32?

> Проблема в
> невозможности собрать /usr/sbin/grub (кстати, а почему он лежит в
> /usr?), в результате grub нечем установить на диск при запущенной
> системе.

Кто бы мне объяснил, зачем нужен -m32 в /usr/sbin/grub?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и сородичи

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 11880 bytes --]

On Thu, Dec 21, 2006 at 06:46:57PM +0300, Dmitry V. Levin wrote:
> On Thu, Dec 21, 2006 at 06:42:43PM +0300, Sergey Vlasov wrote:
> > On Thu, Dec 21, 2006 at 06:15:04PM +0300, Epiphanov Sergei wrote:
> > > > > Думал, можно обойтись малой кровью. :( Интересно, а что мешает
> > > > > попробовать собрать grub без этого ключа? Программирование на asm?
> > > >
> > > > Сергей сказал, что там есть i386 asm.
> > > 
> > > Вот только насколько оно привязано именно к i386 и к 32-битному полю?.. 
> > > Неужели так жёстко, что сборка под 64-бит рушит сам процесс работы grub? 
> > > Жаль, не на чем проверить...
> > 
> > Собственно загрузчик (/boot/grub/stage*) всегда собирается с -m32, и
> > с этой частью особых проблем нет (кроме необходимости костылей в
> > configure для объезда невозможности линковки с -m32, а также
> > исправления нескольких ошибок в Makefile.am).
> 
> Т.е. там не нужен -m32?

Как раз нужен - проблема в том, что с нашим gcc не проходят тесты в
configure из-за того, что делается попытка собрать бинарник с -m32;
приходится обходить это хаками.

--- grub-0.97/stage2/Makefile.am.alt-x86_64-m32	2006-07-21 11:02:14 +0400
+++ grub-0.97/stage2/Makefile.am	2006-07-21 11:09:07 +0400
@@ -55,11 +55,11 @@
 endif
 MOSTLYCLEANFILES = $(noinst_PROGRAMS)
 
-PRE_STAGE2_LINK = -nostdlib -Wl,-N -Wl,-Ttext -Wl,8200
-START_LINK = -nostdlib -Wl,-N -Wl,-Ttext -Wl,8000
-NBLOADER_LINK = -nostdlib -Wl,-N -Wl,-Ttext -Wl,0
-PXELOADER_LINK = -nostdlib -Wl,-N -Wl,-Ttext -Wl,7C00
-START_ELTORITO_LINK = -nostdlib -Wl,-N -Wl,-Ttext -Wl,7C00
+PRE_STAGE2_LINK = $(STAGE2_CFLAGS) -nostdlib -Wl,-N -Wl,-Ttext -Wl,8200
+START_LINK = $(STAGE2_CFLAGS) -nostdlib -Wl,-N -Wl,-Ttext -Wl,8000
+NBLOADER_LINK = $(STAGE2_CFLAGS) -nostdlib -Wl,-N -Wl,-Ttext -Wl,0
+PXELOADER_LINK = $(STAGE2_CFLAGS) -nostdlib -Wl,-N -Wl,-Ttext -Wl,7C00
+START_ELTORITO_LINK = $(STAGE2_CFLAGS) -nostdlib -Wl,-N -Wl,-Ttext -Wl,7C00
 
 if NETBOOT_SUPPORT
 NETBOOT_FLAGS = -I$(top_srcdir)/netboot -DSUPPORT_NETBOOT=1
@@ -82,7 +82,7 @@
 STAGE2_COMPILE = $(STAGE2_CFLAGS) -fno-builtin -nostdinc \
 	$(NETBOOT_FLAGS) $(SERIAL_FLAGS) $(HERCULES_FLAGS)
 
-STAGE1_5_LINK = -nostdlib -Wl,-N -Wl,-Ttext -Wl,2000
+STAGE1_5_LINK = $(STAGE2_CFLAGS) -nostdlib -Wl,-N -Wl,-Ttext -Wl,2000
 STAGE1_5_COMPILE = $(STAGE2_COMPILE) -DNO_DECOMPRESSION=1 -DSTAGE1_5=1
 
 # For stage2 target.
--- grub-0.97/stage1/Makefile.am.alt-x86_64-m32	2006-07-21 11:02:14 +0400
+++ grub-0.97/stage1/Makefile.am	2006-07-21 11:09:33 +0400
@@ -5,7 +5,7 @@
 
 # We can't use builtins or standard includes.
 AM_CCASFLAGS = $(STAGE1_CFLAGS) -fno-builtin -nostdinc
-LDFLAGS = -nostdlib -Wl,-N,-Ttext,7C00
+LDFLAGS = $(STAGE1_CFLAGS) -nostdlib -Wl,-N,-Ttext,7C00
 
 noinst_PROGRAMS = stage1.exec
 stage1_exec_SOURCES = stage1.S stage1.h
--- grub-0.97/configure.ac.alt-x86_64-m32	2005-05-08 06:36:03 +0400
+++ grub-0.97/configure.ac	2006-07-21 11:02:15 +0400
@@ -47,7 +47,9 @@
 fi
 
 if test "x$host_cpu" = xx86_64; then
-  CFLAGS="-m32 $CFLAGS"
+  M32_FLAG="-m32 -nodefaultlibs"
+else
+  M32_FLAG=
 fi
 
 #
@@ -84,7 +86,7 @@
     if test "x$with_binutils" != x; then
       CFLAGS="-B$with_binutils/ $CFLAGS"
     fi
-    STAGE1_CFLAGS="-O2"
+    STAGE1_CFLAGS="$M32_FLAG -O2"
     GRUB_CFLAGS="-O2"
     AC_CACHE_CHECK([whether optimization for size works], size_flag, [
       saved_CFLAGS=$CFLAGS
@@ -97,6 +99,7 @@
     else
       STAGE2_CFLAGS="-O2 -fno-strength-reduce -fno-unroll-loops"
     fi
+    STAGE2_CFLAGS="$M32_FLAG $STAGE2_CFLAGS"
     # OpenBSD has a GCC extension for protecting applications from
     # stack smashing attacks, but GRUB doesn't want this feature.
     AC_CACHE_CHECK([whether gcc has -fno-stack-protector],
@@ -157,6 +160,9 @@
   AC_CHECK_TOOL(OBJCOPY, objcopy)
 fi
 
+grub_saved_CFLAGS="$CFLAGS"
+CFLAGS="$M32_FLAG $CFLAGS"
+
 # Defined in acinclude.m4.
 grub_ASM_USCORE
 grub_PROG_OBJCOPY_ABSOLUTE
@@ -173,6 +179,8 @@
 
 grub_ASM_ABSOLUTE_WITHOUT_ASTERISK
 
+CFLAGS="$grub_saved_CFLAGS"
+
 grub_CHECK_START_SYMBOL
 grub_CHECK_USCORE_START_SYMBOL
 if test "x$grub_cv_check_start_symbol" != "xyes" \




--- grub-0.97/stage2/disk_io.c.alt-x86_64-build	2006-07-21 10:58:25 +0400
+++ grub-0.97/stage2/disk_io.c	2006-07-21 10:58:25 +0400
@@ -130,7 +130,7 @@
 static inline unsigned long
 grub_log2 (unsigned long word)
 {
-  asm volatile ("bsfl %1,%0"
+  asm volatile ("bsf %1,%0"
 		: "=r" (word)
 		: "r" (word));
   return word;
--- grub-0.97/stage2/fsys_ext2fs.c.alt-x86_64-build	2006-07-21 10:58:25 +0400
+++ grub-0.97/stage2/fsys_ext2fs.c	2006-07-21 10:58:25 +0400
@@ -242,7 +242,7 @@
 static __inline__ unsigned long
 ffz (unsigned long word)
 {
-  __asm__ ("bsfl %1,%0"
+  __asm__ ("bsf %1,%0"
 :	   "=r" (word)
 :	   "r" (~word));
   return word;
--- grub-0.97/stage2/fsys_fat.c.alt-x86_64-build	2006-07-21 10:58:25 +0400
+++ grub-0.97/stage2/fsys_fat.c	2006-07-21 10:58:25 +0400
@@ -57,7 +57,7 @@
 static __inline__ unsigned long
 grub_log2 (unsigned long word)
 {
-  __asm__ ("bsfl %1,%0"
+  __asm__ ("bsf %1,%0"
 	   : "=r" (word)
 	   : "r" (word));
   return word;
--- grub-0.97/stage2/fsys_iso9660.c.alt-x86_64-build	2006-07-21 10:58:25 +0400
+++ grub-0.97/stage2/fsys_iso9660.c	2006-07-21 10:58:25 +0400
@@ -59,7 +59,7 @@
 static inline unsigned long
 grub_log2 (unsigned long word)
 {
-  asm volatile ("bsfl %1,%0"
+  asm volatile ("bsf %1,%0"
 		:          "=r" (word)
 		:          "r" (word));
   return word;
--- grub-0.97/stage2/fsys_reiserfs.c.alt-x86_64-build	2006-07-21 10:58:25 +0400
+++ grub-0.97/stage2/fsys_reiserfs.c	2006-07-21 10:58:25 +0400
@@ -369,7 +369,7 @@
 static __inline__ unsigned long
 grub_log2 (unsigned long word)
 {
-  __asm__ ("bsfl %1,%0"
+  __asm__ ("bsf %1,%0"
 	   : "=r" (word)
 	   : "r" (word));
   return word;
--- grub-0.97/stage2/fsys_xfs.c.alt-x86_64-build	2005-05-08 06:15:55 +0400
+++ grub-0.97/stage2/fsys_xfs.c	2006-07-21 10:58:25 +0400
@@ -100,26 +100,16 @@
 static inline __const__ xfs_uint16_t
 le16 (xfs_uint16_t x)
 {
-	__asm__("xchgb %b0,%h0"	\
-		: "=q" (x) \
-		:  "0" (x)); \
-		return x;
+	return ((x & 0x00ff) << 8) | ((x & 0xff00) >> 8 );
 }
 
 static inline __const__ xfs_uint32_t
 le32 (xfs_uint32_t x)
 {
-#if 0
-        /* 386 doesn't have bswap.  */
-	__asm__("bswap %0" : "=r" (x) : "0" (x));
-#else
-	/* This is slower but this works on all x86 architectures.  */
-	__asm__("xchgb %b0, %h0" \
-		"\n\troll $16, %0" \
-		"\n\txchgb %b0, %h0" \
-		: "=q" (x) : "0" (x));
-#endif
-	return x;
+	return (((x & 0x000000ffUL) << 24) |
+		((x & 0x0000ff00UL) << 8) |
+		((x & 0x00ff0000UL) >> 8) |
+		((x & 0xff000000UL) >> 24));
 }
 
 static inline __const__ xfs_uint64_t
--- grub-0.97/stage2/smp-imps.c.alt-x86_64-build	2005-02-02 23:36:00 +0300
+++ grub-0.97/stage2/smp-imps.c	2006-07-21 11:01:30 +0400
@@ -270,7 +270,7 @@
 /*
  *  This contains the local APIC hardware address.
  */
-static unsigned imps_lapic_addr = ((unsigned) (&lapic_dummy)) - LAPIC_ID;
+static unsigned long imps_lapic_addr = ((unsigned long) (&lapic_dummy)) - LAPIC_ID;
 /*
  *  These map from virtual cpu numbers to APIC id's and back.
  */
--- grub-0.97/grub/asmstub.c.alt-x86_64-build	2006-07-21 10:58:25 +0400
+++ grub-0.97/grub/asmstub.c	2006-07-21 10:58:25 +0400
@@ -105,6 +105,12 @@
 static unsigned int serial_speed;
 #endif /* SIMULATE_SLOWNESS_OF_SERIAL */
 
+#ifdef __x86_64__
+#define SP_REG		"rsp"
+#else
+#define SP_REG		"esp"
+#endif
+
 /* The main entry point into this mess. */
 int
 grub_stage2 (void)
@@ -122,7 +128,7 @@
   void doit (void)
     {
       /* Make sure our stack lives in the simulated memory area. */
-      asm volatile ("movl %%esp, %0\n\tmovl %1, %%esp\n"
+      asm volatile ("mov %%" SP_REG ", %0\n\tmov %1, %%" SP_REG "\n"
 		    : "=&r" (realstack) : "r" (simstack));
       
       /* Do a setjmp here for the stop command.  */
@@ -140,7 +146,7 @@
 	}
       
       /* Replace our stack before we use any local variables. */
-      asm volatile ("movl %0, %%esp\n" : : "r" (realstack));
+      asm volatile ("mov %0, %%" SP_REG "\n" : : "r" (realstack));
     }
 
   assert (grub_scratch_mem == 0);



--- grub-0.97-alt2/grub.spec	2006-05-31 11:51:47 +0000
+++ grub-0.97-alt2.0.1/grub.spec	2006-07-21 06:58:22 +0000
@@ -1,11 +1,11 @@
 Name: grub
 Version: 0.97
-Release: alt2
+Release: alt2.0.1
 
 Summary: GRand Unified Bootloader
 License: GPL
 Group: System/Kernel and hardware
-Exclusivearch: %ix86
+Exclusivearch: %ix86 x86_64
 
 Source: ftp://alpha.gnu.org/gnu/grub/%name-%version.tar
 #"grubonce" is script to demonstrate & ease "savedefault --once"
@@ -46,12 +46,15 @@ Patch223:        stage2-wildcard-doc.dif
 Patch224:        grub-%{version}-protexec.patch
 Patch299:        grub-0.97-stackptr.diff
 
+Patch1000:	grub-0.97-alt-x86_64-m32.patch
+Patch1001:	grub-0.97-alt-x86_64-build.patch
 
 Provides: %name-doc = %version, %name-graph = %version
 Obsoletes: %name-doc, %name-graph
 
 # Automatically added by buildreq on Wed May 31 2006
-BuildRequires: libncurses-devel reiser4progs-minimal-devel tetex-latex
+BuildRequires: libncurses-devel tetex-latex
+# reiser4progs-minimal-devel
 
 %package utils
 Group: System/Kernel and hardware
@@ -81,8 +84,8 @@ Additional utilites for %name
 #%patch5 -p1
 %patch6 -p1
 %patch7 -p1
-%patch8 -p1
-%patch9 -p1
+#%patch8 -p1
+#%patch9 -p1
 #SuSE:
 
 rm -f acconfig.h || true
@@ -90,7 +93,7 @@ rm -f acconfig.h || true
 %patch201
 %patch202 -p1
 %patch203 -p1
-%patch204 -p1
+###%patch204 -p1
 %patch205 -p1
 %patch206 -p1
 %patch207 -p1
@@ -99,15 +102,18 @@ rm -f acconfig.h || true
 %patch210 -p1
 %patch211 -p1
 %patch212 -p1
-%patch213
-%patch214
+###%patch213
+###%patch214
 # Disable the wildcard feature
 #%patch220 -p1
 #%patch221 -p1
 #%patch222 -p1
 #%patch223 -p1
 %patch224 -p1
-%patch299
+###%patch299
+
+%patch1000 -p1 -b .alt-x86_64-m32
+%patch1001 -p1 -b .alt-x86_64-build
 
 %build
 #rm -rf configure
@@ -117,12 +123,15 @@ rm -f acconfig.h || true
 aclocal && autoheader && autoconf && automake --add-missing
 ###
 
-#%ifarch x86_64
-#  EXTRACFLAGS=' -fno-strict-aliasing -minline-all-stringops -m32 -fno-asynchronous-unwind-tables '
-#%else
+%ifarch x86_64
+  EXTRACFLAGS=' -fno-strict-aliasing -minline-all-stringops -fno-asynchronous-unwind-tables '
+  STAGEx_CFLAGS=' -m32 '
+%else
 EXTRACFLAGS=' -fno-strict-aliasing -minline-all-stringops'
-#%endif  
-CFLAGS="$RPM_OPT_FLAGS -Os -DNDEBUG -W -Wall -Wpointer-arith $EXTRACFLAGS" ./configure \
+  STAGEx_CFLAGS=
+%endif  
+CFLAGS="$RPM_OPT_FLAGS -Os -DNDEBUG -W -Wall -Wpointer-arith $EXTRACFLAGS" \
+STAGE1_CFLAGS="$STAGEx_CFLAGS" STAGE2_CFLAGS="$STAGEx_CFLAGS" ./configure \
   --prefix=/usr --infodir=%{_infodir} --mandir=%{_mandir} --datadir=%{_datadir} \
   --libexecdir=%{_libexecdir} \
   --disable-auto-linux-mem-opt --enable-diskless \


Так оно делает вид, что собирается, но на самом деле не работает.

> > Проблема в невозможности собрать /usr/sbin/grub (кстати, а
> > почему он лежит в /usr?), в результате grub нечем установить на
> > диск при запущенной системе.
> 
> Кто бы мне объяснил, зачем нужен -m32 в /usr/sbin/grub?

  char *stage2_first_buffer = ...
  int i;
  ...
  i = (int) stage2_first_buffer + SECTOR_SIZE - 4;
  while (*((unsigned long *) i))
    {
      if (i < (int) stage2_first_buffer
          || (*((int *) (i - 4)) & 0x80000000)
          || *((unsigned short *) i) >= 0xA00
          || *((short *) (i + 2)) == 0)
        {
          errnum = ERR_BAD_VERSION;
          goto fail;
        }
    
      *((int *) i) = 0;
      *((int *) (i - 4)) = 0;
      i -= 8;
    }

И такого кода там куча.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и сородичи

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

On Thu, Dec 21, 2006 at 07:13:15PM +0300, Sergey Vlasov wrote:
> И такого кода там куча.

Кстати, возможно, как раз из-за подобных трюков с указателями и
наблюдается https://bugzilla.altlinux.org/show_bug.cgi?id=10319 -
эта проблема пропадает, если grub собрать более старым компилятором
(например, gcc 3.x).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и сородичи

[Epiphanov Sergei]

В сообщении от Thursday 21 December 2006 19:19 Sergey Vlasov написал(a):
> On Thu, Dec 21, 2006 at 07:13:15PM +0300, Sergey Vlasov wrote:
> > И такого кода там куча.
>
> Кстати, возможно, как раз из-за подобных трюков с указателями и
> наблюдается https://bugzilla.altlinux.org/show_bug.cgi?id=10319 -
> эта проблема пропадает, если grub собрать более старым компилятором
> (например, gcc 3.x).

Если верить документации на gcc, то можно при игре с указателями попробовать 
использовать "long int" вместо "int". По идее, ничего не должно порушиться 
на i586: 
"The 32-bit environment sets int, long and pointer to 32 bits and generates 
code that runs on any i386 system.  The 64-bit environment sets int to 32 
bits and long and pointer to 64 bits and generates code for AMD's x86-64 
architecture."

-- 
С уважением, Епифанов Сергей

Re: [devel] GRUB и сородичи

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 1482 bytes --]

Здравствуйте Anton Farygin
  В сообщении от Среда 20 декабря 2006 Anton Farygin написал(a):
 > >
 > > 4. Правильно ли я понял, что grub устарел в пользу grub2?
 >
 > Ильдар, на мой взгляд всё-таки grub не устарел в пользу grub2.
 >
 >
 >
 > Безусловно его надо обновлять и фиксить.
 > Но вот основная задача - сборка его на x86_64 пока не выполнима по
 >
 > причине сломанного флага -m32 в нашей сборочной среде для x86_64. е,
 > IMHO надо вместо lilo использовать grub по умолчанию, ибо 
 > тот же
 > xen без него не работает.

За это время что-нибудь изменилось ?
Посмотрел Spec в Suse - там :

BuildRequires: aaa_base ......
.....
% строк
....
 glibc-32bit glibc-devel-32bit libtool ncurses-32bit ncurses-devel-32bit 
......

1 Это как-нибудь можно организовать ?
В смысле если буду собирать для себя - просто кину эти библиотеки и 
хидеры в сборочный каталог или положу эти пакеты в x86_common прикреплю 
к apt (первая мысль), а вот как системно и правильно это сделать?
2 А можно использовать 32-х битный grub, собранный через setarch i386 ?
Вроде grub загружается первым, какая ему разница какое ядро он
 загрузит ?



PS Давно хочу попробовать xen :), например для запуска ядра MCBC  и 
других старых ядер и дистрибутивов в среде ALTLinux :)


-- 
  А ещё говорят так  (fortune):
 
Be frank and explicit with your lawyer ... it is his business to confuse
the issue afterwards.
________________________________________________________________________
С уважением Хихин Руслан

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и сородичи

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]

Здравствуйте Anton Farygin
  В сообщении от Среда 20 декабря 2006 Anton Farygin написал(a):
 > >
 > > 4. Правильно ли я понял, что grub устарел в пользу grub2?
 >
 > Ильдар, на мой взгляд всё-таки grub не устарел в пользу grub2.
 >
 >
 >
 > Безусловно его надо обновлять и фиксить.
 > Но вот основная задача - сборка его на x86_64 пока не выполнима по
 >
 > причине сломанного флага -m32 в нашей сборочной среде для x86_64. е,
 > IMHO надо вместо lilo использовать grub по умолчанию, ибо 
 > тот же
 > xen без него не работает.

За это время что-нибудь изменилось ?
Посмотрел Spec в Suse - там :

BuildRequires: aaa_base ......
.....
% строк
....
 glibc-32bit glibc-devel-32bit libtool ncurses-32bit ncurses-devel-32bit 
......

1 Это как-нибудь можно организовать ?
В смысле если буду собирать для себя - просто кину эти библиотеки и 
хидеры в сборочный каталог или положу эти пакеты в x86_common прикреплю 
к apt (первая мысль), а вот как системно и правильно это сделать?
2 А можно использовать 32-х битный grub, собранный через setarch i386 ?
Вроде grub загружается первым, какая ему разница какое ядро он
 загрузит ?



PS Давно хочу попробовать xen :), например для запуска ядра MCBC  и 
других старых ядер и дистрибутивов в среде ALTLinux :)


-- 
  А ещё говорят так  (fortune):
 
Be frank and explicit with your lawyer ... it is his business to confuse
the issue afterwards.
________________________________________________________________________
С уважением Хихин Руслан
-- 
С уважением Xихин Руслан

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и сородичи

[Anton Farygin]

Hihin Ruslan wrote:
> Здравствуйте Anton Farygin
>   В сообщении от Среда 20 декабря 2006 Anton Farygin написал(a):
>  > >
>  > > 4. Правильно ли я понял, что grub устарел в пользу grub2?
>  >
>  > Ильдар, на мой взгляд всё-таки grub не устарел в пользу grub2.
>  >
>  >
>  >
>  > Безусловно его надо обновлять и фиксить.
>  > Но вот основная задача - сборка его на x86_64 пока не выполнима по
>  >
>  > причине сломанного флага -m32 в нашей сборочной среде для x86_64. е,
>  > IMHO надо вместо lilo использовать grub по умолчанию, ибо 
>  > тот же
>  > xen без него не работает.
> 
> За это время что-нибудь изменилось ?

Практически нет, за исключением того, что Петя Савельев доточил -m32 в 
gcc. Теперь ждём кто исправит rpm и тогда всё это можно втаскивать в 
Sisyphus.

> Посмотрел Spec в Suse - там :
> 
> BuildRequires: aaa_base ......
> .....
> % строк
> ....
>  glibc-32bit glibc-devel-32bit libtool ncurses-32bit ncurses-devel-32bit 
> ......
> 
> 1 Это как-нибудь можно организовать ?
> В смысле если буду собирать для себя - просто кину эти библиотеки и 
> хидеры в сборочный каталог или положу эти пакеты в x86_common прикреплю 
> к apt (первая мысль), а вот как системно и правильно это сделать?

нужно что бы RPM умел ставить libgcc.32bit. Т.е. - нужен biarch в RPM'е.


> 2 А можно использовать 32-х битный grub, собранный через setarch i386 ?
> Вроде grub загружается первым, какая ему разница какое ядро он
>  загрузит ?

Использовать можно, не не получится - для этого нужно будет установить в 
систему ещё и 32-х битный glibc.


> 
> 
> 
> PS Давно хочу попробовать xen :), например для запуска ядра MCBC  и 
> других старых ядер и дистрибутивов в среде ALTLinux :)


Я тоже ;)

Rgds,
Rider

Re: [devel] GRUB и сородичи

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

Здравствуйте Anton Farygin
  В сообщении от Четверг 05 апреля 2007 Anton Farygin написал(a):
 > > За это время что-нибудь изменилось ?
 >
 > Практически нет, за исключением того, что Петя Савельев доточил -m32
 > в gcc. Теперь ждём кто исправит rpm и тогда всё это можно втаскивать
 > в  Sisyphus.

Как я понял - если не так, то поправьте пожалуйста. Для сборки grub в 
среде x86_64 мешает не столько отсутствие biarch в rpm (путь Suse и 
иже), сколько ассемблерные (asm i386)  вставки в коде. 
Вот если я сейчас найду в инете учебник по ассемлеру и правильно заменю 
вставки на C-шные команды, то будет-ли grub (теоретически) работать 
(вариант заменить на asm x86_64?), или за этим поворотом меня ожидает 
следующая засада :) ? 

-- 
С уважением Xихин Руслан

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и сородичи

[Anton Farygin]

Hihin Ruslan wrote:
> Здравствуйте Anton Farygin
>   В сообщении от Четверг 05 апреля 2007 Anton Farygin написал(a):
>  > > За это время что-нибудь изменилось ?
>  >
>  > Практически нет, за исключением того, что Петя Савельев доточил -m32
>  > в gcc. Теперь ждём кто исправит rpm и тогда всё это можно втаскивать
>  > в  Sisyphus.
> 
> Как я понял - если не так, то поправьте пожалуйста. Для сборки grub в 
> среде x86_64 мешает не столько отсутствие biarch в rpm (путь Suse и 
> иже), сколько ассемблерные (asm i386)  вставки в коде. 
> Вот если я сейчас найду в инете учебник по ассемлеру и правильно заменю 
> вставки на C-шные команды, то будет-ли grub (теоретически) работать 
> (вариант заменить на asm x86_64?), или за этим поворотом меня ожидает 
> следующая засада :) ? 

Т.е.  - ты хочешь пойти другим путём и собрать GRUB нативно под x86_64 ?

Что-ж.. можно и так, только нужно насколько мне известно не ассемблерные 
вставки исправлять, а C-шный код фиксить.

Rgds,
Rider

Re: [devel] GRUB и сородичи

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]

On Sun, Apr 08, 2007 at 11:12:03AM +0400, Anton Farygin wrote:
> Hihin Ruslan wrote:
> > Здравствуйте Anton Farygin
> >   В сообщении от Четверг 05 апреля 2007 Anton Farygin написал(a):
> >  > > За это время что-нибудь изменилось ?
> >  >
> >  > Практически нет, за исключением того, что Петя Савельев доточил -m32
> >  > в gcc. Теперь ждём кто исправит rpm и тогда всё это можно втаскивать
> >  > в  Sisyphus.
> > 
> > Как я понял - если не так, то поправьте пожалуйста. Для сборки grub в 
> > среде x86_64 мешает не столько отсутствие biarch в rpm (путь Suse и 
> > иже), сколько ассемблерные (asm i386)  вставки в коде. 
> > Вот если я сейчас найду в инете учебник по ассемлеру и правильно заменю 
> > вставки на C-шные команды, то будет-ли grub (теоретически) работать 
> > (вариант заменить на asm x86_64?), или за этим поворотом меня ожидает 
> > следующая засада :) ? 
> 
> Т.е.  - ты хочешь пойти другим путём и собрать GRUB нативно под x86_64 ?
> 
> Что-ж.. можно и так, только нужно насколько мне известно не ассемблерные 
> вставки исправлять, а C-шный код фиксить.

Примеры кривого кода на С демонстрировал vsu@ в devel@lists несколько
месяцев назад.  У меня сложилось ощущение, что grub проще переписать,
чем исправить нативную сборку под 64-битную архитектуру.

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


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и сородичи

[Eugene Ostapets]

08.04.07, Dmitry V. Levin<ldv altlinux.org> написал(а):
> Впрочем, судя по grub2, не всякое перепеисывание grub обязательно приведёт
> к нормальной реализации поддержки 64-битной архитектуры.
Это же можно сказать по примеру xmms2... Переписывание далеко не
всегда дает нормальный результат...

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] GRUB и сородичи

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

Здравствуйте Anton Farygin
  В сообщении от Воскресенье 08 апреля 2007 Anton Farygin написал(a):
 > Т.е.  - ты хочешь пойти другим путём и собрать GRUB нативно под
 > x86_64 ?
 >
 > Что-ж.. можно и так, только нужно насколько мне известно не
 > ассемблерные
 > вставки исправлять, а C-шный код фиксить.

Да - похоже это единственный путь :)

Начал фиксить - тут конечно и C и asm - 
главное понять где нужен 32битный int, а где нужно именно слово 
(64бит) - поначалу забиваю на 32-битную совместимость - иначе в голове 
вообще сумбур будет :)

-- 
С уважением Xихин Руслан

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] GRUB и сородичи

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]

Здравствуйте Dmitry V. Levin
  В сообщении от Воскресенье 08 апреля 2007 Dmitry V. Levin написал(a):
 > Примеры кривого кода на С демонстрировал vsu@ в devel@lists
 > несколько
 > месяцев назад.  У меня сложилось ощущение, что grub проще
 > переписать,
 > чем исправить нативную сборку под 64-битную архитектуру.
 >
 >
 > Впрочем, судя по grub2, не всякое перепеисывание grub обязательно
 > приведёт
 > к нормальной реализации поддержки 64-битной архитектуры.  
В общем наверное вы правы :)

Только время на это требуется немеренно :)

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

В общем путём корректировки и неоднократных make постртроил stage1 и 
stage2 (и вылетел на построении самого grub) , а когда попытался это 
повторить через построение из спека, вылетел раньше. 

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

PS жаль, что git не освоил :) 
PPPS Знаю, что даже если соберётся - не заработает - там ещё типы 
переменных надо приводить к правильным значениям.

-- 
С уважением Xихин Руслан

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] xmms2 (was: Re: GRUB и сородичи )

[Igor Zubkov]

В сообщении от Sunday 08 April 2007 13:31:59 Eugene Ostapets написал(а):
> 08.04.07, Dmitry V. Levin<ldv altlinux.org> написал(а):
> > Впрочем, судя по grub2, не всякое перепеисывание grub обязательно
> > приведёт к нормальной реализации поддержки 64-битной архитектуры.
>
> Это же можно сказать по примеру xmms2... Переписывание далеко не
> всегда дает нормальный результат...

А чем плох xmms2? Мне немного нравится. Работает просто, памяти жрёт мало. 
Если памяти не жалко, то я бы использовал всегда amaroK. Да и вообще, в 
данном случае, алтернатив предостаточно что бы было что выбрать.

-- 
icesik

Re: [devel] xmms2 (was: Re: GRUB и сородичи )

[Eugene Ostapets]

10.04.07, Igor Zubkov<icesik mail.ru> написал(а):
> > Это же можно сказать по примеру xmms2... Переписывание далеко не
> > всегда дает нормальный результат...
>
> А чем плох xmms2? Мне немного нравится. Работает просто, памяти жрёт мало.
> Если памяти не жалко, то я бы использовал всегда amaroK. Да и вообще, в
> данном случае, алтернатив предостаточно что бы было что выбрать.
Угу... Посмотри внутрь и ужаснись... Я не видел исходники xmms1, но
переписывать все с нуля для получения xmms2 явно не стоило...

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] GRUB и сородичи

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

Здравствуйте Anton Farygin
  В сообщении от 5 апреля 2007 Anton Farygin написал(a):
 > Использовать можно, не не получится - для этого нужно будет
 > установить в
 >
 > систему ещё и 32-х битный glibc.

я тут недавно наткнулся на 
http://syslinux.zytor.com/archives/2007-May/008525.html
и сразу возникла мысль - а syslinux к Xen никак привязать нельзя ?
В частности extlinux ?


-- 
С уважением Xихин Руслан

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]