# udev [059-070] bug discussions

## drphibes

Looks like there were some very substantive changes for udev-059.   I just emerged 059 and I notice that when I boot, the /etc/hotplug.d/default.hotplug script complains bitterly on any reference to /dev/null, e.g. line 26.   Are there changes we need to make to hotplug to accommodate udev-059?   Note that the /dev/null device is created by udev, but it seems it is now not there when hotplug wants it.   Starting hotplug in either runlevel 'boot' or 'default' yields the same result.  I normally start both hot/coldplug in the boot runlevel.   

Looks like the default.hotplug script is now incompatibile with udev-059.Last edited by drphibes on Thu Sep 15, 2005 5:54 pm; edited 8 times in total

----------

## chenxy

same problem as you.

----------

## m0p

Run etc-update (or dispatch-conf, either or) and see if that fixes the problem. Someone had a problem like this earlier on IRC.

----------

## drphibes

No it's not that simple.   From what I am reading in the udev release-notes, the old hotplug agent is being supplanted by udev and udev rules.  In other words, when you hotplug a device, the "new" way to do things is to use /sbin/udevsend as the hotplug agent instead of /sbin/hotplug,  with udev now using rules to guide the loading of modules through this new agent.Last edited by drphibes on Thu Jul 14, 2005 9:03 pm; edited 3 times in total

----------

## didl

You can try to completele remove hotplug (and with it the default.hotplug script)

from your install leaving only udev and hotplug-base. This works fine for me.

----------

## drphibes

 *didl wrote:*   

> You can try to completele remove hotplug (and with it the default.hotplug script)
> 
> from your install leaving only udev and hotplug-base. This works fine for me.

 

did you try hotplugging something afterwards?   i would typically hotplug one or two usb devices, such as my memory stick reader....do i need to write udev rules to do what hotplug used to do?

----------

## didl

I tried my USB mouse - no problem. I didn't have to write any rules,

at least not for the mouse.

----------

## drphibes

Well, my external usb dvd drive is not detected without hotplug and, worse, coldplug depends on hotplug, i.e. emerge -C hotplug && emerge coldplug will reinstall hotplug anyway.   I am gonna mask off udev-059 and let the dust settle.  I expect many posts and bug reports on related issues.   Back to udev-058 for now.

----------

## Lawless

The new udev seems to ruin half of my system...

First here I posted that my udev script stopped working

https://forums.gentoo.org/viewtopic-t-355137.html

Now I've noticed that when I plug in my wlan usb stick the whole system suddenly gets very slow - ifconfig does not work at all and after a while the system crashes completly...

I downgraded to udev-058 but no change.

udev was the _only_ thing I had changed on the system - so it has to be related to udev....

I'm trying now a backup of my system  :Mad: 

----------

## Matteo Azzali

Same issue here (hotplug line 26) and some maybe related issues with mouse....

I'll downgrade to udev-0.58 , when I'll remember where the file for masking is located  :Embarassed: 

----------

## rm

@Matteo Azzali: that would be /etc/portage/package.mask

I'm in the process of reinstalling my system on a separate partition,

should I consider using 059 or better back off and install 058 or lower?

thx,

roel

----------

## Lawless

From the changelog

```

01 Jul 2005; Greg Kroah-Hartman <gregkh@gentoo.org> +udev-059.ebuild:

  059 release

  

  Note this is _very_ experimental still.  Not quite sure if /etc/dev.d/

  rules still run properly, but booting should still work just fine (as

  long as your boot partitions aren't under some crazy-whack rule...)

```

 :Mad: 

----------

## Headrush

 *Lawless wrote:*   

> From the changelog
> 
> ```
> 
> 01 Jul 2005; Greg Kroah-Hartman <gregkh@gentoo.org> +udev-059.ebuild:
> ...

 

Another case of people being ~x86 emerge happy without reading the changelog.

----------

## rm

in the ebuild it talking about "custom rules",

I don't have any, my new system is clean as a whistle,

I just tarred the partition, and will try 059, can easily untar 

and go on with my life  :Twisted Evil: 

roel

----------

## drphibes

 *Headrush wrote:*   

> Another case of people being ~x86 emerge happy without reading the changelog.

 

Actually I had a legitimate reason to ~ unmask udev, related to the fbsplash and 2.6.12 problems.  I run a x86 system with ~x86 packages used only for good reason.   Now if I stopped to read the package's changelog everytime a package presents itself on my emerge -Dup world list, I'd get nothing done.   My feeling is the package ought to have been hard-masked, not arch-masked if it's so experimental.  That said, there is a problem with udev-059 in so far as it interacts with the hotplug script bundle.  It's coming up in other distros.  The default.hotplug script is trying to close all the file descriptors using references to /dev/null which isn't yet available at the time the script fires.

```
exec < /dev/null
```

 to close stdin?  How about just: 

```
exec 0<&-
```

 etc.

----------

## Headrush

 *drphibes wrote:*   

> Actually I had a legitimate reason to ~ unmask udev, related to the fbsplash and 2.6.12 problems.  I run a x86 system with ~x86 packages used only for good reason.   Now if I stopped to read the package's changelog everytime a package presents itself on my emerge -Dup world list, I'd get nothing done.   

 

I use ~amd64 packages myself but you shouldn't need to run a totally ~x86 system.

You shouldn't need ~x86 for every new version of an ebuild either. (udev)

If you have a problem with fbsplash and need udev-058 for example, you should just unmask that package needed to fix your problem.

No need to accept every new unstable udev ebuild from then on.

I just think for a "core" package that is foolish and just asking for problems  :Smile: 

----------

## drphibes

So your contribution, then, is solely to tell me that my actions were foolish for installing it in the first place?   Okay.... thanks much.

----------

## Headrush

 *drphibes wrote:*   

> So your contribution, then, is solely to tell me that my actions were foolish for installing it in the first place?   Okay.... thanks much.

 

Easy. I'm trying to help you so you don't run into problems when you don't need to.

Take the foolish to mean it's a bad thing to do, nothing personal.

----------

## Lawless

Saying 'it had been better not to do it' doesn't help cause it is already done... 

As I said downgrading to the stable udev didn't solved the problem - my system is messed up - kernel panics when plugging in wlan stick, no recognition of other usb devices, udev needs nearly a minute to start (58 as well as 59...).

This is _not_ worth calling a 'testing' package.

I'm currently bootstrapping.....

----------

## unz

hey man ... if no-one tryes ~x86 packages, we were still stucked @ vanilla-sources-0.5-r2 ...

... we got problems to solve ... let's brainstorming alltogether ... IMHO  :Wink: 

----------

## Lawless

My system is ~x86 cause I'm happy testing new packages (my home server which has the mentioned problems will now become a x86 system) but when somebody writes:

"Not quite sure if /etc/dev.d/ rules still run properly"

that sounds not like a testing package to me - not in the case of a package like udev on which the whole system depends on.

For me there is still a difference between testing and unstable at least with vital packages.

----------

## Headrush

 *unz wrote:*   

> hey man ... if no-one tryes ~x86 packages, we were still stucked @ vanilla-sources-0.5-r2 ...
> 
> ... we got problems to solve ... let's brainstorming alltogether ... IMHO 

 

No one is saying not to run ~x86 packages. But if as you said: let's brainstorming alltogether, you need to read the changelog then if you're trying to help.  :Smile:  I suspect several of the users aren't using this package to help test it. (Easy people, don't view everything as absolutes, this doesn't mean everyone!)

My point is not towards people that know how to test, but more towards noobies who are blindly unmasking all versions of packages and then wondering why it stops working.

I've wasted too many comments on this  :Wink:  , back to helping in other threads.  :Very Happy: 

----------

## rm

so I did that foolish thing, ppl are talking 'bout  :Wink: 

no problems so far - but it's a test installation, not my "normal" environment.

The whole thing is at the edge.

Udev/hotplug just "pauzes" for 3-4 secs when doing it's thing, then everything goes on.

I'll see the next few days - if I have time - what gives.

bye,

roel

----------

## drphibes

They are thrashing out the bug upstream:  *Quote:*   

> 
> 
> On Sat, Jul 02, 2005 at 12:06:46PM -0700, Greg KH wrote:
> 
> > On Sat, Jul 02, 2005 at 08:55:42AM -0700, Greg KH wrote:
> ...

 

----------

## arunarunarun

 *Quote:*   

> Now I've noticed that when I plug in my wlan usb stick the whole system suddenly gets very slow - ifconfig does not work at all and after a while the system crashes completly... 
> 
> 

 

Lawless, this might be one thing that's making things slow - from the Changelog...

```
o kernel 2.6.12 has the "detached_state" attribute removed from

  sysfs, which was used to recognize sysfs population. We switched that

  to wait for the "bus" link, which is only available in kernels after 2.6.11.

  Running this udev version on older kernels may cause a short delay for

  some events. 
```

Also, https://forums.gentoo.org/viewtopic-t-355137.html and https://bugs.gentoo.org/show_bug.cgi?id=97667 might shed some more light.

----------

## Lawless

The first linked thread was mine  :Wink: 

And I have a second system with 2.6.12 and default.hotplug removed - no problems so far. It's fast as ever with udev 059. 

_But_ on that system I do not have any selfmade udev rules and scripts so I don't use hotplug functionality at all.

It is just with the other system (wlan / bluetooth dongles, pda, printers...) where all scripts showed another symptom from not working to crashing the system.

I switch this system to x86 at the moment so hopefully this problem is solved for me now or better not solved but bypassed...

----------

## apache

udev-060 is out now and solves the hotplug problem.

 *Quote:*   

> *udev-060 (03 Jul 2005)
> 
> 03 Jul 2005; Greg Kroah-Hartman <gregkh@gentoo.org>
> 
> +files/udev.conf.post_059, +udev-060.ebuild:
> ...

 

I've tested it and it works now.

----------

## drphibes

 *apache wrote:*   

> udev-060 is out now and solves the hotplug problem.
> 
>  *Quote:*   *udev-060 (03 Jul 2005)
> 
> 03 Jul 2005; Greg Kroah-Hartman <gregkh@gentoo.org>
> ...

 

Works but it sure creates strange cdrom devices now ... I get everything under the sun except a /dev/cdrom link to my ide cdrom device hdc, e.g. a /dev/cdrom1 pointing to my dvd not my cd, /dev/cdroms/cdrom0 pointing to my ide cd, but no /dev/cdrom pointing anywhere.   I do get a /dev/cdrom if I comment out the devfs-names for ide-devices rules.   I have to check bugzilla to see if anything is up there on this.   I guess another udev thread is in order.

----------

## apache

 *drphibes wrote:*   

> 
> 
> Works but it sure creates strange cdrom devices now ... I get everything under the sun except a /dev/cdrom link to my ide cdrom device hdc, e.g. a /dev/cdrom1 pointing to my dvd not my cd, /dev/cdroms/cdrom0 pointing to my ide cd, but no /dev/cdrom pointing anywhere.   I do get a /dev/cdrom if I comment out the devfs-names for ide-devices rules.   I have to check bugzilla to see if anything is up there on this.   I guess another udev thread is in order.

 

Hmm, you are right the cdrom devices directly under /dev are gone but the devices under /dev/cdroms are correct for me. Maybe you fix that with a simple symlink.

----------

## drphibes

 *apache wrote:*   

> Hmm, you are right the cdrom devices directly under /dev are gone but the devices under /dev/cdroms are correct for me. Maybe you fix that with a simple symlink.

 

Yes it's easily fixed by a local rule.  What troubles me is the config file /etc/udev/cdsymlinks.conf clearly says 

```
# We always output 'cdrom', 'dvd' etc. for the best-match devices.
```

 which I interpret as a promise to symlink /dev/cdrom to whatever udev thinks is the best device.   It does link /dev/dvd correctly, but the cdrom stuff just looks wrong:

```
/dev/cdrom1 -> /dev/sr0 (my dvd/cd burner)

/dev/cdroms/cdrom0 -> /dev/hdc (my ide cdrom)
```

If I comment out the devfs-names kernel="hd*" rule, I get:

```
/dev/cdrom -> /dev/hdc (good!) 

/dev/cdrom1 -> /dev/sr0

and no /dev/cdroms directory (fine)
```

so something odd is going on there.

----------

## apache

Ok, its seems to be a problem of udev itself.

I uncommented the OUTPUT and the NUMBERED_LINKS lines in cdsymlinks.conf but no changes, also the cdsymlinks.sh script has not been changed since udev-058. Still searching ...

----------

## apache

Welcome guys to the next round:

udev-061 is out and the cdsymlink issues is fixed now, we are all happy that udev works now without any problems and giving a big party.

But wait, there is something, YES another bug is rolling in, now /dev/dsp gets wrong permissions. In details: /dev/dsp or rather the linked /dev/sound/dsp device has now following permissions:

crw-rw----   18 root

So who the fuck is user 18? No user with that ID, but wait, there is a group with that ID and its audio. So what happened: The developers drunk a bit to much beer and then they interchanged group and user. But no need to worry, udev-062 will be released shortly  :Wink: 

----------

## apache

I think its now time to ask for the phone number of one of the developers, so that we can call him after every new release *g*

----------

## drphibes

 *apache wrote:*   

> Welcome guys to the next round:
> 
> udev-061 is out and the cdsymlink issues is fixed now, we are all happy that udev works now without any problems and giving a big party.
> 
> But wait, there is something, YES another bug is rolling in, now /dev/dsp gets wrong permissions. In details: /dev/dsp or rather the linked /dev/sound/dsp device has now following permissions:
> ...

 

Apache,  i just posted bug# 98256 on this -- udev-061 is reversing the owner/goup permissions on devices, i.e. above your owner should be root and your group should be 18 (audio), not the reverse.  Same problem for fb devices and probably others.

----------

## apache

 *drphibes wrote:*   

> Apache,  i just posted bug# 98256 on this -- udev-061 is reversing the owner/goup permissions on devices, i.e. above your owner should be root and your group should be 18 (audio), not the reverse.  Same problem for fb devices and probably others.

 

Thanks for opening a bug report about that, I didn't do that because there were already some when I found that issue. I'm becoming now a little bit angry about that bugs one after another since 058. I know that all above 058 is masked ~x86 but three errors in a row and that simple? Is nobody testing that stuff before they release it?

----------

## drphibes

 *apache wrote:*   

> Thanks for opening a bug report about that, I didn't do that because there were already some when I found that issue. I'm becoming now a little bit angry about that bugs one after another since 058. I know that all above 058 is masked ~x86 but three errors in a row and that simple? Is nobody testing that stuff before they release it?

 

There's a patch already for it.  Should come through portage soon.  I strongly agree with you that they are releasing these a bit too quickly.Last edited by drphibes on Thu Jul 07, 2005 8:40 pm; edited 1 time in total

----------

## drphibes

udev-062 is out.

----------

## apache

 *drphibes wrote:*   

> udev-062 is out.

 

Permissions are fixed now, hopefully this version is now free of such critical bugs.

----------

## JLP

After upgrading to 0.62 K3b doesn't detect my CD-R and DVD-R anymore. I'm using kernel 2.6.12-r4 and K3b 0.12.2 in KDE 3.4.1. It worked just fine with udev 0.60.

----------

## Lawless

No problems here - as root as well as an unprivileged user

Oh I just saw I have k3b 0.11... I'l try 0.12

----------

## drphibes

 *JLP wrote:*   

> After upgrading to 0.62 K3b doesn't detect my CD-R and DVD-R anymore. I'm using kernel 2.6.12-r4 and K3b 0.12.2 in KDE 3.4.1. It worked just fine with udev 0.60.

 

Looks like the issue with the devfs-names rule and cdsymlinks was fixed with udev-062.  What I would do first is to comment out any custom rules you might have had, e.g. in /etc/udev/rules.d/10-local-udev.rules, then reboot.

If you never had any custom rules, can you tell us what devices are being created for your cd/dvd devices?

EDIT: Or, it's this udev-062 permissions bug: https://bugs.gentoo.org/show_bug.cgi?id=98290

----------

## JLP

Yeah I guess this is the bug. Permissions are set to root root here.

----------

## jbjay

well,what shall we do now?after i ugraded the kernel-2.6.11 to kernel-2.6.12 usb stick does not work too many symlinks error pops up and i don't have permissions to enter the floppy:?

----------

## apache

I strongly recommend everbody who is not so familiar with that task, to downgrade to udev-058 until this bug series is over. That's another case showing that accept_keywords=~x86 is sometimes a bad thing.

----------

## apache

 *JLP wrote:*   

> Yeah I guess this is the bug. Permissions are set to root root here.

 

Hmm, permissions are set root:disk here for hdc and hdd (I have 2 dvd devices) and thats what it should be from the view of ide but it would be better, if udev seperates the removeable media from the hard disks and sets the right permissions for the different device types.

----------

## TrickerZ

it seems like it's not running the PROGRAM="/etc/udev/scripts/cdsymlinks.sh %k"

----------

## drphibes

 *TrickerZ wrote:*   

> it seems like it's not running the PROGRAM="/etc/udev/scripts/cdsymlinks.sh %k"

  all that program does is return symlink names.  You can run it interactively and nonprivileged, e.g. 

```
$ /etc/udev/scripts/cdsymlinks.sh sr0

cdrom1 cdrw dvd dvdrw
```

It returns 4 symlink names for my dvd drive on /dev/sr0

----------

## drphibes

thread renamed.

----------

## drphibes

btw i notice (at least with 062, because that's what i am running now) that the /dev/misc/rtc device (symlink /dev/rtc) is root/root 664, so i copied the rtc rule into my 10-local-udev.rules file and added GROUP="video" so that applcations like mplayer and tvtime can use the real-time clock properly..

----------

## gimpel

 *apache wrote:*   

>  *JLP wrote:*   Yeah I guess this is the bug. Permissions are set to root root here. 
> 
> Hmm, permissions are set root:disk here for hdc and hdd (I have 2 dvd devices) and thats what it should be from the view of ide but it would be better, if udev seperates the removeable media from the hard disks and sets the right permissions for the different device types.

 

same here! currently using 0.60. seems 10-local.rules gets ignored or something

----------

## apache

 *gimpel wrote:*   

>  *apache wrote:*    *JLP wrote:*   Yeah I guess this is the bug. Permissions are set to root root here. 
> 
> Hmm, permissions are set root:disk here for hdc and hdd (I have 2 dvd devices) and thats what it should be from the view of ide but it would be better, if udev seperates the removeable media from the hard disks and sets the right permissions for the different device types. 
> 
> same here! currently using 0.60. seems 10-local.rules gets ignored or something

 

If you want, you can fix this by alter the subgroup line (change group to cdrom) above the cdsymlink rules and adding another above the disk devices (with group disk).

Btw. it seems that the .permissions files are ignored too, I tried to fix the dsp issue with some permission rules in 50-udev.permissions but it didn't do that.

----------

## gimpel

 *apache wrote:*   

>  *gimpel wrote:*    *apache wrote:*    *JLP wrote:*   Yeah I guess this is the bug. Permissions are set to root root here. 
> 
> Hmm, permissions are set root:disk here for hdc and hdd (I have 2 dvd devices) and thats what it should be from the view of ide but it would be better, if udev seperates the removeable media from the hard disks and sets the right permissions for the different device types. 
> 
> same here! currently using 0.60. seems 10-local.rules gets ignored or something 
> ...

 

permissions.d/* is useless since 0.52 

i have that in my /etc/udev/rules.d/10-local.rules:

 *Quote:*   

> BUS="ide", KERNEL="hdc", GROUP="cdrw", MODE="0660", NAME="%k", SYMLINK="dvd cdroms/cdrom%n"
> 
> BUS="ide", KERNEL="hdd", GROUP="cdrw", MODE="0660", NAME="%k", SYMLINK="cdrecorder cdroms/cdrom%n"

 

and that worked fine 'till 0.58  :Confused: 

currently my "fix" (lol) is adding a chown root:cdrw on hdc and hdd in local.start  :Razz:  i somehow don't want to set all my disks to cdrw/cdrom group...

i'm sure that it's just some sort of configuration issue... but what, how and where?

----------

## apache

 *gimpel wrote:*   

> permissions.d/* is useless since 0.52 

 

Good to know that by now  :Sad: 

 *gimpel wrote:*   

> currently my "fix" (lol) is adding a chown root:cdrw on hdc and hdd in local.start 
> 
> i'm sure that it's just some sort of configuration issue... but what, how and where?

 

*lol* Thats the standard fix for every permissions problem in gentoo  :Smile: 

----------

## gimpel

humm, now i edited my /etc/udev/rules.d/10-local.rules to look like that:

 *Quote:*   

> BUS="ide", KERNEL="hdc", GROUP="cdrw", MODE="0660", PROGRAM="/etc/udev/scripts/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}"
> 
> BUS="ide", KERNEL="hdd", GROUP="cdrw", MODE="0660", PROGRAM="/etc/udev/scripts/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}"
> 
> 

 

then for fun chown'ed hdc and hdd to root:disk, and after a udevstart:

 *Quote:*   

> $ ls -l /dev/hdc
> 
> brw-rw----  1 root cdrom 22, 0  7. Jul 00:42 /dev/hdc
> 
> 

 

lol, well, at least! good knows why... looks like cdsymlinks.sh has to be called explicitly for the cdrom devices _before_ 50-udev.rules is called and sets them to root:disk or something...

btw: i don't use pam-login, -pam globally, so it shouldn't be pam causing wrong perms. don't want to reboot now, next kernel update will show  :Razz: 

----------

## manny15

Adjusting /etc/udev/rules.d/10-local.rules didn't work for me. Instead...

```

emerge =sys-fs/udev-060

udevstart

echo "=sys-fs/udev-062" >>/etc/portage/package.mask

```

That'll keep that bastard at bay! Why were the permissions adjusted anyway? I went around in circles trying to figure out why grip had quit working. Developers, please, don't do that.

----------

## apache

 *manny15 wrote:*   

> 
> 
> ```
> 
> emerge =sys-fs/udev-060
> ...

 

I don't recommend that because of the cdsymlink bug in udev-060, the last really stable version was udev-058.

----------

## manny15

oh, ok. I used 0.60 because that was the prior version I had, and it worked fine (it seems like it anyway). For some reason, I had a bad feeling when I noticed an update for udev (0.60 -> 0.62). Maybe it's from experience. But that's the sacrifice for living on the edge  :Smile: 

----------

## apache

 *manny15 wrote:*   

>  For some reason, I had a bad feeling when I noticed an update for udev (0.60 -> 0.62).

 

Well, 061 was totally broken, they removed it from portage.

----------

## drphibes

udev-063 is out.   claims to fix cdrom permission issue (bug# 98290) and raw1394 issue (bug #98824), possibly others.

----------

## drphibes

https://forums.gentoo.org/viewtopic-t-359880-start-0-postdays-0-postorder-asc-highlight-.html

another permissions concern for the hd devices.

----------

## DumbMan

Thanks drphibes, 

Here is the post:

 *Quote:*   

> 
> 
> Hi all,
> 
> The latest udev-0.63 solved the issue with the "cdrom" group (hdc and hdd are now root:cdrom)
> ...

 

Dumbman

----------

## drphibes

it is an interesting observation, that the partition block device gid != main partition gid.   my suggestion is to post a bug to  https://bugs.gentoo.org/, subject "udev 063 inconsistent gid on hd partitiion devices," copy your ls -l output and let fly.  greg will respond very quickly with comments.   he's probably watching bugzilla very carefully these days, and he's a principal udev maintainer and a gentoo dev.

----------

## apache

 *DumbMan wrote:*   

> Thanks drphibes, 
> 
> Here is the post:
> 
>  *Quote:*   
> ...

 

Oh, I think that's a clever permissions management, better then setting all to root:root. The reason why every partition is root:root is that only root should be able to mount them (just forget etc/fstab at this point). Giving root:disk to the disks theirself seperates them logically from the partitions and gives you the possibility to allow certain users disk operations without granting them root access.

----------

## DumbMan

Well, after taking a closer look at  *Quote:*   

> /etc/udev/scripts/ide-devfs.sh

  and  *Quote:*   

> /etc/udev/rules.d/50-udev.rules

  it turns out that the group distiction drive-partition is made on purpose. 

A special check is made to distinguish between drives and partitions, so I don't think it's a bug.

But I still can't see the advantage of having separate groups for drives and partitions. I mean, if I'm part of the "disk" group, and hence I can access hda, what would be the operations that I could not do to hda partitions?

apache, can you please give some examples? (sorry, I'm still a noob  :Very Happy:  )

----------

## apache

 *DumbMan wrote:*   

> But I still can't see the advantage of having separate groups for drives and partitions. I mean, if I'm part of the "disk" group, and hence I can access hda, what would be the operations that I could not do to hda partitions?
> 
> apache, can you please give some examples? (sorry, I'm still a noob  )

 

In your case there is no advantage but also no disadvantage but there are some cases where it could help. For example, I administrate some servers with shared drives (and some other applications) for currently 350 users and over night there is a cron job doing backup and maintenance operations and there I'm using that kind of permissions.

----------

## DumbMan

Thanks apache, I get the idea now.

That's why I istalled Gentoo anyway, I'm learning every day  :Very Happy: 

Dumbman

----------

## Matteo Azzali

 *Headrush wrote:*   

>  *Lawless wrote:*   From the changelog
> 
> ```
> 
> 01 Jul 2005; Greg Kroah-Hartman <gregkh@gentoo.org> +udev-059.ebuild:
> ...

 

Lol, I'm the last and only one to have old ~x86 system-wide Keyword (in make.conf)?

However, wish that all packages got bugfixed and released as fast as udev, 

got 063 and is working fine.

----------

## Gergan Penkov

A have a simple question, is it possible for someone in group disk, if the whole discs are with root:disk permission, to get a raw access for it and overwrite for example the partition table?

----------

## apache

 *Gergan Penkov wrote:*   

> A have a simple question, is it possible for someone in group disk, if the whole discs are with root:disk permission, to get a raw access for it and overwrite for example the partition table?

 

I never tried this but I think it must be possible. I will make a test with an old disk this evening.

----------

## apache

Ok, here is the answer to your question:

I didn't try to alter the disks but there is something more worrying. While it's not possible to run cat /dev/hda1 > /home/foobar/out.txt as normal user, a member of the disk group can just run cat /dev/hda > /home/foobar/out.txt .

I don't think that it's very difficult to extract what ever you want out of the outcoming file: passwords, whole files, ... The only think you will need is some knowledgement of file systems and a good program doing the rest *g*

Or with other words, members of group disk have access to the hole disk.

----------

## Gergan Penkov

I would say we must file a security-bug for this, because normally a user would receive disc group only if for example he should be able to write do cdroms or sth like this, but writing to the base hard-disc is to stay root-prerogative for the time being (at least as a default rule).

----------

## drphibes

yeah i have to agree.   ordinary users with group disk should not be able to do things like this: 

```
 dd if=/dev/zero of=/dev/hda
```

 and zero out the whole disk.

----------

## apache

Is there already a report about that or should I open a new one (just want to prevent duplicates)?

----------

## Gergan Penkov

apache I think, you could open it, because you have tested it. Probably, you must wait for drphibes to affirm, that he has not filed a bug-report for this issue or simply search the bugzilla.

----------

## apache

Ok, I will open one under Gentoo Security.

EDIT: Here is the link: https://bugs.gentoo.org/show_bug.cgi?id=100115

----------

## DerCorny

While waiting for an advise of the maintainer, think about: is this a bug or a feature? Ever thought about that you might not be supposed to add normal users to group "disk"?

----------

## apache

 *DerCorny wrote:*   

> While waiting for an advise of the maintainer, think about: is this a bug or a feature? Ever thought about that you might not be supposed to add normal users to group "disk"?

 

To my mind, disk should have root:root permissions beside you need others, but that should be set by root and not by default. Due to the recently udev permission problems some users added their standard account to group disk or they just did it because they think being in group disk gives you some speed improvement or something else ...

Again, if somebody needs that particular permissions, he knows why he needs it and can set it by himself.

----------

## Gergan Penkov

Ok, I have this objection to the feature-idea. The disc group is thought of as a last resort to reduce the possible security implication in the need of giving somebody raw access to some disc or partition. Examples: central deployed servers with vmware(qemu) and read,write access to one partition/special disc for the user, archiving software with only partition/disc-readonly access running as a cron-job and so on. This means if someone coming from another distribution makes it the same way on gentoo, he is giving an unprivileged user all the access, which he/she is needing to ruin the system. And why giving somebody or some group a simple way for privilige-escalation, all the users in disc group could simply change /etc/passwd line for root to sth like root::... instead of root:x:... (I think this was the way, if not it is that easy) and receive passwordless access?

[EDIT] I mean it with sth like dd if=..|sed ...|dd of=..., not that I think, someone could change it with vi or gedit (the partitions have the correct permissions)) :: :Smile: ))

----------

## apache

The reason why this group exists is clear and it makes sense but as Gergan said already it can be used to alter data or just erase the disk. Although this group should be used only for administrative objectives and therefore it should be assigned to users only if really needed. But fact is, that there is no warning about that in the gentoo manual and every users can be assigned to that group without any warnings.

It's nearly the same like the cdrom and cdrw group, users select this group because they need access to their cdrom and want to brun cds and some may think: Hey, I need access to my drives, so I need to be in disk group.

----------

## DerCorny

Ok, I'm saying this without any specific knowledge of udev and so on - so chances are (and history shows  :Wink: ) that i'm completely wrong with this - so don't flame me if I'm wrong. Better wait for real comments from the udev gods.

But you said yourself: "disk" group is a dangerous group and should be considered as a very last resort. This implies that _no_ normal, untrusted and unprivileged users should be in this group. Putting all disks into the "disk" group offers the advantage that we can now allow trusted users raw disk access without putting them into the "root" group.

I can hardly protect users from doing not-so-smart things. And putting users in $DANGEROUS_GROUP is such a thing.

----------

## Gergan Penkov

Don't get me wrong. I also don't want to start a flame war, it probably should simply be documented (as apache said) and there must be warnings in the emerge process, because it is a major change in priviliges of a group. 

I think that there must be a gentoo policy concerning and explaining the groups, which are used from various packages and the base system, because it is possible for an uninformed sys-admin to open a security hole in the system.

----------

## apache

 *Gergan Penkov wrote:*   

> I think that there must be a gentoo policy concerning and explaining the groups, which are used from various packages and the base system, because it is possible for an uninformed sys-admin to open a security hole in the system.

 

Exactly, that's what I thought too.

----------

## drphibes

 *DerCorny wrote:*   

> Ok, I'm saying this without any specific knowledge of udev and so on - so chances are (and history shows ) that i'm completely wrong with this - so don't flame me if I'm wrong. Better wait for real comments from the udev gods.
> 
> But you said yourself: "disk" group is a dangerous group and should be considered as a very last resort. This implies that _no_ normal, untrusted and unprivileged users should be in this group. Putting all disks into the "disk" group offers the advantage that we can now allow trusted users raw disk access without putting them into the "root" group.
> 
> I can hardly protect users from doing not-so-smart things. And putting users in $DANGEROUS_GROUP is such a thing.

 

The problem, er rather the discussion, seems to be a perceived change in the semantics of being a member of group disk.   I must admit that my notion of membership in that group had more to do with granting ordinary users write access to removable disk media.  Now this membership seems to have more "strength."   I agree the bug should have been submitted if for no other reason than to let Greg know that we are debating this point now.

----------

## apache

 *drphibes wrote:*   

> I agree the bug should have been submitted if for no other reason than to let Greg know that we are debating this point now.

 

And unfortunately a bug report is nearly the only way to do this. I just gave an example (so that the report has not been deleted immediately) and pointed to that thread.

----------

## drphibes

bit of a flame war going on in that bug report ... so let's reason this out.   i have no problem removing disk from ordinary users' group lists.   but, i need to give them rw access to my usb writer /dev/dvd -> /dev/sr0 which udev currently creates as root/disk w/perms 660.    i note there is no dvd group in /etc/group, but there is cdrom and cdrw.  i suppose i could change the gid on sr0 to cdrw, or add a 'dvd' group and use that gid, then grant dvd or cdrw membership to ordinary users an be done with group disk as far as they are concerned.   btw why isn't there a 'dvd' group?

also i do think that the partition devices (e.g. hda[1-9]) and whole disk device (e.g. hda) should be in the same group, WHATEVER that ends up being, i.e. disk or root.   it makes little sense to have them in different groups.

----------

## drphibes

thread renamed: [59-65]

My system hangs during boot on "Setting system clock to hardware clock [Local TIme] ..." after upgrade to udev-064-r1.  I had to boot from a CD and downgrade to udev-063 to straighten it out.   I'll post another bug report.

I am masking off >= 064.

EDIT: bug# 101110 postedLast edited by drphibes on Thu Aug 04, 2005 12:53 am; edited 1 time in total

----------

## eltino

udev-065 is back to taking cdrom devices out of the cdrom group... back to root:disk... Hell, such a small little package...

----------

## zerb

The same thing has been bugging me too. Why did they take cdrom devices out of that group in the first place?

----------

## gimpel

indeed 065 is fucked up again, back to 063 here.. works flawlessly

i really liked the "old" way most where one could set things in permissions.d. 

for example: you want dvd drive be accessible for group cdrom, but burner only for group cdrw... how the fscking heck can that be done atm? setting up custom rules for hdc and hdd in 10-local.rules is useless, and it really should be possible to adjust that easily, shouldn't it?

----------

## drphibes

 *gimpel wrote:*   

> indeed 065 is fucked up again, back to 063 here.. works flawlessly
> 
> i really liked the "old" way most where one could set things in permissions.d. 
> 
> for example: you want dvd drive be accessible for group cdrom, but burner only for group cdrw... how the fscking heck can that be done atm? setting up custom rules for hdc and hdd in 10-local.rules is useless, and it really should be possible to adjust that easily, shouldn't it?

 

065 is a mess, true.  I am using 063 also.  I have a custom rule for my burner to put it in cdrw.  Try these local rules: 

```
BUS=="ide",  KERNEL="hdc", PROGRAM="/etc/udev/scripts/cdsymlinks.sh %k", SYMLINK+="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}", NAME="%k", GROUP:="cdrom"

BUS=="ide",  KERNEL="hdd", PROGRAM="/etc/udev/scripts/cdsymlinks.sh %k", SYMLINK+="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}", NAME="%k", GROUP:="cdrw"
```

assuming you meant hdc=cdrom and hdd=cdrw.   That should create these devices in the right GROUP, while creating the useful symlinks also.  Note GROUP:= syntax and not GROUP= (the := syntax means "cut" -- do not process any subsequent GROUP= matches for this device).

----------

## gimpel

humm, my current 10-local.rules is:

 *Quote:*   

> BUS="ide", KERNEL="hdc", PROGRAM="/etc/udev/scripts/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}", GROUP="cdrom", MODE="0660"
> 
> BUS="ide", KERNEL="hdd", PROGRAM="/etc/udev/scripts/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}", GROUP="cdrw", MODE="0660"
> 
> 

 

so looks like i use a wrong syntax? BUS==? Group:=? very weird...

well, with your syntax it works! 

didn't know about the cut in GROUP..

thx dude!  :Smile: 

----------

## drphibes

I think the NAME key is always "terminal" as a far as the udev rule-chaining is concerned, i.e. the NAME specifier will be ignored on a rule that matches later.  Other keys like GROUP, however, keep chaining along until the last match is met and then that one is used.   Thus the := syntax (see man udev).  I was using the old prolog term "cut" as an analogy.  You'll have to experiment with the other keys to see which ones might require "cut" syntax.   The == is just like c/c++, a comparison for equality, whereas = is assignment.   Obviously you want to match on the BUS key, not assign it.

Anyhow, glad it works.   Wish I could say the same for 065.

----------

## RaZoR1394

udev 065 messed up my CD/DVD devices as well. 064 and 064-r1 are the ones which works best for me as the kde system sounds finally works so I downgraded to 064-r1.

----------

## Hobbit_HK

Works for me on 065:

```

BUS=="ide", KERNEL=="hdc", GROUP:="cdrom", MODE:="0660", PROGRAM="/etc/udev/scripts/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}"

BUS=="ide", KERNEL=="hdd", GROUP:="cdrom", MODE:="0660", PROGRAM="/etc/udev/scripts/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}"

```

----------

## seppelrockt

 *drphibes wrote:*   

> 
> 
> 065 is a mess, true.  I am using 063 also.  I have a custom rule for my burner to put it in cdrw.  Try these local rules: 
> 
> ```
> ...

 

I have tried your custom rule no. 1 with udev-058 with no sucess. I have my dvd-cdrw combo at /dev/sr0 and the group is wrongly set to disk. Of cause I have changed the rule to "scsi" and "sr0". When I just add GROUP="cdrom" to the line in 50-udev.rules it works, however. Why not with 10-local.rules?

Second, I need permissions for /dev/sg1, too for audiocd playback but could not find a rule in 50-udev-rules so I'm not sure how my custom line should look like. Is the BUS="scsi" too (as this is scsi emulation I think)?

Are there any advantages in udev-063 over 058?

----------

## Hobbit_HK

About the group thing, maybe it's because 50-udev.rules is executed after your local rules and overrides your group setting, try GROUP:= instead of GROUP= in your local rules.

----------

## seppelrockt

I already had group:= in it but it didn't work. I have tried two different versions, the first (now in cooments) is from this post and the second is the line from the original 50-udev-rules + group:= argument at the end - neither worked. Looks like 10-local-rules is not used at all?

```
~ # cat /etc/udev/rules.d/10-local.rules

# This custom udev rules should hopefully fix my group permission problems for the DVD-CDRW Combo on Dell I6000

# For further information see http://forums.gentoo.org/viewtopic-t-355069-postdays-0-postorder-asc-start-75.html

#BUS=="scsi", KERNEL="sr0", PROGRAM="/etc/udev/scripts/cdsymlinks.sh %k", SYMLINK+="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}", GROUP:="cdrom"

BUS="scsi", KERNEL="sr[0-9]*", PROGRAM="/etc/udev/scripts/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}", GROUP:="cdrom"
```

Where does udev put the log? I have enabled logging but there is nothing in /var/log and dmesg |grep -i udev doesn't show anything.

----------

## Hobbit_HK

Udev is supposed to use syslog, so maybe check log/everything to something..

And try to use == and not = in your comprasions.

----------

## seppelrockt

 *Hobbit_HK wrote:*   

> Udev is supposed to use syslog, so maybe check log/everything to something..
> 
> And try to use == and not = in your comprasions.

 

As you can see in my previous post of 10-local-rules I used == in the first try (now commented) - didn't help. To avoid syntax errors I tried the group:="cdrom" instead of group="cdrom" in the 50-udev-rules and it doesn't work. Only = works here, so maybe there a syntax changes after udev-058? 

This would meen, how do I tell udev not to overwrite entries from 10-local-rules? I commented out the line in 50-* regarding my cdrom and set in in 10-* (with GROUP="cdrom") to find out whether 10-* works but is overwritten by 50-*, but no success. Seems like 10-* is still not used. Do I have to do something else to tell udev to regarde my custom rules? Permissions for 10-* are right, btw.

----------

## Hobbit_HK

Hmm.. Maybe there was some change in versions above 058? Maybe the manual has something to say?

----------

## seppelrockt

OK, no I have udev-063 and it doesn't work out of the box but at least with the 10-local-rules like this:

```
~ # cat /etc/udev/rules.d/10-local.rules

# This custom udev rules should hopefully fix my group permission problems for the DVD-CDRW Combo on Dell I6000

# For further information see http://forums.gentoo.org/viewtopic-t-355069-postdays-0-postorder-asc-start-75.html

BUS=="scsi", KERNEL="sr[0-9]*", PROGRAM="/etc/udev/scripts/cdsymlinks.sh %k", SYMLINK+="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}", GROUP:="cdrom"

```

Will add a command to bug 98290. Thanks for your help anyway!

----------

## drphibes

 *seppelrockt wrote:*   

> OK, no I have udev-063 and it doesn't work out of the box but at least with the 10-local-rules like this:
> 
> ```
> ~ # cat /etc/udev/rules.d/10-local.rules
> 
> ...

 

The problem is that you have not specified the NAME specifier which is the key that actually triggers the creation of the node.   Add NAME="%k" and you will be fine.

----------

## seppelrockt

 *drphibes wrote:*   

>  *seppelrockt wrote:*   OK, no I have udev-063 and it doesn't work out of the box but at least with the 10-local-rules like this:
> 
> ```
> ~ # cat /etc/udev/rules.d/10-local.rules
> 
> ...

 

Thanks, it works with and without "NAME" in it. Has anybody already tested udev-066?

----------

## drphibes

You need to be cautious about udev-065-066 since he's moving to eliminate all non-standard device names.

The device-naming standard that udev is moving toward is this: 

http://www.lanana.org/docs/device-list/devices-2.6+.txt

Devices like /dev/vc/* are all going away -- and this is not without some issues.   You really need to check your /etc directory for things like /dev/vc/*.  On my box, for example, I used a grub kernel= line with 'CONSOLE=/dev/vc/1'.  That causes my box to hang when it boots since there is no /dev/vc/* anymore.   Also look at /etc/securetty, etc.     Mine is nothing but vc/? references.  I also had changed my /etc/inittab a long while back so my getty's listen on vc devices and not tty, because utmp TTY logging was wrong otherwise.   Stuff like this needs to be retrofitted back to use ttyX devices  for udev-065 and higher.   I think several system packages will have to be upgraded, e.g. shadow (file: /etc/securetty), once this becomes the norm.

Bottom line is that these are testing versions, so.... be careful.

----------

## Mustaavalkosta

 *seppelrockt wrote:*   

> Has anybody already tested udev-066?

 

Yes, and now all my cdrom-symlinks are gone.  :Crying or Very sad: 

----------

## seppelrockt

 *Mustaavalkosta wrote:*   

>  *seppelrockt wrote:*   Has anybody already tested udev-066? 
> 
> Yes, and now all my cdrom-symlinks are gone. 

 

I think I will wait for things to stabelize as my system works quite OK for now. Hope they fix it till September cause I want to install Gentoo on my parents box and udev troubles would cause many troubles there.

Did anybody know when and why the /dev/cdrom/cdromX links are gone? I still have the /dev/cdrom and such and never understood what the others are for, and for some time they are gone now ... Well I do not use the devfs tarball anymore maybe thats related.

----------

## drphibes

 *seppelrockt wrote:*   

> Did anybody know when and why the /dev/cdrom/cdromX links are gone? I still have the /dev/cdrom and such and never understood what the others are for, and for some time they are gone now ... Well I do not use the devfs tarball anymore maybe thats related.

 

/dev/cdrom/* are devfs names which he is eliminating.

----------

## RaZoR1394

I upgraded to udev 066 today and I can't get the cd/dvdroms working properly just as with 065. I know that the /dev/cdromX are gone but I've always used /dev/hda and /dev/hdb in the configs for them. I'm going back to 064-r1 again  :Sad: 

----------

## Matteo Azzali

0.67 give issues here : some rules with

PROGRAM="......." in it seems not processed (no devices....)

[SOLVED]: seems to work fine by substituting with the correct syntax, i.e.:

PROGRAM=="......."

----------

## drphibes

I upgraded to udev-067 and no cd/dvd symlinks were created at boot.  However, after the boot completes, if I login as root and manually run udevstart, the symlinks are created.  I posted bug #102669 on this issue.

----------

## svenneberka

I have the same problem with my dvb devices. No /dev/dvb structure shows up until I manually run a udevstart AFTER I have inserted the dvb modules.

----------

## bizzo

udev-067 doesn't create any disk related devices for me.  I'm running on a software raid which works fine until the system checks the root filesystem.  There's no /dev/md1 device created...nor are there any hd devices.  There is are entries in /sys/block for all the drives and software raids, and from what I can tell udevtest claims that /dev/md/1 and /dev/md1 should be created.  

I suppose a possible contributing factor is that I'm running on kernel 2.6.10-gentoo-r6.  From what I've read, 2.6.10 should work but it will be slow.  Anyway, I'm working on building a new kernel but any thoughts would be helpful...

----------

## drphibes

 *bizzo wrote:*   

> udev-067 doesn't create any disk related devices for me.  I'm running on a software raid which works fine until the system checks the root filesystem.  There's no /dev/md1 device created...nor are there any hd devices.  There is are entries in /sys/block for all the drives and software raids, and from what I can tell udevtest claims that /dev/md/1 and /dev/md1 should be created.  
> 
> I suppose a possible contributing factor is that I'm running on kernel 2.6.10-gentoo-r6.  From what I've read, 2.6.10 should work but it will be slow.  Anyway, I'm working on building a new kernel but any thoughts would be helpful...

 

udev-063 was solid for me and the last version before the huge push to convert everything over to LSB names.  Try using nothing later than 063 until the bugs are worked out.  067 is definitely buggy.

----------

## bizzo

It turns out my udev troubles were caused by ldap.  Heh, yes ldap.  Basically, if you use the supplied nsswitch.ldap file as your nsswitch.conf udevstart will stall and finally fail because an ldap server cannot be contacted (no network devices).

This is an educated guess...

Because udev is run in user space it needs a user environment so nsswitch is kicked off.  If you have nsswitch setup to check ldap then the system will try to connect to an ldap server.  Apparently ldap falls into an infinite loop until it can resolve the ldap server and udevstart has timeout of about 1 minute.  

Anyway, udev worked fine on my system once I reverted back to the default nsswitch.conf file.  I'm not doing anything unusual except for running the root filesystem on a software raid.  I suspect you can configure nsswitch to use ldap as a last resort which should  allow udev to do it's thing.  I know there are situations where you would want ldap checked first so it would be nice if udevstart somehow worked differently on boot.

----------

## drphibes

udev-068 is looking much better here.   The cd/dvd symlinks have been fixed.   The only custom rules I need at the moment are these:

/etc/udev/rules.d/90-local-udev.rules:

```
# 90-local-udev.rules

# put rtc in video group so video members can write to it

KERNEL=="rtc", MODE="0664", GROUP="video"

# put cd rw-capable devices into group cdrw

ENV{ID_CDROM_CD_RW}=="?*",  GROUP="cdrw"
```

Note that I renamed my local rules file from 10-local-udev.rules to 90-local.udev.rules so that my local rules fire AFTER the rules in 50-udev.rules.   The reason is I want the 50-udev rule:

```
BUS=="scsi",    KERNEL="sr[0-9]*", ACTION=="add", IMPORT="/sbin/cdrom_id --export $tempnode"
```

to fire first and load the udev environment with the ID_CDROM* vars for my sr0 burner.  Then I can apply my custom rule against the ID_CDROM_CD_RW to put the sr0 device into group cdrw.

I suppose one could argue that, if the new cdrom_id program sets ID_CDROM_CD_RW=1 for a device, then the default group should be cdrw not cdrom, but at least I can change it at will.

----------

## seppelrockt

Hey, udev-068 is marked stable on x86. Let's see what it brings to us  :Wink: 

----------

## drphibes

been running 068 since it came out.  it's been solid for me.   the only related quibble i have at the moment is with hdparm. the hdparm startup script tries to _open_ non-devfs named devices at boot prior to running hdparm on the device (in an effort to convince itself that the device node is legitimately tied to a real device).  this means, for example, if you have a cdrom and want to run hdparm automatically at boot against it, e.g. to turn on or off dma, under udev-068 it will only work if there's a disc in the drive (ugh!).   the workaround for me was to alter the hdparm startup script (/etc/init.d/hdparm) so as not to try and open the damn device prior to running hdparm against it.  see, with udev, the creation of the device node itself should be considered enough to allow hdparm actions at boot.  this is unlike devfs, where people may be creating their /dev devices from a tarball and the thus the device node may not be attached to a real device.  i filed a bug ( https://bugs.gentoo.org/show_bug.cgi?id=103202 ) about this but the dev INCORRECTLY marked it a dup of something else.

----------

## Clansman

I upgraded udev to 068 today and kde doesn't start anymore. There isn't any error log except if I run startkde from a failsafe X session.... output follows:

```

pjlv@archon ~ $ startkde

xset:  bad font path element (#70), possible causes are:

    Directory does not exist or has wrong permissions

    Directory missing fonts.dir

    Incorrect font server address or syntax

xset:  bad font path element (#70), possible causes are:

    Directory does not exist or has wrong permissions

    Directory missing fonts.dir

    Incorrect font server address or syntax

startkde: Starting up...

kbuildsycoca running...

libhal.c 911 : Error sending msg: No property info.category on device with id /o

rg/freedesktop/Hal/devices/ide_0_0

libhal.c 911 : Error sending msg: No property info.category on device with id /o

rg/freedesktop/Hal/devices/ide_0_0

libhal.c 911 : Error sending msg: No property info.category on device with id /o

rg/freedesktop/Hal/devices/ide_0_0

libhal.c 1205 : Error sending msg: No property volume.disc.has_audio on device w

ith id /org/freedesktop/Hal/devices/block_3_4

libhal.c 1205 : Error sending msg: No property volume.disc.has_audio on device w

ith id /org/freedesktop/Hal/devices/block_3_5

libhal.c 911 : Error sending msg: No property info.category on device with id /o

rg/freedesktop/Hal/devices/ide_0_0

kdecore (KLibLoader): WARNING: KLibrary: /usr/kde/3.4/lib/kde3/kcm_kdnssd.so: un

defined symbol: init_kdnssd

_IceTransmkdir: ERROR: Owner of /tmp/.ICE-unix must be set to root

_IceTransSocketUNIXCreateListener: mkdir(/tmp/.ICE-unix) failed, errno = 1

_IceTransMakeAllCOTSServerListeners: failed to create listener for local

KSMServer: Error listening for connections: Cannot establish any listening socke

ts

KSMServer: Aborting.

startkde: Shutting down...

klauncher: Exiting on signal 1

ICE default IO error handler doing an exit(), pid = 19085, errno = 0

startkde: Running shutdown scripts...

startkde: Done.

pjlv@archon ~ $ 

```

It seems that something changed (and looking at the RELEASE_NOTES from the udev doc directory, everything changed since 058) and kde/hal is looking for legacy device names/arguments/whatever. Tried to wipe .kde directory so that it'd build some configuration files from scratch hoping to regenerate some nicer defaults, but the result is the same.

Is this a known issue?

thanks.

[]

----------

## Matteo Azzali

Dunno if this is a bug. But rules with scripts spying /proc/bus/input/devices

(standard procedure for drivers that don'export sysfs attributes)

never work at first boot (not soft-reboot),neither when executed as last rule

(90-local.rules ). IMHO cause /proc is ready after udev, I don't know if the bug 

is my script (howtdated way to do that) and it should spy something else.

using udevstart after boot results in rule working.

----------

## Clansman

 *Matteo Azzali wrote:*   

> Dunno if this is a bug. But rules with scripts spying /proc/bus/input/devices
> 
> (standard procedure for drivers that don'export sysfs attributes)
> 
> never work at first boot (not soft-reboot),neither when executed as last rule
> ...

 

ok, brown paper bag time...

after re-re-re-reading the posted output, I saw the ERROR about ownership of /tmp/.ICE-unix and after doing udevstart, kde worked again. Not sure which of the two fixes solved the problem... will test more. Also if the .ICE-unix is reproducible, I'll investigate further and maybe do a bugreport about /etc/conf.d/bootmisc configuration on clearing /tmp. apparently .ICE-unix gets created by non-root even when X is started by kdm.

thanks once more.

[]

----------

## cylix

Well I just ran the update to 068.  All is well with the world after new links for my dvd drive with one exeption.  I am running on a notebook using an ipw2200 wireless net card.  The firmware no longer loads.  I only run stable stuff and IMOP it shouldn't be marked stable if it can't load firmware properly.

My wireless is my only internet connection so..... I'm back on 058.

```

echo "=sys-fs/udev-068" >>/etc/portage/package.mask

emerge =sys-fs/udev-058

```

That said I don't know much about udev so maybe I need to do something.  I just didn't expect to need to since it had always just worked before.  So should I bug report or is there something I should know?

Info very welcome.

----------

## kanttu

I don't know if my dvd drive problem is an udev releated one but however it's very strange and I haven't find any solution yet.

Main problem is that the dvd-data is read incorrectly and eject button doesn't work in all cases.

The whole case is explained here --> https://forums.gentoo.org/viewtopic-p-2691989.html

----------

## Matteo Azzali

**Surprise!**

It wasn't just the rule spying inside /proc/bus/input/devices to not work. (udev 068)

Both these 2 lines in my 90-local.rules:

```

KERNEL=="event*",   DRIVER=="wacom", SYMLINK+="input/tablet"

KERNEL=="event*", PROGRAM=="/etc/udev/scripts/evremote.sh %k", SYMLINK+="input/remote"

```

won't work at startup, but only after a second udev start (softreboot or udevstart).

I also tried to add %e in the end of symlink names, no luck.

The second line uses a .sh to spy /proc/bus/input/devices, but the first one just uses DRIVER key instead of SYSFS{}.

I can't use %k or %n since I need fixed device names (to plug/unplug my joypad without having these change)

----------

## elgrande71

Unable to login as root (on console).

The only workaround is to login as normal user and to invoke su (with the root password).  :Wink: 

----------

## drphibes

 *doomhammer666 wrote:*   

> Unable to login as root (on console).
> 
> The only workaround is to login as normal user and to invoke su (with the root password). 

 

The console devices changed from vcX to ttyX in udev-068.  Type tty on your console and note the device, e.g. /dev/tty1.  Then check your /etc/securetty, which determines which consoles root is allowed to login on, and make sure there is an entry for all consoles you want, e.g. tty0, tty1, etc.  That should fix your problem.

----------

## elgrande71

 *drphibes wrote:*   

>  *doomhammer666 wrote:*   Unable to login as root (on console).
> 
> The only workaround is to login as normal user and to invoke su (with the root password).  
> 
> The console devices changed from vcX to ttyX in udev-068.  Type tty on your console and note the device, e.g. /dev/tty1.  Then check your /etc/securetty, which determines which consoles root is allowed to login on, and make sure there is an entry for all consoles you want, e.g. tty0, tty1, etc.  That should fix your problem.

 

Thanks for your response.

That works.  :Wink: 

----------

## klemi

Hallo,

I habe updated yesterday to udev-o068. At this time, I have problems with my cdrom-drives. I have also installed ivman.

my fstab (this function is fine bevor updating)

```
/dev/hda1      /boot      ext2      defaults,noatime   1 2

/dev/hda5      /      ext3      noatime         0 1

/dev/hda2      none      swap      sw         0 0

/dev/hda6      /usr      ext3      noatime         0 1

/dev/hda7      /opt      ext3      noatime         0 1

/dev/hda8      /var      ext3      noatime         0 1

/dev/hda9      /home      ext3      noatime         0 1

/dev/hda10      /video      ext3      noatime         0 1

#/dev/hdc      /media/dvd   iso9660      noauto,users,exec   0 0

/dev/hdd      /media/dvdrw   iso9660      noauto,users,exec   0 0

/dev/fd0      /media/floppy   auto      noauto,rw,users,umask=007   0 0

#/dev/MO_Disk      /media/MO_Disk   vfat,ext3,ext2   noauto,users,exec   0 0

/dev/DIGIKAM_M603   /media/DIGIKAM_M603 auto      noauto,rw,users,noatime 0 0

# NOTE: The next line is critical for boot!

none         /proc      proc      defaults      0 0

# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for

# POSIX shared memory (shm_open, shm_unlink).

# (tmpfs is a dynamically expandable/shrinkable ramdisk, and will

#  use almost no memory if not populated with files

# Adding the following line to /etc/fstab should take care of this:

none         /dev/shm   tmpfs      defaults      0 0

/dev/hdc                /media/cdrom1           auto    users,exec,noauto,managed 0 0
```

```
tux ~ # ls -l /dev/dvd

lrwxrwxrwx  1 root root 3  2. Sep 2005  /dev/dvd -> hdc 
```

The new 50-udev-rules are:

```
# cdrom symlinks and other good cdrom naming

BUS=="ide",   KERNEL=="hd[a-z]", ACTION=="add", IMPORT="/sbin/cdrom_id --export $tempnode"

BUS=="scsi",   KERNEL="sr[0-9]*", ACTION=="add", IMPORT="/sbin/cdrom_id --export $tempnode"

BUS=="scsi",   KERNEL="scd[a-z]", ACTION=="add", IMPORT="/sbin/cdrom_id --export $tempnode"

ENV{ID_CDROM}=="?*",      SYMLINK+="cdrom%e", GROUP="cdrom"

ENV{ID_CDROM_CD_RW}=="?*",   SYMLINK+="cdrw%e"

ENV{ID_CDROM_DVD}=="?*",   SYMLINK+="dvd%e"

ENV{ID_CDROM_DVD_R}=="?*",   SYMLINK+="dvdrw%e" 
```

The 10-udev-rules are not used for cdrom-devices.

When I klick on ther cdrom-Button of the dektop this appears:

```
"Konnte /media/cdrom in etc/fstab oder /etc/mtab nicht finden"
```

What can I do? Must I create a rule in 10-udev-rules?

What is with the symlink cdrom?

I have add cdrom to my user-konto..

Thank for help!

----------

## drphibes

 *klemi wrote:*   

> 
> 
> ```
> /dev/hdc                /media/cdrom1           auto    users,exec,noauto,managed 0 0
> ```
> ...

 

What does ls -l /dev/cdrom* say?

Could be you need an entry in /etc/fstab for /dev/cdrom indicating a mount point ...

----------

## bravecobra

I've tried the upgrade to 068, but it didn't work for me. I have a second IDE controller on a PCI card (using the siimage kernel module which is loaded in the autoload). Attached to it are two HD's, giving me /dev/hde and /dev/hdf. Their partitions are mounted at boot-up. All was working fine on udev-058. 

After the upgrade to udev-068 these partitions aren't accessible by fsck during startup, complaining about bad superblocks. Removing them from /etc/fstab allowed me to boot again. Once in X (thus after a while) I was able to mount them without any problem. It seems that the /dev/hde* and /dev/hdf* nodes are created "too late". The /dev/hda* up to /dev/hdd (including cdroms) are detected correctly however.

Might this have to do with the new udev.rules? 

I had to downgrade to 058 again to make everything work again.  :Sad: 

----------

## drphibes

guys, post bug reports to bugzillla.  the official supporters are only a bug report away.

----------

## klemi

```
klemens@tux ~ $ ls -l /dev/cdrom1

lrwxrwxrwx  1 root root 3  3. Sep 2005  /dev/cdrom1 -> hdd
```

I think, it is'nt correct. hdd is not the right device. It is hdc. Wy is it so? I don'nt understand it.

Is it better to define static the entry for cdrom - device in fstab?

Thanks!

----------

## drphibes

 *klemi wrote:*   

> 
> 
> ```
> klemens@tux ~ $ ls -l /dev/cdrom1
> 
> ...

 

it's normal for udev to create a /dev/cdrom link to the "best" cdrom device it finds, in your case /dev/hdc.  it's also normal for udev to create a /dev/cdrom1 symlink to your burner on /dev/hdd, as well as symlinks /dev/dvd, /dev/dvdrw and /dev/cdrw.  When you click on some desktop mounting tool to mount your cdrom (hdc), the best way to make it work is to have an entry in /etc/fstab, such as: 

```
/dev/cdrom    /mnt/cdrom  (or whatever mountpoint you prefer)  ... options ...
```

it seems to me all you need is an fstab entry for /dev/cdrom to your mount point, as long as you are indeed seeing a symlink /dev/cdrom -> /dev/hdc.

----------

## Lawless

Plz don't punish me for not reading the whole thread... today I updated to udev 068 (stable) and one script stopped working.

When I plug in my pda udev should create /dev/tts/USB0 and then start a connection script. After this update the device is created _after_ running the script.

I placed the *dev script in /etc/dev.d/tts - I also tried dev.d/tty and /default as well as the RUN+= command within my 10-udev.rules.

I don't understand why this happens because I use another script for my usb printer which starts after /dev/usb/lp0 is created... no problems here... 

Help... :(

----------

## novazur

Hi,

I have a big problem with new udev 068.

I updated udev from 058 to 068, accepted all configuration modifies

But, when I reboot, udevstart give me a segmentation default

So, boot can't continu because /dev is nearly empty.

I tried to compile udev 2 times. Before reboot, I don't have any message with udevstart.

For the moment, I masked udev-068, but I need to solve that.

If someone can have a idea for me

NB : sorry for my english

----------

## drphibes

 *Lawless wrote:*   

> Plz don't punish me for not reading the whole thread... today I updated to udev 068 (stable) and one script stopped working.
> 
> When I plug in my pda udev should create /dev/tts/USB0 and then start a connection script. After this update the device is created _after_ running the script.
> 
> I placed the *dev script in /etc/dev.d/tts - I also tried dev.d/tty and /default as well as the RUN+= command within my 10-udev.rules.
> ...

 

you didn't display the details of your rule, but you might try moving that rule into a file called 90-local-udev.rules instead of 10-udev.rules, so the rule fires after the base stuff and not before.  might not work but worth a shot.  also realize that the standard names this udev wants to use are these: http://www.lanana.org/docs/device-list/devices-2.6+.txt  you should try to conform to that list now.Last edited by drphibes on Mon Sep 05, 2005 11:55 pm; edited 2 times in total

----------

## drphibes

 *novazur wrote:*   

> Hi,
> 
> I have a big problem with new udev 068.
> 
> I updated udev from 058 to 068, accepted all configuration modifies
> ...

 

What is your RC_DEVICES set to in /etc/conf.d/rc?

----------

## Lawless

10-udev.rules

```

KERNEL=="ttyUSB0", NAME=="pda"

```

which creates /dev/pda correctly (when I move the file to 60-udev.rules there is no pda device)

/etc/dev.d/pda/ppc.dev

```

if [ $ACTION == "add" ]; then

command1

command2 that needs /dev/pda

fi

if [ $ACTION == "remove" ]; then

bla

fi

```

command1 that does not need the pda device is started - so the rule and the script is correct - but command2 which depends on /dev/pda does not work because pda seems to be created after running the script.

I tried a  while [ ! -x /dev/pda ]; do sleep 1; done  but then the script runs forever. Killing it causes /dev/pda to be created... 

I thought the dev.d scripts ony exist because of udevs lazyness when creating /dev nodes

----------

## novazur

 *drphibes wrote:*   

> What is your RC_DEVICES set to in /etc/conf.d/rc?

 

```
# grep RC_DEVICES /etc/conf.d/rc

RC_DEVICES="udev"
```

----------

## drphibes

 *Lawless wrote:*   

> 10-udev.rules
> 
> ```
> 
> KERNEL=="ttyUSB0", NAME=="pda"
> ...

 

I see the rule: 

```
KERNEL=="ttyUSB[0-9]*", NAME="tts/USB%n", GROUP="tty", MODE="0660"
```

 exists in 50-udev.rules which would be the one that would fire in lieue of your rule.  I might try this approach:  Leave the default rule in place and let it create the /dev/tts/USB0 node normally.  Add a new rule in 60-local-udev.rules: 

```
KERNEL=="ttyUSB0, SYMLINK="pda", RUN+="your script"
```

  Try referencing /dev/tts/USB0 and/or /dev/pda within your script.  My guess is /dev/tts/USB0 will have been created.  The problem with rules containing the NAME key is that those rules actually create the devices.   So, if you separate the thing into two rules: one to create the node (the default rule) and one to add a symlink /dev/pda after the fact, which also runs a script, you may get lucky and have  /dev/tts/USB0 created and ready within your script.  Or, you may not.   :Wink:    Give it a try.

----------

## drphibes

 *novazur wrote:*   

>  *drphibes wrote:*   What is your RC_DEVICES set to in /etc/conf.d/rc? 
> 
> ```
> # grep RC_DEVICES /etc/conf.d/rc
> 
> ...

 

is your hard drive an ordinary drive on /dev/hda or something unusual?   i have no idea what the problem could be.....

----------

## Lawless

Argh, found the problem... the connection command uses modprobe without a path. The new udev seems to use an empty PATH... now its working again.

----------

## novazur

 *drphibes wrote:*   

> is your hard drive an ordinary drive on /dev/hda or something unusual?   i have no idea what the problem could be.....

 

Yes, my HD is really normal IDE, /dev/hda.

And that's because I don't have idea too that I need help  :Wink: 

I saw somethings about ldap, and groups that don't exist in /etc/passwd. May be it is that. I haven't tried yet.

Or maybe my grub line with fbsplash :

title=Gentoo Linux 2.6.12-gentoo-r9bs

root (hd0,6)

kernel /boot/kernel-2.6.12-gentoo-r9bs root=/dev/hda7 splash=silent,fadein,theme:livecd-2005.1 quiet video=vesafb:ywrap,mtrr,1024x768-32@70 CONSOLE=/dev/tty1

initrd /boot/fbsplash-livecd-2005.1-1024x768

don't know...

----------

## drphibes

 *novazur wrote:*   

> 
> 
> Yes, my HD is really normal IDE, /dev/hda.
> 
> And that's because I don't have idea too that I need help ;-
> ...

 

did you try using the new udev rules and scripts, or did you use your old ones? ... they are very different...

----------

## klemi

hi,

last Friday I had problems with my dvd -device (but the dvd-hardware is not ok. I had tested it with windows --> no reaction. That' s bad luck)

I have the next question for my Fujitsu MO-disk with udev-068. The storage is extern connected to USB-bus. The rewritable optical disks have differnt file systems.

I have the (old) 10-udev-rules 

```
#MO-Laufwerk

BUS=="scsi", KERNEL=="sd*", SYSFS{model}="MCM3130UB-S", NAME="usbdisk", SYMLINK+="MO_Disk", GROUP="disk"
```

My fstab:

```
/dev/MO_Disk      /media/MO_Disk   auto      noauto,users,exec,utf8,noatime   0 0
```

1.) When I switch on the MO-device with insert a disk during start-up, I can mount the device fine. 

2.) I take out the MO-Disk (manually) - MO-device is still online to USB-BUS

3.) The device MO_Disk is dissappeard

4.) I insert a new Disk 

5.) I cannot mount the device - only I put in "udevstart" in Konsole or remove the usb-cable an insert again.

Have someone an idea, to create udev-rules or fstab which works accurately.

Thank you very much.

Klemi

----------

## drphibes

 *klemi wrote:*   

> 1.) When I switch on the MO-device with insert a disk during start-up, I can mount the device fine. 
> 
> 2.) I take out the MO-Disk (manually) - MO-device is still online to USB-BUS
> 
> 3.) The device MO_Disk is dissappeard
> ...

 

did you unmount the disk before you removed it?  

```
# umount /media/MO_Disk
```

 and then eject the disk.

----------

## novazur

 *drphibes wrote:*   

> did you try using the new udev rules and scripts, or did you use your old ones? ... they are very different...

 

As I said, I accepted all updates, so, I had new config file, of course...

<EDIT>

The only solution I found to solve my problem was to comment the line :

```
KERNEL=="tpm*",   NAME="%k", OWNER="tss", GROUP="tss", MODE="0600"
```

in 50-udev.rules

because, with nss_ldap, if a user/group doesn't exist, udevstart crashes.

I found something here :

https://bugs.gentoo.org/show_bug.cgi?id=99564

I don't know if there is a better solution.

</EDIT>Last edited by novazur on Fri Sep 09, 2005 5:57 am; edited 1 time in total

----------

## macxs

Hi all,

udev068 is my first udev version, I did not upgrade from former versions. I remerged udev some times and etc-updated (=>"nothing to do") but this thing bothers me:

```

cat /etc/udev/rules.d/50-udev.rules 

# /etc/udev/udev.rules:  device naming rules for udev

#

# Gentoo specific rules

#

# There are a number of modifiers that are allowed to be used in some of the

# fields.  See the udev man page for a full description of them.

```

That file is in state empty  :Sad: 

Can someone confirm that or is it my mistake? Where can I find a predefined default rules file?

Ciao!

Marco

----------

## Raistlin

That file should not be empty... Try re-emerging udev.

Cheers, R.

----------

## macxs

As I wrote I already re-emerged it some times (about 5 times). Also no etc-update helped (=> "nothing to do").

Ciao!

Marco

----------

## wyv3rn

Try editing the file, then remerging udev?

----------

## macxs

I got a predefined file from a friend. Thanks.

----------

## drphibes

thread renamed in case anyone is having difficulty with 069 or 070.  i upgraded from 068 to 070 without incident.

----------

## stalynx

From 068 I have been unable to read from my cdrom as user... however I can mount as user.

relevant udev line

```

ENV{ID_CDROM}=="?*",            SYMLINK+="cdrom%e", GROUP="cdrom"

```

user groups

```

uid=1000(stalyn) gid=100(users) groups=10(wheel),18(audio),19(cdrom),27(video),35(games),80(cdrw),100(users),409(plugdev)

```

relevant permissions

```

lrwxrwxrwx  1 root root 3 Sep 16 08:42 cdrom -> hdb

brw-rw----  1 root cdrom 3, 64 Sep 15 14:13 hdb

```

fstab entry

```

/dev/hdb                /media/cdrecorder       auto    user,exec,noauto,manage$

```

versions

```

[ebuild   R   ] sys-fs/udev-070

[ebuild   R   ] sys-apps/hal-0.5.4

[ebuild   R   ] sys-apps/pmount-0.9.3-r3

```

any help would be greatly appreciated.

----------

## wnelson

For fstab I have for my cdrw

/dev/hdd               /mnt/cdrom   iso9660   ro,user,noauto,unhide  0      0

Walt

----------

## linkan

OK, just for info, going to try to replicate tomorrow and file a bug if it persists.

With udev 0.68-r1 my stable system wont boot, it complains about not being able to check /dev/hdb2, the normal press ctrl+D or root ruckus...

```

/dev/hdb2 = boot (ext3)

/dev/hdb3 = swap

/dev/hdb4 = / (reiserfs)

```

First time after entering root pw I tried doing a manual fsck, but it could find the device. Did a ls -l /dev/hdb* and it listed hdb[5-20], none of the ones I need  :Smile:  same thing with hda and hdd. ctrl+d to logout and it rebooted like it was supposed to.

reboot (took a loooooong time at setting up udev), repeat, but after doing ctrl+d it continued bootup, X crashed of course though, but i could log in. / was mounted, but the device didn't show in /dev, set /etc/conf.d/rc to use udev explicitly and set RC_DEVICE_TARBALL=no.

reboot (same loooooong wait at udev). won't get past setting the time.

<browse forums on laptop>

live-CD, chroot, emerge udev-058. working system again, turn on music, write this.

sleeep.

----------

## PseudoRE

i have the same problem as you linkan. im on the live cd right now looking for a solution 

i will edit this post if i find anything

----------

## jd5419

I'm having problems too, but i have a feeling that my problems are worse then yours.. i cant emerge udev-058 so things are not looking good for that box. i miss devfsd.

----------

## bakaohki

Some extra stuff to the /dev/cdrom vs /dev/cdroms/cdrom0 madness: the hdparm init script still uses the old format, so everyone should check if his or her cdrom drive is correctly set up for dma.

For the udev-68-r1 boot problems. It happened to me after a full system backup (missing partition problems), so here's what I did:

1. Live cd, chroot (etc-update, source profile) mount offline gentoo partitions.

2. delete everything from dev

3. mknod null and console

4. emerge system and/or bash udev sysfsutils baselayout sys-libs/readline sysvinit

5. etc-update and reboot

----------

## CodeHacker84

Had some trouble updating to udev-070. udevstart ended up segfaulting. Have heard some whispers about this being related to the file /etc/nsswitch.conf, but mine is exactly the same as the ones that apparently work. 

<complain>

I don't really want to mess with it too much, since udev-068-r1 works just fine. Think I'm going to keep a known-good version of udev packaged and ready to go on the root partition from now on. Doesn't it stink that an update to the device filesystem is now persistant across kernel builds...I remember when a problem like this was easily solved by downgrading to a backup kernel...didn't even require a LiveCD.

</complain>

----------

## BlueByte

udev-070 doesn't work my amd64 system! segfaults  :Sad: 

----------

## Vandroiy

Please help. I have updated udev from v68 to v70 this morning and cannot boot my system now. I get a

```
/sbin/rc: line 93: 997 Segmentation Fault  /sbin/udevstart
```

and after this it is unable to mount my root partition. It says it may have a bad superblock, but everything's fine when I mount it in Knoppix. I tried to emerge back to udev-68 but the emerge command doesn't work in the emergency console I get after this error.

Vandroiy.

----------

## nichocouk

 *Vandroiy wrote:*   

> 
> 
> ```
> /sbin/rc: line 93: 997 Segmentation Fault  /sbin/udevstart
> ```
> ...

 

Same here after update to udev70. I'm going to try to downgrade to the previous version.

For that, Vandroiy, it should be possible to mount from the Live CD, chroot and mount and stuff, and redo the emerge. Well, I'm gonna try myself and let you know...

 :Mad: 

----------

## Vandroiy

Thanks a lot, nichocouk! After chrooting I was able to downgrade to 068 and everything's fine again  :Smile: 

Vandroiy.

----------

## tomas.rollo

I got the same problems with udev 70 too. Luckily I keep one of the older kernels without udev as a boot option so I could boot via it and downgrade to 68-r1.

BTW I got terrified at the first glance when I saw messages about system being unable to read /dev/hda3, but after a boot from Slax, I found the data safe and untouched. What a relief!

If anybody asks, there's already a bug about this in bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=109789

----------

## nichocouk

Yep, I managed to boot again after downgrading to 068-r1 from Live CD.

However I am not able any more to start X... Problem with nvidia it seems, and I've re-emerged nvidia-kernel without any success. Could it be related?

Anyway I'll try again tomorrow after a new emerge sync as there is a new udev ebuild (070-r1) which should be working.

 :Cool: 

----------

## wyv3rn

I'm also having problems with udev-70 segfaulting on boot.  I believe it is trying to overstep resource limits and change the .core file size from 0 (core files disabled) to 4096 (I don't want core files all over the place) and the grsecurity kernel is denying the change.  I don't know why udev doesn't handle this situation gracefully and just say ok, no core files then.  Another machine (also using grsecurity kernel) was upgraded to udev-70 and has no problems.  I suppose I will go back to udev-68-r1 on the problem machine.

Similar to this, except it does stop everything, udev doesn't run and doesn't populate /dev:

https://forums.gentoo.org/viewtopic-t-283744-view-previous.html?sid=0d2a56aa6fc015e7e2e9acdb07ab16ee

----------

## dmpogo

 *nichocouk wrote:*   

> Yep, I managed to boot again after downgrading to 068-r1 from Live CD.
> 
> However I am not able any more to start X... Problem with nvidia it seems, and I've re-emerged nvidia-kernel without any success. Could it be related?
> 
> Anyway I'll try again tomorrow after a new emerge sync as there is a new udev ebuild (070-r1) which should be working.
> ...

 

perhaps you have deleted nvidia devices   /dev/nvidia0 and /dev/nvidiactl  along the way.  They are not created automatically now with 2.6.13 lernel, it seems. You have to do it by hand.  There was a lot of discussion of this on the forum last week.

----------

## nichocouk

Thanks dmpogo, you're right. My upgrade to 070-r1 worked smoothly and reboot was no problem any more , but I'm still having the X problem and indeed, I've lost the 2 files you mention. I'll read these threads to see how I can solve that.

Cheers,

----------

## Bob P

i got b0rked by udev-070 as well.  add that ebuild to the long list of ebuilds that have had insufficient QA.

----------

## nichocouk

 *nichocouk wrote:*   

> Thanks dmpogo, you're right. My upgrade to 070-r1 worked smoothly and reboot was no problem any more , but I'm still having the X problem and indeed, I've lost the 2 files you mention. I'll read these threads to see how I can solve that.
> 
> Cheers,

 

Just to make it clear for others who would have the same problem: I ran 

```
/sbin/NVmakedevices.sh
```

 and yipeee, all is back in place!

 :Very Happy: 

----------

## Bob P

at this point, the ebuild is fixed and has been replaced by an updated revision.  a simple fix is to just resync and emerge the newest package.

----------

## wyv3rn

I downgraded back to 68-r1 last night w/o issue.  I tried 70-r1 today and the problem is gone, works great.

----------

## Merlin8000

I just got bitten by this bug.  https://forums.gentoo.org/viewtopic-t-438226.html

I think I fixed my particular system, we'll find out in the morning when I can gain physical access to it.

----------

