[18908] in Athena Bugs
Athena on the Pentium IV - (uname -m)
daemon@ATHENA.MIT.EDU (Tom Cavin)
Tue Apr 17 13:44:25 2001
From: Tom Cavin <tec@ai.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <15068.32997.181893.861892@vivaldi.mit.edu>
Date: Tue, 17 Apr 2001 13:44:05 -0400 (EDT)
To: bugs@mit.edu
Cc: Tom Cavin <tec@ai.mit.edu>
Hi,
I'm running Athena Linux on a new Pentium IV system and it is having
some trouble taking updates:
bash# cat update.log
Beginning update from 8.4.19 to 8.4.22 at Tue Apr 17 11:00:33 EDT 2001.
Update failed due to the following problems:
package inetd-0.16-7 is for a different architecture
package kernel-pcmcia-cs-2.2.17-14 is for a different architecture
package athena-ssh-8.4-21 is for a different architecture
package athena-passwd-8.4-21 is for a different architecture
package kernel-2.2.17-14 is for a different architecture
package athena-afs-8.4-21 is for a different architecture
package athena-lprng-8.4-21 is for a different architecture
package athena-rpmupdate-8.4-21 is for a different architecture
package athena-sysinfo-8.4-21 is for a different architecture
package glibc-2.1.3-22 is for a different architecture
package athena-xscreensaver-8.4-21 is for a different architecture
package athena-sendmail-8.4-21 is for a different architecture
package athena-motif-8.4-21 is for a different architecture
package glibc-profile-2.1.3-22 is for a different architecture
package athena-ws-8.4-21 is for a different architecture
package textutils-2.0e-6 is for a different architecture
package glibc-devel-2.1.3-22 is for a different architecture
*** The update has failed ***
Please contact Athena Cluster Services at x3-1410. -Athena Operations
bash# uname -m
i?86
I did a little bit of research with Jonathon Weiss, and we feel that
it is now up to you folks.
The problem is that the system doesn't identify itself properly as
able to run i386, i586, or i686 code. The info in /proc/cpuinfo isn't
usable and may be where "uname -m" gets its information.
The only hack I can think of to get around this problem is to replace
the "uname" program with a script that fakes the output for a Pentium
III. I don't like that idea, but I don't have a better one.
Please let me know if there is anything I can do to help get this
issue resolved.
Thanks,
--Tom
Jonathon Weiss writes:
>
> > An old Pentium system is an "i586". I don't know what an Pentium II
> > reports, but a Pentium III claims to be an "i686". What should a
> > Pentium IV be?
>
> I'm not sure.
>
> > Actually, checking /proc/cpuinfo on FPN gives a bit more of a clue:
> >
> > bash# cat /proc/cpuinfo
> > processor : 0
> > vendor_id : GenuineIntel
> > cpu family : ?
> > model : 0
> > model name : 00/00
>
> Indeed, it's even possible that's where uname looks for its info.
>
> > I suspect that the kernel just doesn't know what it's running on,
> > which would indicate a need for a new kernel. Possibly updating all
> > the lockers with new "@sys" links, and in general doing a lot of work.
> >
> > I assume that this new chip will run older code, so an interrim fix
> > would be to get the system to lie and claim to be an "i686".
> >
> > Do you have any suggestions about how to do that? The first idea that
> > comes to my mind is faking a "uname" command, but I don't know if that
> > is deep enough into the system to catch all the dependencies.
>
> Not really. At this point I suggest you send mail to bugs with what
> we've figured out and see if anyone there has something to say.
>
>
> Jonathon
--
Tom Cavin Phone: (617) 258 - 7806
WCCF Computer Operations Manager Email: tec@ai.mit.edu
