Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Bet you got an update from Ubombtu that made the changes.........they know how your box should run. <sarcasm>
This is a possibility. If there was a kernel update for Ubuntu since you edited grub's menu.lst, it may have replaced your menu.lst file with a new kernel entry. Check your menu.lst to see if acpi=force is still there in the kernel line for booting Ubuntu. It only needs to be in the first entry for booting Ubuntu.
If things were working ok before you started turning off services with sysv-rc-conf (as in the link to the thread in the Ubuntu forums), then turn those services back on to see if the problems go away. You should not turn off services unless you know what they are for, and you are sure that you don't need them.
And one more thing,
If you want to disable ACPI, you don't need to mess aroud with stopping services with sysv-rc-conf. All you need to do is edit your grub's menu.lst and change the acpi=force to acpi=off that you added to the kernel line for booting Ubuntu. Then reboot, and ACPI will be disabled.
I have had a similar problem as initially described by Pazau on an Acer 5700GX desktop system, in fact i was preparing 5 of them and they all did the same. What worked for me was a simple modification in the /etc/default/halt file. apparently this was a sound driver related issue, although sound worked fine during each session and for that reason it did not seem like a logic thing to do. I did not question the solution as it worked immediately and every time. I added this line to the top of the file:
and now all five of them shut down fine.
trying won't hurt so just give this a try and see if this works for you, providing your system has an intel sound card.
Linux runs excellent with my AMD Turion64 processor, it also runs excellent with AMD Powernow which is embedded in my processor.
In Vista, the battery keep power in 1½ hour. On Ubuntu, the battery keep now power in 2½ hour!
The problem was just with ACPI, but preliminary work it through acpi=force command.
You could do it that way, as it says in the link you posted. The # defoptions=quiet splash acpi=force will be applied to all kernels in grub's menu.lst. (As far as I know anyway!). Adding it to the kernel line as I suggested will only apply to the kernel you are using.
It may be preferable to add it to the defoptions section. This way, when there is a kernel update for Ubuntu, you won't have to re-edit menu.lst to add acpi=force to the new kernel line. When ever a new kernel is installed grub will put it first in the list and leave the old kernels below it. Either way will work though.
If the shutdown problem comes back, you may want to try Wabbalee's suggestion of adding rmmod snd_hda_intel to the /etc/default/halt file. This applies to your sound card, not the CPU. To see if you are using the snd_hda_intel driver run " lsmod | grep -i snd" from terminal. If it reports snd_hda_intel is running, then you might consider trying Wabbalees's suggestion. If there is no snd_hda_intel, then then this does not apply to you.
yes, that is the way. as you can see (well in my case anyway) there are also some lines with a '#' in front of it, these lines are being ignored by the OS, and are there (in this case) for your information. I will insert a example copy of my /etc/default/halt file, but use your own not mine:
### BEGIN INIT INFO
# Provides: halt
# Required-Start: umountroot
# Should-Start: lvm raid2
# Default-Start: 0
# Short-Description: Execute the halt command.
### END INIT INFO
Tommcd: But now that I seem to have found a way, can I just remove acpi=force from /boot/grub/menu.lst, and Ubuntu will still close properly?
If lsmod reports that snd_hda_intel is running, and then adding "rmmod snd_hda_intel" to /etc/default/halt fixes the shut down problem, then yes, you could try removing acpi=force from grub's menu.lst and see if it still shuts down properly. If the shut down problem returns you could always put acpi=force back in menu.lst.
I fell over this tutorial for Linux on HP dv6000. Nvidia driver version 177 is reported to cause problems with standby and shutdown in Ubuntu 8.10, so I switched to version 173, and it works just as good as before. But thank you very much for your good help!