Re: udevsend and hotplug
On 7/12/05, kareemy <[EMAIL PROTECTED]> wrote:
> On 7/11/05, Dan McGhee <[EMAIL PROTECTED]> wrote:
> > kareemy wrote:
> >
>
> Thank you. I have read that. It provided some insight as to how
> udev+hotplug are supposed to work but didn't quite solve my issue. In
> the meantime I found two possible solutions that have worked for me.
>
> 1) Keep /sbin/udevsend as the hotplug handler. Compile the
> run_directory extras in the udev source code by issuing the command
> "make EXTRAS=extras/run_directory". This will generate a
> udev_run_hotplugd binary. Copy that binary to /sbin and add the
> following rule to 50-udev.rules:
>
> ENV{UDEVD_EVENT}=="1", RUN+="/sbin/udev_run_hotplugd"
>
This is the correct option - from udev-059 onwards, the hotplug
handling is being done differently, with the udev rules being expanded
to allow calling of hotplug scripts from the udev rules file. It will
take a while to get a properly grip on the new functionality.
Ideally, the hotplug scripts will go away entirely, and be replaced by
udev rules that can call modprobe directly, etc. - that will take some
time however.
-- -
Steve Crosby
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: udevsend and hotplug
On 7/11/05, Dan McGhee <[EMAIL PROTECTED]> wrote:
> kareemy wrote:
>
> >Hello,
> >
> >I noticed that the lfs bootscripts changed to echo /sbin/udevsend into
> >/proc/sys/kernel/hotplug instead of /sbin/hotplug.
> >
> >Does hotplug ever get called anymore in this case?
> >
> >My problem is with my digital camera. It does not have a /dev entry.
> >When I plug it in, a new entry is created in /proc/bus/usb along with
> >some very hidden usb entry in the /sys filesystem usually
> >/sys/class/usb_host/usb2/device/usb2/2-1 or something to that effect.
> >That is all that happens when the camera is plugged in. On my old
> >system when /sbin/hotplug was used, the usb scripts properly found the
> >/proc/bus/usb entry and my usbcam script properly set the permissions
> >so I could use the camera as my normal user. I have always used gphoto
> >and it seems to communicate to the camera through this /proc entry.
> >Now that /sbin/udevsend is used, nothing is happening. My usb hotplug
> >scripts are never called and udevinfo prints nothing about a camera
> >device. So I have a few questions about how to best solve this.
> >
> >Why was the switch made to use /sbin/udevsend? On my old system using
> >/sbin/hotplug, buth udev and hotplug worked great. Now hotplug does
> >not seem to work.
> >
> >Can I switch back to /sbin/hotplug? Will there be any adverse effects?
> >
> >Is there a better way to get my digital camera to work than using
> >hotplug with a usbcam script? Perhaps a udev rule (The camera never
> >used a /dev entry in the past at all, so I don't know if this is
> >possible) ?
> >
> >I read the udevsend manpage and it seems that udevsend is supposed to
> >be called by hotplug, but that doesn't seem to be happening. Is there
> >a way to get use /sbin/hotplug and have it call udevsend or even have
> >/sbin/udevsend call /sbin/hotplug so both tools can work?
> >
> >Thanks,
> >Kareem
> >
> >
> Kareem,
>
> Let me point you to this series of messages in the archives:
>
> http://archives.linuxfromscratch.org/mail-archives/lfs-support/2005-July/027542.html
>
> This message and the next three or four replies to it may answer your
> questions.
>
> Dan
>
Thank you. I have read that. It provided some insight as to how
udev+hotplug are supposed to work but didn't quite solve my issue. In
the meantime I found two possible solutions that have worked for me.
1) Keep /sbin/udevsend as the hotplug handler. Compile the
run_directory extras in the udev source code by issuing the command
"make EXTRAS=extras/run_directory". This will generate a
udev_run_hotplugd binary. Copy that binary to /sbin and add the
following rule to 50-udev.rules:
ENV{UDEVD_EVENT}=="1", RUN+="/sbin/udev_run_hotplugd"
I added that at the end of the file. I copied it from the gentoo
udev.rules file that was included in the udev source code.
My understanding of this method is that udev will handle all hotplug
events, however, if it is given an event that does not match any of
its rules then it will run udev_run_hotplugd which is a simple binary
that traverses the /etc/hotplug.d directory running any scripts in
there. So now when I plug my digital camera in, udev matches this
final rule I created and activates hotplug which sets the permissions
correctly for me.
2) Use /sbin/hotplug as the hotplug event handler and in
/etc/hotplug.d/default/ simply add a symlink to /sbin/udevsend. So
when an event occurs, hotplug handles it but will call udevsend first
and then continue with the hotplug scripts.
I'd like some feedback about these method. Will there be any adverse
side effects or issues ...? I simply don't see a way udev can handle
setting up my digital camera with the correct permissions without the
help of a hotplug script. In addition i have a usbcam.usermap file
that hotplug uses which identifies hundreds of digital cameras it will
handle without issue.
Also, I used the LFS development version from July 9 when I compiled
my system and with the default setup I don't believe the hotplug
scripts were called at all during an hotplug event until I added that
udev rule above. I know they are still used for coldplugging at boot.
I am wondering if that is intentional or an oversight.
Thanks,
Kareem
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: glibc "make check" error
Hi. I've tried "make check" again and the problem was fixed automagically. There was a spiritual problem that affected the connections between the electronic devices of my computer. But finally harmony was re-established between the transistors, and the buses were unblocked permitting the pure bit energy flow free in the motherboard. At the same time my mind was clarified by the pure light of the GNUniverse, and I reached a state of absolute unity with my computer. Things like this make me love my job. -- David -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udevsend and hotplug
kareemy wrote: Hello, I noticed that the lfs bootscripts changed to echo /sbin/udevsend into /proc/sys/kernel/hotplug instead of /sbin/hotplug. Does hotplug ever get called anymore in this case? My problem is with my digital camera. It does not have a /dev entry. When I plug it in, a new entry is created in /proc/bus/usb along with some very hidden usb entry in the /sys filesystem usually /sys/class/usb_host/usb2/device/usb2/2-1 or something to that effect. That is all that happens when the camera is plugged in. On my old system when /sbin/hotplug was used, the usb scripts properly found the /proc/bus/usb entry and my usbcam script properly set the permissions so I could use the camera as my normal user. I have always used gphoto and it seems to communicate to the camera through this /proc entry. Now that /sbin/udevsend is used, nothing is happening. My usb hotplug scripts are never called and udevinfo prints nothing about a camera device. So I have a few questions about how to best solve this. Why was the switch made to use /sbin/udevsend? On my old system using /sbin/hotplug, buth udev and hotplug worked great. Now hotplug does not seem to work. Can I switch back to /sbin/hotplug? Will there be any adverse effects? Is there a better way to get my digital camera to work than using hotplug with a usbcam script? Perhaps a udev rule (The camera never used a /dev entry in the past at all, so I don't know if this is possible) ? I read the udevsend manpage and it seems that udevsend is supposed to be called by hotplug, but that doesn't seem to be happening. Is there a way to get use /sbin/hotplug and have it call udevsend or even have /sbin/udevsend call /sbin/hotplug so both tools can work? Thanks, Kareem Kareem, Let me point you to this series of messages in the archives: http://archives.linuxfromscratch.org/mail-archives/lfs-support/2005-July/027542.html This message and the next three or four replies to it may answer your questions. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
glibc "make check" error
Hi. Trying to build LFS-6.1: Chapter VI, glibc-2.3.4: "make" went fine, but "make check" fails: [EMAIL PROTECTED]: make check (...) GCONV_PATH=/sources/glibc-build/iconvdata LC_ALL=C LOCPATH=/sources/glibc-build/localedata /sources/glibc-build/elf/ld-linux.so.2 --library-path /sources/glibc-build:/sources/glibc-build/math:/sources/glibc-build/elf:/sources/glibc-build/dlfcn:/sources/glibc-build/nss:/sources/glibc-build/nis:/sources/glibc-build/rt:/sources/glibc-build/resolv:/sources/glibc-build/crypt:/sources/glibc-build/nptl /sources/glibc-build/posix/tst-regex2 > /sources/glibc-build/posix/tst-regex2.out make[2]: *** [/sources/glibc-build/posix/tst-regex2.out] Error 1 make[2]: Leaving directory `/sources/glibc-2.3.4/posix' make[1]: *** [posix/tests] Error 2 make[1]: Leaving directory `/sources/glibc-2.3.4' make: *** [check] Error 2 [EMAIL PROTECTED]: The host system is LFS-6.0. I'd appreciate any help. Thanks. -- David Rosal i Ricart <[EMAIL PROTECTED]> -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
udevsend and hotplug
Hello, I noticed that the lfs bootscripts changed to echo /sbin/udevsend into /proc/sys/kernel/hotplug instead of /sbin/hotplug. Does hotplug ever get called anymore in this case? My problem is with my digital camera. It does not have a /dev entry. When I plug it in, a new entry is created in /proc/bus/usb along with some very hidden usb entry in the /sys filesystem usually /sys/class/usb_host/usb2/device/usb2/2-1 or something to that effect. That is all that happens when the camera is plugged in. On my old system when /sbin/hotplug was used, the usb scripts properly found the /proc/bus/usb entry and my usbcam script properly set the permissions so I could use the camera as my normal user. I have always used gphoto and it seems to communicate to the camera through this /proc entry. Now that /sbin/udevsend is used, nothing is happening. My usb hotplug scripts are never called and udevinfo prints nothing about a camera device. So I have a few questions about how to best solve this. Why was the switch made to use /sbin/udevsend? On my old system using /sbin/hotplug, buth udev and hotplug worked great. Now hotplug does not seem to work. Can I switch back to /sbin/hotplug? Will there be any adverse effects? Is there a better way to get my digital camera to work than using hotplug with a usbcam script? Perhaps a udev rule (The camera never used a /dev entry in the past at all, so I don't know if this is possible) ? I read the udevsend manpage and it seems that udevsend is supposed to be called by hotplug, but that doesn't seem to be happening. Is there a way to get use /sbin/hotplug and have it call udevsend or even have /sbin/udevsend call /sbin/hotplug so both tools can work? Thanks, Kareem -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Binutils version change
Daryn Neadow wrote: Does anyone know why the version of binutils was dropped back for the just released 6.1 version? The last SVN version I was running was 20050608 and had binutils-2.16 in it while the 6.1 version just released has 2.15.94.0.2.2? It didn't drop back. The way we develop the book is that we get to a certain point and then decide that a release is in order. At this point, the book splits into two development paths. "trunk" (also known as 'svn' or 'development') continues to go full-steam ahead, with packages being updated to the latest versions available upstream. The release branch (also known as 'testing'), however, freezes package versions unless a critical bug is found in them. This allows us to stabilise the book and have a well-tested combination of packages by the time the release is finally made. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Warning on running "make check", second round
Hi Chris, > No, don't apply the patch - that won't work because > the glibc versions Oh, sorry, too late here, done already. I re-ran, the second time, # make check To my surprise this time it went through without complaint/warning. Later I encountered another problem of "Segmentation fault'. Then I ran; # make localedata/install-locales It went through with only one mistake; "sid_ET.UTF-8...LC_ADDRESS: `lang_lib' value does not match `lang_term' value done" > You'll need to > remove everything > in glibc-build and glibc-2.3.4-20040701 directories > and rebuild. When > you run make check again, you can simply ignore > those 2 errors I told > you about. OK. Shall I do it again? B.R. Stephen -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Warning on running "make check", second round
Stephen Liu wrote: Hi Chris, - snip - Actually, it's a different error (look carefully - it's "tst-cancelx17" - before it was "tst-cancel17"). That's the other known frequent-failing test, also fixed by the patch in the latest LFS. That error can also be ignored. Try "make check" again. Performed following steps From; http://www.sg.linuxfromscratch.org/patches/downloads/glibc/ download "glibc-2.3.2-test_lfs-1.patch" # cp /path/to/glibc-2.3.2-test_lfs-1.patch /mnt/lfs/sources/glibc-2.3.4-20040701 root:/sources/glibc-build# cd /sources/glibc-2.3.4-20040701 root:/sources/glibc-2.3.4-20040701# patch -Np1 -i glibc-2.3.5-fix_test-1.patch patching file nptl/tst-cancel17.c # cd ../glibc-build/ root:/sources/glibc-build# make check ... make[1]: *** [/sources/glibc-build/c++-types-check.out] Error 1 make[1]: Leaving directory `/sources/glibc-2.3.4-20040701' make: *** [check] Error 2 Warning still existed. B.R. Stephen No, don't apply the patch - that won't work because the glibc versions are slightly different. Again, I just mentioned it let you know that the errors you got are completely normal. You'll need to remove everything in glibc-build and glibc-2.3.4-20040701 directories and rebuild. When you run make check again, you can simply ignore those 2 errors I told you about. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Binutils version change
Does anyone know why the version of binutils was dropped back for the just released 6.1 version? The last SVN version I was running was 20050608 and had binutils-2.16 in it while the 6.1 version just released has 2.15.94.0.2.2? Thanks -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS-Version 7.0-cross-lfs-20050707-x86_64
Luca wrote: Hi all! When I give the command LFSHOME=`su - lfs -c 'echo $HOME'` in chapter 4.5 Creating the $HOME/cross-tools Directory everything hangs. How to solve the problem? Host system is SuSE 9.1, cpu is athlon64. What exactly do you mean 'everything hangs'? Are you able to use another terminal? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS-Version 7.0-cross-lfs-20050707-x86_64
On Mon, 11 Jul 2005, Luca wrote: > Hi all! > > When I give the command LFSHOME=`su - lfs -c 'echo $HOME'` in chapter > 4.5 Creating the $HOME/cross-tools Directory everything hangs. How to > solve the problem? > Host system is SuSE 9.1, cpu is athlon64. > > Thanks in advance, > Luca Piol > > This sounds as if it might be the 'bash-3.0 hangs with recent glibc' problem : in LFS, we fix that with the bash-3.0-avoid_WCONTINUED-1.patch but for fixing the host system, a better approach would be to look for an update from SuSE. However, it seems a little unlikely that a big-name distro would ship with this sort of problem (unless you've upgraded libc on SuSE), maybe something else is the problem. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Hotplug, hotplug-ng, & udev: Versions?
On Sat, Jul 09, 2005 at 10:45:07PM +0100, Declan Moriarty wrote: > > Mind you, I STILL have no /dev/hdc, or /dev/hdd. /proc/ide/ide0 shows me > hda (all nodes present & correct). There is no hdb in the box. > > /proc/ide/ide1 shows me hdc & hdd as cdroms in the media file. hdd is > actually a dvd. NO NODES :-((. See. That's technical progress. Without udev you had to have a zillion 'device files' (and MAKEDEV to help you), and with udev you have to have a zillion 'rules' and nothing to help you. It's probably meant to improve your learning abilities. Check if you compiled a driver or module called 'idecd'. It's in Device Drivers/Ata Atapi/IDE Atapi CDROM. Or maybe your drive is one of the 'old CD Roms'? (I think not, though. I'm using old hardware here because of money problems, but if it was _that_ old, the electrolytic capacitors would have dried out by now anyway, wouldn't they.) > Also, btw, loading the 57 framebuffer modules (by running hotplug) seems > to cure the cursor thing, but gives me the ugliest 80x30 screen setting > ever. How does a guy set up his framebuffer modes? Get fbset (from the Debian guys). But with 640x480 on the framebuffer I kept getting 80x30 too, so maybe you need to load another font. I don't know how, though. I guess 'setfont' won't do it, because you have to choose extra framebuffer fonts in 'make menuconfig'. I think you would need a 8x20 font to get 80x24 characters, but the biggest framebuffer font is 8x16, giving the familiar 80x30 characters on 640x480 pixels. I can only guess right now. I gave up on the whole framebuffer thing myself on friday, concerning LFS 6.x. I found X11 on the framebuffer was even slower than on the regular nvidia driver from kernel org. Damn. Everything is different with kernel 2.6. (Not complaining, just ranting.) Joern -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Segmentation fault
Hi folks, 6.11.1. Installation of Glibc http://www.sg.linuxfromscratch.org/lfs/view/6.0/chapter06/glibc.html upto root:/sources/glibc-build# touch /etc/ld.so.conf root:/sources/glibc-build# make install All went through without problem Now coming to re-do root:/sources/glibc-build# mkdir -p /usr/lib/locale root:/sources/glibc-build# localedef -i de_DE -f ISO-8859-1 de_DE Segmentation fault root:/sources/glibc-build# localedef -i [EMAIL PROTECTED] -f ISO-8859-15 [EMAIL PROTECTED] Segmentation fault What is Segmentation fault. How to get rid of them. TIA B.R. Stephen Liu -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Hotplug, hotplug-ng, & udev: Versions?
Recently, Somebody Somewhere wrote these words > Declan Moriarty wrote: > > >On the basis that udev-059 should have improved things, (but didn't); > >udev-060 should have fixed that (but didn't); So udev-061 must work... > > And our survey said"possibly not" :) Try udev-062! Too late... Udev-058 went in, and hotplug. By the time I type make uninstall, there'll probably be udev-065 :-/. Now whan hotplug runs, I get this from lsmod af_packet 13128 2 usbhid 24772 0 radeonfb 21396 1 cfbcopyarea 3648 1 radeonfb cfbimgblt 2752 1 radeonfb cfbfillrect 3584 1 radeonfb softcursor 1856 1 radeonfb via_agp 7680 1 parport_pc 30212 1 snd_cmipci 29184 0 snd_pcm82276 1 snd_cmipci snd_page_alloc 7620 1 snd_pcm snd_opl3_lib9280 1 snd_cmipci snd_timer 21188 2 snd_pcm,snd_opl3_lib snd_hwdep 7136 1 snd_opl3_lib snd_mpu401_uart 6144 1 snd_cmipci snd_rawmidi20512 1 snd_mpu401_uart snd_seq_device 6924 2 snd_opl3_lib,snd_rawmidi snd45668 8 snd_cmipci,snd_pcm,snd_opl3_lib,snd_timer,snd_hwdep,snd_mpu401_uart,snd_rawmidi,snd_seq_device soundcore 7392 1 snd via_rhine 20164 0 usbmouse4352 0 uhci_hcd 30220 0 usbcore 119868 4 usbhid,usbmouse,uhci_hcd udf84356 0 isofs 24452 0 vfat 10816 0 fat46108 1 vfat AFTER I have manually removed the ehci_hcd module which gives me continuous current warnings. I commented it out of the /etc/hotplug.d/ scripts, and checked it wasn't in /etc/rc.d/init.d either :-o. I have a gigabyte of syslog messages about overcurrent. Mind you, I STILL have no /dev/hdc, or /dev/hdd. /proc/ide/ide0 shows me hda (all nodes present & correct). There is no hdb in the box. /proc/ide/ide1 shows me hdc & hdd as cdroms in the media file. hdd is actually a dvd. NO NODES :-((. Also, btw, loading the 57 framebuffer modules (by running hotplug) seems to cure the cursor thing, but gives me the ugliest 80x30 screen setting ever. How does a guy set up his framebuffer modes? It doesn't matter what I boot on, hotplug screws it up on me :-(. lad set up -- With best Regards, Declan Moriarty. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
LFS-Version 7.0-cross-lfs-20050707-x86_64
Hi all! When I give the command LFSHOME=`su - lfs -c 'echo $HOME'` in chapter 4.5 Creating the $HOME/cross-tools Directory everything hangs. How to solve the problem? Host system is SuSE 9.1, cpu is athlon64. Thanks in advance, Luca Piol -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Warning on running "make check", second round
Hi Chris, - snip - > Actually, it's a different error (look carefully - > it's "tst-cancelx17" > - before it was "tst-cancel17"). That's the other > known frequent-failing > test, also fixed by the patch in the latest LFS. > That error can also be > ignored. Try "make check" again. Performed following steps From; http://www.sg.linuxfromscratch.org/patches/downloads/glibc/ download "glibc-2.3.2-test_lfs-1.patch" # cp /path/to/glibc-2.3.2-test_lfs-1.patch /mnt/lfs/sources/glibc-2.3.4-20040701 root:/sources/glibc-build# cd /sources/glibc-2.3.4-20040701 root:/sources/glibc-2.3.4-20040701# patch -Np1 -i glibc-2.3.5-fix_test-1.patch patching file nptl/tst-cancel17.c # cd ../glibc-build/ root:/sources/glibc-build# make check ... make[1]: *** [/sources/glibc-build/c++-types-check.out] Error 1 make[1]: Leaving directory `/sources/glibc-2.3.4-20040701' make: *** [check] Error 2 Warning still existed. B.R. Stephen -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
