Hide Forgot
Description of problem: udevd is started when the package is installed, even if it is installed in a chroot environment. The %post section of the spec file is to blame: %post if [ "$1" -ge "1" -a -x /sbin/pidof ]; then pid=$(/sbin/pidof -c udevd) while [ -n "$pid" ]; do for p in $pid; do kill $hard $p; done sleep 0.2 pid=$(/sbin/pidof -c udevd) hard="-9" done /sbin/udevd -d fi exit 0 Version-Release number of selected component (if applicable): udev-095-14.24.el5 How reproducible: Package installations always start udevd. Steps to Reproduce: 1. Install udev to a chroot. 2. Observe udevd is running Actual results: udevd is running Expected results: udevd is not running
the code got patched: 267,279c269,304 < if [ $1 = 0 -a -f %{_initrddir}/udev ]; then < if [ -x /sbin/pidof ]; then < pid=$(/sbin/pidof -c udevd) < while [ -n "$pid" ]; do < for p in $pid; do < kill $hard $p; < done < sleep 0.2 < pid=$(/sbin/pidof -c udevd) < hard="-9" < done < fi < /sbin/chkconfig --del udev --- > if [ "$1" -eq 0 -a -f %{_initrddir}/udev ]; then > if [ -f /proc/1/exe -a -d /proc/1/root ] && [ / -ef /proc/1/root ]; then > if [ -x /sbin/pidof ]; then > pid=$(/sbin/pidof -c udevd) > while [ -n "$pid" ]; do > for p in $pid; do > kill $hard $p 2>/dev/null > done > sleep 0.2 > pid=$(/sbin/pidof -c udevd) > hard="-9" > done > fi > fi > /sbin/chkconfig --del udev > fi > if [ "$1" -eq 0 ]; then > /sbin/chkconfig --del udev-retry > fi > /sbin/chkconfig --del udev-post >/dev/null 2>&1 || : > exit 0 > > %pre > # kill daemon if we are not in a chroot > if [ -f /proc/1/exe -a -d /proc/1/root ] && [ / -ef /proc/1/root ]; then > if test -x /sbin/udevd -a -x /sbin/pidof ; then > pid=$(/sbin/pidof -c udevd) > while [ -n "$pid" ]; do > for p in $pid; do > kill $hard $p 2>/dev/null > done > sleep 0.2 > pid=$(/sbin/pidof -c udevd) > hard="-9" > done > fi 284,294c309,311 < if [ "$1" -ge "1" -a -x /sbin/pidof ]; then < pid=$(/sbin/pidof -c udevd) < while [ -n "$pid" ]; do < for p in $pid; do < kill $hard $p; < done < sleep 0.2 < pid=$(/sbin/pidof -c udevd) < hard="-9" < done < /sbin/udevd -d --- > # start daemon if we are not in a chroot > if [ -f /proc/1/exe -a -d /proc/1/root ] && [ / -ef /proc/1/root ]; then > /sbin/udevd -d >/dev/null 2>&1 || : however, the fix doesn't do what the bug/fix description says - it doesn't detect trick like "chroot /" ... but quick googling says there's no safe way to detect chroot and comparing inodes seems to be the best guess - at least it is good enough to workaround the problem
just to demonstrate ... .live.[root@ppcp-5s-m1 /]# chroot chroot /bin/bash -c 'if [ -f /proc/1/exe -a -d /proc/1/root ] && [ / -ef /proc/1/root ]; then echo "not chroot" ; else echo "chroot"; fi' chroot .live.[root@ppcp-5s-m1 /]# chroot / /bin/bash -c 'if [ -f /proc/1/exe -a -d /proc/1/root ] && [ / -ef /proc/1/root ]; then echo "not chroot" ; else echo "chroot"; fi' not chroot (where ./chroot contains minimal system to run bash)
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause The user runs fsck.gfs2 on a GFS2 file system in verbose mode (with the -v parameter). Consequence The user sees alarming error messages indicating that the master and root inode are not marked "In use" by the file system and an indication that the problem has been corrected: System inode for 'master' is located at block 23 (0x17) The inode exists but the block is not marked 'in use'; fixing it. System inode for 'root' is located at block 22 (0x16) The inode exists but the block is not marked 'in use'; fixing it. There is no problem with either inode; the error messages are just misleading. Fix The code has been changed to set both the master and root inodes as "in use" in the in-core block map. Result As a result, fsck.gfs2 now realizes the master and root inodes are properly marked, so the error messages are not printed.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-1046.html