Bug 251815

Summary: udev after update complains "unknown format variable"
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: felixbellaby
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: udev-114-2.fc8 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-08-13 08:47:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
first screen from oops with 2.6.22.1-32.fc6
none
second screen from oops with 2.6.22.1-32.fc6 none

Description Michal Jaegermann 2007-08-11 20:40:50 UTC 
Description of problem:

After an update to udev-114-1.fc8 I see the following while booting:

Starting udev: udevd-event[966]: udev_rules_apply_format: unknown format
variable '$(while read id; do echo pnp:d$$id; done < /sys$devpath/id)''
udevd-event[967]: udev_rules_apply_format: unknown format variable '$(while read
id; do echo pnp:d$$id; done < /sys$devpath/id)''
udevd-event[968]: udev_rules_apply_format: unknown format variable '$(while read
id; do echo pnp:d$$id; done < /sys$devpath/id)''
udevd-event[979]: udev_rules_apply_format: unknown format variable '$(while read
id; do echo pnp:d$$id; done < /sys$devpath/id)''
udevd-event[986]: udev_rules_apply_format: unknown format variable '$(while read
id; do echo pnp:d$$id; done < /sys$devpath/id)''
udevd-event[987]: udev_rules_apply_format: unknown format variable '$(while read
id; do echo pnp:d$$id; done < /sys$devpath/id)''
udevd-event[992]: udev_rules_apply_format: unknown format variable '$(while read
id; do echo pnp:d$$id; done < /sys$devpath/id)''

and so on ....  That is with kernel 2.6.23-0.74.rc2.git1.fc8 as
2.6.23-0.96.rc2.git2.fc8 does not boot.

After that things seems to be in a runnable state (although maybe
I am just lucky with my hardware config?).

Version-Release number of selected component (if applicable):
udev-114-1.fc8
Comment 1 Michal Jaegermann 2007-08-11 21:10:52 UTC 
> 2.6.23-0.96.rc2.git2.fc8 does not boot.
See bug 251816.
Comment 2 Michal Jaegermann 2007-08-11 22:45:27 UTC 
Created attachment 161124 [details]
first screen from oops with 2.6.22.1-32.fc6

With a help of 'boot_delay=200' I took pictures of both exception
screens for 2.6.22.1-32.fc6.  It says "invalid opcode" at the beginning.
Comment 3 Michal Jaegermann 2007-08-11 22:46:11 UTC 
Created attachment 161125 [details]
second screen from oops with 2.6.22.1-32.fc6
Comment 4 Michal Jaegermann 2007-08-11 22:49:47 UTC 
Oops!  Scratch attachments from comments 2 and 3.  They are ok, but
for another bug.
Comment 5 Tom London 2007-08-12 16:47:03 UTC 
Get this too.  Could it be from 80-drivers.rules:

[root@localhost rules.d]# cat 80-drivers.rules 
# do not edit this file, it will be overwritten on update

ACTION!="add", GOTO="drivers_end"

DRIVER!="?*", ENV{MODALIAS}=="?*", RUN{ignore_error}+="/sbin/modprobe
$env{MODALIAS}"
SUBSYSTEM=="pnp", DRIVER!="?*", ENV{MODALIAS}!="?*", \
  RUN{ignore_error}+="/bin/sh -c '/sbin/modprobe -a $(while read id; do echo
pnp:d$$id; done < /sys$devpath/id)'"
SUBSYSTEM=="tifm", RUN+="/sbin/modprobe --all tifm_sd tifm_ms"
SUBSYSTEM=="mmc", RUN+="/sbin/modprobe mmc_block"
SUBSYSTEM=="ide", ATTR{media}=="tape", RUN+="/sbin/modprobe ide-scsi"
SUBSYSTEM=="scsi_device", TEST!="[module/sg]", RUN+="/sbin/modprobe sg"

LABEL="drivers_end"

[root@localhost rules.d]#
Comment 6 Michal Jaegermann 2007-08-13 19:02:58 UTC 
> Could it be from 80-drivers.rules ...

Replacing in this file both single quotes on RUN line with \" at 
least shuts down all that noise.
Comment 7 Harald Hoyer 2007-08-14 09:55:44 UTC 
correct fix, as in the newest version: "$$(" instead of "$("
Comment 8 Harald Hoyer 2007-08-14 13:02:33 UTC 
*** Bug 252168 has been marked as a duplicate of this bug. ***
Comment 9 Harald Hoyer 2007-08-14 13:23:59 UTC 
fixed in udev-114-2.fc8