All of lore.kernel.org
 help / color / mirror / Atom feed
* [Ocfs2-devel] A patch for ocfs2 source configuration process.
@ 2006-08-03  1:27 tao.ma
  2006-08-03 15:20 ` Joel Becker
  0 siblings, 1 reply; 3+ messages in thread
From: tao.ma @ 2006-08-03  1:27 UTC (permalink / raw)
  To: ocfs2-devel

Hi,
     I have downloaded the newest source code ocfs2-1.2.3.tar.gz from
oss.oracle.com.
     After do the configuration I find a strange thing. Although my
kernel is "2.6.9-11.19AX"(Asianux2.0 on a vmware server with a single
processor configured), the configuration find that it is
2.6.9-11.19AX-smp. So after I make and install, those *.ko went to the
wrong place.
The reason is:
1. When vendor/ax2/vendor.guess runs.
The script is :if [ "`rpm -qf /etc/asianux-release --qf '%{VERSION}'
2>/dev/null`" != "8AX" ]
while in my machine it is "2.0", not "8AX".

I also modify the script in vendor.guess. In asianux2.0, In /etc, you
can find
redhat-release and asianux-release.  So the vendor.guess will get the
wrong string
"ax2
rhel4".

Attachment is my patch. Hope it can help.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ocfs2.patch
Type: text/x-patch
Size: 1011 bytes
Desc: not available
Url : http://oss.oracle.com/pipermail/ocfs2-devel/attachments/20060803/58a3721f/ocfs2.bin

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Ocfs2-devel] A patch for ocfs2 source configuration process.
  2006-08-03  1:27 [Ocfs2-devel] A patch for ocfs2 source configuration process tao.ma
@ 2006-08-03 15:20 ` Joel Becker
  2006-08-03 19:16   ` tao.ma
  0 siblings, 1 reply; 3+ messages in thread
From: Joel Becker @ 2006-08-03 15:20 UTC (permalink / raw)
  To: ocfs2-devel

On Thu, Aug 03, 2006 at 04:27:31PM +0800, tao.ma wrote:
>     After do the configuration I find a strange thing. Although my
> kernel is "2.6.9-11.19AX"(Asianux2.0 on a vmware server with a single
> processor configured), the configuration find that it is
> 2.6.9-11.19AX-smp. So after I make and install, those *.ko went to the
> wrong place.

	Interesting.

> The reason is:
> 1. When vendor/ax2/vendor.guess runs.
> The script is :if [ "`rpm -qf /etc/asianux-release --qf '%{VERSION}'
> 2>/dev/null`" != "8AX" ]
> while in my machine it is "2.0", not "8AX".

	Hmm, I wonder where we got 8AX (from someone with Aisianux, I'm
sure, I'm going to check...).  Hm, the logs don't say where I got it
from.  Can someone on this list verify what that should be?  Anyone with
Asianux, please respond with the output of:

    # rpm -qf /etc/asianux-release --qf '%{VERSION}'

> I also modify the script in vendor.guess. In asianux2.0, In /etc, you
> can find
> redhat-release and asianux-release.  So the vendor.guess will get the
> wrong string
> "ax2
> rhel4".

> 
> Attachment is my patch. Hope it can help.

	NAK.  The entire point of ./vendor.guess is that it has
absolutely ZERO vendor-specific knowledge.  We're not adding
vendor-specific knowledge to the generic script.
	That said, Asianux also keeping /etc/redhat-release is really
broken.  Bad Asianux.  _That_ said, we have to deal with the real world.
I suspect that the sort order solves it.  If we exit with our first
successful vendor, we win (it will find asianux before redhat).

Joel

-- 

Life's Little Instruction Book #452

	"Never compromise your integrity."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Ocfs2-devel] A patch for ocfs2 source configuration process.
  2006-08-03 15:20 ` Joel Becker
@ 2006-08-03 19:16   ` tao.ma
  0 siblings, 0 replies; 3+ messages in thread
From: tao.ma @ 2006-08-03 19:16 UTC (permalink / raw)
  To: ocfs2-devel

I have updated my Asianux2.0 to Asianux2.0sp1, kernel version is 2.6.9-34.
vendor.guess still get the wrong string "rhel4", but the configuration 
is right. It find my right kernel version.
So I think that is not a problem in this bew version of Asianux2.0sp1.
Joel Becker wrote:

>On Thu, Aug 03, 2006 at 04:27:31PM +0800, tao.ma wrote:
>  
>
>>    After do the configuration I find a strange thing. Although my
>>kernel is "2.6.9-11.19AX"(Asianux2.0 on a vmware server with a single
>>processor configured), the configuration find that it is
>>2.6.9-11.19AX-smp. So after I make and install, those *.ko went to the
>>wrong place.
>>    
>>
>
>	Interesting.
>
>  
>
>>The reason is:
>>1. When vendor/ax2/vendor.guess runs.
>>The script is :if [ "`rpm -qf /etc/asianux-release --qf '%{VERSION}'
>>2>/dev/null`" != "8AX" ]
>>while in my machine it is "2.0", not "8AX".
>>    
>>
>
>	Hmm, I wonder where we got 8AX (from someone with Aisianux, I'm
>sure, I'm going to check...).  Hm, the logs don't say where I got it
>from.  Can someone on this list verify what that should be?  Anyone with
>Asianux, please respond with the output of:
>
>    # rpm -qf /etc/asianux-release --qf '%{VERSION}'
>
>  
>
>>I also modify the script in vendor.guess. In asianux2.0, In /etc, you
>>can find
>>redhat-release and asianux-release.  So the vendor.guess will get the
>>wrong string
>>"ax2
>>rhel4".
>>    
>>
>
>  
>
>>Attachment is my patch. Hope it can help.
>>    
>>
>
>	NAK.  The entire point of ./vendor.guess is that it has
>absolutely ZERO vendor-specific knowledge.  We're not adding
>vendor-specific knowledge to the generic script.
>	That said, Asianux also keeping /etc/redhat-release is really
>broken.  Bad Asianux.  _That_ said, we have to deal with the real world.
>I suspect that the sort order solves it.  If we exit with our first
>successful vendor, we win (it will find asianux before redhat).
>
>Joel
>
>  
>



<http://www.oracle.com/cdc/>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-08-03 19:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-08-03  1:27 [Ocfs2-devel] A patch for ocfs2 source configuration process tao.ma
2006-08-03 15:20 ` Joel Becker
2006-08-03 19:16   ` tao.ma

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.