Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is
On Fri, Oct 31, 2008 at 4:35 AM, Loïc Minier [EMAIL PROTECTED] wrote: On Fri, Oct 31, 2008, Loïc Minier wrote: Actually I dropped that part when rewriting the init script; any idea what could set MODPROBE_OPTIONS for you? Could you either try the attached module-init-tools patch, or prepend MODPROBE_OPTIONS= to the modprobe --all --use-blacklist call in the init script? If the latter works, I'll push a new acpid with this workaround while waiting for the former to be merged. -- Loïc Minier Hi Loïc. The culprit appears to be inside initrd. The 'init' script in the initrd image is setting MODPROBE_OPTIONS=-qb. This cascades down through the init.d scripts and is picked up by /etc/init.d/acpid which fails. I've tested both 'unset MODPROBE_OPTIONS' and 'MODPROBE_OPTIONS=' in /etc/init.d/acpid and both methods work to start acpid when no modules are available. Derrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is
On Sun, Nov 02, 2008, Derrick Karpo wrote: The culprit appears to be inside initrd. The 'init' script in the initrd image is setting MODPROBE_OPTIONS=-qb. This cascades down through the init.d scripts and is picked up by /etc/init.d/acpid which fails. Ah right, forgot to update this bug; the culprit is initramfs which exports tons of stuff: https://bugs.launchpad.net/bugs/291619 I wasn't seeing this bug because I'm using upstart. I've tested both 'unset MODPROBE_OPTIONS' and 'MODPROBE_OPTIONS=' in /etc/init.d/acpid and both methods work to start acpid when no modules are available. Cool, we'll apply this workaround then while we wait for either of initramfs or modprobe to be fixed. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is
On Thu, Oct 30, 2008, Derrick Karpo wrote: Just to recount and answer some of Michael's questions, none of the acpid modules exist in this test as they are all compiled in. If all acpi modules are compiled into the kernel then the acpid fails to start at boot. If they are left as modules then acpid successfully starts at boot. With 2/dev/null removed there is no more useful information on boot but manually running the script post-boot will show the modprobe warnings that the modules don't exist. Aha, thanks, I think I got it: Around module-init-tools-3.3-pre11/modprobe.c:1373, modprobe will either error() and return or if unknown_silent is set will exit(1). unknown_silent is set with modprobe -q/-Q/--quiet/--silent which is set via MODPROBE_OPTIONS in the acpid init script. This is only set if VERBOSE is false. So there's a different behavior in terms of exit status between: modprobe --all foobar (exit 0) modprobe --all --quiet foobar (exit 1) This is quite problematic as --all is supposed to proceed and attempt to load all modules, but in --quiet it stops as soon as a module can not be loaded... So I think I'll drop --quiet for now and report the bug against modprobe. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is
On Fri, Oct 31, 2008, Loïc Minier wrote: MODPROBE_OPTIONS in the acpid init script. This is only set if VERBOSE is false. Actually I dropped that part when rewriting the init script; any idea what could set MODPROBE_OPTIONS for you? -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is
On Fri, Oct 31, 2008, Loïc Minier wrote: Actually I dropped that part when rewriting the init script; any idea what could set MODPROBE_OPTIONS for you? Could you either try the attached module-init-tools patch, or prepend MODPROBE_OPTIONS= to the modprobe --all --use-blacklist call in the init script? If the latter works, I'll push a new acpid with this workaround while waiting for the former to be merged. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is
On Fri, Oct 31, 2008, Michael Meskes wrote: Loic, this means we catch this failure by changing the default, right? Yup, but it would still be exposed to people who have a custom list of modules in /etc/default/acpid and who don't merge the new conffile. :-/ -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is
On Thu, Oct 30, 2008 at 10:27:47PM -0600, Derrick Karpo wrote: Just to recount and answer some of Michael's questions, none of the acpid modules exist in this test as they are all compiled in. If all Loic, this means we catch this failure by changing the default, right? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is
Hi Derrick, Could you please edit /etc/init.d/acpid as root, and change the set -e into: set -e set -x initlogfile=$(mktemp -t acpid.init.) exec 2$initlogfile This will record the execution of acpid's init script to a log file in /tmp. Please send us the resulting /tmp/acpid.init.* files after: - reboot (where you report acpid doesn't startup) - /etc/init.d/acpid restart (where you report acpid starts up) Thanks, -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is
On Thu, Oct 30, 2008 at 3:29 AM, Loïc Minier [EMAIL PROTECTED] wrote:
Hi Derrick,
Could you please edit /etc/init.d/acpid as root, and change the
set -e into:
set -e
set -x
initlogfile=$(mktemp -t acpid.init.)
exec 2$initlogfile
This will record the execution of acpid's init script to a log file in
/tmp.
Please send us the resulting /tmp/acpid.init.* files after:
- reboot (where you report acpid doesn't startup)
- /etc/init.d/acpid restart (where you report acpid starts up)
Thanks,
--
Loïc Minier
Hello.
I've attached both the temp files for your interest where you can see
that the modprobe stalls. Putting an strace wrapper around
/etc/init.d/acpid shows that the modprobe quits with exit_group(1) on
boot but once the system is running it runs clean with the usually
WARNING for non-existent modules.
Just to recount and answer some of Michael's questions, none of the
acpid modules exist in this test as they are all compiled in. If all
acpi modules are compiled into the kernel then the acpid fails to
start at boot. If they are left as modules then acpid successfully
starts at boot. With 2/dev/null removed there is no more useful
information on boot but manually running the script post-boot will
show the modprobe warnings that the modules don't exist.
Derrick
Here's the strace output at boot:
4435 open(/lib/modules/2.6.27.1/modules.alias,
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOTDIR (Not a
directory)
4435 open(/lib/modules/2.6.27.1/modules.alias, O_RDONLY) = 3
4435 fstat(3, {st_mode=S_IFREG|0644, st_size=37219, ...}) = 0
4435 mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa83e54f000
4435 read(3, # Aliases extracted from modules ..., 4096) = 4096
4435 read(3, nd_usb_audio\nalias usb:v0582p0012..., 4096) = 4096
4435 read(3, isc*ip* snd_usb_audio\nalias usb:v..., 4096) = 4096
4435 read(3, c*i* snd_hda_intel\nalias pci:v000..., 4096) = 4096
4435 read(3, ipv4\nalias nf_conntrack-2 nf_conn..., 4096) = 4096
4435 read(3, 001002d7835sv*sd*bc*sc*i* rad..., 4096) = 4096
4435 read(3, ia:m*c*f*fn01pfn*pa8FDF8F89pbDD5E..., 4096) = 4096
4435 read(3, rial_cs\nalias pcmcia:m*c*f*fn*pfn..., 4096) = 4096
4435 read(3, 0e\nalias pci:v8086d104Asv..., 4096) = 4096
4435 read(3, 0* intel_agp\nalias pci:v8086d..., 4096) = 355
4435 read(3, ..., 4096) = 0
4435 close(3) = 0
4435 munmap(0x7fa83e54f000, 4096) = 0
4435 exit_group(1) = ?
4406 ... wait4 resumed [{WIFEXITED(s) WEXITSTATUS(s) == 1}], 0,
NULL) = 4435
4406 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
4406 --- SIGCHLD (Child exited) @ 0 (0) ---
4406 wait4(-1, 0x7fff716aae44, WNOHANG, NULL) = -1 ECHILD (No child processes)
4406 rt_sigreturn(0x8) = 0
4406 rt_sigaction(SIGINT, {SIG_IGN}, {SIG_IGN}, 8) = 0
4406 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
4406 exit_group(1) = ?
Here's the strace output once acpid has been manually started post boot:
5260 open(/lib/modules/2.6.27.1/modules.alias,
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOTDIR (Not a
directory)
5260 open(/lib/modules/2.6.27.1/modules.alias, O_RDONLY) = 3
5260 fstat(3, {st_mode=S_IFREG|0644, st_size=37219, ...}) = 0
5260 mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2256999000
5260 read(3, # Aliases extracted from modules ..., 4096) = 4096
5260 read(3, nd_usb_audio\nalias usb:v0582p0012..., 4096) = 4096
5260 read(3, isc*ip* snd_usb_audio\nalias usb:v..., 4096) = 4096
5260 read(3, c*i* snd_hda_intel\nalias pci:v000..., 4096) = 4096
5260 read(3, ipv4\nalias nf_conntrack-2 nf_conn..., 4096) = 4096
5260 read(3, 001002d7835sv*sd*bc*sc*i* rad..., 4096) = 4096
5260 read(3, ia:m*c*f*fn01pfn*pa8FDF8F89pbDD5E..., 4096) = 4096
5260 read(3, rial_cs\nalias pcmcia:m*c*f*fn*pfn..., 4096) = 4096
5260 read(3, 0e\nalias pci:v8086d104Asv..., 4096) = 4096
5260 read(3, 0* intel_agp\nalias pci:v8086d..., 4096) = 355
5260 read(3, ..., 4096) = 0
5260 close(3) = 0
5260 munmap(0x7f2256999000, 4096) = 0
5260 write(2, WARNING: Module battery not found..., 35) = 35
5260 open(/etc/modprobe.conf,
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
5260 open(/etc/modprobe.conf, O_RDONLY) = -1 ENOENT (No such file
or directory)
5260 open(/etc/modprobe.d, O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
5260 fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
5260 getdents(3, /* 14 entries */, 4096) = 448
5260 open(/etc/modprobe.d/aliases,
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOTDIR (Not a
directory)
5260 open(/etc/modprobe.d/aliases, O_RDONLY) = 4
5260 fstat(4, {st_mode=S_IFREG|0644, st_size=4619, ...}) = 0
5260 mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2256999000
5260 read(4, # These are the standard
Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is
On Fri, Oct 24, 2008, Derrick Karpo wrote: In looking at the /etc/init.d/acpid script from Ubuntu it appears to solve many of the modprobe issues that I am seeing. It checks to ensure the modules exist before loading them and won't attempt to load modules twice. Perhaps it's worth merging chunks of their load_modules() into the Debian script. The Ubuntu script is essentially a previous version of the Debian script; it calls in many commands, triggers many file reads, both of these slowing the boot, and is generally quite odd. Please, let's find out why the new Debian script doesn't work for you and we'll do Debian and Ubuntu some good. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is
On Fri, Oct 24, 2008 at 08:57:09PM -0600, Derrick Karpo wrote: My previous tests confirmed that $MODULES is not empty and contains well defined space-delimited modules as defined in /etc/default/acpid. And all these modules do exist? Do you get meaningful output by removing the 2/dev/null? In looking at the /etc/init.d/acpid script from Ubuntu it appears to solve many of the modprobe issues that I am seeing. It checks to ensure the modules exist before loading them and won't attempt to load modules twice. Perhaps it's worth merging chunks of their load_modules() into the Debian script. I definitely agree with Loïc that the new version is easier to digest and thus way better maintainable. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is not
unmerge 502704 reopen 502704 thanks Could you please test with acpid_1.0.6-15? I'd expect it to fix your problem or I misjudged where your problem lies. Michael Hello. acpid_1.0.6-15 exhibits the same issue and I confirmed that /proc/modules does exist at that point in the script. As a Sorry, I just reopened the bug. As a workaround, I've attached a patch to /etc/init.d/acpid to get past the modprobe when it fails. It's a hack but at least it allows acpid to start when there are no modules to load. There's likely something bigger at play here. I doubt it. Just running modprobe without any module to load gives a return code of 1. However, I don't think we should ignore errors but instead check whether the modules list is empty. How about this: if [ $MODULES ]; then modprobe --all --use-blacklist $MODULES 2/dev/null fi Does this work for you? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is not
On Fri, Oct 24, 2008, Michael Meskes wrote: if [ $MODULES ]; then modprobe --all --use-blacklist $MODULES 2/dev/null fi Err you probably lack a -n here, but FYI there's already: if [ -z $MODULES ]; then return fi I think modprobe --all always returns 0 (which is probably a bug; I've reported when I rewrote the init script), so it might be a bogus return again which might want to be return 0, but I don't think so. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is
On Fri, Oct 24, 2008, Michael Meskes wrote: No. For some strange reasons the if [ $MODULES ] works for me as does if [ ! -z $MODULES ] but if [ -n $MODULES ] does not. Err because you need to quote it! if [ -n $MODULES ] becomes if [ -n ] when MODULES is empty; what you want is if [ -n $MODULES ] which becomes if [ -n ]. Derrick, could you please add an echo and output $MODULES on your system with some boundaries, so we see whether it's empty or maybe containing some empty string or whatever? Also could you send us the modules.dep file? Or set -x at the top and exec 2/tmp/acpid-log.txt and attach that; I think it works but didn't test. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is
On Fri, Oct 24, 2008 at 10:19:55AM +0200, Loïc Minier wrote: On Fri, Oct 24, 2008, Michael Meskes wrote: if [ $MODULES ]; then modprobe --all --use-blacklist $MODULES 2/dev/null fi Err you probably lack a -n here, but FYI there's already: No. For some strange reasons the if [ $MODULES ] works for me as does if [ ! -z $MODULES ] but if [ -n $MODULES ] does not. if [ -z $MODULES ]; then return fi Ah sorry, missed this. I think modprobe --all always returns 0 (which is probably a bug; I've reported when I rewrote the init script), so it might be a bogus return again which might want to be return 0, but I don't think so. Probably not. From what I understood the modprobe is executed on his system, so the return is not. Derrick, could you please add an echo and output $MODULES on your system with some boundaries, so we see whether it's empty or maybe containing some empty string or whatever? Also could you send us the modules.dep file? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is
On Fri, Oct 24, 2008 at 11:00:28AM +0200, Loïc Minier wrote: No. For some strange reasons the if [ $MODULES ] works for me as does if [ ! -z $MODULES ] but if [ -n $MODULES ] does not. Err because you need to quote it! ... Sorry, incorrectly pasted (in fact I typed this) into my email. But since this doesn't seem to be the solution there is no need to check what went wrong in my test anyway. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is
On Fri, Oct 24, 2008 at 2:57 AM, Michael Meskes [EMAIL PROTECTED] wrote: On Fri, Oct 24, 2008 at 10:19:55AM +0200, Loïc Minier wrote: On Fri, Oct 24, 2008, Michael Meskes wrote: if [ $MODULES ]; then modprobe --all --use-blacklist $MODULES 2/dev/null fi Err you probably lack a -n here, but FYI there's already: No. For some strange reasons the if [ $MODULES ] works for me as does if [ ! -z $MODULES ] but if [ -n $MODULES ] does not. if [ -z $MODULES ]; then return fi Ah sorry, missed this. I think modprobe --all always returns 0 (which is probably a bug; I've reported when I rewrote the init script), so it might be a bogus return again which might want to be return 0, but I don't think so. Probably not. From what I understood the modprobe is executed on his system, so the return is not. Derrick, could you please add an echo and output $MODULES on your system with some boundaries, so we see whether it's empty or maybe containing some empty string or whatever? Also could you send us the modules.dep file? Michael My previous tests confirmed that $MODULES is not empty and contains well defined space-delimited modules as defined in /etc/default/acpid. I've also confirmed that modules.dep checks out so that shouldn't be the issue but it was worth checking out. In looking at the /etc/init.d/acpid script from Ubuntu it appears to solve many of the modprobe issues that I am seeing. It checks to ensure the modules exist before loading them and won't attempt to load modules twice. Perhaps it's worth merging chunks of their load_modules() into the Debian script. Derrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is not
On Wed, Oct 22, 2008 at 04:11:48PM -0600, Derrick Karpo wrote: Along with the 'set -x' I also added logging statements before and after the modprobe in /etc/init.d/acpid. modprobe is called correctly and $MODULES is propagated with the MODULES that are defined in /etc/default/acpid. However, the /etc/init.d/acpid script doesn't get past the modprobe. I'm a little short on testing time (as this is occurring on my primary work machine) however I'll try take a look at it later today. Could you please test with acpid_1.0.6-15? I'd expect it to fix your problem or I misjudged where your problem lies. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502704: [Pkg-acpi-devel] Bug#502704: Bug#502704: Bug#502704: acpid is not
On Thu, Oct 23, 2008 at 2:10 AM, Michael Meskes [EMAIL PROTECTED] wrote: On Wed, Oct 22, 2008 at 04:11:48PM -0600, Derrick Karpo wrote: Along with the 'set -x' I also added logging statements before and after the modprobe in /etc/init.d/acpid. modprobe is called correctly and $MODULES is propagated with the MODULES that are defined in /etc/default/acpid. However, the /etc/init.d/acpid script doesn't get past the modprobe. I'm a little short on testing time (as this is occurring on my primary work machine) however I'll try take a look at it later today. Could you please test with acpid_1.0.6-15? I'd expect it to fix your problem or I misjudged where your problem lies. Michael Hello. acpid_1.0.6-15 exhibits the same issue and I confirmed that /proc/modules does exist at that point in the script. As a workaround, I've attached a patch to /etc/init.d/acpid to get past the modprobe when it fails. It's a hack but at least it allows acpid to start when there are no modules to load. There's likely something bigger at play here. Derrick acpid-1.0.6-15-modprobe.patch.gz Description: GNU Zip compressed data
