/etc/init.d/udev-trigger --verbose start * Generating a rule to create a /dev/root symlink ... * Populating /dev with existing devices through uevents ... * $:-no} is not set properly * ERROR: udev-trigger failed to start I didn't change any setting in the recently automatically created /etc/conf.d/udev-trigger file. /etc/init.d/udev-trigger has automatically put to the sysinit runlevel, but cannot be started. Thus KMS seems not to work and X cannot be started. Reproducible: Always
Created attachment 404872 [details, diff] udev-init-scripts-28-udev-trigger_init_script_fix.patch Possible fix
Created attachment 404874 [details, diff] udev-init-scripts-28-udev-trigger_init_script_fix.patch In my previous patch I forgot to fix indentation of one line.
/etc/init.d/udev-trigger is still not starting, but the error is gone. /etc/init.d/udev-trigger --verbose start * Generating a rule to create a /dev/root symlink ... * Populating /dev with existing devices through uevents ... * ERROR: udev-trigger failed to start I will attach the debug output of /etc/init.d/udev-trigger --verbose start.
Created attachment 404876 [details] udev-trigger debug output
Can confirm, same problem.
Created attachment 404878 [details, diff] udev-trigger patch
I believe the patch above fixes the issue, the culprit was actually the function display_hotplugged_services, where it couldn't fill the variable services, and wasn't able to make use of it later. The patch works for me.
Patch worked for me too. Thank you.
Created attachment 404884 [details] rc.log with "set -x" in udev-trigger's start_pre() The patch from Lars (attachment 404876 [details]) does _not_ solve the problem for me.
Sorry, I meant Lars' attachment 404874 [details, diff]. The patch from Daniel (attachment 404878 [details, diff]) works for me. At least no error on start (I don't use hotplugged stuff, so I don't know if this is working). But the output looks weird: > * Generating a rule to create a /dev/root symlink ... > [ ok ] > * Populating /dev with existing devices through uevents ... > [ ok ] > * Device initiated services: * > > rc sysinit logging stopped at Wed Jun 10 15:06:57 2015 (see the asterisk character on the right after "device initated services")
I tried the patch from Daniel Salas, and it also worked for me. For the curious (like me) the problem was that "continue" had to be converted to "true" so the return was not undefined (I think). And the syntax error in the line "if yesno "${udev_monitor}:-no}"; then", caused another failure. That is, removing the extra "}" before the ":" was also required for a successful exit. That is to say, the patch fixes two problems.
Created attachment 404892 [details, diff] udev-trigger.patch I believe this is what we want. There is a typo, and all of the _pre/_post functions should always return 0.
No, please don't enforce "return 0". How would you catch errors like > - if yesno "${udev_monitor}:-no}"; then > + if yesno "${udev_monitor:-no}"; then You should always check for return values. If you do something and don't care if it was successful or not, that's an indication you are doing something unnecessary, not?
(In reply to Thomas D. from comment #13) > No, please don't enforce "return 0". Seconded, please fix only where non-zero `$?' can be tolerated. Instead of the three `return 0' in comment #12, change > [ -n "${services}" ] && einfo "Device initiated services:${HILITE}${services}${NORMAL}" in `display_hotplugged_services()' to > [ -z "${services}" ] || einfo "Device initiated services:${HILITE}${services}${NORMAL}" resolves the issue on my machine without introducing unnecessary hacks.
(In reply to Casper Ti. Vector from comment #14) > Instead of the three `return 0' in comment #12, change Actually four instead of three. Never mind...
I'm becoming little frustrated about which patch to use.
(In reply to Perfect Gentleman from comment #16) > I'm becoming little frustrated about which patch to use. Wait for the bug to be resolved then.
(In reply to Thomas D. from comment #13) > No, please don't enforce "return 0". How would you catch errors like > > > - if yesno "${udev_monitor}:-no}"; then > > + if yesno "${udev_monitor:-no}"; then > That would not be caught anyway; the return value is currently inherited from the display_hotplugged_services function.
(In reply to Mike Gilbert from comment #17) > (In reply to Perfect Gentleman from comment #16) > > I'm becoming little frustrated about which patch to use. > > Wait for the bug to be resolved then. okay
(In reply to Casper Ti. Vector from comment #14) > Instead of the three `return 0' in comment #12, change > > [ -n "${services}" ] && einfo "Device initiated services:${HILITE}${services}${NORMAL}" > in `display_hotplugged_services()' to > > [ -z "${services}" ] || einfo "Device initiated services:${HILITE}${services}${NORMAL}" > resolves the issue on my machine without introducing unnecessary hacks. That is probably a better solution indeed.
Created attachment 404900 [details, diff] add different checks to the variable I believe this is a better fix, instead of just returning 0 or displaying that ugly message, let's tell the user exactly what is happening, no services were loaded.
(In reply to Casper Ti. Vector from comment #14) > (In reply to Thomas D. from comment #13) > > No, please don't enforce "return 0". > > Seconded, please fix only where non-zero `$?' can be tolerated. non-zero $? must be tolerated in the _pre/_post functions. The things they control (specifically the udev_monitor and display_hotplugged_services code) have nothing to do with the success or failure of udev-trigger; they are optional code to aid with debugging. In the previous version of the scripts, we did not care about the return codes from udev trigger so I was just bringing that forward as well to not break anything.
(In reply to William Hubbs from comment #22) > non-zero $? must be tolerated in the _pre/_post functions. The things they > control (specifically the udev_monitor and display_hotplugged_services code) > have nothing to do with the success or failure of udev-trigger; they are > optional code to aid with debugging. But incorrect code is still incorrect code, like above-mentioned `"${udev_monitor}:-no}"' and (arguably) `[ -n "${services}" ] && ...'. I still consider it better strategy to fix individual incorrectness, rather than blanket assuming the whole module is correct. In other words, sweeping dirt under the carpet does not really make the room cleaner.
Daniel's patch (attachment 404900 [details, diff]) works for me. The output looks good, too.
(In reply to Casper Ti. Vector from comment #23) > (In reply to William Hubbs from comment #22) > > non-zero $? must be tolerated in the _pre/_post functions. The things they > > control (specifically the udev_monitor and display_hotplugged_services code) > > have nothing to do with the success or failure of udev-trigger; they are > > optional code to aid with debugging. > > But incorrect code is still incorrect code, like above-mentioned > `"${udev_monitor}:-no}"' and (arguably) `[ -n "${services}" ] && ...'. I > still consider it better strategy to fix individual incorrectness, rather > than blanket assuming the whole module is correct. In other words, sweeping > dirt under the carpet does not really make the room cleaner. ${foo:-no} is correct code; the issue is there is an extra } in the script, ${foo}:-no} which is fixed in my patch. [ -n "${services}" ] appears to be correct posix shell code to me. So if I correct the typo, on the first thing you point out as part of my fix, what's the issue that is left?
This is fixed in release 29; thanks for the report.
(In reply to William Hubbs from comment #25) > ${foo:-no} is correct code; the issue is there is an extra } in the script, > ${foo}:-no} which is fixed in my patch. > > [ -n "${services}" ] appears to be correct posix shell code to me. > > So if I correct the typo, on the first thing you point out as part of my > fix, what's the issue that is left? Both grammatical correctness and semantic correctness matter. The root cause of this issue is that failure in `[ -n "${services}" ]' is tolerable, which however does not imply any potential error in `*_pre()' and `*_post()' would be likewise tolerable.
version 29 is still broken for me. Had to downgrade to 27. With 28/29: my wifi card driver isn't modprobed, my X11 has no mouse or keyboard. X11 outputs two lines saying: ConnectSession: DBUS_SESSION_BUS_ADDRESS missing or invalid however dbus is running.
Hi, Seems like 29 is still not working smoothly. After boot I don't get X started. I need to run: /etc/init.d/udev-trigger --verbose restart And after that restart xdm to get my KDE desktop
For me, udev-init-scripts-29 don't work, too: I have renamed interfaces (via 80-net-setup-link.rules). When booting with udev-init-scripts-29, these interfaces won't be renamed on boot. Can we please re-open this bug (this is the second report that -29 still doesn't work) or should I fill another bug?
For [IP-] [ ] sys-fs/udev-init-scripts-29:0 rc-update del udev-trigger sysinit rc-update add udev-trigger default worked for me.
Well, moving udev-trigger to default run level works for me, too. But if I add "sleep 10" before > ebegin "Populating /dev with existing devices through uevents" > udevadm trigger --type=subsystems --action=add > udevadm trigger --verbose --type=devices --action=add udev-trigger will work for me in sysinit like designed. Race condition? Also interesting to note: This only happens with udev-220-r1 (same with the currently masked udev-220-r2 from tree from "Fri, 12 Jun 2015 13:45:01 +0000"). udev-init-scripts-29 with udev-219 works fine.
In reply to comment #27: The *_pre and *_post functions in this script handle purely optional functionality which you activate in the conf.d file to aid with debugging, so whether they fail or not is not relevant to whether the trigger code in start() fails. (In reply to wolfwood from comment #28) > version 29 is still broken for me. Had to downgrade to 27. > > With 28/29: my wifi card driver isn't modprobed, my X11 has no mouse or > keyboard. > > X11 outputs two lines saying: > ConnectSession: DBUS_SESSION_BUS_ADDRESS missing or invalid > however dbus is running. (In reply to Iddo from comment #29) > Hi, > > Seems like 29 is still not working smoothly. After boot I don't get X > started. I need to run: > > /etc/init.d/udev-trigger --verbose restart > > And after that restart xdm to get my KDE desktop Both of these sound like bug #551808, which is not a script issue; 220-r2 should take care of it. Please do not move udev-trigger to the default runlevel. This belongs in sysinit; remember it was part of "udev" in earlier versions and "udev" Is in sysinit.
For my issue from comment 30 and comment 32 I filled a new bug 551928.
