Re: udev on Fedore 5 - Gentoo script not very helpfull in LFS

Re: udev on Fedore 5 - Gentoo script not very helpfull in LFS

[Piet Delaney]

On Thu, 2006-08-03 at 01:39 -0700, Greg KH wrote:
> On Wed, Aug 02, 2006 at 10:14:46PM -0700, Piet Delaney wrote:
> > I wasn't able to login to your Fedora 5 (10.10.111.220).
> > I tried my AMD hammer at home (hammer.piet.net) and looked
> > at the Fedora 5 udev scripts. I can't see what the gento 
> > /sbin/start_udev might be doing to boost Performance so much
> > and didn't see the udev daemon stuff we saw on your system.
> > Perhaps it's probing the modules to pre-awaken them. I'm not
> > using modules, so I doubt it would have an effect.
> 
> The gentoo script for startup is attached below.  It picks it's startup
> logic depending on the kernel version running.
> 
> Hope this helps,

I messed with the gentoo script today, adding missing gentoo functions
and all.  udev 096 doesn't install sbin/udev so even with a new 
version of the udev distribution installed the script doesn't know. 

If you install 096's udev to sbin the gentoo script still gets confused
with 2.6.13 kernels. It tries to use the non-existing udevstart 
and udevsend cmds which don't exist; or tries to use old 030 versions!

The RELEASE-NOTES only say udev is no longer installed to
avoid looping (which I experienced) with old kernels and that
the man page is out of date.

I'm starting to lean towards just waiting till we have Linux From
Scratch (LFS) 6.2 working and then switching to the new event mechanism.
It's about to be released and supported the new 2.6.16 kernel and the
new udev-096. Perhaps I can extract 6.2 udev scripts part of
6.2 without too much work and supports pre 2.6.16 kernels; I suspect
not.

I get the impression that the udev code and associated scripts haven't
been designed for backward compatibility. Perhaps I'm wrong, I only
spent a day or two on it, but that's my initial impesssion. I get the
impression from the news groups that better clarity in the environment
would be greatly appreciated my many.

-piet

> 
> greg k-h
> 
> ------------------
> # Copyright 1999-2005 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> 
> udev_version() {
> 	local version=0
> 
> 	if [[ -x /sbin/udev ]] ; then
> 		version=$(/sbin/udev -V)
> 		# We need it without a leading '0', else bash do the wrong thing
> 		version=${version##0}
> 		# Older udev's will print nothing
> 		[[ -z ${version} ]] && version=0
> 	fi
> 
> 	echo "${version}"
> }
> 
> # This works for 2.6.15 kernels or greater
> trigger_events() {
> 	list=""
> 	# if you want real coldplug (with all modules being loaded for all
> 	# devices in the system), uncomment out the next line.
> 	#list="$list $(echo /sys/bus/*/devices/*/uevent)"
> 	list="$list $(echo /sys/class/*/*/uevent)"
> 	list="$list $(echo /sys/block/*/uevent /sys/block/*/*/uevent)"
> 	for i in $list; do
> 		case "$i" in
> 			*/device/uevent)
> 				# skip followed device symlinks
> 				continue
> 				;;
> 			*/class/mem/*|*/class/tty/*)
> 				first="$first $i"
> 				;;
> 			*/block/md*)
> 				last="$last $i"
> 				;;
> 			*/*)
> 				default="$default $i"
> 				;;
> 		esac
> 	done
> 
> 	# trigger the sorted events
> 	for i in $first $default $last; do
> 		echo "add" > "$i"
> 	done
> }
> 
> populate_udev() {
> 	# populate /dev with devices already found by the kernel
> 	if [ "$(get_KV)" -gt "$(KV_to_int '2.6.14')" ] ; then
> 		ebegin "Populating /dev with existing devices through uevents"
> 		udevtrigger
> 		eend 0
> 	else
> 		ebegin "Populating /dev with existing devices with udevstart"
> 		/sbin/udevstart
> 		eend 0
> 	fi
> 
> 	# loop until everything is finished
> 	# there's gotta be a better way...
> 	ebegin "Letting udev process events"
> 	loop=0
> 	while test -d /dev/.udev/queue; do
> 		sleep 0.1;
> 		test "$loop" -gt 300 && break
> 		loop=$(($loop + 1))
> 	done
> 	#einfo "loop = $loop"
> 	eend 0
> 
> 	return 0
> }
> 
> seed_dev() {
> 	# Seed /dev with some things that we know we need
> 	ebegin "Seeding /dev with needed nodes"
> 
> 	# copy over any persistant things
> 	if [[ -d /lib/udev/devices ]] ; then
> 		cp --preserve=all --recursive --update /lib/udev/devices/* /dev
> 	fi
> 
> 	# Not provided by sysfs but needed
> 	ln -snf /proc/self/fd /dev/fd
> 	ln -snf fd/0 /dev/stdin
> 	ln -snf fd/1 /dev/stdout
> 	ln -snf fd/2 /dev/stderr
> 	[[ -e /proc/kcore ]] && ln -snf /proc/kcore /dev/core
> 
> 	# Create problematic directories
> 	mkdir -p /dev/{pts,shm}
> 	eend 0
> }
> 
> 
> main() {
> 	# Setup temporary storage for /dev
> 	ebegin "Mounting /dev for udev"
> 	if [[ ${RC_USE_FSTAB} = "yes" ]] ; then
> 		mntcmd=$(get_mount_fstab /dev)
> 	else
> 		unset mntcmd
> 	fi
> 	if [[ -n ${mntcmd} ]] ; then
> 		try mount -n ${mntcmd}
> 	else
> 		if egrep -qs tmpfs /proc/filesystems ; then
> 			mntcmd="tmpfs"
> 		else
> 			mntcmd="ramfs"
> 		fi
> 		# many video drivers require exec access in /dev #92921
> 		try mount -n -t ${mntcmd} udev /dev -o exec,nosuid,mode\a55
> 	fi
> 	eend $?
> 
> 	# Create a file so that our rc system knows it's still in sysinit.
> 	# Existance means init scripts will not directly run.
> 	# rc will remove the file when done with sysinit.
> 	touch /dev/.rcsysinit
> 
> 	# Selinux lovin; /selinux should be mounted by selinux-patched init
> 	if [[ -x /sbin/restorecon && -c /selinux/null ]] ; then
> 		restorecon /dev &> /selinux/null
> 	fi
> 
> 	# Actually get udev rolling
> 	if [[ ${RC_DEVICE_TARBALL} = "yes" && \
> 	      -s /lib/udev-state/devices.tar.bz2 ]] ; then
> 		ebegin "Populating /dev with saved device nodes"
> 		try tar -jxpf /lib/udev-state/devices.tar.bz2 -C /dev
> 		eend $?
> 	fi
> 
> 	seed_dev
> 
> 	# Setup hotplugging (if possible)
> 	ebegin "Setting up proper hotplug agent"
> 	if [[ -e /proc/sys/kernel/hotplug ]] ; then
> 		if [ "$(get_KV)" -gt "$(KV_to_int '2.6.14')" ] ; then
> 			einfo "  Using netlink for hotplug events..."
> 			echo "" > /proc/sys/kernel/hotplug
> 		elif [[ $(udev_version) -ge "48" ]] ; then
> 			einfo "  Setting /sbin/udevsend as hotplug agent ..."
> 			echo "/sbin/udevsend" > /proc/sys/kernel/hotplug
> 		elif [[ -x /sbin/hotplug ]] ; then
> 			einfo "  Using /sbin/hotplug as hotplug agent ..."
> 		else
> 			einfo "  Setting /sbin/udev as hotplug agent ..."
> 			echo "/sbin/udev" > /proc/sys/kernel/hotplug
> 		fi
> 	fi
> 	eend 0
> 
> 	ebegin "Starting udevd"
> 	/sbin/udevd --daemon
> 	eend $?
> 
> 	populate_udev
> 
> 	# Create nodes that udev can't
> 	ebegin "Finalizing udev configuration"
> 	[[ -x /sbin/dmsetup ]] && /sbin/dmsetup mknodes &>/dev/null
> 	[[ -x /sbin/lvm ]] && \
> 		/sbin/lvm vgscan -P --mknodes --ignorelockingfailure &>/dev/null
> 	# Running evms_activate on a LiveCD causes lots of headaches
> 	[[ -z ${CDBOOT} ]] && [[ -x /sbin/evms_activate ]] && \
> 		/sbin/evms_activate -q &>/dev/null
> 	eend 0
> }
> 
> main
> 
> 
> # vim:ts=4
-- 
Piet Delaney
BlueLane Teck
W: (408) 200-5256; piet@bluelane.com
H: (408) 243-8872; piet@piet.net



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev on Fedore 5 - Gentoo script not very helpfull in LFS

[Dan Nicholson]

On 8/4/06, Piet Delaney <piet@bluelane.com> wrote:
>
> I'm starting to lean towards just waiting till we have Linux From
> Scratch (LFS) 6.2 working and then switching to the new event mechanism.
> It's about to be released and supported the new 2.6.16 kernel and the
> new udev-096. Perhaps I can extract 6.2 udev scripts part of
> 6.2 without too much work and supports pre 2.6.16 kernels; I suspect
> not.

6.2 is out now. Here's the book and the bootscripts directly.

http://www.linuxfromscratch.org/lfs/view/stable/
http://wiki.linuxfromscratch.org/lfs/browser/tags/6.2/bootscripts/lfs/init.d/udev?revw62
http://wiki.linuxfromscratch.org/lfs/browser/tags/6.2/bootscripts/lfs/init.d/udev_retry?revw62

They are installed as S10udev and S45udev_retry. No attempt at
backwards compatibility with earlier kernels or udev is attempted.
We're assuming you followed the LFS book and are using the packages
mentioned there. I believe it would work with kernels back to 2.6.15,
but I don't know.

--
Dan

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev on Fedore 5 - Gentoo script not very helpfull in LFS

[Greg KH]

On Fri, Aug 04, 2006 at 12:56:12AM -0700, Piet Delaney wrote:
> I get the impression that the udev code and associated scripts haven't
> been designed for backward compatibility. Perhaps I'm wrong, I only
> spent a day or two on it, but that's my initial impesssion. I get the
> impression from the news groups that better clarity in the environment
> would be greatly appreciated my many.

They are backwards compatible with older kernels, not older versions of
udev (as the startup script comes along with the version of udev you are
installing on Gentoo.)

And yes, I'd agree that you just stick with the LFS stuff, as that's the
system you are using :)

thanks,

greg k-h

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev on Fedore 5 - Gentoo script not very helpfull in LFS

[Piet Delaney]

On Fri, 2006-08-04 at 08:12 -0700, Dan Nicholson wrote:
> On 8/4/06, Piet Delaney <piet@bluelane.com> wrote:
> >
> > I'm starting to lean towards just waiting till we have Linux From
> > Scratch (LFS) 6.2 working and then switching to the new event mechanism.
> > It's about to be released and supported the new 2.6.16 kernel and the
> > new udev-096. Perhaps I can extract 6.2 udev scripts part of
> > 6.2 without too much work and supports pre 2.6.16 kernels; I suspect
> > not.
> 
> 6.2 is out now. Here's the book and the bootscripts directly.
> 
> http://www.linuxfromscratch.org/lfs/view/stable/
> http://wiki.linuxfromscratch.org/lfs/browser/tags/6.2/bootscripts/lfs/init.d/udev?revw62
> http://wiki.linuxfromscratch.org/lfs/browser/tags/6.2/bootscripts/lfs/init.d/udev_retry?revw62
> 
> They are installed as S10udev and S45udev_retry. No attempt at
> backwards compatibility with earlier kernels or udev is attempted.
> We're assuming you followed the LFS book and are using the packages
> mentioned there. I believe it would work with kernels back to 2.6.15,
> but I don't know.

Hi Dan:

I'm Having better luck with udev-056, MUCH faster with 2.6.13 kernel
than udev-030. Majors and Minors are identical. Permissions are
derived from the Original udev permissions and likely the original 
LFS permissions. 

Is it difficult to get the original LFS permissions for various releases
easily? For now I'll just use our existing LFS permissions from way
back in 6.1 (or perhaps even earlier). I tried browsing the src and
using wiki.linuxfromscratch.org but didn't easily find it.

-piet

> 
> --
> Dan
-- 
Piet Delaney
BlueLane Teck
W: (408) 200-5256; piet@bluelane.com
H: (408) 243-8872; piet@piet.net



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev on Fedore 5 - Gentoo script not very helpfull in LFS

[Dan Nicholson]

On 8/4/06, Piet Delaney <piet@bluelane.com> wrote:
> On Fri, 2006-08-04 at 08:12 -0700, Dan Nicholson wrote:
> >
> > 6.2 is out now. Here's the book and the bootscripts directly.
> >
> > http://www.linuxfromscratch.org/lfs/view/stable/
> > http://wiki.linuxfromscratch.org/lfs/browser/tags/6.2/bootscripts/lfs/init.d/udev?revw62
> > http://wiki.linuxfromscratch.org/lfs/browser/tags/6.2/bootscripts/lfs/init.d/udev_retry?revw62
>
> I'm Having better luck with udev-056, MUCH faster with 2.6.13 kernel
> than udev-030. Majors and Minors are identical. Permissions are
> derived from the Original udev permissions and likely the original
> LFS permissions.

By permissions I assume you mean the rules files. The udev rules have
jumped around a bit. They've only come under version control in the
past few months. Here's the rules and bootscripts from 6.1.1, which
used udev-056 and linux-2.6.12.

http://downloads.linuxfromscratch.org/udev-config-4.rules
http://downloads.linuxfromscratch.org/lfs-bootscripts-3.2.1.tar.bz2

I think you can also safely update to udev-071 with the same setup.
Read the NEWS and README in udev. It's noted when things become
incompatible such as kernel version needed, or a tool going away, like
udevstart.

--
Dan

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev on Fedore 5 - Gentoo script not very helpfull in LFS

[Piet Delaney]

On Fri, 2006-08-04 at 17:13 -0700, Dan Nicholson wrote:

Hi Dan:

> On 8/4/06, Piet Delaney <piet@bluelane.com> wrote:
> > On Fri, 2006-08-04 at 08:12 -0700, Dan Nicholson wrote:
> > >
> > > 6.2 is out now. Here's the book and the bootscripts directly.
> > >
> > > http://www.linuxfromscratch.org/lfs/view/stable/
> > > http://wiki.linuxfromscratch.org/lfs/browser/tags/6.2/bootscripts/lfs/init.d/udev?revw62
> > > http://wiki.linuxfromscratch.org/lfs/browser/tags/6.2/bootscripts/lfs/init.d/udev_retry?revw62
> >
> > I'm Having better luck with udev-056, MUCH faster with 2.6.13 kernel
> > than udev-030. Majors and Minors are identical. Permissions are
> > derived from the Original udev permissions and likely the original
> > LFS permissions.
> 
> By permissions I assume you mean the rules files.

Well..., yes. It seems between 030 and 056 the permissions directory
support was dropped yet lots of examples existed and it appears to
parse it in the log so it's hidden in the noise that the changing
of permissions is now done in the rules files. Even the udev 
Change log doesn't indicate this.


>                                                  The udev rules have
> jumped around a bit. They've only come under version control in the
> past few months. Here's the rules and bootscripts from 6.1.1, which
> used udev-056 and linux-2.6.12.
> 
> http://downloads.linuxfromscratch.org/udev-config-4.rules
> http://downloads.linuxfromscratch.org/lfs-bootscripts-3.2.1.tar.bz2

Thanks. I've been using the udev-config-4.rules and it bring us closer
to our previous permissions. It seems there was yet another undocumented
change. The config files:

	# default_mode - set the default mode for all nodes that have no
	#                explicit match in the permissions file
	default_mode="0600"

is no longer supported. The Change log only indicates it's being
supported way back when udev started to exist. So many permissions
with your LFS udev-config-4.rules still leave difference from our
previous environment. Many appear to be a consistent difference between
default permissions. Many of our files have permissions 600 and are
now coming up 660. I think this is likely because default_mode="0600"
is now ignored in the config file.

Might be best to try two versions of udev-config-4.rules, one with the
way they exist in the 6.1.1 release and another that beings us closer
to the permissions we are using from 6.1 (or earlier).

Any thoughts on that. You may be in a great position to know which
environment be best. Using the stock udev-config-4.rules from 6.1.1
would likely make future migration to 6.2 easier. Modifying the
udev-config-4.rules to give the same permissions we use now with
6.1 would likely minimize risk of our appliance behavior changing.

I haven't seen anything in your /lfs-bootscripts-3.2.1.tar that
changes files modes in /dev.

-piet
	
> 
> I think you can also safely update to udev-071 with the same setup.
> Read the NEWS and README in udev. It's noted when things become
> incompatible such as kernel version needed, or a tool going away, like
> udevstart.
> 
> --
> Dan
-- 
Piet Delaney
BlueLane Teck
W: (408) 200-5256; piet@bluelane.com
H: (408) 243-8872; piet@piet.net



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev on Fedore 5 - Gentoo script not very helpfull in LFS

[Dan Nicholson]

On 8/4/06, Piet Delaney <piet@bluelane.com> wrote:
>
> Thanks. I've been using the udev-config-4.rules and it bring us closer
> to our previous permissions. It seems there was yet another undocumented
> change. The config files:
>
>         # default_mode - set the default mode for all nodes that have no
>         #                explicit match in the permissions file
>         default_mode="0600"
>
> is no longer supported. The Change log only indicates it's being
> supported way back when udev started to exist. So many permissions
> with your LFS udev-config-4.rules still leave difference from our
> previous environment. Many appear to be a consistent difference between
> default permissions. Many of our files have permissions 600 and are
> now coming up 660. I think this is likely because default_mode="0600"
> is now ignored in the config file.

Mode 660 isn't really a big deal since the default group is root.
Unless you have a bunch of users in the root group, then it's not an
issue.

You can add this rule, though, which is used by redhat:

KERNEL="*", OWNER="root" GROUP="root", MODE="0600"

> Any thoughts on that. You may be in a great position to know which
> environment be best. Using the stock udev-config-4.rules from 6.1.1
> would likely make future migration to 6.2 easier. Modifying the
> udev-config-4.rules to give the same permissions we use now with
> 6.1 would likely minimize risk of our appliance behavior changing.

It could help, but in between that rule set and what's used in 6.2, a
lot changed in udev. There are more specialized rules needed for
handling sysfs, modprobe, scsi and firmware. Here's the link for the
development of our rules.

http://wiki.linuxfromscratch.org/lfs/browser/trunk/udev-config

Also, look at the rules that are shipped in the udev tarball. The suse
and redhat rules I'm fairly certain are used by those distros.

> I haven't seen anything in your /lfs-bootscripts-3.2.1.tar that
> changes files modes in /dev.

No, only the udev script is important for your case. You need to get
udevd running, tell the kernel what's going to handle events, and
handle coldplugging all your devices. This has changed over the
lifetime of udev, so be careful.

--
Dan

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel