Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Got udev working, now what?!
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4 ... 28, 29, 30  Next  
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo
View previous topic :: View next topic  
Author Message
takev
n00b
n00b


Joined: 20 Dec 2003
Posts: 11
Location: Amsterdam

PostPosted: Sun Dec 21, 2003 11:51 pm    Post subject: Reply with quote

added, /dev should still be mounted, such that it can be populated with the devices.tar.bz2.
I added it right under the mounting of /dev

/udev is only populated by /sbin/udev
Back to top
View user's profile Send private message
Decibels
Veteran
Veteran


Joined: 16 Aug 2002
Posts: 1623
Location: U.S.A.

PostPosted: Mon Dec 22, 2003 4:21 am    Post subject: Reply with quote

Hmmm, tried from your recap and nothing. Added the 'populate_udev' under it in /sbin/rc and populates the /udev folder with:
Code:
console  hdb1   loop7  ram2  tty1   tty19  tty28  tty37  tty46  tty55  tty7   ttyS7
fd0      hdb2   ptmx   ram3  tty10  tty2   tty29  tty38  tty47  tty56  tty8
hda      hdc    ram0   ram4  tty11  tty20  tty3   tty39  tty48  tty57  tty9
hda1     loop0  ram1   ram5  tty12  tty21  tty30  tty4   tty49  tty58  ttyS0
hda2     loop1  ram10  ram6  tty13  tty22  tty31  tty40  tty5   tty59  ttyS1
hda3     loop2  ram11  ram7  tty14  tty23  tty32  tty41  tty50  tty6   ttyS2
hda4     loop3  ram12  ram8  tty15  tty24  tty33  tty42  tty51  tty60  ttyS3
hda5     loop4  ram13  ram9  tty16  tty25  tty34  tty43  tty52  tty61  ttyS4
hda6     loop5  ram14  tty   tty17  tty26  tty35  tty44  tty53  tty62  ttyS5
hdb      loop6  ram15  tty0  tty18  tty27  tty36  tty45  tty54  tty63  ttyS6

That was with the usb scanner plugged in, replugged it and still no scanner in /udev . Well, maybe need to add an entry in udev.rules for the scanner, still that seems to kindof defeat the purpose also, it should know from hotplug.

Don't have any more time to play with it right now, work calls. Still, this way is cool and should be the way it works, but what about devices like nvidiactl, nvidia#, alsa devices, lm_sensors,... Still seems there is going to be a need for either saving the current state when rebooting AND this would still require remerging of all of them. That is just a preliminary assumption though.
Maybe that is part of the reason udev is only partitially functional, cause Developers are working that out?
_________________
Support bacteria – they’re the only culture some people have.”

– Steven Wright
Back to top
View user's profile Send private message
at_chaos
Tux's lil' helper
Tux's lil' helper


Joined: 09 Nov 2003
Posts: 149
Location: EU|Austria

PostPosted: Mon Dec 22, 2003 11:14 am    Post subject: Reply with quote

maybe it works with the new hotplug release?! (but I am too new to gentoo/linux to see if it works now :roll: )

changelog hotplug:
Quote:
*hotplug-20030805-r3 (21 Dec 2003) 21 Dec 2003; Daniel Robbins <drobbins@gentoo.org> hotplug-20030805-r3.ebuild: New patch to allow hotplug to work with kernel 2.6. This is needed to patch around some unfinished code in the hotplug sources.
Back to top
View user's profile Send private message
takev
n00b
n00b


Joined: 20 Dec 2003
Posts: 11
Location: Amsterdam

PostPosted: Mon Dec 22, 2003 11:49 am    Post subject: Reply with quote

Decibels wrote:
Hmmm, tried from your recap and nothing. Added the 'populate_udev' under it in /sbin/rc and populates the /udev folder with:
Code:
console  hdb1   loop7  ram2  tty1   tty19  tty28  tty37  tty46  tty55  tty7   ttyS7
fd0      hdb2   ptmx   ram3  tty10  tty2   tty29  tty38  tty47  tty56  tty8
hda      hdc    ram0   ram4  tty11  tty20  tty3   tty39  tty48  tty57  tty9
hda1     loop0  ram1   ram5  tty12  tty21  tty30  tty4   tty49  tty58  ttyS0
hda2     loop1  ram10  ram6  tty13  tty22  tty31  tty40  tty5   tty59  ttyS1
hda3     loop2  ram11  ram7  tty14  tty23  tty32  tty41  tty50  tty6   ttyS2
hda4     loop3  ram12  ram8  tty15  tty24  tty33  tty42  tty51  tty60  ttyS3
hda5     loop4  ram13  ram9  tty16  tty25  tty34  tty43  tty52  tty61  ttyS4
hda6     loop5  ram14  tty   tty17  tty26  tty35  tty44  tty53  tty62  ttyS5
hdb      loop6  ram15  tty0  tty18  tty27  tty36  tty45  tty54  tty63  ttyS6

That was with the usb scanner plugged in, replugged it and still no scanner in /udev . Well, maybe need to add an entry in udev.rules for the scanner, still that seems to kindof defeat the purpose also, it should know from hotplug.


I think it worked for you, as you see only block devices hd[abc] are there, not hdd.

I find it strange you had to add the 'populate_udev' yourself after the mount command, as I have it there already.
Then maybe you don't have the sys-apps/baselayout-1.8.6.12-r2.

I think the scanner is not supported by udev yet, it only supports "class" and "block" devices reported under /sys. sysfs doesn't support all devices yet either. For example there are no alsa devices in there.

If you would be able to connect an external USB harddisk I think it should work for you too.

Decibels wrote:


Don't have any more time to play with it right now, work calls. Still, this way is cool and should be the way it works, but what about devices like nvidiactl, nvidia#, alsa devices, lm_sensors,... Still seems there is going to be a need for either saving the current state when rebooting AND this would still require remerging of all of them. That is just a preliminary assumption though.
Maybe that is part of the reason udev is only partitially functional, cause Developers are working that out?


I think indeed that is why they call it partly supported. I've read the sourcecode of udev, and a lot of devices are not supported yet.
some devices are not supported by sysfs yet either.

All the devices should be created with udev at some point.
Now, udev already keeps state info, which with my configuration is thrown away at reboot. This state is for example the permissions for each device.
But I find this strange as you already can change the persmission in the configuration file and then we would have the permissions in
two places.
Back to top
View user's profile Send private message
Decibels
Veteran
Veteran


Joined: 16 Aug 2002
Posts: 1623
Location: U.S.A.

PostPosted: Mon Dec 22, 2003 1:22 pm    Post subject: Reply with quote

I just figure out why I had to use populate_udev again, I put the mount /udev at the end of the function, you must have put it right after the mounting of /dev, but before it's populate_udev. I'll try that when I get home.

No, my scanner shows up in /sys when I plug/unplug it. Comes up when check usb bus devices. And ya, my block devices only go to hdc so it does them correctly.

I didn't take time to look at the permissions and see if udev.permissions took affect in /udev, I know there not in /dev. So will see when get home.

Going to get a new computer chair at officemax today and that will probably make everything much more clear. :lol:
_________________
Support bacteria – they’re the only culture some people have.”

– Steven Wright
Back to top
View user's profile Send private message
TheCoop
Veteran
Veteran


Joined: 15 Jun 2002
Posts: 1814
Location: Where you least expect it

PostPosted: Mon Dec 22, 2003 2:21 pm    Post subject: Reply with quote

the /udev thing works fine, and replugging in my usb mem stick produces /udev/sda but it doesnt mount it, even though theres a script in the hotplug dir which does mount it...

alsa and i2c still needs to be supported in sysfs and thus udev, but it shouldnt be long until we can get rid of this silly devices.tar.bz2 or whatever its called.

Now I just need to figure out how to produce /udev/cdrom and /udev/dvd...
_________________
95% of all computer errors occur between chair and keyboard (TM)

"One World, One web, One program" - Microsoft Promo ad.
"Ein Volk, Ein Reich, Ein Führer" - Adolf Hitler

Change the world - move a rock
Back to top
View user's profile Send private message
takev
n00b
n00b


Joined: 20 Dec 2003
Posts: 11
Location: Amsterdam

PostPosted: Mon Dec 22, 2003 2:41 pm    Post subject: Reply with quote

I just plugged in my USB printer, and /udev/lp0 appeared.

I just pluggend in my USB scanner,
and the /udev/scanner0 appeared.

So scanners are indeed supported.

What you could try is add changing the udev-009.ebuild in your /usr/portage.
And change the line:
sed -ie '/^DEBUG/ c\DEBUG = false' Makefile
into
sed -ie '/^DEBUG/ c\DEBUG = true' Makefile

Then rebuild udev, and change your metalog.conf (or other syslog configuration)
to log facility=* minimum=9, I guess that would be *.debug in syslog.

Then when you plug in devices it will print debug statements in syslog, like this for scanners.

Code:

Dec 22 13:11:14 [kernel] hub 1-0:1.0: new USB device on port 1, assigned address 3
Dec 22 13:11:14 [usb.agent] ... no modules for USB product 4b8/10b/114
Dec 22 13:11:14 [udev] main: version 009
Dec 22 13:11:14 [udev] main: looking at '/devices/pci0000:00/0000:00:1f.2/usb1/1-1/1-1:1
.0'
Dec 22 13:11:14 [udev] main: not a block or class device

I guess a piece of the USB hub is detected here.

Code:

Dec 22 13:11:14 [kernel] drivers/usb/image/scanner.c: USB scanner device (0x04b8/0x010b)
 now attached to usb/scanner0
Dec 22 13:11:16 [udev] main: version 009
Dec 22 13:11:16 [udev] main: looking at '/devices/pci0000:00/0000:00:1f.2/usb1/1-1'
Dec 22 13:11:16 [udev] main: not a block or class device

scanner is detected, first pci hotplug events are not recognised by udev.

Code:

Dec 22 13:11:16 [udev] main: version 009
Dec 22 13:11:16 [udev] main: looking at '/class/usb/scanner0'
Dec 22 13:11:16 [udev] get_dirs: sysfs_path='/sys'
Dec 22 13:11:16 [udev] parse_config_file: reading '/etc/udev/udev.conf' as config file
Dec 22 13:11:16 [udev] namedev_init_rules: reading '/etc/udev/udev.rules.devfs' as rules
 file
Dec 22 13:11:16 [udev] namedev_init_permissions: reading '/etc/udev/udev.permissions' as
 permissions file
Dec 22 13:11:16 [udev] sleep_for_dev: looking for '/sys/class/usb/scanner0/dev'
Dec 22 13:11:16 [udev] get_class_dev: looking at '/sys/class/usb/scanner0'
Dec 22 13:11:16 [udev] get_class_dev: class_dev->name='scanner0'
Dec 22 13:11:16 [udev] get_major_minor: dev='180:48_'
Dec 22 13:11:16 [udev] get_major_minor: found major=180, minor=48
Dec 22 13:11:16 [udev] sysfs_path_is_link: stat() failed_
                - Last output repeated 3 times -
Dec 22 13:11:16 [udev] namedev_name_device: sysfs_device->path='/sys/devices/pci0000:00/
0000:00:1f.2/usb1/1-1/1-1:1.0'
Dec 22 13:11:16 [udev] namedev_name_device: sysfs_device->bus_id='1-1:1.0'
Dec 22 13:11:16 [udev] namedev_name_device: sysfs_device->bus='usb'
Dec 22 13:11:16 [udev] build_kernel_number: kernel_number='0'

Everthing about the device is detected by udev.

Code:

Dec 22 13:11:16 [udev] namedev_name_device: name, 'scanner0' is going to have owner='',
group='', mode = 0666

Here it goes through the rules, however it doesn't seem to work on my system yet. So it uses the name that the kernel gave to the device.

Code:

Dec 22 13:11:16 [udev] udev_add_device: name='scanner0'
Dec 22 13:11:16 [udev] create_node: mknod(/udev/scanner0, 020666, 180, 48)
Dec 22 13:11:16 [udev] create_node: chmod(/udev/scanner0, 020666)

The actual device is created.

Anyway maybe an error will show up on your config.
Back to top
View user's profile Send private message
Decibels
Veteran
Veteran


Joined: 16 Aug 2002
Posts: 1623
Location: U.S.A.

PostPosted: Mon Dec 22, 2003 4:55 pm    Post subject: Reply with quote

Nope still don't work! Thanks for the info on the debug and syslog though. Due to the bug in sysfsutils-0.4.0 had to reemerge 0.3.0, then udev-009, then back to 0.4.0.

Tried my usb mouse and scanner, both don't produce devices in /udev
My mouse is set to /dev/usb/mice in XF86Config-4 file, but get:
Code:
Dec 22 10:30:38 c1404124-a udev[6307]: main: version 009
Dec 22 10:30:38 c1404124-a udev[6307]: main: no devpath?
Dec 22 10:30:38 c1404124-a udev[6321]: main: version 009
Dec 22 10:30:38 c1404124-a udev[6321]: main: looking at '/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'
Dec 22 10:30:38 c1404124-a udev[6321]: main: not a block or class device
Dec 22 10:30:38 c1404124-a udev[6331]: main: version 009
Dec 22 10:30:38 c1404124-a udev[6331]: main: looking at '/devices/pci0000:00/0000:00:07.2/usb1/1-1'
Dec 22 10:30:38 c1404124-a udev[6331]: main: not a block or class device
Dec 22 10:30:40 c1404124-a modprobe: FATAL: Module mousedev not found.
Dec 22 10:30:40 c1404124-a udev[6364]: main: version 009
Dec 22 10:30:40 c1404124-a udev[6364]: main: looking at '/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0'
Dec 22 10:30:40 c1404124-a udev[6364]: main: not a block or class device
Dec 22 10:30:40 c1404124-a udev[6371]: main: version 009
Dec 22 10:30:40 c1404124-a udev[6371]: main: no devpath?
Dec 22 10:30:42 c1404124-a udev[6373]: main: version 009
Dec 22 10:30:42 c1404124-a udev[6373]: main: looking at '/devices/pci0000:00/0000:00:07.2/usb1/1-1'
Dec 22 10:30:42 c1404124-a udev[6373]: main: not a block or class device


Scanner is Microtek xsane uses scsi for it and picks /dev/sg0 (sane-find-scanner), but produces (sorry for the long output):

Code:
Scanner
Dec 22 10:31:15 c1404124-a udev[6381]: main: version 009
Dec 22 10:31:15 c1404124-a udev[6381]: main: looking at '/class/scsi_device/0:0:0:0'
Dec 22 10:31:15 c1404124-a udev[6381]: get_dirs: sysfs_path='/sys'
Dec 22 10:31:15 c1404124-a udev[6381]: parse_config_file: reading '/etc/udev/udev.conf' as config file
Dec 22 10:31:15 c1404124-a udev[6381]: namedev_init_rules: reading '/etc/udev/udev.rules' as rules file
Dec 22 10:31:15 c1404124-a udev[6381]: namedev_init_permissions: reading '/etc/udev/udev.permissions' as permissions file
Dec 22 10:31:15 c1404124-a udev[6381]: udev_remove_device: '/class/scsi_device/0:0:0:0' not found in database, falling back on default name
Dec 22 10:31:15 c1404124-a udev[6381]: udev_remove_device: name is '(null)'
Dec 22 10:31:15 c1404124-a udev[6395]: main: version 009
Dec 22 10:31:15 c1404124-a udev[6395]: main: looking at '/class/scsi_host/host0'
Dec 22 10:31:15 c1404124-a udev[6395]: get_dirs: sysfs_path='/sys'
Dec 22 10:31:15 c1404124-a udev[6395]: parse_config_file: reading '/etc/udev/udev.conf' as config file
Dec 22 10:31:15 c1404124-a udev[6395]: namedev_init_rules: reading '/etc/udev/udev.rules' as rules file
Dec 22 10:31:15 c1404124-a udev[6395]: namedev_init_permissions: reading '/etc/udev/udev.permissions' as permissions file
Dec 22 10:31:15 c1404124-a udev[6395]: udev_remove_device: '/class/scsi_host/host0' not found in database, falling back on default name
Dec 22 10:31:15 c1404124-a udev[6395]: udev_remove_device: name is '(null)'
Dec 22 10:31:15 c1404124-a udev[6409]: main: version 009
Dec 22 10:31:15 c1404124-a udev[6409]: main: looking at '/devices/pci0000:00/0000:00:07.2/usb1/1-2/1-2:1.0'
Dec 22 10:31:15 c1404124-a udev[6409]: main: not a block or class device
Dec 22 10:31:15 c1404124-a udev[6419]: main: version 009
Dec 22 10:31:15 c1404124-a udev[6419]: main: looking at '/devices/pci0000:00/0000:00:07.2/usb1/1-2'
Dec 22 10:31:15 c1404124-a udev[6419]: main: not a block or class device
Dec 22 10:31:15 c1404124-a udev[6422]: main: version 009
Dec 22 10:31:15 c1404124-a udev[6422]: main: looking at '/devices/legacy/host0/0:0:0:0'
Dec 22 10:31:15 c1404124-a udev[6422]: main: not a block or class device
Dec 22 10:31:17 c1404124-a udev[6453]: main: version 009
Dec 22 10:31:17 c1404124-a udev[6453]: main: looking at '/devices/pci0000:00/0000:00:07.2/usb1/1-2/1-2:1.0'
Dec 22 10:31:17 c1404124-a udev[6453]: main: not a block or class device
Dec 22 10:31:18 c1404124-a udev[6461]: main: version 009
Dec 22 10:31:18 c1404124-a udev[6461]: main: looking at '/class/scsi_host/host1'
Dec 22 10:31:18 c1404124-a udev[6461]: get_dirs: sysfs_path='/sys'
Dec 22 10:31:18 c1404124-a udev[6461]: parse_config_file: reading '/etc/udev/udev.conf' as config file
Dec 22 10:31:18 c1404124-a udev[6461]: namedev_init_rules: reading '/etc/udev/udev.rules' as rules file
Dec 22 10:31:18 c1404124-a udev[6461]: namedev_init_permissions: reading '/etc/udev/udev.permissions' as permissions file
Dec 22 10:31:18 c1404124-a udev[6461]: sleep_for_dev: looking for '/sys/class/scsi_host/host1/dev'
Dec 22 10:31:18 c1404124-a scsi.agent[6463]: how to add device type= at /devices/legacy/host1/1:0:0:0 ??
Dec 22 10:31:18 c1404124-a udev[6474]: main: version 009
Dec 22 10:31:18 c1404124-a udev[6474]: main: looking at '/devices/legacy/host1/1:0:0:0'
Dec 22 10:31:18 c1404124-a udev[6474]: main: not a block or class device
Dec 22 10:31:18 c1404124-a udev[6481]: main: version 009
Dec 22 10:31:18 c1404124-a udev[6481]: main: looking at '/class/scsi_device/1:0:0:0'
Dec 22 10:31:18 c1404124-a udev[6481]: get_dirs: sysfs_path='/sys'
Dec 22 10:31:18 c1404124-a udev[6481]: parse_config_file: reading '/etc/udev/udev.conf' as config file
Dec 22 10:31:18 c1404124-a udev[6481]: namedev_init_rules: reading '/etc/udev/udev.rules' as rules file
Dec 22 10:31:18 c1404124-a udev[6481]: namedev_init_permissions: reading '/etc/udev/udev.permissions' as permissions file
Dec 22 10:31:18 c1404124-a udev[6481]: sleep_for_dev: looking for '/sys/class/scsi_device/1:0:0:0/dev'
Dec 22 10:31:19 c1404124-a udev[6461]: sleep_for_dev: looking for '/sys/class/scsi_host/host1/dev'
Dec 22 10:31:19 c1404124-a udev[6481]: sleep_for_dev: looking for '/sys/class/scsi_device/1:0:0:0/dev'
Dec 22 10:31:19 c1404124-a udev[6483]: main: version 009
Dec 22 10:31:19 c1404124-a udev[6483]: main: looking at '/devices/pci0000:00/0000:00:07.2/usb1/1-2'
Dec 22 10:31:19 c1404124-a udev[6483]: main: not a block or class device
Dec 22 10:31:20 c1404124-a udev[6461]: sleep_for_dev: looking for '/sys/class/scsi_host/host1/dev'
Dec 22 10:31:20 c1404124-a udev[6481]: sleep_for_dev: looking for '/sys/class/scsi_device/1:0:0:0/dev'


So, like said, must not be able to do anything but tty and block now, in file:/sys/devices/legacy/host2/2:0:0:0/model is: Scanner V6UPL
which is exactly what it is. I got there from the debug saying: /sys/class/scsi_device/2:0:0:0/dev' Which changed to scsi_device/2 from 1 when plugged it back in the second time. Now it is 3 (fyi)
Same with the mouse, can find it where it says also.
Going to play with /sbin/rc script a little bit.
_________________
Support bacteria – they’re the only culture some people have.”

– Steven Wright
Back to top
View user's profile Send private message
takev
n00b
n00b


Joined: 20 Dec 2003
Posts: 11
Location: Amsterdam

PostPosted: Mon Dec 22, 2003 5:06 pm    Post subject: Reply with quote

Hi,

I think that your scsi like scanner is not supported yet.
mice are now supported via /dev/input but the input devices are not supported yet by udev either.

I have the same thing with my mouse.

But that you have the block and tty devices is really promossing.

Now we just have to wait, or start helping the udev people.
Back to top
View user's profile Send private message
TheCoop
Veteran
Veteran


Joined: 15 Jun 2002
Posts: 1814
Location: Where you least expect it

PostPosted: Mon Dec 22, 2003 5:15 pm    Post subject: Reply with quote

I would help, but I dont have any C++ programming experience :(
_________________
95% of all computer errors occur between chair and keyboard (TM)

"One World, One web, One program" - Microsoft Promo ad.
"Ein Volk, Ein Reich, Ein Führer" - Adolf Hitler

Change the world - move a rock
Back to top
View user's profile Send private message
takev
n00b
n00b


Joined: 20 Dec 2003
Posts: 11
Location: Amsterdam

PostPosted: Mon Dec 22, 2003 5:27 pm    Post subject: Reply with quote

That is ok, it is written in ISO-C.
Back to top
View user's profile Send private message
TheCoop
Veteran
Veteran


Joined: 15 Jun 2002
Posts: 1814
Location: Where you least expect it

PostPosted: Mon Dec 22, 2003 5:47 pm    Post subject: Reply with quote

or C experience...
_________________
95% of all computer errors occur between chair and keyboard (TM)

"One World, One web, One program" - Microsoft Promo ad.
"Ein Volk, Ein Reich, Ein Führer" - Adolf Hitler

Change the world - move a rock
Back to top
View user's profile Send private message
derk
Guru
Guru


Joined: 10 Mar 2003
Posts: 347
Location: St Thomas Ontario

PostPosted: Mon Dec 22, 2003 10:10 pm    Post subject: Reply with quote

hi I noticed that quite a few people say the udevs does not seem to load soon enough .. I'm wondering how many added hotplug to the boot runlevel without removing it from the default runlevel as should be done.

i.e. it should only exist in the boot runlevel and not in default ..

else rc-update may not set it, to let it run soon enough.

derk
Back to top
View user's profile Send private message
takev
n00b
n00b


Joined: 20 Dec 2003
Posts: 11
Location: Amsterdam

PostPosted: Mon Dec 22, 2003 10:29 pm    Post subject: Reply with quote

actually I had hotplug in "default" only, I changed it to "boot" now.
Back to top
View user's profile Send private message
Decibels
Veteran
Veteran


Joined: 16 Aug 2002
Posts: 1623
Location: U.S.A.

PostPosted: Mon Dec 22, 2003 11:30 pm    Post subject: Reply with quote

derk wrote:
hi I noticed that quite a few people say the udevs does not seem to load soon enough .. I'm wondering how many added hotplug to the boot runlevel without removing it from the default runlevel as should be done.

i.e. it should only exist in the boot runlevel and not in default ..

else rc-update may not set it, to let it run soon enough.

derk


Good point thought derk. Something that would be good to add to the tutorial. I didn't even have mine at any runlevel before installing udev, so wasn't the issue with me, but going to put that in the tutorial. Good idea! :idea:

Okay, done, put in the tutorial.
_________________
Support bacteria – they’re the only culture some people have.”

– Steven Wright
Back to top
View user's profile Send private message
dreamer_
n00b
n00b


Joined: 27 Aug 2003
Posts: 46

PostPosted: Tue Dec 23, 2003 11:11 pm    Post subject: Reply with quote

For ppp, this thing worked for me :

Code:

mknod -m 600 /dev/ppp c 108 0


Thank you Decibels for your tutorial & script. Helped me a lot 8)

(sorry for my english )
Back to top
View user's profile Send private message
TheCoop
Veteran
Veteran


Joined: 15 Jun 2002
Posts: 1814
Location: Where you least expect it

PostPosted: Tue Dec 23, 2003 11:18 pm    Post subject: Reply with quote

udev-010 is released/set loose now
_________________
95% of all computer errors occur between chair and keyboard (TM)

"One World, One web, One program" - Microsoft Promo ad.
"Ein Volk, Ein Reich, Ein Führer" - Adolf Hitler

Change the world - move a rock
Back to top
View user's profile Send private message
Decibels
Veteran
Veteran


Joined: 16 Aug 2002
Posts: 1623
Location: U.S.A.

PostPosted: Wed Dec 24, 2003 1:51 am    Post subject: Reply with quote

dreamer_ wrote:
For ppp, this thing worked for me :

Code:

mknod -m 600 /dev/ppp c 108 0


Thank you Decibels for your tutorial & script. Helped me a lot 8)

Your Welcome :!:
Seems that a lot of people still need /dev/ppp so added it to the script. :)
_________________
Support bacteria – they’re the only culture some people have.”

– Steven Wright
Back to top
View user's profile Send private message
at_chaos
Tux's lil' helper
Tux's lil' helper


Joined: 09 Nov 2003
Posts: 149
Location: EU|Austria

PostPosted: Wed Dec 24, 2003 8:07 am    Post subject: Reply with quote

Hi,

don't know if it is needed, I only had to update to the latest baselayout to get it automatically created. Are you sure that you have already the latest baselayout?
_________________
if you stand still, you move backward
Back to top
View user's profile Send private message
Decibels
Veteran
Veteran


Joined: 16 Aug 2002
Posts: 1623
Location: U.S.A.

PostPosted: Wed Dec 24, 2003 4:11 pm    Post subject: Reply with quote

Well, tried out the ebuild for udev-010 and nothing really changes from what I can see, it does take longer to create the devices now. You can watch it in /udev about 1 device a second. At that rate when they get all the devices need in there going to take quite awhile to boot.

No new devices created, same ole same ole. Can tail syslog and still doesn't know what the hell to do with my usb mouse and usb scanner that uses scsi. You'd think that they might have had this a little further along if they were going to obsolete devfs and strip it down?!?!

takev you have to take your addition to /sbin/rc out, well maybe after 5 mins or so the thing will finish and boot. I didn't know it was taking so long to create the devices now, so didn't wait that long. I just took it out and ran the modified /etc/init.d/udev script to populate /udev .

I guess that the developers are smarter than some people gave them credit for and taking this slow, cause it only creates a few devices like block, ram, tty, console. Boy would people be screaming if they dropped it right in and said wait until your devices are supported. :lol:
_________________
Support bacteria – they’re the only culture some people have.”

– Steven Wright
Back to top
View user's profile Send private message
takev
n00b
n00b


Joined: 20 Dec 2003
Posts: 11
Location: Amsterdam

PostPosted: Wed Dec 24, 2003 4:36 pm    Post subject: Reply with quote

wel they still have devfs in the kernel for the reason that udev and sysfs are no where near finished yet.
You should also take in mind that the kernel developers probably thought, well there is only one major distribution that actually uses devfs (gentoo).

Now most of the stuff that doesn't work yet isn't actually the fault of udev, more the fault of sysfs that does produce sufficiant (or at all) information about all the devices plugged into your system.

for example: /dev/random, /dev/null, /dev/zero, etc are not supported yet either, they are not in sysfs, so they will not be created by udev.
And these things will take new kernel versions. Oh well. We'll just have to wait, or send patches to Linus.
Back to top
View user's profile Send private message
motaboy
Developer
Developer


Joined: 15 Dec 2003
Posts: 1483

PostPosted: Wed Dec 24, 2003 5:20 pm    Post subject: Reply with quote

Decibels wrote:
Well, tried out the ebuild for udev-010 and nothing really changes from what I can see, it does take longer to create the devices now. You can watch it in /udev about 1 device a second. At that rate when they get all the devices need in there going to take quite awhile to boot.

No new devices created, same ole same ole. Can tail syslog and still doesn't know what the hell to do with my usb mouse and usb scanner that uses scsi. You'd think that they might have had this a little further along if they were going to obsolete devfs and strip it down?!?!

takev you have to take your addition to /sbin/rc out, well maybe after 5 mins or so the thing will finish and boot. I didn't know it was taking so long to create the devices now, so didn't wait that long. I just took it out and ran the modified /etc/init.d/udev script to populate /udev .

I guess that the developers are smarter than some people gave them credit for and taking this slow, cause it only creates a few devices like block, ram, tty, console. Boy would people be screaming if they dropped it right in and said wait until your devices are supported. :lol:


The problem is explained on the Linux Kernel Mailinglist, the problem is that udev is TOO FAST so sometimes it receive the call from hotplug before the sysfs entry is created. eheheh. The author of udev is waiting for some changes to the sysfslib to correct this and for now he made this workaround of waiting for 1 second for every new device.
On another thread a gentoo developer says that it will not insert udev010 in the portage tree to avoid a lot of bug request at bugs.gentoo.org.
in the mailinglist there are also a lot of patch for the kernel 2.6.1 to add new device in sysfs. We have only to wait some time.

Bye!
Back to top
View user's profile Send private message
Decibels
Veteran
Veteran


Joined: 16 Aug 2002
Posts: 1623
Location: U.S.A.

PostPosted: Wed Dec 24, 2003 10:21 pm    Post subject: Reply with quote

Quote:
well there is only one major distribution that actually uses devfs (gentoo).
Nope, Mandrake also. That was discussed on one of the threads of the kernel mailing group, plus use to use it. There are others also, just haven't used them recently enough to say for sure. Came straight from Debian here. Think Debian did also, but can't remember for sure. I know it's being discussed on the mailing list also.

Says in the kernel that devfs:
Code:
It has been stripped down to a bare minimum and is only provided for
legacy installations that use its naming scheme which is
unfortunately different from the names normal Linux installations
use.
Didn't say devfs wasn't there, said stripped down.

Quote:
Now most of the stuff that doesn't work yet isn't actually the fault of udev, more the fault of sysfs that does produce sufficiant (or at all) information about all the devices plugged into your system.

Might say that about my mouse, but do find the info in /sys about my scanner, it knows the model name and other information about it. Maybe not enough, but it does correctly identify it. Think the biggest issue with it is udev/sysfs is only dealing with scsi pretty much for block devices at this time.

Yes, I know about the race condition, from the author:
Quote:
This was done to try to fix the race condition where udev beats the
kernel before it has created all of the sysfs links and files. I need
some libsysfs changes before this can be done properly, without the big
speed hit (the libsysfs people are working on it.)

Sorry if mislead, was mainly mentioning it because, some of us had added a line in /sbin/rc to test it in another way, with that line it would take much much longer to boot and appear to be locked.

Quote:
On another thread a gentoo developer says that it will not insert udev010 in the portage tree to avoid a lot of bug request at bugs.gentoo.org.
Which is why didn't report any bugs. :wink:
Plus, who in there right mind would report any more on an ebuild that was taken from gentoo.bugs, other than if the ebuild didn't work at all. It works fine, installs better than 009, which had to have sysfsutils downgraded to 0.3.0, then back to 0.4.0 after.

See you all after the holidays. :D
_________________
Support bacteria – they’re the only culture some people have.”

– Steven Wright
Back to top
View user's profile Send private message
infirit
l33t
l33t


Joined: 11 Jan 2003
Posts: 778
Location: Hoofddorp / The Netherlands

PostPosted: Thu Dec 25, 2003 2:32 pm    Post subject: UDEV 011 Reply with quote

A new version of udev has been released, below are the major changes. I have modified the 009 ebuild for 011, if somebody wants it i'l post it somewhere.

[edit]
http://www.xs4all.nl/~infirit/udev-011.ebuild

Quote:
I've released the 011 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-011.tar.gz

rpms built against Red Hat FC1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-011-1.i386.rpm
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-011-1.src.rpm

udev is a implementation of devfs in userspace using sysfs and
/sbin/hotplug. It requires a 2.6 kernel to run. Please see the udev
FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

The major changes since the 010 release are:
- The _long_ time delay on startup if you used the udev init
script is now gone. We now fork a new process of udev for
every device in the sysfs tree, causing any slow udev proceses
(due to the type of device) to be not noticeable by the user.

- The RPM package is built against klibc. If you have any
problems with this image, please let me know.

- The big "always wait 1 second" problem with the 010 release is
now pretty much fixed. I still need some libsysfs changes to
work around some of the delays I had to hard code in, but for
any device that is not a partition, and has a "device"
symlink, udev will not sleep at all. If a device does not
have a "device" symlink, we will wait around for a few seconds
to see if one is going to be created or not, and then move on.
It's the only sane way of handling the issue of not knowing
what kinds of devices have symlinks and which ones do not.

- fixed a few bugs when devices did not have a "device" symlink.
Rules were getting applied when they should not have been.

- LABEL and CALLOUT rules now no longer require the BUS key. If
the BUS key is not present, the LABEL or CALLOUT rule will be
always be checked. This allows us to use these types of rules
for devices without a "device" symlink.

- a few other minor tweaks and bug fixes too.

Thanks again to everyone who has send me patches for this release, a
full list of everyone, and their changes is below.

udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev

Daily snapshots of this tree used to be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
But that box seems to be down now. Hopefully it will be restored
someday. If anyone ever wants a tarball of the current bk tree, just
email me.

It's time to go cook the Tofurky...

thanks,

greg k-h

_________________
EASY TO INSTALL = Difficult to install, but instruction manual has pictures.
Join the adopt an unanswered post initiative today
Back to top
View user's profile Send private message
Wedge_
Advocate
Advocate


Joined: 08 Aug 2002
Posts: 3614
Location: Scotland

PostPosted: Fri Dec 26, 2003 1:55 pm    Post subject: Reply with quote

Thanks for all the information here. I hadn't tried udev for a while, but the 011 version is working fine so far (thanks for the ebuild infirit) after following Decibels guide + some other tips.
_________________
Per Ardua Ad Astra
The Earth is the cradle of the mind, but we cannot live forever in a cradle - Konstantin E. Tsiolkovsky
Gentoo Radeon FAQ
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo All times are GMT
Goto page Previous  1, 2, 3, 4 ... 28, 29, 30  Next
Page 3 of 30

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum