Interesting problem

**stuart_b** · 10-23-2004, 03:30 AM

I have an older PC with a K6-2 processor with an interesting mainboard that could be installed with either AT or ATX power supplies. So it has the ability to shut off the PC when attached to an ATX supply, but in mine it has an AT one, and it can't. But Knoppix doesn't know that, and it tries to power it off on shutdown, and I get a segmentation fault.

I ran into this before with Mandrake, and was able to edit the "halt" script in /etc. But I haven't figured out how to accomplish the same in Debian, and I'm not sure Knoppix's autodetection wouldn't "fix" it every time it booted anyway.

Has anyone run into this and found how to deal with it?

**shah** · 10-23-2004, 06:15 AM

You could try:
1) Check your /etc/lilo.cfg; remove line apm=power-off
2) Add/append /etc/lilo.cfg with noapm

**firebyrd10** · 10-23-2004, 06:44 AM

try typing noapm or acpi=off at boot. That should solve it. (if your useing an install, follow shah's advice.

**stuart_b** · 10-25-2004, 05:56 PM

Weird. I removed apm=power-off (from the append lines relating to all the Linux entries) in /etc/lilo.conf, and added noapm, and it still tries to shut down on halt. I tried to add noapm as an append at the end of the file, but running lilo to write it to the MBR caused it to gripe at me--so I didn't think it took.

I haven't tried feeding it noapm or acpi=off at boot yet, but even if it works that won't help much, since the system is for someone else. I'll see if acpi=off works as a lilo.conf append, and look into whether this works in concert with changing the halt script.

I do notice that this doesn't really affect anything, while the problem I had in Mandrake 8.1 (I think) bacically halted the system like a BSOD or something. I couldn't restart with <ctrl> + <alt> + <del>, while with Knoppix it's just ugly-looking.

**stuart_b** · 10-25-2004, 11:21 PM

I can't believe it. I fixed it.

My problem was that I had put the OS on the machine by imaging with Ghost, since it was faster than trying to remaster it, and by making the system redetect its hardware everything worked. My clue was that I was able to load the 2.6.x kernel and DIDN'T have the problem, so I edited /etc/modules and that fixed it. I then went ahead and deleted it and both the kernel-specific ones, so it goes through the full autodetect the next time any are loaded.