Hello. I want to announce new udev fork... Not far ago we decided to make a standalone version, because of recent changes in project (udev <-> systemd integration) based on udev-182

In the early times of portage's udev > 179, I had noticed : KV_min=2.6.34
I did not follow the history of the developments achieved since early > 179 versions but, I can now read in all portage ebuilds : KV_min=2.6.39

Having still a couple of 2.6.38 running, I'd be happy to read that your fork is still compatible with KV >= 2.6.34

BTW, I would be grateful if someone could point a link to any discussion supporting the increase of KV_min to 2.6.39._________________

Hello. I want to announce new udev fork... Not far ago we decided to make a standalone version, because of recent changes in project (udev <-> systemd integration) based on udev-182

In the early times of portage's udev > 179, I had noticed : KV_min=2.6.34
I did not follow the history of the developments achieved since early > 179 versions but, I can now read in all portage ebuilds : KV_min=2.6.39 8O

Having still a couple of 2.6.38 running, I'd be happy to read that your fork is still compatible with KV >= 2.6.34

BTW, I would be grateful if someone could point a link to any discussion supporting the increase of KV_min to 2.6.39.

It was the upstream guys decision, not ours. We haven't tested anything with pre 3.0 kernels, so we can't say for sure. However, if you try to run udev on 2.6.38, and it works, we'll decrease the required kernel number :)

Linus' patch is getting various ACKs right now, seems it's almost done. That thing looks easily backportable, but I'd recommend you move up to at least 3.0 anyway. _________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

Looks sane. TBH, I'd still prefer to see udev forcibly taken over and put into
usr/udev in kernel tree - I don't trust that crowd at all and the fewer
critical userland bits they can play leverage games with, the safer we are.

Looks sane. TBH, I'd still prefer to see udev forcibly taken over and put into
usr/udev in kernel tree - I don't trust that crowd at all and the fewer
critical userland bits they can play leverage games with, the safer we are.

By the way, its working great with a separate /usr (and /var), root on lvm, and (almost) complete disk encryption. The only minor irritation is that udev-190 is still trying to start alsactl before /usr is mounted. It would be nice if there was something we could do about that, like maybe alter a udev rule or make a package that fixes the rule whenever alsa is re-installed or something?

Anyway, great work on the fork guys. I really appreciate not having upstream try to dictate my partition scheme or try to push me into systemd._________________First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.

That way, alsactl is not required to run when /var is not yet mounted.

Code:

# rc-update delete alsasound
# rc-update add alsasound default

And the problem, (that has been irritating me too ) went away !

I did try that already. It seems that did not work for me.
I wonder what difference is between our setups. The only time I have not noticed this occurring is when an fscheck comes up, then I actually specifically noticed its not being started until /usr is mounted.

As I indicated before I am running udev-190. Are you one of the brave souls testing udev-9999?_________________First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.

Just to echo everyone else, and say well done to consus, greydot and khayyam for working on this.

The Doctor wrote:

By the way, its working great with a separate /usr (and /var), root on lvm, and (almost) complete disk encryption. The only minor irritation is that udev-190 is still trying to start alsactl before /usr is mounted. It would be nice if there was something we could do about that, like maybe alter a udev rule or make a package that fixes the rule whenever alsa is re-installed or something?

Going forward, that might be an issue with other things: it's the reason udev upstream started to insist udev be started after /usr et al are mounted, since rules are allowed to call on binaries or libs from any file-system, including /usr or /var (under this model, you can't have a split /usr or if you do you must run an initramfs, and deal with the same problem there instead.)

There used to be two stages to the udev bring-up, and one could explicitly call the second stage after localmount (that's what udev-postmount is for.) That was the usage-model that was deprecated last year.

Thinking about it, the patches to udev initscripts here would go nicely with this setup, since there's already patches applied to the initscripts. That gives you an initramfs option in udev.conf (defaults to "yes"). Setting it to "no" means udev is configured for startup immediately after localmount (you have to switch its run-level to boot, and add sysfs and udev-mount to sysinit.) It's been working here with official udev since last August, but that setup doesn't allow for use-cases that have traditionally required an initrd (like root-fs on lvm or encrypted.)

What it does mean, though is that /usr /var /tmp etc are mounted before udev starts, and it simply replays events ("coldplug") whenever it does start. The only difference I've noticed is the nvidia module blinks the screen when udev comes up._________________

A big Thank You to grey_dot,consus,khayyam et al.
I installed from overlay,everything works out of the box after running revdep-rebuild.
Printer,scanner,wacom tablet,mice (I have 2,wired),sound.
No problem having /usr and /var on separate partitions.

Maybe some native speaker could write a howto.

Anyway thanks again.
Gerard._________________To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download

I seem to be getting kudos where its undeserved, I'm just a user and early adopter, and my contribution has been more in terms of providing feedback and helping out those who run into issues. I'm not directly involved with the fork, grey_dot and consus should recieve full credit for that.

Truth be told I'm actually a little nervous about the whole thing, as I don't think the project is well managed. If udev-standalone is going to be a viable alternative to systemd-udev then more needs to be done to make this happen, and currently this isn't happening. There is no bug open on b.g.o and there is no liason/discussion between gentoo devs and udev-standalone devs as to how the project should proceed and what needs to happen for the project to move from overlay status to virtual/dev-manager status, or even, what issues might stand in the way of this.

I tried to broach this subject some weeks back, but as yet there has been no responce. I know it has been discussed in dev circles and it seems that (for reasons related to soname changes, and/or if udev-standalone can actually function as a "drop-in replacement") opinions seem to be that udev-standalone isn't viable. Some of this may just be lack of communication between the various parties ... which brings me full circle.

steveL wrote:

Thinking about it, the patches to udev initscripts here would go nicely with this setup, since there's already patches applied to the initscripts

steveL ... I'll look at intergrating these into udev-init-scripts in my overlay ...

Thanks for the warning khayyam.
Well you contributed a lot I think so that's why I mentioned you.
If this peters out I'll go back to udev-176.
I for one will not have systemd forced down my throat.
Never used initram,why complicate things.
Gerard_________________To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download

erm, what's that udev-176 thing people keep talking about? As far as I can see, 171-r6 is the highest pre-180 version in portage._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

@genstorm,
AFAIK 176-r6 is the highest version that allows you to have /usr & /var on separate partitions w/o an initram.
Gerard._________________To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download

Truth be told I'm actually a little nervous about the whole thing, as I don't think the project is well managed.

I have to find myself in agreement. I have no doubts regarding the quality of the fork, consus and grey_dot have done a great job, and everything works well, but I feel the fork needs to receive wider adoption. I don't know what this issue is with sonames, although I have heard it mentioned before. I was under the impression that the fork had resolved that issue. I'm surprised that this doesn't have official status within Gentoo, because many Gentoo devs have expressed their desire in some sort of solution, well here's a solution to the problem. I think it's unlikely that extracting udev from systemd will be a long-term solution to the problem.

There are also other players at stake here. Slackware is very anti-systemd and would probably be interested in this fork, and a number of people on the linux-kernel mailing list have expressed desire for a fork. Keep up the good work guys, I'm glad this exists and is working well.

EDIT: Please note, I was not so much saying that the maintainership is bad for the forked udev, but that it's a shame this does not have official status within Gentoo as a virtual. Hopefully this will soon change.

I tried to broach this subject some weeks back, but as yet there has been no responce. I know it has been discussed in dev circles and it seems that (for reasons related to soname changes, and/or if udev-standalone can actually function as a "drop-in replacement") opinions seem to be that udev-standalone isn't viable. Some of this may just be lack of communication between the various parties ... which brings me full circle.

Sorry, I had been quite busy with my.. errrr.. life. Doesn't matter though.