Bug 18991 - chkconfig won't run on EV5 (compiled for EV6?)
Summary: chkconfig won't run on EV5 (compiled for EV6?)
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: chkconfig
Version: 7.3
Hardware: alpha
OS: Linux
high
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-10-12 18:51 UTC by Chris Adams
Modified: 2014-03-17 02:16 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-10-19 06:53:33 UTC
Embargoed:


Attachments (Terms of Use)

Description Chris Adams 2000-10-12 18:51:23 UTC
I cannot run /sbin/chkconfig on an EV5 system (AlphaServer 1000A 5/300) -
all I get is "Illegal instruction".  I recompiled it and it works fine, so
it may be that it was compiled for EV6 only.

This caused the install to leave the /etc/rc.d/rc?.d directories empty as
well.

Comment 1 Bill Nottingham 2000-10-17 05:17:44 UTC
I don't *think* it's compiled wrong.

If you rebuild it with -mcpu=ev5, does it work?

Comment 2 Chris Adams 2000-10-17 13:46:54 UTC
Yes, it works if I recompile it.  All I did to recompile it was "rpm -i
chkconfig-1.2.16-1.src.rpm" and "rpm -bc chkconfig.spec" and run the resulting
binary.

It looks like it was compiled for EV5:

$  rpm -qvp --qf '%{optflags}\n' chkconfig-1.2.16-1.alpha.rpm 
-O2 -mieee -mcpu=ev5
$ 

I have several programs that don't work (I can't even boot into the normal
multi-user runlevel).  I guess it is possible that something is screwy on my
system; this is an older Alpha that I've cobbled together from parts from
several.  I do have a hard drive with a bad spot (but I'm using RAID5 so it
_shouldn't_ be a problem except that of course the partition with the bad spot
is not used and that partition of the RAID is running degraded).  I think my RAM
is okay; is there any kind of memory tester (like "memtest86" on x86)?

I've got Digital Unix 5.1 CDs sitting on my desk; I guess I could try installing
it and see what it sees.

I'm willing to try anything you can suggest.

Comment 3 Chris Adams 2000-10-17 15:50:22 UTC
I just did a fresh install after removing the questionable disk.  I
didn't do anything special; I did a text install on a serial console,
did a "server" install, letting the installer partition the disks.  I
booted once with "init=/bin/sh" so I could turn off console gettys,
install getty_ps (I think this should be installed by default) and set
up a getty on ttyS0.  I also fixed the aboot.conf (I had to add
"console=ttyS0" and fix the kernel path: the installer put
"0:1/vmlinux...." in there, but the "1/" should just be "/"; I'll
bugzilla that).

Here is the tail of the boot and a login attempt:

INIT: Entering runlevel: 3
egrep: /proc/stat: No such file or directory
/etc/rc3.d/S99local: [: : integer expression expected
/etc/rc3.d/S99local: /etc/issue: Read-only file system
/etc/rc3.d/S99local: /etc/issue: Read-only file system
/etc/rc3.d/S99local: /etc/issue: Read-only file system
cp: cannot stat `/etc/issue': No such file or directory
/etc/rc3.d/S99local: /etc/issue: Read-only file system
(none) login: root
Login incorrect

login:

It has the same problems as before: chkconfig didn't work so /etc/rc3.d
is empty except for S99local. Then there are other programs not working
either so the whole thing is screwed up.

I wouldn't expect to get the exact same problem from flakey RAM or bad disk.

I thought perhaps I had a corrupted CD, but I just booted up with
"init=/bin/sh", brought up the network with "ifup eth0" (which worked okay), and
FTPed the chkconfig package from ftp.beta.redhat.com.  No difference, except I
noticed that passive FTP (which apparently is the default now in "ftp") did not
work either.  I don't know if I should bugzilla that or not, since I don't know
if the problem is just me or what.


Comment 4 Bill Nottingham 2000-10-18 06:36:37 UTC
Are both the rebuilt and original source RPMs built with the
same optflags if you query them?


Comment 5 Chris Adams 2000-10-18 16:25:13 UTC
Now that I look at it, my recompiled chkconfig does NOT have "-mcpu=ev5", while
the distributed version does.  However, I just forced it to use "-mcpu=ev5" and
recompiled (so the flags match the distributed version) and my recompiled
version still works fine.

I just found that the other main package I'm having this trouble with is
initscripts.  I just recompiled and reinstalled it and chkconfig (and then
re-ran chkconfig to add all the init scripts), and now the system boots okay
into multiuser mode (I'm able to log in remotely via ssh now).


Comment 6 Bill Nottingham 2000-10-19 06:51:34 UTC
If you try the chkconfig-1.2.17-1 RPM from 

people.redhat.com/notting/chkconfig/

does that work?

Comment 7 Bill Nottingham 2000-10-19 06:53:31 UTC
Oh, never mind. This is the RPM problem. Everything that linked in popt
statically (chkconfig and initlog) would die horribly.
RPM got fixed, so this should be fixed with the new chkconfig build.

Comment 8 Brock Organ 2000-10-19 17:38:35 UTC
verified fix in internal testing ...


Note You need to log in before you can comment on or make changes to this bug.