I would like to rebuild the grub package to check the effects of a patch supposed to solve a bizarre Xen-related problem on an AMI bios.

My machine is an X86_64 AMD. I first tried to rebuild the rpm from the src.rpm with rpmbuild, to make sure I can at least recreate the rpm package provided by Centos 5.1. I cannot get past that point. Those commands failed to produce a working grub executable similar to the official one that gets installed in /sbin/grub :
# rpmbuild -ba path/to/spec/file
# rpmbuild -ba --target i386 path/to/spec

Is there a place I could get the build log for the grub package (x86_64.rpm) as distributed ? Or could someone explain to me how to do it ?

Thanks in advance

Andre Gosselin

It would be helpful to see the actual errors that resulted from executing either of the two rpmbuild commands that you quoted.

I also note

Quote:

The correct format should be rpmbuild -ba --target=i386 spec-file (note the = sign).

Alan.

Quote:
Actually, either format should work.

Akemi

Apologies for my error, as pointed out by toracat.

Alan.

Here is a more precise statement of the problem. Remember that my machine is 64-bit AMD .

1- I uninstall the grub package, to start from a clean state.
2- I install the official grub-0.97-13.x86_64.rpm package. Then perform the following checks :
=======
[root@lauimldsoes04 orig]# ls -l /sbin/grub
-rwxr-xr-x 1 root root 579932 Oct 1 2006 /sbin/grub
[root@lauimldsoes04 orig]# file /sbin/grub
/sbin/grub: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, statically linked, for GNU/Linux 2.6.9, stripped
[root@lauimldsoes04 orig]# /sbin/grub
Probing devices to guess BIOS drives. This may take a long time.


GNU GRUB version 0.97 (640K lower / 3072K upper memory)

[ Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists the possible
completions of a device/filename.]
grub> quit
====

3- I rebuild the package from the grub-0.97-13.src.rpm source :
# rpmbuild --rebuild grub-0.97-13.src.rpm

This produces two binary packages : grub-0.97-13.i386.rpm and grub-0.97-13.x86_64.rpm

I omitted this time the --target=i86 argument in order to produce both 32 and 64 bit versions of the binary package. I also went straight to the --rebuild option, since it
is cleaner and simpler than specifying the spec path. I do not think it makes a difference with "--ba path/to/spec ".

4- I uninstall grub to make sure, then install the newly generated grub-0.97-13.x86_64.rpm package.
5- I reexecute the previous checks, and here is what I get :
===
[root@lauimldsoes04 redhat]# ls -l /sbin/grub
-rwxr-xr-x 1 root root 287488 Feb 3 08:13 /sbin/grub
[root@lauimldsoes04 redhat]# file /sbin/grub
/sbin/grub: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
[root@lauimldsoes04 redhat]# /sbin/grub
-bash: /sbin/grub: No such file or directory
===

Note the differences. The new /sbin/grub is not statically linked, and worst, it does not even want to execute.

6- If I uninstall grub and then install the newly generated 32bit package, I get the same picture as above.
The /sbin/grub executable is dynamically linked, but at least it executes correctly.

This is all done on the same machine and te same 64 bit RHE5.1 (Centos 5.1 if you like).

So I am surely missing something in the way I regenerate the 64bit vesion of the package. (extra options, etc)
This is why it would be interesting to see the build log of this package.

Regards,
A. Gosselin

I think I can confirm what you described. The grub executable compiled from srpm on x86_64 is not statically linked. This used to be a known problem and I thought the bug was fixed long time ago:

https://bugzilla.redhat.com/show_bug.cgi?id=121095

So, I don't know what is going on here. If you like, I can share my log file.

Akemi

Thanks for your help. Sure, I would be happy to see your logs. Does that mean that you succeeded in generating a new grub executable for 64bit OS ?

Since the 32bit executes correctly, do you think it would be safe for me to "grub" my 64-bit boot disk with this version, or would this be asking for trouble ?

Remember that the reason I am into all this is to simply try a patch to the grub code in order to see if this could help me overcome a problem with Xen kernel not
seeing all my memory. The patch is described here :
https://bugzilla.redhat.com/show_bug.cgi?id=250299

I know how to regenerate a new ".src.rpm" with this patch applied, but sadly enough I do not know how to regenerate the binary package (except the 32bit one).
Perhaps I could achieve the same result in a simpler way, but I am lost here. If you could help me, I would really appreciate it.

Regards

A. Gosselin

I have only built it on a x86_64 system but did not test it or anything. It did build the 64-bit /sbin/grub but it was not statically linked.

Could you perhaps file a bug at bugs.centos.org ? This way, it will be seen by CentOS devs as well. Make sure you include all the details you described here. In the meantime, here is my log file:

http://toracat.freeshell.org/centos/logfile.txt

Thanks,

A last detail : what was the exact command line you used ? Was it :
# rpmbuild --rebuild --target=x86_64 grub-0.97-13.src.rpm

I deeply than you for your help,

Regards,

AG

I first tried that command using mock. However it did not finish for an unknown reason. So, I installed the srpm file to see what is going on and built it by:

rpmbuild -bb --target `uname -m` grub.spec

on an x86_64 machine. The log file is from this process.

I talked with a knowledgeable person (Jeff on the centos-devel irc). He noticed in the grub.spec file that it requires /usr/lib/crt1.o:

BuildRequires: automake /usr/lib/crt1.o

Therefore, compiling on a 64-bit system would fail unless you have the 32-bit glibc-devel. My mock cfg file was excluding this and other 32-bit rpms, which explains why it did not complete in mock.

Anyway, if you wish to build grub for x86_64, you could probably do so by satisfying the dependencies. But I would think that the 32-bit grub should be fine for you (don't take my word for it though). Just thought I should share what I've learned.

I too am experiencing this problem. Does anyone know if the fix for this issue is being built into any future releases of Grub? I am brand new to Linux and not sure how to build RPMs from source.

By having this problem... I mean I am having the issue with the Xen kernel not recognizing all of my memory. I would like to apply the same patch to my kernel as mentioned in this thread but I'm not certain how to do it. Does anyone know if there is a grub package available with the patch already applied?

Sorry for being unclear.

Quote:
As I wrote in the bug report http://bugs.centos.org/view.php?id=1905 I can offer the patched grub rpm if you wish (for testing).

Akemi

Akemi,

Please post your rpm anywhere you can, I will manage to get at it.
Can also email to : gosselina at globetrotter dot net.

Still wondering why it is so difficult to simply have a look at Centos build logs. Since the Centos team did manage to build the grub package (both 32- and 64- bit versions), it goes without saying that they know how to do it. Must this remain secret ? You previously referred to a knowledgeable person (Jeff on the centos-devel irc) . Could'nt this person help us here ?

Regards,

A. Gosselin

This is 32-bit:

http://www.scripps.edu/mem/biochem/ayagi/centos/grub-0.97-13.ay1.i386.rpm

I will get back to you with more details later,

Akemi

[EDIT] The above link is obsolete now. Patched grub packages are now available from:

http://centos.toracat.org/grub-0.97/CentOS-5/

Please keep in mind that the rpm I am offering has not been tested.

To answer you question... yes, CentOS has been building grub, so the developers certainly know how to build. I am trying to get it working myself at the moment. It will take a while though. In the meantime, you can ask the CentOS team if they can provide the grub with the patch applied. Perhaps in that bug tracker?

Akemi

First, there is no requirement to provide the build logs publicly, so we don't. It is not the hardest thing in the world to rebuild upstream sources, but we do not have any desire to help other people do it so that they can take away centos users. We did at one time help the group that built Oracle linux, and see what it got us, a competitor in our market space. Don't get me wrong, we are all for GPL software and we are happy to use it and provide all sources. Just not tell people how to make us (The CentOS Project) irrelevant.

That said, the issue here is quite simple

There is a known bug in the yum that ships with centos-5 (and rhel-5) ... version 3.0.x ... where BuildRequires that are in the form of BuildRequires: <file_path> do not work.

This bug will take any file, the first one it finds actually, and use it to meet the build requirement ... not the one specified by the full path.

SO ... in this case the problem is that the grub spec file has this line for the x86_64 package build:

BuildRequires: automake /usr/lib/crt1.o

The problem is that what needs to be installed is glibc-devel.i386 ... however a different package meets that require due to the bug, and the build fails (if using mock and centos-5 as the base). If you use centos-4 as the base os and setup mock to build centos-5 packages on that machine, then this package will build via mock.

I did manage to rebuild a correct x86_64 grub package, with the suggested patch. I installed it, and regrubbed my system.

Unfortunately, the patch did not change a thing. Still only 3.2GB seen by the Xen kernel out of 16, whereas the bare-metal kernel sees all.
I will have to look somewhere else, altough I am quite lost at the present time.

Thanks all for your help.

Worked for me!

I rebuilt the grub package for x86_64 with the patch provided at https://bugzilla.redhat.com/show_bug.cgi?id=250299
Grub now works and my 8Gb of memory are recognized with the Xen kernel. For the record I am running on a Hetzner root server DS8000.

You can grab the fixed package at:
ftp://ftp.zouric.com/public/grub-0.97-14.x86_64.rpm

__
Eric