# Announce: just another one udev fork

## consus

Hello. I want to announce new udev fork (link). Not far ago we decided to make a standalone version, because of recent changes in project (udev <-> systemd integration) based on udev-182 and now we have backported all valuable patches from upstream udev's git (up to 10 august).

Main advantages (compared to mainstream) are:

separate /usr works just fine

we will not drop useful features like unix-socket support

we will not try to integrate with any init system, so if you want to use sysV-init you can do it without any hacks

Ebuild and patches for udev-initscripts can be found at "Downloads" page.

If anyone else is interested in this project bugreports, patches and other help are appreciated.

----------

## VinzC

Sounds pretty interesting indeed. Just one question: how can we deal with packages that depend directly upon systemd? Is it possible to have an abstraction layer to those packages that would proxy systemd calls to the appropriate packages? I'm really curious.

----------

## consus

We are not planning to write such abstraction layer by ourselves, but if someone will send us patches that won't break anything -- why not?

----------

## VinzC

Sounds good anyway!

----------

## Fitzcarraldo

As I understand it, the Gentoo developers have committed to keeping OpenRC and not adopting systemd. If my understanding is correct, would it be better for the Gentoo developers to use this udev fork rather than the official udev which was merged into systemd in April?

----------

## mv

This is really the best news since sliced bread.  :Very Happy: 

I was hoping for this since Lennart admitted that the originally claimed reasons for the merge were just marketing lies with the actual purpose to force users into systemd (which was of course not a surprising opening; only surprise was that Lennart admitted it in a sense.)

So far, I was able to dump systemd and all the *kit stuff from my systems, but I was afraid that udev could be the serious obstacle, because mdev is really only a poor man's replacement for udev, not really suitable for desktops.

 *Fitzcarraldo wrote:*   

> for the Gentoo developers to use this udev fork rather than the official udev which was merged into systemd in April?

 

I hope that they will make at least a virtual: There were already discussed plans for a virtual, but rejected because with actually only one upstream (at that time) it made no sense. Probably now they should change their mind.

For marketing reasons, it appears a bit unfortunate to me that the fork keeps the same name as original udev (but maybe this is necessary due to the license?) - maybe at least something like udev-ng or udev-standalone might be allowed?

----------

## grey_dot

 *VinzC wrote:*   

> Sounds pretty interesting indeed. Just one question: how can we deal with packages that depend directly upon systemd? Is it possible to have an abstraction layer to those packages that would proxy systemd calls to the appropriate packages? I'm really curious.

 

As far as I know there are no packages depending on systemd except for those from the systemd framework (upstream udev, logind, journald, etc). Some of them might possibly be used without systemd running, though I doubt it.

 *Quote:*   

> For marketing reasons, it appears a bit unfortunate to me that the fork keeps the same name as original udev (but maybe this is necessary due to the license?) - maybe at least something like udev-ng or udev-standalone might be allowed?

 

Yeah, we already gave that a thought. I think udev-standalone would be nice.

----------

## consus

About naming: we are thinking about udev-standalone too, just haven't got any time to rename it -- there are a lot of commits between 182 and 189 and not all of them were good enough  :Smile:  It gonna be fixed soon.

----------

## asturm

I'm all for it.

we should have a poll on the name. what about 'moodev'?

@mv: do you have a link?  :Smile: 

----------

## aidanjt

 *grey_dot wrote:*   

> As far as I know there are no packages depending on systemd except for those from the systemd framework (upstream udev, logind, journald, etc). Some of them might possibly be used without systemd running, though I doubt it.

 

That'll probably change as Poettering uses his Red Hat clout to contaminate other open source projects.  All his crap has ruined Linux, though, and I'd see all his crap booted out of the ecosystem.

----------

## Ant P.

I had a name ready in the event something like this happened: µdev.

Good luck with the project, sounds like people like it already.

----------

## Jaglover

Like is understatement, try love.  :Wink: 

----------

## PaulBredbury

 *consus wrote:*   

> bugreports

 

I'm running it now  :Smile: 

Not exactly a huge issue - this is missing a space:

```
./src/udevd.c:        print_kmsg("starting version" VERSION "\n");
```

----------

## grey_dot

 *PaulBredbury wrote:*   

> 
> 
> Not exactly a huge issue - this is missing a space:
> 
> ```
> ...

 

Thanks, fixed now %)

----------

## cach0rr0

 *mv wrote:*   

> 
> 
> I was hoping for this since Lennart admitted that the originally claimed reasons for the merge were just marketing lies with the actual purpose to force users into systemd (which was of course not a surprising opening; only surprise was that Lennart admitted it in a sense.)

 

link?

 *aidanjt wrote:*   

> 
> 
> That'll probably change as Poettering uses his Red Hat clout to contaminate other open source projects.  All his crap has ruined Linux, though, and I'd see all his crap booted out of the ecosystem.

 

yep. ++ times a million

anecdotally, this disease has been so virulent and toxic I've gone back from a "modern" DE, to plain ole fluxbox. Doubt they'll be fucking that one up any time soon. I don't care how much of a pain it is, I'll go back to static /dev if I have to. That faildesktop/Gnome can hijack the entirety of linux is infuriating to the point it's completely killed any enthusiasm I might have had for contributing. I just use linux now, and no longer expect to enjoy myself doing so.

----------

## asturm

Apparently he said this:

 *Quote:*   

> (Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely.)

 

----------

## grey_dot

 *aidanjt wrote:*   

> That'll probably change as Poettering uses his Red Hat clout to contaminate other open source projects.  All his crap has ruined Linux, though, and I'd see all his crap booted out of the ecosystem.

 

Mister Poettering is not a disease, he's merely a painful symptom like reactive diarrhea or something. The disease itself started a long time ago, when people started using quite useful and powerful things outside of the area of their applicability. Take a look at Bluez spoiled with dbus as an example of this. But this is not the subject of this thread.

P.S. By the way, there had been even more retarted attempts to get everything FUBAR. Back those days when DBus was not started GNOME had been using ORBit (CORBA implementation), which was attempted to be ported inside the linux kernel. Luckily, that attempt failed.

----------

## VinzC

 *cach0rr0 wrote:*   

> That faildesktop/Gnome can hijack the entirety of linux is infuriating to the point it's completely killed any enthusiasm I might have had for contributing. I just use linux now, and no longer expect to enjoy myself doing so.

 

I don't want to bother you but it's the exact opposite that should be done. If you can contribute to your favourite branch then you'd probably work at making that other side better and more attractive. Giving up before the unwanted is making it the only one rising. Maybe your contributions will greatly help, don't you think?

 *Lennart Poettering @ http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html wrote:*   

> (Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely.)

 

I'd be glad to be explained in details and understand why it would be a dead end [on non-systemd systems]. Indeed. My opinion is udev is somewhat cluttered and that rules system looks like a horrible spaghetti mess (though I love pasta). But it just needs some cleansing or rework, that's it.

What also pisses me off somehow is Gnome stuff ruling the rest of the system packages. *That* I really don't like. In the end, what will mostly distinguish distributions is only their package manager. One systemd to rule them all... just as if there were only one way to boot a machine, run services and manage hardware devices.

----------

## khayyam

 *consus wrote:*   

> Ebuild and patches for udev-initscripts can be found at "Downloads" page. If anyone else is interested in this project bugreports, patches and other help are appreciated.

 

consus ...

here is a sys-fs/udev-init-scripts ebuild with the neccessary inclusions for the conf and init.d patches. Its untested as I have't as yet built 'udev-standalone', but the patches are applied, so it should work as expected.

udev-init-scripts-16.ebuild

```
# Copyright 1999-2012 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: $

EAPI=4

inherit eutils

if [ "${PV}" = "9999" ]; then

   EGIT_REPO_URI="git://git.overlays.gentoo.org/proj/udev-gentoo-scripts.git"

   inherit git-2

fi

DESCRIPTION="udev startup scripts for openrc"

HOMEPAGE="http://www.gentoo.org"

LICENSE="GPL-2"

SLOT="0"

IUSE=""

if [ "${PV}" != "9999" ]; then

   SRC_URI="mirror://gentoo/${P}.tar.bz2"

   KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86"

fi

RESTRICT="test"

DEPEND=""

RDEPEND=">=sys-fs/udev-187

   sys-apps/openrc

   !<sys-fs/udev-186"

src_prepare() {

   epatch "${FILESDIR}"/udev-conf.diff || die "patch failed"

   epatch "${FILESDIR}"/udev-init.diff || die "patch failed"

}

pkg_postinst()

{

   # If we are building stages, add udev to the sysinit runlevel automatically.

   if use build

   then

      if [[ -x "${ROOT}"/etc/init.d/udev \

         && -d "${ROOT}"/etc/runlevels/sysinit ]]

      then

         ln -s /etc/init.d/udev "${ROOT}"/etc/runlevels/sysinit/udev

      fi

   fi

   # migration to >=openrc-0.4

   if [[ -e "${ROOT}"/etc/runlevels/sysinit \

      && ! -e "${ROOT}"/etc/runlevels/sysinit/udev ]]

   then

      ewarn

      ewarn "You need to add the udev init script to the runlevel sysinit,"

      ewarn "otherwise your system will not be able to boot"

      ewarn "after updating to >=openrc-0.4.0"

      ewarn "Run this to enable udev for >=openrc-0.4.0:"

      ewarn "\trc-update add udev sysinit"

      ewarn

   fi

   ewarn "The udev-postmount service has been removed because the reasons for"

   ewarn "its existance have been removed upstream."

   ewarn "Please remove it from your runlevels."

}
```

best ... khay

EDIT: for me the sys-fs/udev-9999 provided fails with automake: automake-1.11: cannot open < gtk-doc.make: No such file or directory. USE="-doc" is currently set.

----------

## grey_dot

 *khayyam wrote:*   

> EDIT: for me the sys-fs/udev-9999 provided fails with automake: automake-1.11: cannot open < gtk-doc.make: No such file or directory. USE="-doc" is currently set.

 

As for now, udev needs gtkdocize from gtk-doc to be run before autoconf/automake, so you have to install gtk-doc. We are working on this issue, and gtk-doc will be optional in the near future.

----------

## khayyam

 *grey_dot wrote:*   

> As for now, udev needs gtkdocize from gtk-doc to be run before autoconf/automake, so you have to install gtk-doc. We are working on this issue, and gtk-doc will be optional in the near future.

 

grey_dot ...

OK, in which case I'll hold off until that time. I did take a quick look at sys-fs/udev-9999::gentoo which likewise has USE="doc", but I don't have the time right now to see what might be required to have it work without having the kitchen sink installed, seems they are just echoing 'EXTRA_DIST =' into ("${WORKDIR}/systemd-${PV}") docs/gtk-doc.make if USE="-doc" is set, and then running elibtoolize.

best ... khay

----------

## McGruff

 *genstorm wrote:*   

> we should have a poll on the name. what about 'moodev'?

 

"betterdev"

"udeviant"

----------

## sitquietly

 *mcgruff wrote:*   

>  *genstorm wrote:*   we should have a poll on the name. what about 'moodev'? 
> 
> "betterdev"
> 
> "udeviant"

 

udder (UDev DERivative) ?

I'm so glad to see support for a unix-style startup system and will be switching to udev-standalone, or udder, as soon as possible.  systemd is infecting Archlinux, which brought me here to enjoy better engineering with openrc and udev.  With a Debian 3.2 kernel compiled with real-time patches and without any initrd my Gentoo bootup takes about half the time of my mostly identical Archlinux system.

----------

## Anon-E-moose

Nothing to add at the moment as I'm at udev-171 and wasn't planning to upgrade to anything hooked into systemd. 

Having said that, I'm glad to see someone step up and "scratch an itch". 

This is how unix has worked all along.  Kudos.

----------

## GFCCAE6xF

Very nice! I've been reading up on mdev and thinking about trying it out - I may just try this out soon instead   :Cool: 

@sitquietly

If you are who I think you are, welcome, have you finally left the makeworld manipulation behind too?   :Razz: 

----------

## khayyam

 *grey_dot wrote:*   

> As for now, udev needs gtkdocize from gtk-doc to be run before autoconf/automake, so you have to install gtk-doc. We are working on this issue, and gtk-doc will be optional in the near future.

 

grey_dot ...

I had sometime to look at the issue and it can be built without gtkdocize, so USE="-doc" does currently work. The attatched ebuild has the necessary changes required, I also had to change 'dodoc' to remove 'Changelog' and 'NEWS'  as they are nolonger in the git repo.

udev-9999.ebuild

```
# Copyright 1999-2012 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: $

EAPI="4"

EGIT_REPO_URI="https://bitbucket.org/braindamaged/udev.git"

EGIT_HAS_SUBMODULES="0"

inherit autotools eutils linux-info git-2 toolchain-funcs

DESCRIPTION="Linux dynamic and persistent device naming support (aka userspace devfs)"

HOMEPAGE="https://bitbucket.org/braindamaged/udev"

LICENSE="GPL-2"

SLOT="0"

KEYWORDS=""

IUSE="doc debug gudev hwdb introspection keymap floppy +openrc selinux static-libs"

RESTRICT="test"

# Required kernel version

KV_MIN="2.6.39"

COMMON_DEPEND="gudev? ( dev-libs/glib:2 )

   introspection? ( >=dev-libs/gobject-introspection-1.31.1 )

   selinux? ( sys-libs/libselinux )

   >=sys-apps/kmod-5

   >=sys-apps/util-linux-2.20

   !<sys-libs/glibc-2.12"

DEPEND="${COMMON_DEPEND}

   dev-util/gperf

   >=dev-util/intltool-0.40.0

   virtual/pkgconfig

   virtual/os-headers

   !<sys-kernel/linux-headers-${KV_MIN}

   doc? ( dev-util/gtk-doc )

   app-text/docbook-xsl-stylesheets

   dev-libs/libxslt"

RDEPEND="${COMMON_DEPEND}

   hwdb? ( sys-apps/hwids )

   openrc?

   (

      >=sys-fs/udev-init-scripts-16

      !<sys-apps/openrc-0.9.9

   )

   !sys-apps/coldplug

   !<sys-fs/lvm2-2.02.45

   !sys-fs/device-mapper

   !<sys-fs/udev-init-scripts-16

   !<sys-kernel/dracut-017-r1

   !<sys-kernel/genkernel-3.4.25

   !<sys-apps/systemd-188"

# Required kernel options

CONFIG_CHECK="~DEVTMPFS ~HOTPLUG ~INOTIFY_USER ~NET ~PROC_FS ~SIGNALFD ~SYSFS

   ~!SYSFS_DEPRECATED ~!SYSFS_DEPRECATED_V2 ~BLK_DEV_BSG"

## Checks current kernel version

#

# Return values:

#   0 -- Kernel is new enough

#   1 -- Kernel is too old

#

udev_check_kv() {

   kernel_is -ge ${KV_MIN//./ }

   return $?

}

pkg_setup() {

   echo

   get_version && udev_check_kv

   case $? in

      0)   einfo "Your current kernel version (${KV_FULL}) is new enough to run ${P}."

         ;;

      1)   eerror "Your current kernel version (${KV_FULL}) is too old to run ${P}."

         eerror "You need at least ${KV_MIN}."

         ;;

   esac

   KV_FULL_SRC=${KV_FULL}

   echo

   get_running_version && udev_check_kv

   case $? in

      0)   einfo "Your running kernel version (${KV_FULL}) is new enough to run ${P}."

         ;;

      1)   eerror "Your running kernel version (${KV_FULL}) is too old!"

         eerror "You need at least ${KV_MIN}."

         ;;

   esac

   

   echo

   check_extra_config

}

src_prepare() {

   # Change rules back to group uucp instead of dialout for now

   sed -e 's/GROUP="dialout"/GROUP="uucp"/g' \

      -i rules/*.rules \

      || die "failed to change group dialout to uucp"

   

   if [[ ! -e configure ]]

   then

      if use doc

      then

         gtkdocize --docdir docs || die "gtkdocize failed"

      else

         echo 'EXTRA_DIST =' > gtk-doc.make

      fi

      eautoreconf

   else

      check_default_rules

      elibtoolize

   fi

   eautoreconf

}

src_configure() {

   econf \

      --prefix="${EPREFIX}" \

      --with-rootprefix="${EPREFIX}" \

      --bindir="${EPREFIX}"/sbin \

      --sysconfdir="${EPREFIX}"/etc \

      --libexecdir="${EPREFIX}"/"$(get_libdir)" \

      --libdir="${EPREFIX}"/usr/"$(get_libdir)" \

      --with-rootlibdir="${EPREFIX}"/"$(get_libdir)" \

      --includedir="${EPREFIX}"/usr/include \

      --datarootdir="${EPREFIX}"/usr/share \

      --docdir="${EPREFIX}"/usr/share/doc/"${PF}" \

      --with-html-dir="${EPREFIX}"/usr/share/doc/"${PF}"/html \

      --with-pci-ids-path="${EPREFIX}"/usr/share/misc/pci.ids \

      --with-usb-ids-path="${EPREFIX}"/usr/share/misc/usb.ids \

      --enable-logging \

      $(use_with selinux) \

      $(use_enable debug) \

      $(use_enable doc gtk-doc) \

      $(use_enable static-libs static) \

      $(use_enable keymap) \

      $(use_enable floppy) \

      $(use_enable gudev) \

      $(use_enable introspection)

}

src_install() {

   emake DESTDIR="${D}" install

   

   # Install documentation

   dodoc COPYING README INSTALL TODO

   # Install gentoo-specific rules

   insinto /"$(get_libdir)"/udev/rules.d

   doins "${FILESDIR}"/40-gentoo.rules

}

pkg_postinst() {

   # Create rundir for udev

   mkdir -p "${ROOT}"/run

}
```

best ... khay

EDIT: I've created an overlay on github with both the sys-fs/udev and sys-fs/udev-init-scripts ebuids above ... incase anyone is interested: khayyam-overlay

----------

## cach0rr0

 *VinzC wrote:*   

> If you can contribute to your favourite branch then you'd probably work at making that other side better and more attractive. Giving up before the unwanted is making it the only one rising. Maybe your contributions will greatly help, don't you think?

 

perhaps. But I am a little fish, and the desktop does not butter my bread. We've lost udev, and unless someone pulls rank on Poettering, with it we lose the desktop. Money, is what talks. If RH Inc begins to lose money over this, heads will roll, and the necessary walkbacks will happen. Their enterprise customers should raise holy hell over this. Along the lines of, "Hi, we're a Fortune 500 company, we rely on you to provide us a stable secure server platform for our critical business infrastructure. Why the fuck is Gnome development even involved, and why are you changing a critical component of our server platform for the sake of a fucking desktop environment?" That, is the best contribution anyone can make to this. 

 *VinzC wrote:*   

> What also pisses me off somehow is Gnome stuff ruling the rest of the system packages. *That* I really don't like. In the end, what will mostly distinguish distributions is only their package manager. One systemd to rule them all... just as if there were only one way to boot a machine, run services and manage hardware devices.

 

it's braindead. Completely and totally braindead. Device management is not simply a novelty item for desktop users. Linux makes its money as a server platform. Server platforms also need a dev manager. It's as though they've forgotten the world even exists outside of a home user's desktop, that people actually use linux for something other than running Gnome. How in the blue fuck someone thought it was a great idea to let THAT drive development is completely baffling to me.

And this is a perfect example:

 *grey_dot wrote:*   

> 
> 
> As for now, udev needs gtkdocize from gtk-doc to be run before autoconf/automake, so you have to install gtk-doc. 

 

^^what in the blue fuck should gtk have to do with udev? why is gtk infesting a device management system? 

(NB: grey_dot, that isn't directed at you, by the way. I'm just using the example of udev defaulting to relying on gtk-doc to hammer home the point of the amount of stupid that's made its way into udev. Pretty soon we'll see Frozen Bubble as a build dependency for udev)

----------

## sitquietly

 *PSYKORGASM wrote:*   

> Very nice! I've been reading up on mdev and thinking about trying it out - I may just try this out soon instead  
> 
> @sitquietly
> 
> If you are who I think you are, welcome, have you finally left the makeworld manipulation behind too?  

 

Good to be here.

Uh, well, I'm known as sitquietly in the Arch forums too (the guy from Moscow Tennessee).  I bought a SanDisk Extreme ssd for Gentoo and do maintain my Arch from-source install on my old Intel X-25E ssd.  Maintaining the Arch system is not too demanding for me since I'm maintaining a database of all Archlinux packages (abs + aur) and use some custom scripts for maintenance, but customizing Arch pkgbuilds requires that I manually carry forward my local changes using meld: it's semi-automated and not remotely as nice as the portage system.

I'm still playing with both my custom Archlinux and with Funtoo to make sure I "know what I'm talking about."  So far I can say that Funtoo/Gentoo has far superior engineering in its ebuilds than Arch's pkgbuilds, a proper o.s. development model, a more flexible and useful system maintenance technology, better kernels, more packages.  It is probably the right basis for what I'm building, a purpose-built scientific linux suitable for autonomous systems, e.g. off-grid, off-the-radar applications or deep-space missions  :Smile: 

There is much discussion over in the Archlinux forum about the speed of bootup with systemd.  It seems, well, nuts to me.  I got my Intel Sandybridge i5 bootup time (grub prompt to linux console prompt) down from 17.8 seconds with Archlinux to 8.5 seconds with Funtoo using a simple, reliable (no initrd) kernel (debian-sources 3.2.23 with the realtime patches) with Gentoo OpenRC/udev.  

I assume you are Psykorgasm in the Archlinux forum, the guy from England...

You should have gone with Funtoo, try it again.

----------

## khayyam

 *cach0rr0 wrote:*   

> And this is a perfect example:
> 
>  *grey_dot wrote:*   As for now, udev needs gtkdocize from gtk-doc to be run before autoconf/automake, so you have to install gtk-doc. 
> 
> ^^what in the blue f*** should gtk have to do with udev? why is gtk infesting a device management system? 
> ...

 

cach0rr0 ... this isn't actually the case though, grey_dot was mistaken. Its just an automake issue that appears when running elibtoolize. Its easily fixed (see the ebuild above).

Otherwise, I agree, far too much user facing gumpf is being pushed deeper and deeper into the OS, and it shouldn't be there, no does it need to be. The problem, as I see it, is that the very concept of 'the desktop' is from an altogether different paradigm to 'unix', so its very much like mixing water and oil, they will seperate out unless you agitate constantly. So the dream of the 'Desktop OS' (and the desktop in general) with its 'unix underpinnings' is, I think, a failed one, but it none the less still has a strong following, and it is this as much as the developers that are driving this madness.

best ... khay

----------

## grey_dot

 *cach0rr0 wrote:*   

>  *grey_dot wrote:*   
> 
> As for now, udev needs gtkdocize from gtk-doc to be run before autoconf/automake, so you have to install gtk-doc.  
> 
> ^^what in the blue fuck should gtk have to do with udev? why is gtk infesting a device management system? 
> ...

 

gtk-doc is a documentation generator, it does not need gtk to work and it is not a runtime dependency. Besides, I've just made it optional. So, if you do not need api documentation, you have nothing to worry about.

 *khayyam wrote:*   

> I had sometime to look at the issue and it can be built without gtkdocize, so USE="-doc" does currently work. 

 

It was still needed at that time. And we have not /docs directory, thus gtkdocize must be run without arguments. Check autogen.sh script in the repo.

----------

## Hypnos

khay,

Good observation.

The Unix philosophy is about modularity and clarity -- i.e, developer/power user friendly.  A toolbox.

The aim of the "Desktop OS" is integration and opacity -- i.e., "grandma" friendly.  An appliance.

That said, OSX and Android seem to accomplish the feat of layering a desktop on a Unix base.  How do they manage?  Do they require the same cruft in the Unix layer that GNOME is pushing for?

----------

## VinzC

udemand (Unix DEvice MANager Daemon). You have.

Or even Udemand is a DEvice MANager Daemon.

 *khayyam wrote:*   

> its very much like mixing water and oil, they will seperate out unless you agitate constantly.

 

I very much like this comparison. They've already started to separate judging from what we're talking about. And if we consider making much noise around this very topic, it would compare to agitation.  :Wink: 

I'd add to what cach0rr0 said, what I have learnt from Linux (and possibily UNIX) is to minimize dependencies and functionalities for greater independence. Making a desktop system rely upon one given system manager is breaking that barrier. Not only does it taint all distributions but it also enforces unwanted and unneeded dependencies from the system management point of view. Unifying all platforms might be not a bad idea IMHO but only if you stay on the user's desktop side.

Gnome devs didn't listen to their user base. Now they're back doing the same with system admins, breaking independence. That's very sad.

----------

## khayyam

 *grey_dot wrote:*   

>  *khayyam wrote:*   I had sometime to look at the issue and it can be built without gtkdocize, so USE="-doc" does currently work.  
> 
> It was still needed at that time. And we have not /docs directory, thus gtkdocize must be run without arguments. Check autogen.sh script in the repo.

 

grey_dot ... I did look at the autogen.sh and though no */docs exist the gtk-doc.make is looked for by automake in the directory where its run and so the above ebuild works. Of course, I may have did my 'ebuild udev-9999.ebuild compile' at a time after any commits were made, but from what I could gleen from udev-9999::gentoo this is also how they avoid the need for gtkdocize, and so I think your mistaken that it won't compile without it, but no biggy.

 *Hypnos wrote:*   

> [...] OSX and Android seem to accomplish the feat of layering a desktop on a Unix base. How do they manage? Do they require the same cruft in the Unix layer that GNOME is pushing for?

 

Imagine your hand as a pointing device, you can point at an object, direct it, etc, and some invisible force does all the work necessary to follow your directions, but as the hand has now become a pointing device it can nolonger be used in all other capacities, you can nolonger 'gasp' as the pointing device is now a single-mode device, a pointer. Your hand, which you could use for myrid forms of manipulation (aquired from years of evolution, and use) has been subsituted for a prothesis. Some will say, well, look how much easier it is to use a pointing device, anybody can use it, it doesn't require years/millenia of training, practice, use ... plug & play.

This analogy (though admittedly stretched) is exactly the one used in all "ease of use", "usablitity", models, its so easy my 6 year old child could use it, etc, etc. But with this "use" comes, like the above pointing device, a 'single mode' clause, its nolonger a matter of actual use (skill aquisition, learning, etc) but a prosthesis for all possible use senarios. This is the 'fail' I was pointing to above, and I don't think OSX and Android have accomplished anything in this regard. The very idea of "layering" a pointing device on top of a device like the hand has already failed. This very idea has been central to computing since the '70's, and its mostly driven by the desire for market share than any kind of design principle, its the mantra for all kinds of dead end 'usability design', but of course in this model the user is a total abstraction.

 *VinzC wrote:*   

>  *khayyam wrote:*   [...] its very much like mixing water and oil, they will seperate out unless you agitate constantly. 
> 
> I very much like this comparison. They've already started to separate judging from what we're talking about. And if we consider making much noise around this very topic, it would compare to agitation.

 

But everyone knows that oil and water don't mix (at least without an emusifier) ... my analogy was that the 'unix' and 'desktop' models are in stark contrast to each other, and that the attempt to mix them is only really an illusion born of someone adjitating the mixture enough to say "see, they do mix".

best ... khay

----------

## PaulBredbury

Stop polluting this thread! Start a "We hate LP" or "Philosophy of computer devices" thread in Off The Wall, if you must get it off your chest  :Evil or Very Mad: 

Edit: Here's the zoo thread, for the monkeys to play in.

----------

## Anon-E-moose

I have been doing some reading on systemd since the start of this thread. 

I'm glad that the fork is taking place. 

For one I am running basically a single user system and 

don't have consolekit, cgroups, etc enabled on my box.

----------

## DaggyStyle

I'm going to watch this thread because I don't like that /usr, /var on different partitions needs initramfs.

also I don't like someone shoving his views into other's throat with no shred of consideration on how it will affect them.

I like current openrc and I intend to keep it although it seems that systemd is good for me as I use multiseat setup.

hope that I can enjoy both worlds in the end, if not, I'll be happy to give up on systemd.

great job! keep it up.

----------

## krinn

i'm going to watch this thread because i like openrc simplicity and it just work. And i dislike the udev/systemd... One Ring

i really feel like the dark prophet now after reading that thread.

----------

## hcaulfield57

This is a great development. Good luck, I hope to see this succeed and become mainstream!

----------

## The Doctor

Excellent. I don't suppose any devs could comment on when we can expect this to hit the unstable branch?

----------

## grey_dot

Guys, I'm really glad this fork is appreciated and somebody is going to use it. You may direct your bugreports, feature requests, patches, and other related stuff to our bugtracker (https://bitbucket.org/braindamaged/udev/issues) or directly to me. Thanks for your support.

----------

## cach0rr0

you know i did forget to say this betwixt my rants - 

thank you guys for doing this. I hope this takes off like gangbusters. I am too time-constrained right now to do any "early adopter" stuff, but this is exactly what I'd been hoping someone would do, and hoping that distros will get behind to send a swift middle finger to upstream.

----------

## Anon-E-moose

You could name the fork "utrw" ... Udev The Right Way.   :Laughing: 

----------

## grey_dot

 *Anon-E-moose wrote:*   

> You could name the fork "utrw" ... Udev The Right Way.  :lol:

 

I think we will stay with udev as it is for now. Besides, the upstream version is called systemd-udevd, and many distros do not have packages named udev anymore.

----------

## Sadako

grey_dot, is /run in the root directory integral to your fork as in upstream, or are you (ie all the devs) open to making the runtime directory location configurable either at build or run time (preferably both)?

Would making a feature request for such a change be worth while?

----------

## grey_dot

 *Sadako wrote:*   

> grey_dot, is /run in the root directory integral to your fork as in upstream, or are you (ie all the devs) open to making the runtime directory location configurable either at build or run time (preferably both)?
> 
> Would making a feature request for such a change be worth while?

 

run directory location was configurable at run time before the merge with systemd. You may specify it with "udev_run" option in udev.conf. If nothing specified there, the path is set to '/run'. The same is for /dev and /sys. Other paths (e.g. configuration files) are configured at compile time.

Honestly, I cannot imagine why upstream devs hardcoded all the paths (/dev, /sys, /run, etc), as it seems retarded to me.Last edited by grey_dot on Thu Aug 30, 2012 9:52 pm; edited 1 time in total

----------

## Ant P.

True, you'll probably have a hard time using non-FHS locations for /dev & /sys with the rest of the system though.

----------

## khayyam

grey_dot, et all ...

haven't noticed any issues as yet ... the hdparm script from laptop-mode-tools (/usr/share/laptop-mode-tools/modules/hdparm) has a minor problem with the version returned by 'udevadm info -V', but other than that hunky-dorry.

So, outside of possible name change (which I think will need to be considered if this is to be a virtual stand-in for the currently named 'udev' package) it seems 'standalone' is a drop-in replacement.

best ... khay

----------

## grey_dot

 *khayyam wrote:*   

> grey_dot, et all ...
> 
> haven't noticed any issues as yet ... the hdparm script from laptop-mode-tools (/usr/share/laptop-mode-tools/modules/hdparm) has a minor problem with the version returned by 'udevadm info -V', but other than that hunky-dorry.
> 
> So, outside of possible name change (which I think will need to be considered if this is to be a virtual stand-in for the currently named 'udev' package) it seems 'standalone' is a drop-in replacement.
> ...

 

There are still minor problems, but we'll handle those. For example, kmod is installed in /usr by default in gentoo, so either /usr should be mounted when udev starts, or you have to link udev statically against libkmod. Or rebuild kmod to be installed in /. Anyway, this is easily managable.

BTW, me and consus were having a talk regarding the versioning scheme, and we decided to switch to year-month release versioning. E.g. r1208, r1209, and so on.

----------

## khayyam

 *grey_dot wrote:*   

> BTW, me and consus were having a talk regarding the versioning scheme, and we decided to switch to year-month release versioning. E.g. r1208, r1209, and so on.

 

grey_dot ... but this will break things that expect 'udevadm info -V' to be consistant with udev-systemd, at least in terms of returning the same number of fields, etc. For example, laptop-mode-tools does the following:

```
UDEVVERSION=$(udevadm info -V | awk '{print $3}')
```

This string will be empty for 'udev-standalone' ... smilarly when it looks for the version integer ...

```
UDEVVERSION=$(udevadm info -V)

UDEV_VER_VERIFY=$(echo $UDEVVERSION | cut -b 1)
```

... with the above scheme this will only ever return 'r' and so when it checks to see the version is greater than '70', it fails.

So, while some schema of identifiying 'udev-standalone' is prehaps necessary, changing the schema may cause some issues and this I think should be avoided if it is to be a drop in replacement.

best ... khay

----------

## VinzC

 *khayyam wrote:*   

> For example, laptop-mode-tools does the following:
> 
> ```
> UDEVVERSION=$(udevadm info -V | awk '{print $3}')
> ```
> ...

 

I have udev-171-r6 and udevadm info -V returns only an integer number:

```
171
```

There's no second nor third field. So I guess that's laptop-mode that's already mistaken.

----------

## khayyam

 *VinzC wrote:*   

> I have udev-171-r6 and udevadm info -V returns only an integer number:
> 
> ```
> 171
> ```
> ...

 

VinzC ... yes, but 'echo 171 | cut -b 1' will return an integer, and not an alpha. Looking at the script in question its not at all correct and I don't think it'll do as expected either way, but thats somewhat besides the point, we don't really know what else may be doing the same, only properly.

best ... khay

----------

## grey_dot

 *khayyam wrote:*   

>  *VinzC wrote:*   I have udev-171-r6 and udevadm info -V returns only an integer number:
> 
> ```
> 171
> ```
> ...

 

You got me. LVM also needs numeric version, so we probably will follow the systemd version for now.

Also, our overlay is up. https://bitbucket.org/braindamaged/udev-overlay/. kmod configured properly included.

----------

## khayyam

 *grey_dot wrote:*   

> You got me. LVM also needs numeric version, so we probably will follow the systemd version for now.

 

grey_dot ... I imagine there are probably others to. I'm not sure how you might go about handling this, but for easy of transition its probably best to leave things as they are.

 *grey_dot wrote:*   

> Also, our overlay is up. kmod configured properly included.

 

OK, great. You should probably send an email to overlays at gentoo.org, so that is can be added to repositories.xml (and so available via layman). BTW, feel free to add the udev-init-scripts-16.ebuild I provided above. 

best ... khay

EDIT: I just rebuilt udev and kmod from the udev-overlay, and the Manifest for udev is broken so you might want to fix that.

Also when running revdep-rebuild, lvm2 (2.02.88 with USE="static" which is +static in IUSE) will fail unless udev is built with the 'static-libs' useflag.

----------

## grey_dot

 *khayyam wrote:*   

> 
> 
> EDIT: I just rebuilt udev and kmod from the udev-overlay, and the Manifest for udev is broken so you might want to fix that.
> 
> 

 

Sorry, my bad. Fixed.

 *khayyam wrote:*   

> 
> 
> Also when running revdep-rebuild, lvm2 (2.02.88 with USE="static" which is +static in IUSE) will fail unless udev is built with the 'static-libs' useflag.

 

That's expected, because you need libudev (and other lvm dependencies) to provide libraries for static linking.

----------

## khayyam

 *grey_dot wrote:*   

>  *khayyam wrote:*   Also when running revdep-rebuild, lvm2 (2.02.88 with USE="static" which is +static in IUSE) will fail unless udev is built with the 'static-libs' useflag. 
> 
> That's expected, because you need libudev (and other lvm dependencies) to provide libraries for static linking.

 

yes, it was said more as a warning to others, becuase the gentoo lvm2 packages have 'static' set by default.

best ... khay

----------

## asturm

That's interesting. For sys-fs/lvm2-2.02.97 this is not the case.

----------

## sylware

I got the code from the bitbucket fork.

I did minimalized it, removed the autotools and coded a basic ebuild 

to override official udev ebuild.

https://code.google.com/p/mudev

https://www.gitorious.org/sylware-linux/mudev

https://github.com/sylware/mudev

----------

## DaggyStyle

 *sylware wrote:*   

> I got the code from the bitbucket fork.
> 
> I did minimalized it, removed the autotools and coded a basic ebuild 
> 
> to override official udev ebuild.
> ...

 

so wait, now it is a fork for the fork?

----------

## sylware

 *DaggyStyle wrote:*   

>  *sylware wrote:*   I got the code from the bitbucket fork.
> 
> I did minimalized it, removed the autotools and coded a basic ebuild 
> 
> to override official udev ebuild.
> ...

 

Nope... this is the fork code.

Some code removed and no autotools, bare brutal makefiles (and an ebuild for overlays)

----------

## khayyam

 *sylware wrote:*   

> I got the code from the bitbucket fork. I did minimalized it, removed the autotools and coded a basic ebuild to override official udev ebuild.

 

sylware ... I installed the udev-189.ebuild but had some issues when booting and didn't have the time to look into it as I was right in the middle of something when I tried. It may be due to locating udevd from /lib to /sbin or the various things not installed to /lib/udev/* /etc/* ... or perhaps my udev-init-scripts package, or relocation of files from kmod. Anyhow, it didn't work out well, and I didn't have time to see what the issue(s) might be.

best ... khay

----------

## sylware

 *khayyam wrote:*   

>  *sylware wrote:*   I got the code from the bitbucket fork. I did minimalized it, removed the autotools and coded a basic ebuild to override official udev ebuild. 
> 
> sylware ... I installed the udev-189.ebuild but had some issues when booting and didn't have the time to look into it as I was right in the middle of something when I tried. It may be due to locating udevd from /lib to /sbin or the various things not installed to /lib/udev/* /etc/* ... or perhaps my udev-init-scripts package, or relocation of files from kmod. Anyhow, it didn't work out well, and I didn't have time to see what the issue(s) might be.
> 
> best ... khay

 

Indeed, I don't use openrc, I use cinitramfs.

Then if openrc hardcodes udevd and udevdadm paths... it won't work nicely...

Possible to modify the ebuild to setup proper symlinks at locations expected by openrc.

----------

## grey_dot

 *sylware wrote:*   

> I got the code from the bitbucket fork.
> 
> I did minimalized it, removed the autotools and coded a basic ebuild 
> 
> to override official udev ebuild.
> ...

 

Hey, awesome idea. We already thought of that, but we still do need autotools and gtk-doc for documentation and stuff.

 *khayyam wrote:*   

>  I installed the udev-189.ebuild but had some issues when booting and didn't have the time to look into it as I was right in the middle of something when I tried. 

 

Try installing udev-init-scripts from our overlay or manually fix the path at /etc/init.d/udev. Also try running revdep-rebuild.

----------

## DaggyStyle

sorry but I still don't follow, thats the diff between https://code.google.com/p/mudev and https://bitbucket.org/braindamaged/udev/overview ?

----------

## khayyam

 *grey_dot wrote:*   

>  *khayyam wrote:*   I installed the udev-189.ebuild but had some issues when booting and didn't have the time to look into it as I was right in the middle of something when I tried.  
> 
> Try installing udev-init-scripts from our overlay or manually fix the path at /etc/init.d/udev. Also try running revdep-rebuild.

 

greg_dot ... that particular package doesn't install anything to /etc/*, or indeed anything in /lib/udev/rules.d, and (as I remember) /lib/udev. Also, /lib/udev/udevd is installed as /sbin/udevd, which while a more logical location for a daemon, is not the path provided by udev-init-scripts::udev-overlay.

As for revdep-rebuild, there should be no reason for it, the library versions are the same as sys-fs/udev-9999::udev-overlay so I doubt this is the issue. Basically, the package only installs the minimal of udev components, so paths aside, the rules.d/* will not be applied, but again, I didn't have time to look into it.

 *sylware wrote:*   

> [...] I don't use openrc, I use cinitramfs. Then if openrc hardcodes udevd and udevdadm paths... it won't work nicely... possible to modify the ebuild to setup proper symlinks at locations expected by openrc.

 

sylware ... indeed /etc/conf.d/udev from ::udev-overlay has 'udev_cmd=/lib/udev/udevd' which is no doubt in part why the above failed, but there is also the issue of rules.d/ and other components ... I should have kept a list of what was installed but as I said I was in a hurry to reboot and get on with other things.

best ... khay

----------

## sylware

 *grey_dot wrote:*   

>  *sylware wrote:*   I got the code from the bitbucket fork.
> 
> I did minimalized it, removed the autotools and coded a basic ebuild 
> 
> to override official udev ebuild.
> ...

 

Updated the ebuild to be more openrc friendly (mostly paths)

----------

## Jubei-Mitsuyoshi

Hi all, i am involved in an effort to provide a bunch of "non-systemd" packages over at Arch

https://bbs.archlinux.org/viewtopic.php?id=148429

obviously am watching this thread with GREAT interest.

PLEASE PLEASE keep up the good work, i am very much relying on this effort, and if anyone has any Arch experience please keep us somewhere in the back of your mind when formatting patches  :Smile: 

----------

## khayyam

 *Jubei-Mitsuyoshi wrote:*   

> Hi all, i am involved in an effort to provide a bunch of "non-systemd" packages over at Arch

 

Jubei-Mitsuyoshi ... I have to say, reading that thread caused some of my hair to fall out :)  ... while I have nothing against Arch I can't understand how the replacement of a package (and dependent packages) need be so difficult, it really was only a matter of 15 minutes work to replace udev with udev-standalone on my machine, and that includes some faffing arround with the udev-init-scripts ebuild to apply the two patches from the udev overlay. This is really the distinct advantage of portage.

 *Jubei-Mitsuyoshi wrote:*   

> PLEASE PLEASE keep up the good work, i am very much relying on this effort, and if anyone has any Arch experience please keep us somewhere in the back of your mind when formatting patches :)

 

The only patches that exist are for a seperate package (udev-init-scripts) and these are openrc specific and so outside the realm of possible issues for arch. As far as the udev-standalone fork goes I have been able to build, and run, it successfully on consecutive days since first installing last week, with only a few minor issues (related to version naming cited above). So, at least in my case it was a drop in replacement, and you shouldn't have any issues packaging it, though it sounds as though there are additional complexities with regards to Arch init your end.

EDIT:

grey_dot ... I ment to mention that now that udevd has moved to /sbin (yay!) the patches for udev-init-scipts-16::udev-overlay should be changed to reflect this. I noticed they are still using the old path after just pulling the tree a few minutes ago.

Also, you really should send an email to overlays[shift+2]gentoo.org so that these ebuilds can be on the official overlay list and available via layman. Basically, it'd be a first step to wider adoption.

best ... khay

----------

## grey_dot

 *khayyam wrote:*   

> 
> 
> Jubei-Mitsuyoshi ... I have to say, reading that thread caused some of my hair to fall out :)  ... while I have nothing against Arch I can't understand how the replacement of a package (and dependent packages) need be so difficult, it really was only a matter of 15 minutes work to replace udev with udev-standalone on my machine, and that includes some faffing arround with the udev-init-scripts ebuild to apply the two patches from the udev overlay. This is really the distinct advantage of portage.
> 
> 

 

That's cuz they cannot rebuild all the necessary packages with just one command (:

 *khayyam wrote:*   

> 
> 
> grey_dot ... I ment to mention that now that udevd has moved to /sbin (yay!) the patches for udev-init-scipts-16::udev-overlay should be changed to reflect this. I noticed they are still using the old path after just pulling the tree a few minutes ago.
> 
> 

 

I've just added udev-init-scripts-9999 to deal with this.

 *khayyam wrote:*   

> 
> 
> Also, you really should send an email to overlays[shift+2]gentoo.org so that these ebuilds can be on the official overlay list and available via layman. Basically, it'd be a first step to wider adoption.
> 
> best ... khay

 

Yeah, I know. I just got a little bit stuck with my primary work.

----------

## grey_dot

From now on you can add our overlay with `layman -a udev' command. I strongly suggest also installing kmod from it, so udev doesn't have any dependencies in /usr.

----------

## Jubei-Mitsuyoshi

edited out  :Smile: Last edited by Jubei-Mitsuyoshi on Mon Sep 10, 2012 1:20 am; edited 1 time in total

----------

## khayyam

 *Jubei-Mitsuyoshi wrote:*   

> [...] So to that end i have written a few words i would like you guys to comment on, a kind of statement of intent.[...]

 

Jubei-Mitsuyoshi ... if there is any interest it should really be discussed in a seperate thread, otherwise this thread will become less about udev-standalone and more about, well, whatever it is your proposing.

best ... khay

----------

## khayyam

 *grey_dot wrote:*   

> From now on you can add our overlay with `layman -a udev' command. I strongly suggest also installing kmod from it, so udev doesn't have any dependencies in /usr.

 

grey_dot ... good news.

I've tested both udev-189 and udev-9999, udev-init-scripts-16, and both kmod-9-r4 and kmod-10 ebuilds, and everything seems to be in order.

Thanks for all the work in this regard & best ... khay

EDIT: actually, I was mistaken, there is one issue, udev-189 will install udevd to /lib/udev, the tarball should be updated to reflect the move to /sbin. Also, this ebuild should be keyworded (at least for ~x86) as otherwise its not possible to select this ebuild over 9999 (both being **).Last edited by khayyam on Mon Sep 10, 2012 11:06 am; edited 1 time in total

----------

## Jubei-Mitsuyoshi

 *khayyam wrote:*   

>  *Jubei-Mitsuyoshi wrote:*   [...] So to that end i have written a few words i would like you guys to comment on, a kind of statement of intent.[...] 
> 
> Jubei-Mitsuyoshi ... if there is any interest it should really be discussed in a seperate thread, otherwise this thread will become less about udev-standalone and more about, well, whatever it is your proposing.
> 
> best ... khay

 

good point, can someone move it or something, or should i just edit it out?

----------

## khayyam

 *Jubei-Mitsuyoshi wrote:*   

>  *khayyam wrote:*   Jubei-Mitsuyoshi ... if there is any interest it should really be discussed in a seperate thread, otherwise this thread will become less about udev-standalone and more about, well, whatever it is your proposing. 
> 
> good point, can someone move it or something, or should i just edit it out?

 

Jubei-Mitsuyoshi ... just edit and move to a more relevant section.

best ... khay

----------

## Jimmy Jazz

 *consus wrote:*   

> Hello. I want to announce new udev fork 
> 
> Main advantages (compared to mainstream) are:
> 
> separate /usr works just fine
> ...

 

I didn't test your udev fork on github right now, but It is a good idea to separate it from systemd 

Also I modified the actual udev ebuild  to avoid /run and /usr directories.

FYI, I don't use gentoo initscripts at all.

If you are curious about how other devs proceed without udev, you could read the s6-devd code

http://www.skarnet.org/software/s6-linux-utils/index.html

see sys-apps/s6-linux-utils ebuild.

```
# diff -ruN /usr/portage/sys-fs/udev/udev-189.ebuild udev-189.ebuild

--- /usr/portage/sys-fs/udev/udev-189.ebuild   2012-08-24 18:21:22.000000000 +0200

+++ udev-189.ebuild   2012-08-25 16:13:08.713313195 +0200

@@ -1,6 +1,6 @@

 # Copyright 1999-2012 Gentoo Foundation

 # Distributed under the terms of the GNU General Public License v2

-# $Header: /var/cvsroot/gentoo-x86/sys-fs/udev/udev-189.ebuild,v 1.1 2012/08/24 16:21:22 williamh Exp $

+# $Header: $

 

 EAPI=4

 

@@ -13,12 +13,12 @@

    EGIT_REPO_URI="git://anongit.freedesktop.org/systemd/systemd"

    inherit git-2

 else

-   patchset=1

+   patchversion=

    SRC_URI="http://www.freedesktop.org/software/systemd/systemd-${PV}.tar.xz"

-   if [[ -n "${patchset}" ]]

+   if [[ -n "${patchversion}" ]]

       then

             SRC_URI="${SRC_URI}

-               http://dev.gentoo.org/~williamh/dist/${P}-patches-${patchset}.tar.bz2"

+               mirror://gentoo/${P}-patches-${patchversion}.tar.bz2"

          fi

    KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86"

 fi

@@ -69,7 +69,7 @@

 

 S="${WORKDIR}/systemd-${PV}"

 

-udev_check_KV()

+check_KV()

 {

    if kernel_is lt ${KV_min//./ }

    then

@@ -101,7 +101,7 @@

 

    linux-info_pkg_setup

 

-   if ! udev_check_KV

+   if ! check_KV

    then

       eerror "Your kernel version (${KV_FULL}) is too old to run ${P}"

       eerror "It must be at least ${KV_min}!"

@@ -109,7 +109,7 @@

 

    KV_FULL_SRC=${KV_FULL}

    get_running_version

-   if ! udev_check_KV

+   if ! check_KV

    then

       eerror

       eerror "Your running kernel version (${KV_FULL}) is too old"

@@ -121,17 +121,24 @@

 src_prepare()

 {

    # backport some patches

-   if [[ -n "${patchset}" ]]

+   if [[ -n "${patchversion}" ]]

    then

       EPATCH_SUFFIX=patch EPATCH_FORCE=yes epatch

    fi

 

+   find . -type f -name "*.[hc]" -exec sed -i.ori 's:/cgroup/systemd:/cgroup/daemon:g' {} +

+   find . -type f -name "*.[hc]" -exec sed -i.ori 's:/run/systemd:/var/run/systemd:g' {} +

+   find . -type f -name "*.[hc]" -exec sed -i.ori 's:name=systemd:name=daemon:g' {} +

+   find . -type f -name "*.[hc]" -exec sed -i.ori 's:systemd-udevd:udevd:g' {} +

+   find . -type f -name "*.[hc]" -exec sed -i.ori 's:/run/udev:/var/run/udev:g' {} +

+   #epatch "${FILESDIR}/${P}"-run-to-var.patch || die

+

    # change rules back to group uucp instead of dialout for now

    sed -e 's/GROUP="dialout"/GROUP="uucp"/' \

       -i rules/*.rules \

    || die "failed to change group dialout to uucp"

 

-   if [[ ! -e configure ]]

+   if [ ! -e configure ]

    then

       if use doc

       then

@@ -156,14 +163,22 @@

       DBUS_CFLAGS=' '

       DBUS_LIBS=' '

       --docdir=/usr/share/doc/${PF}

-      --libdir=/usr/$(get_libdir)

+      --libdir=/$(get_libdir)

+      --libexecdir=/lib

+      --with-firmware-path=/lib/firmware/updates:/lib/firmware

+      --prefix=/

+      --exec-prefix=/

+      --includedir=/usr/include

+      --datarootdir=/usr/share

+      --with-dbuspolicydir=/usr/dbus-1/system.d

+      --libdir=/$(get_libdir)

       --with-distro=gentoo

-      --with-firmware-path=/usr/lib/firmware/updates:/usr/lib/firmware:/lib/firmware/updates:/lib/firmware

       --with-html-dir=/usr/share/doc/${PF}/html

-      --with-pci-ids-path=/usr/share/misc/pci.ids

-      --with-rootlibdir=/usr/$(get_libdir)

-      --with-rootprefix=/usr

-      --with-usb-ids-path=/usr/share/misc/usb.ids

+      --with-pci-ids-path=/etc/hwids/pci.ids

+      --with-usb-ids-path=/etc/hwids/usb.ids

+      --with-rootprefix=/

+      --with-rootlibdir=/$(get_libdir)

+      --disable-acl

       --disable-audit

       --disable-coredump

       --disable-hostnamed

@@ -171,6 +186,7 @@

       --disable-libcryptsetup

       --disable-localed

       --disable-logind

+      --disable-vconsole

       --disable-nls

       --disable-pam

       --disable-quotacheck

@@ -179,13 +195,13 @@

       --disable-tcpwrap

       --disable-timedated

       --disable-xz

-      $(use_enable acl)

       $(use_enable doc gtk-doc)

       $(use_enable gudev)

       $(use_enable introspection)

       $(use_enable keymap)

       $(use_enable selinux)

       $(use_enable static-libs static)

+      $(use_enable acl)

    )

    econf "${econf_args[@]}"

 }

@@ -213,7 +229,7 @@

    use keymap && targets+=( keymap )

    use gudev && targets+=( libgudev-1.0.la )

 

-   emake "${targets[@]}"

+   emake udevlibexecdir=/lib/udev "${targets[@]}"

    if use doc

    then

       emake -C docs/libudev

@@ -259,6 +275,7 @@

 

    # add final values of variables:

    targets+=(

+      udevlibexecdir=/lib/udev

       rootlibexec_PROGRAMS=systemd-udevd

       bin_PROGRAMS=udevadm

       lib_LTLIBRARIES="${lib_LTLIBRARIES}"

@@ -280,15 +297,35 @@

    dodoc TODO

 

    prune_libtool_files --all

-   rm -f "${D}"/usr/lib/udev/rules.d/99-systemd.rules

+   rm -f "${D}"/lib/udev/rules.d/99-systemd.rules

    rm -rf "${D}"/usr/share/doc/${PF}/LICENSE.*

 

+   dodir /usr/$(get_libdir)

+   mv ${D:-:}/$(get_libdir)/pkgconfig ${D}/usr/$(get_libdir)

+

+   gen_usr_ldscript libudev.so

+

+   dodir /$(get_libdir)/udev

+   mv ${D}/lib/systemd/systemd-udevd ${D}/$(get_libdir)/udev/udevd

+   rm -r "${D}"/lib/systemd

+

+   dodir /sbin

+

+   if [ -x ${D}/bin/udevadm ]; then

+      mv ${D}/bin/udevadm ${D}/sbin/udevadm

+   fi

+   # udevadm is now in /usr/bin. <--- I can't believe it !!

+   dosym /sbin/udevadm /bin/udevadm

+

+   # create symlinks for these utilities to /sbin

+   # where multipath-tools expect them to be (Bug #168588)

+   dosym /lib/udev/scsi_id /sbin/scsi_id

+

+

    # install gentoo-specific rules

-   insinto /usr/lib/udev/rules.d

+   insinto /lib/udev/rules.d

    doins "${FILESDIR}"/40-gentoo.rules

 

-   # install udevadm symlink

-   dosym ../usr/bin/udevadm /sbin/udevadm

 }

 

 pkg_preinst()

@@ -305,7 +342,7 @@

             /usr/share/gtk-doc/html/${htmldir}

       fi

    done

-   preserve_old_lib /usr/$(get_libdir)/libudev.so.0

+   preserve_old_lib /$(get_libdir)/libudev.so.0

 }

 

 # This function determines if a directory is a mount point.

@@ -383,17 +420,6 @@

    ewarn "If you are using standalone udev, consolekit handles this"

    ewarn "functionality."

 

-   if [[ -d ${ROOT}lib/udev ]]

-   then

-      ewarn

-      ewarn "This version of udev moves the files that were installed in"

-      ewarn "/lib/udev to /usr/lib/udev."

-      ewarn "We include a backward compatibility patch for gentoo to"

-      ewarn "allow the rules in /lib/udev/rules.d to be read. However,"

-      ewarn "bugs should be filed against packages that are installing"

-   ewarn "files in /lib/udev so they can be fixed."

-   fi

-

    ewarn

    ewarn "You need to restart udev as soon as possible to make the upgrade go"

    ewarn "into affect."

@@ -404,7 +430,7 @@

    ewarn "generator. If you need persistent names for these devices,"

    ewarn "place udev rules for them in ${ROOT}etc/udev/rules.d."

 

-   preserve_old_lib_notify /usr/$(get_libdir)/libudev.so.0

+   preserve_old_lib_notify /$(get_libdir)/libudev.so.0

 

    elog

    elog "For more information on udev on Gentoo, writing udev rules, and"

```

# cat s6-linux-utils-0.12.ebuild 

```

# Copyright 1999-2012 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header:

EAPI=4

inherit multilib toolchain-funcs

DESCRIPTION="set of minimalistic Linux-specific system utilities"

HOMEPAGE="http://www.skarnet.org/software/s6-linux-utils/index.html"

SRC_URI="http://www.skarnet.org/software/${PN}/${P}.tar.gz"

LICENSE="ISC"

SLOT="0"

KEYWORDS="~amd64 ~x86"

IUSE="doc static-libs"

DEPEND="dev-libs/skalibs"

RDEPEND=""

S=${WORKDIR}/admin/${P}

src_prepare() {

   echo ${S} > conf-compile/conf-sp_root

   mkdir -p package/prog/skalibs/sysdeps

   cp -a /usr/$(get_libdir)/skalibs/sysdeps package/prog/skalibs/

   ln -s ../../package/prog/skalibs/sysdeps/systype ${S}/src/sys/systype

}

src_configure() {

   echo $(tc-getCC) ${CFLAGS} > conf-compile/conf-cc

   echo $(tc-getCC) ${LDFLAGS} > conf-compile/conf-dynld

   echo $(tc-getCC) ${LDFLAGS} > conf-compile/conf-ld

   echo /usr/include/skalibs > conf-compile/path-include

   echo /usr/$(get_libdir)/skalibs > conf-compile/path-library

   use static-libs && touch conf-compile/flag-allstatic

}

src_compile() {

   emake -j1

}

src_install() {

   exeinto /sbin

   doexe command/*

   cd doc || die

   for f in $(find . -type f ! -name "*.html" ! -name "COPYING") ; do

      docinto $(dirname f)

      dodoc $f

   done

   docinto html

   use doc && dohtml -r .

}

```

----------

## grey_dot

 *Jimmy Jazz wrote:*   

> 
> 
> If you are curious about how other devs proceed without udev, you could read the s6-devd code
> 
> http://www.skarnet.org/software/s6-linux-utils/index.html
> ...

 

That's really interesting, thanks. Is there any overlay with those?

----------

## Jimmy Jazz

 *grey_dot wrote:*   

>  *Jimmy Jazz wrote:*   
> 
> If you are curious about how other devs proceed without udev, you could read the s6-devd code
> 
> http://www.skarnet.org/software/s6-linux-utils/index.html
> ...

 

Sorry, I do not remember where it came from and nothing about it at overlay

----------

## Jubei-Mitsuyoshi

hi all, a question (on topic for a change  :Smile:  ), i am trying to get udev-fork going on Arch ( thankless task ), i/we have packaged it etc, but there seems to be an issue of a modified soname making it NOT a dropin replacement in an arch system without a bit of recompiling ( an option i am exploring with a script ). Anyway is this a case for a patch ? Would it be feasible to patch the source ( in this case ) and change the soname to whatever the bloody distro is calling for.

That way i dont have to bother the authors with what to them is needless requests.

----------

## grey_dot

 *Jubei-Mitsuyoshi wrote:*   

> hi all, a question (on topic for a change :) ), i am trying to get udev-fork going on Arch ( thankless task ), i/we have packaged it etc, but there seems to be an issue of a modified soname making it NOT a dropin replacement in an arch system without a bit of recompiling ( an option i am exploring with a script ). Anyway is this a case for a patch ? Would it be feasible to patch the source ( in this case ) and change the soname to whatever the bloody distro is calling for.
> 
> That way i dont have to bother the authors with what to them is needless requests.

 

Sure, here you go.

```

diff --git a/Makefile.am b/Makefile.am

index ed86c4c..c2a725f 100644

--- a/Makefile.am

+++ b/Makefile.am

@@ -6,12 +6,12 @@ SUBDIRS = .

 ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}

 AM_MAKEFLAGS = --no-print-directory

 

-LIBUDEV_CURRENT=13

-LIBUDEV_REVISION=4

-LIBUDEV_AGE=0

+LIBUDEV_CURRENT=2

+LIBUDEV_REVISION=0

+LIBUDEV_AGE=1

 

 LIBGUDEV_CURRENT=1

-LIBGUDEV_REVISION=1

+LIBGUDEV_REVISION=2

 LIBGUDEV_AGE=1

 

 AM_CPPFLAGS = \

```

Check the numbers in question, I took them from the current systemd tree, so they may be too 'up-to-date'.

----------

## khayyam

 *khayyam wrote:*   

> EDIT: actually, I was mistaken, there is one issue, udev-189 will install udevd to /lib/udev, the tarball should be updated to reflect the move to /sbin. Also, this ebuild should be keyworded (at least for ~x86) as otherwise its not possible to select this ebuild over 9999 (both being **).

 

grey_dot ... just thought, you probably missed this edit (should have made it a seperate post.)

best ... khay

----------

## grey_dot

 *khayyam wrote:*   

>  *khayyam wrote:*   EDIT: actually, I was mistaken, there is one issue, udev-189 will install udevd to /lib/udev, the tarball should be updated to reflect the move to /sbin. Also, this ebuild should be keyworded (at least for ~x86) as otherwise its not possible to select this ebuild over 9999 (both being **). 
> 
> grey_dot ... just thought, you probably missed this edit (should have made it a seperate post.)
> 
> best ... khay

 

Sorry, missed that indeed. The release had been made before we actually moved udevd to /sbin and therefore wasn't affected. Use -9999 or wait until we do release 190 (yet almost nothing has been commited to upstream udev, so probably new release won't change anything).

----------

## khayyam

 *grey_dot wrote:*   

> The release had been made before we actually moved udevd to /sbin and therefore wasn't affected. Use -9999 or wait until we do release 190 (yet almost nothing has been commited to upstream udev, so probably new release won't change anything).

 

grey_dot ... I am using 9999, I was just reporting for the sake of others who may install it, along with x-udev::udev-init-scripts, and have the init script look under /sbin. Anyhow, 189 isn't keyworded so it shouldn't hit anyone, just thought it was worth mentioning thats all.

best ... khay

----------

## Jubei-Mitsuyoshi

grey_dot....... Dont know what to say, thank you so much, totally blown away   :Very Happy:   :Very Happy:   :Very Happy:   :Very Happy:   :Very Happy: 

----------

## grey_dot

 *Jubei-Mitsuyoshi wrote:*   

> grey_dot....... Dont know what to say, thank you so much, totally blown away  :D  :D  :D  :D  :D

 

No problem, dude. Don't forget to post bugreports, feature request and stuff at our issue tracker if you have any.

----------

## Jubei-Mitsuyoshi

 *grey_dot wrote:*   

>  *Jubei-Mitsuyoshi wrote:*   grey_dot....... Dont know what to say, thank you so much, totally blown away       
> 
> No problem, dude. Don't forget to post bugreports, feature request and stuff at our issue tracker if you have any.

 

Hi again, is that the whole of the patch?, patch is complaining that its terminating in mid line, maybe a bit is missing from the bottom ?

Sure will forward all results and bugs straight to you guys, i think quite a few people will be running it, as its the only real alternative to sysd, and all the bug notices are going through me cos i invented the packages, so passing em to you no probs  :Smile: 

Dio you guys like any "official "format for bug reports, or can we just mail em as emails?

----------

## tclover

thanks for this fork! i was thinking about what i was going to undergo to remove udev completely from my systems, now i did not need to bother.

udev overlay maintainers should consider to add:

```
udev
```

that file to ease overlays management and merging issues related to an unnamed overlay.

EDIT: µdev seems a very good name for me and i guess _µ_ is pretty accessible (even on us keyboards?).

----------

## grey_dot

 *Jubei-Mitsuyoshi wrote:*   

> 
> 
> Hi again, is that the whole of the patch?, patch is complaining that its terminating in mid line, maybe a bit is missing from the bottom ?
> 
> 

 

Try adding new line to the end.

 *Jubei-Mitsuyoshi wrote:*   

> 
> 
> Sure will forward all results and bugs straight to you guys, i think quite a few people will be running it, as its the only real alternative to sysd, and all the bug notices are going through me cos i invented the packages, so passing em to you no probs :)
> 
> Dio you guys like any "official "format for bug reports, or can we just mail em as emails?

 

Just leave 'em there https://bitbucket.org/braindamaged/udev/issues. We probably will launch a maillist later when we have where to host it.

----------

## khayyam

 *tclover wrote:*   

> EDIT: µdev seems a very good name for me and i guess _µ_ is pretty accessible (even on us keyboards?).

 

tclover ... I think something simpler would be better as its not obvious to everyone how to produce that char. Right now a name change might cause some unnecessary headaches due to dependencies, and unless there is somekind of virtual it may not work in favour of adoption. Anyhow, as others have suggested potencial names, I'll do the same: nudev.

best ... khay

----------

## greyspoke

devo?

----------

## Fitzcarraldo

 *khayyam wrote:*   

> Anyhow, as others have suggested potencial names, I'll do the same: nudev.

 

Now that one I like.

----------

## Jubei-Mitsuyoshi

just notice the soname change https://bitbucket.org/braindamaged/udev/changeset/a40c0b83ba7b7f9c31f28c8ac30efdffa0f6c22f THANK YOU VERY MUCH  :Smile:  saves me getting stick for patching it  :Smile:   :Smile: 

----------

## khayyam

 *Fitzcarraldo wrote:*   

>  *khayyam wrote:*   Anyhow, as others have suggested potencial names, I'll do the same: nudev. 
> 
> Now that one I like.

 

Fitzcarraldo ... ya, the naked, or new, udev ... but greyspoke's suggestion I also like ... "are we not men, no, we are devo".

best ... khay

----------

## Ant P.

 *tclover wrote:*   

> thanks for this fork! i was thinking about what i was going to undergo to remove udev completely from my systems, now i did not need to bother.
> 
> udev overlay maintainers should consider to add:
> 
> ```
> ...

 

No need to worry about the non-ascii, typing it out as "mudev" works (and it'll go pretty well with musl when that takes over the world too  :Very Happy: )

----------

## DaggyStyle

how many are using this fork already? how stable is it?

I'm thinking of migrating to it but I cannot afford it to shutdown my server.

----------

## hcaulfield57

I just installed the forked udev, and its working well as far as I can tell. Good work! One thing that I'm not sure is my fault or not. I installed the udev-init-scripts from the overlay, but when the script started it complained about not being able to find /lib/udev/udevd, so I just symlinked that to /sbin/udevd. Also I forgot to add the script to sysinit, but it looks like my system booted fine without udev even running on account of automounting devtmpfs. I'm sure those two issues stem from my ineptitude, and due to the fact that I'm not overly used to OpenRC, and my lack of ability with Portage. However I am happy with it so far, so please keep up the good work, and I hope you succeed with this endeavor.

EDIT: Just noticed that the script warns you to add it to sysinit, so I guess I was too tired and missed that, still funny that my system still booted.

----------

## khayyam

 *hcaulfield57 wrote:*   

> One thing that I'm not sure is my fault or not. I installed the udev-init-scripts from the overlay, but when the script started it complained about not being able to find /lib/udev/udevd, so I just symlinked that to /sbin/udevd.

 

hcaulfield57 ... yes, the udev-init-scripts-16 patch for /etc/conf.d/udev still has '+udev_cmd=/lib/udev/udevd', but the actual location of udevd is /sbin if installing udev-9999 (which will happen because both 189 and 9999 are unkeyworded). So, rather than sym-link simply edit /etc/conf.d/net and change udev_cmd= to /sbin/udev.

best ... khay

----------

## PaulBredbury

 *hcaulfield57 wrote:*   

> /sbin/udevd

 

Compile with:

```
--bindir=/sbin
```

To get udevd and udevadm in /sbin/

----------

## grey_dot

 *DaggyStyle wrote:*   

> how many are using this fork already? how stable is it?
> 
> I'm thinking of migrating to it but I cannot afford it to shutdown my server.

 

Udev-189 have been downloaded about 40 times, and I don't know how many people use -9999 (probably more than -189, though bitbucket doesn't provide statistics on repo access, so I can't say for sure).

At the moment we have no runtime issues, and I think I can say it's stable enough to be used. No system restart is needed :)

----------

## roravun

 *Fitzcarraldo wrote:*   

>  *khayyam wrote:*   Anyhow, as others have suggested potencial names, I'll do the same: nudev. 
> 
> Now that one I like.

 

Why not "mudev"?  νdev is kinda less cool than μdev.  :Smile: 

----------

## DaggyStyle

 *grey_dot wrote:*   

>  *DaggyStyle wrote:*   how many are using this fork already? how stable is it?
> 
> I'm thinking of migrating to it but I cannot afford it to shutdown my server. 
> 
> Udev-189 have been downloaded about 40 times, and I don't know how many people use -9999 (probably more than -189, though bitbucket doesn't provide statistics on repo access, so I can't say for sure).
> ...

 

the 9999 is the equivalent of udev-9999?

----------

## grey_dot

 *DaggyStyle wrote:*   

>  *grey_dot wrote:*    *DaggyStyle wrote:*   how many are using this fork already? how stable is it?
> 
> I'm thinking of migrating to it but I cannot afford it to shutdown my server. 
> 
> Udev-189 have been downloaded about 40 times, and I don't know how many people use -9999 (probably more than -189, though bitbucket doesn't provide statistics on repo access, so I can't say for sure).
> ...

 

yup.

----------

## DaggyStyle

 *grey_dot wrote:*   

>  *DaggyStyle wrote:*    *grey_dot wrote:*    *DaggyStyle wrote:*   how many are using this fork already? how stable is it?
> 
> I'm thinking of migrating to it but I cannot afford it to shutdown my server. 
> 
> Udev-189 have been downloaded about 40 times, and I don't know how many people use -9999 (probably more than -189, though bitbucket doesn't provide statistics on repo access, so I can't say for sure).
> ...

 

I assume right that that the ebuilds are layman?

----------

## grey_dot

 *DaggyStyle wrote:*   

>  *grey_dot wrote:*   
> 
> yup. 
> 
> I assume right that that the ebuilds are layman?

 

Not quite sure I understand what you mean, but yeah, you can install udev from the udev overlay.

----------

## khayyam

 *PaulBredbury wrote:*   

>  *hcaulfield57 wrote:*   /sbin/udevd 
> 
> Compile with:
> 
> ```
> ...

 

Paul ... both ebuilds are already setting --bindir

```
# grep bindir *.ebuild

udev-189.ebuild:                --bindir="${EPREFIX}"/sbin \

udev-9999.ebuild:               --bindir="${EPREFIX}"/sbin \
```

best ... khayLast edited by khayyam on Wed Sep 12, 2012 6:35 pm; edited 1 time in total

----------

## hcaulfield57

 *grey_dot wrote:*   

> 
> 
> Not quite sure I understand what you mean, but yeah, you can install udev from the udev overlay.
> 
> 

 

I know I had trouble getting the correct udev (and kmod) to be pulled in by portage, and had to specify udev::udev and kmod::udev respectively, but it worked fine after that, I'm sure its because this was my first time using an overlay.   :Embarassed: 

----------

## khayyam

 *hcaulfield57 wrote:*   

> I know I had trouble getting the correct udev (and kmod) to be pulled in by portage, and had to specify udev::udev and kmod::udev respectively, but it worked fine after that, I'm sure its because this was my first time using an overlay.

 

hcaulfield57 ... as I tried to explain above, but perhaps I wasn't clear enough, becuase udev-189 and udev-9999 are not keyworded but udev-init-scripts-16 is (~arch) if not stating the '**' you may end up with udev-9999 and udev-init-scripts-16. The later expects udevd to be in /lib/udev/ while the udev-init-scripts-9999 in /sbin. Its the mis-match I reported in post 7136814

The problem as I reported it is that you can't state 'sys-fs/udev-9999::udev **' or 'sys-fs/udev-189 **' (becuase '**' implies 9999 and so amounts to an invalid atom) but as both sys-fs/udev-189 and sys-fs/udev-9999 are not keyworded, but  udev-init-scripts-16 is, without explicitily stating the live ebuild ('**') you will end up (as you did) with two mis-matched packages.

So, to be sure this doesn't happen ...

/etc/portage/package.accept_keywords

```
sys-apps/kmod::udev

sys-fs/udev::udev **

sys-fs/udev-init-scripts::udev **
```

The sys-fs/udev-189.ebuild can not be installed without first keywording, and should only be installed along side udev-init-scripts-16 (unless of course you do as I advised above and edit /etc/conf.d/udev).

Users should probably also mask the udev, udev-init-scripts, and kmod packages from ::gentoo

/etc/portage/package.mask

```
sys-apps/kmod::gentoo

sys-fs/udev::gentoo

sys-fs/udev-init-scripts::gentoo
```

best ... khay

----------

## hcaulfield57

Alright, everything is working properly now. Thank you for providing this software consus and grey_dot and whoever else may be working on it!

----------

## DaggyStyle

 *grey_dot wrote:*   

>  *DaggyStyle wrote:*    *grey_dot wrote:*   
> 
> yup. 
> 
> I assume right that that the ebuilds are layman? 
> ...

 

that is what I meant, I'll try it when I get the time, thanks.

----------

## khayyam

The above keywording issue has been fixed in the overlay (thanks grey_d0t) ... so, for those not wanting the live ebuilds the following should now provide udev-189 and udev-init-scripts-16 (and udevd located in /lib/udev)

/etc/portage/package.accept_keywords

```
sys-apps/kmod::udev

sys-fs/udev::udev

sys-fs/udev-init-scripts::udev
```

and for the live ebuilds, providing udev-9999 and udev-init-scripts-9999 (and udevd located in /sbin)

```
sys-apps/kmod::udev

sys-fs/udev::udev **

sys-fs/udev-init-scripts::udev **
```

best ... khay

----------

## miroR

Copying manually from a cloned Gentoo box that is handicapped, disabled, at this time.

```
# /etc/init.d/udev status

* status: stopped

# /etc/init.d/udev start

* starting udev ...

* start-stop daemon: /usr/lib/systemd/systemd-udevd does not exist

* Failed to start                                                                                        [!!]

* udev failed to start

#

```

I read this topic. I very much agree and appreciate udev-standalone that you developed.

However, those guys behind some apparently silly ideas described in this topic seem to still have a way to make the udev-standalone development difficult...

I only bet it must be something to do with this transition.

I am no programmer, just somewhat experienced user.

My systems generally just work, updated daily or so, testing ~amd branch.

udev is from gentoo overlay, which is currently installed in the system...

No network, the latest kernel (which I described in here:

http://en.gentoo-wiki.com/wiki/Talk:Writing_Ebuilds

that is:

```
sys-kernel/hardened-sources-3.5.3-r3
```

wouldn't boot at all.

All the older kernels boot with just a handful of devices created...

I bet so much it is something to do with this transition, that I dare post this issue here.

I'm available for testing to fix this. I can't do the planned upgrade unless I get it fixed.

To not have to type things in here manually, I do need to boot with sysresccd, get the network up and chroot to repair my system and to uproot, if possible, what's left of evil code deriving from the bad and annoying areas intruding into GNU Linux, as some people dare to see them, don't thay?

----------

## khayyam

 *miroR wrote:*   

> 
> 
> ```
> # /etc/init.d/udev status
> 
> ...

 

miroR ... this just looks to me as though you have installed udev-standalone but haven't installed the udev-init-scripts also from the udev overlay. So, gentoo's init scripts are looking for /usr/lib/systemd/systemd-udevd which of course udev-standalone doesn't have.

best ... khay

----------

## miroR

More info on the mess above.

But first: of course, if you devs deem my posts don't belong here, feel free to move them to somewhere else!

OTOH, since I broached it here, I do need to supply more info now. So here I go.

From sysresccd, where I got the network and X and all for the box currently handicapped. Chrooted, as recommended (by my friend François Dupoux) here:

http://www.sysresccd.org/Sysresccd-Partitioning-EN-Repairing-a-damaged-Grub:

The info:

```
# revdep-rebuild

[ 1% ]  *   broken /lib64/libdevmapper.so.1.02 (requires libudev.so.1)

 *   broken /lib64/liblvm2app.so.2.2 (requires libudev.so.1)

 *   broken /lib64/liblvm2cmd.so.2.02 (requires libudev.so.1)

[ 2% ]  *   broken /lib64/udev/udisks-part-id (requires libudev.so.1)

[ 3% ]  *   broken /sbin/lvm (requires libudev.so.1)

[ 4% ]  *   broken /usr/bin/Xorg (requires libudev.so.1)

[ 37% ]  *   /lib64/libdevmapper.so.1.02 -> sys-fs/lvm2

 *   /lib64/liblvm2app.so.2.2 -> sys-fs/lvm2

 *   /lib64/liblvm2cmd.so.2.02 -> sys-fs/lvm2

 *   /lib64/udev/udisks-part-id -> sys-fs/udisks

 *   /sbin/lvm -> sys-fs/lvm2

 *   /usr/bin/Xorg -> x11-base/xorg-server

emerge --complete-graph=y --oneshot --autounmask-write=y  sys-fs/lvm2:0 sys-fs/udisks:0 x11-base/xorg-server:0

..........

Calculating dependencies... done!

>>> Verifying ebuild manifests

>>> Running pre-merge checks for x11-base/xorg-server-1.13.0

openpty failed: 'out of pty devices'

>>> Starting parallel fetch

>>> Emerging (1 of 3) sys-fs/lvm2-2.02.97

 * LVM2.2.02.97.tgz SHA256 SHA512 WHIRLPOOL size ;-) ...                            [ ok ]

 * Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Found sources for kernel version:

 *     3.5.3-hardened-r3-120914_1500

 * Checking for suitable kernel configuration options...                            [ ok ]

 * Warning, we no longer overwrite /sbin/lvm and /sbin/dmsetup with

 * their static versions. If you need the static binaries,

 * you must append .static to the filename!

>>> Unpacking source...

>>> Unpacking LVM2.2.02.97.tgz to /var/tmp/portage/sys-fs/lvm2-2.02.97/work

>>> Source unpacked in /var/tmp/portage/sys-fs/lvm2-2.02.97/work

>>> Preparing source in /var/tmp/portage/sys-fs/lvm2-2.02.97/work/LVM2.2.02.97 ...

 * Applying lvm.conf-2.02.67.patch ...                                              [ ok ]

 * Applying lvm2-2.02.63-always-make-static-libdm.patch ...                         [ ok ]

 * Applying lvm2-2.02.56-lvm2create_initrd.patch ...                                [ ok ]

 * Applying lvm2-2.02.67-createinitrd.patch ...                                     [ ok ]

 * Applying lvm2-2.02.92-locale-muck.patch ...                                      [ ok ]

 * Applying lvm2-2.02.70-asneeded.patch ... 

```

Clearly, the ".static" suffix is missing. I renamed it after the guide:

http://en.gentoo-wiki.com/wiki/Root_filesystem_over_LVM2,_DM-Crypt_and_RAID where it reads:

```
mv bin/lvm.static bin/lvm
```

EDIT: But the guide refers to renaming those binaries in initramfs directory, doesn't touch the system's ones. So I didin't get that warning, really. It'll take longer for me to figure it out, in my old age, as I am. (end of EDIT)

And now I don't anymore bet with such certainty as before...

Sorry... (Not yet in the clear though, either. Need more pondering, deep thinking and stretching my capabilities to figure this out... God, this will kill me, again!   :Embarassed:   )Last edited by miroR on Sun Sep 16, 2012 11:23 pm; edited 1 time in total

----------

## miroR

 *khayyam wrote:*   

>  *miroR wrote:*   
> 
> ```
> # /etc/init.d/udev status
> 
> ...

 

khayyam,

nice to converse with you, I respect what you do for us users! Thanks!

But no, see this:

```
sysresccd / # emerge -pvt udev-init-scripts

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!

[ebuild   R    ] sys-fs/udev-init-scripts-16::udev [16::gentoo] 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

sysresccd / #
```

If I understand well, it's the same overlay as udev.

I guess so, yes:

```
sysresccd / # emerge -pvt udev 

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!

[ebuild   R    ] sys-fs/udev-189::udev  USE="gudev hwdb openrc static-libs -debug -doc -floppy -introspection -keymap (-selinux)" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

sysresccd / # emerge -s udev-init-scripts

Searching...    

[ Results for search key : udev-init-scripts ]

[ Applications found : 1 ]

*  sys-fs/udev-init-scripts

      Latest version available: 16

      Latest version installed: 16

      Size of files: 4 kB

      Homepage:      http://www.gentoo.org

      Description:   udev startup scripts for openrc

      License:       GPL-2

sysresccd / # 

```

----------

## miroR

Another round of --depclean and revdep-rebuild I go.

```
sysresccd / # emerge -a --depclean ; revdep-rebuild -p ; revdep-rebuild ; 

 * Depclean may break link level dependencies. Thus, it is

 * recommended to use a tool such as `revdep-rebuild` (from

 * app-portage/gentoolkit) in order to detect such breakage.

 * 

 * Always study the list of packages to be cleaned for any obvious

 * mistakes. Packages that are part of the world set will always

 * be kept.  They can be manually added to this set with

 * `emerge --noreplace <atom>`.  Packages that are listed in

 * package.provided (see portage(5)) will be removed by

 * depclean, even if they are part of the world set.

 * 

 * As a safety measure, depclean will not remove any packages

 * unless *all* required dependencies have been resolved.  As a

 * consequence, it is often necessary to run `emerge --update

 * --newuse --deep @world` prior to depclean.

Calculating dependencies... done!

>>> No packages selected for removal by depclean

>>> To see reverse dependencies, use --verbose

Packages installed:   1273

Packages in world:    323

Packages in system:   43

Required packages:    1273

Number removed:       0

[ 2% ]  *   broken /lib64/udev/udisks-part-id (requires libudev.so.1)

[ 47% ]  *   broken /usr/lib64/egl/egl_gallium.so (requires libudev.so.1)

[ 54% ]  *   broken /usr/lib64/gio/modules/libgvfsdbus.so (requires libudev.so.1)

[ 66% ]  *   broken /usr/lib64/libatasmart.so.4.0.5 (requires libudev.so.1)

[ 73% ]  *   broken /usr/lib64/libsolid.so.4.9.1 (requires libudev.so.1)

[ 75% ]  *   broken /usr/lib64/opengl/xorg-x11/lib/libEGL.so.1.0.0 (requires libudev.so.1)

[ 79% ]  *   broken /usr/lib64/pulse-2.1/modules/libalsa-util.so (requires libudev.so.1)

 *   broken /usr/lib64/pulse-2.1/modules/module-alsa-card.so (requires libudev.so.1)

 *   broken /usr/lib64/pulse-2.1/modules/module-alsa-sink.so (requires libudev.so.1)

 *   broken /usr/lib64/pulse-2.1/modules/module-alsa-source.so (requires libudev.so.1)

 *   broken /usr/lib64/pulse-2.1/modules/module-udev-detect.so (requires libudev.so.1)

[ 88% ]  *   broken /usr/lib64/vlc/plugins/services_discovery/libudev_plugin.so (requires libudev.so.1)

[ 94% ]  *   broken /usr/lib64/xorg/modules/drivers/radeon_drv.so (requires libudev.so.1)

 *   broken /usr/lib64/xorg/modules/input/evdev_drv.so (requires libudev.so.1)

[ 97% ]  *   broken /usr/libexec/gvfsd-metadata (requires libudev.so.1)

 *   broken /usr/libexec/udev-acl (requires libudev.so.1)

 *   broken /usr/libexec/udisks-helper-drive-detach (requires libudev.so.1)

[ 100% ]                 

emerge --complete-graph=y --oneshot --autounmask-write=y --pretend sys-fs/lvm2:0 sys-fs/udisks:0 x11-base/xorg-server:0

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R    ] sys-fs/lvm2-2.02.97 

[ebuild   R    ] x11-base/xorg-server-1.13.0 

[ebuild   R    ] sys-fs/udisks-1.0.4-r3 

emerge --complete-graph=y --oneshot --autounmask-write=y  sys-fs/lvm2:0 sys-fs/udisks:0 x11-base/xorg-server:0

..........

Calculating dependencies... done!

>>> Verifying ebuild manifests

>>> Running pre-merge checks for x11-base/xorg-server-1.13.0

openpty failed: 'out of pty devices'

>>> Starting parallel fetch

>>> Emerging (1 of 3) sys-fs/lvm2-2.02.97

 * LVM2.2.02.97.tgz SHA256 SHA512 WHIRLPOOL size ;-) ...                            [ ok ]

 * Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Found sources for kernel version:

...

 
```

And it's churning on now. I'll be back to report how it went.

----------

## miroR

Continuing.

(The kernel can be read the name of in earlier post above. The newest, last night's or so.)

The  lvm2 and  xorg-server installed fine.

Here, the third package not,

/var/log/portage_logs/sys-fs:udisks-1.0.4-r3:20120916-235246.log

http://pastebin.mozilla.org/?dl=1826216

The error:

```
collect2: ld returned 1 exit status

make[4]: *** [udisks-helper-ata-smart-collect] Error 1
```

I can't figure what it means.

Neither what to do now.

Let alone not clear to me, still, still! if these posts of mine with these woes belong here... Sorry if they don't. Glad if they do. Because then bigger issues are solved along with mine...

Any more info, like emerge --info and things. Doing them, in the similar hopefully non-obtrusive pasted form as the above!

EDIT: emerge --info:

http://pastebin.mozilla.org/?dl=1826225

(end of EDIT)

Just:

PORTAGE_TMPDIR="/var/tmp" is only so temporarily with sysresccd. It is sure:

PORTAGE_TMPDIR="/dev/shm" regularly.

----------

## VoidMage

@miroR:

```
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libudev.so.1, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libatasmart.so, not found (try using -rpath or -rpath-link)

```

It's a quite simple error - most likely libatasmart.so is underlinked.

----------

## miroR

 *VoidMage wrote:*   

> @miroR:
> 
> ```
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libudev.so.1, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libatasmart.so, not found (try using -rpath or -rpath-link)
> 
> ...

 

Thanx, VoidMage! But it you thought that'd suffice for me to figure out what to do, you're overly-expective   :Razz:   ...

What exactly is wrong with these, pls.:

```
sysresccd / # ls -l /usr/lib/libatasmart.so*

lrwxrwxrwx 1 root root    20 2012-07-10 17:22 /usr/lib/libatasmart.so -> libatasmart.so.4.0.5

lrwxrwxrwx 1 root root    20 2012-07-10 17:22 /usr/lib/libatasmart.so.4 -> libatasmart.so.4.0.5

-rwxr-xr-x 1 root root 55048 2012-07-10 17:22 /usr/lib/libatasmart.so.4.0.5

sysresccd / # 

```

Most certainly a dev understands what to do with this "easy" piece of advice, but I'm not one, and getting to be one, not in my old age!

```
(try using -rpath or -rpath-link)
```

That is a piece of advice for the programmer to put in the program for users to compile, IMHO, ain't it?

----------

## hcaulfield57

miroR: Do you have automount devtmpfs enabled in the kernel? I find it odd that you are having so many errors, because I just did a reinstall of Gentoo on my desktop, and I'm using the forked udev-189 with udev-init-scripts-16 and everything is working perfectly. 

I'm very glad that udev has been forked, please keep up the good work.

----------

## miroR

 *hcaulfield57 wrote:*   

> miroR: Do you have automount devtmpfs enabled in the kernel? I find it odd that you are having so many errors, because I just did a reinstall of Gentoo on my desktop, and I'm using the forked udev-189 with udev-init-scripts-16 and everything is working perfectly. 
> 
> I'm very glad that udev has been forked, please keep up the good work.

 

Hi, hcaulfield57! 

It's the sysresccd kernel, because I'm chrooted with it.

I don't know. How do I found out. And why would it matter?

But VoidMage was, I think, wrong.

This piece of code form the paste above the .. sys-fs:udisks-1.0.4-r3... .log)

```
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libudev.so.1, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libatasmart.so, not found (try using -rpath or -rpath-link)

/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libatasmart.so: undefined reference to `udev_device_new_from_devnum@LIBUDEV_183'

/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libatasmart.so: undefined reference to `udev_new@LIBUDEV_183'

/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libatasmart.so: undefined reference to `udev_device_get_property_value@LIBUDEV_183'

/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libatasmart.so: undefined reference to `udev_device_unref@LIBUDEV_183'

/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libatasmart.so: undefined reference to `udev_device_get_parent_with_subsystem_devtype@LIBUDEV_183'

/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libatasmart.so: undefined reference to `udev_device_get_sysattr_value@LIBUDEV_183'

/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libatasmart.so: undefined reference to `udev_unref@LIBUDEV_183'

collect2: ld returned 1 exit status

```

says it, the libatasmart.so (which may be just a healty library as any other in my Gentoo) didn't find:

 *Quote:*   

> libudev.so.1

 !

Simply because:

```
sysresccd / # find /usr/ -name 'libudev.so*'

/usr/lib64/libudev.so

/usr/lib32/libudev.so

sysresccd / # 
```

there ain't any libudev.so.1 to be found (or shoud I search somewhere else? I don't think so.

Let's see it I get it this way:

```
sysresccd lib64 # ln -s libudev.so  libudev.so.1

sysresccd lib64 # ls -l libudev.so.1

lrwxrwxrwx 1 root root 10 2012-09-17 03:25 libudev.so.1 -> libudev.so

sysresccd lib64 # 
```

```
ysresccd  # emerge -avt sys-fs/udisks
```

No, but the error is now different, and I got way past the error above!

/var/log/portage_logs/sys-fs:udisks-1.99.0-r1:20120917-012727.log

http://pastebin.mozilla.org/1826341

I actually can't even post the entire log on mozilla pastebin. The above link is short.

I'll make another with the ending of

/var/log/portage_logs/sys-fs:udisks-1.99.0-r1:20120917-012727.log:

http://pastebin.mozilla.org/1826356

Back at  hcaulfield57's advice I might be if I don't get to boot into my box normally. Or indeed if I don't get normal boot, that is if these problems persist... Don't know yet. I'll try boot into this Gentoo box now and be back to tell. Or maybe I study the error that's left for me... first...

Can't figure out the errors...

Which are, in brief, withe the aforementioned   

/usr/lib64/libatasmart.so: 

```
/usr/lib64/libatasmart.so: undefined reference to `udev_unref@LIBUDEV_183'
```

and similar, as in the paste above...

Here is more infor, as required in the log:

```
# emerge -pqv '=sys-fs/udisks-1.99.0-r1'

[ebuild   R   ] sys-fs/udisks-1.99.0-r1  USE="crypt gptfdisk introspection -debug -systemd" 

# 
```

----------

## miroR

I do have those configured in the kernel:

```
sysresccd / # grep DEVTMPFS  /usr/src/linux/.config

CONFIG_DEVTMPFS=y

CONFIG_DEVTMPFS_MOUNT=y

sysresccd / # 

```

And I see why I should:have them:

https://forums.gentoo.org/viewtopic-t-917082.html#7008256

Anyway, some progress.

```
# startx
```

got me into X, but, alas, no keyboard, no mouse. True Vulcan pinch only to restart the system. That is, the mechanical reset switch. Because, still no network (meaning: no ssh from my home/no-internet network into the box), because udev don't start and makes no devices...

I had that no kbd, no mouse situation already, I know it's somewhere on the Forums to find how to deal with it, but if someone remembers the trick or where it is, thanks!

Recompiling my kernel, and willl probably try and reboot again.

I think this got to do with this topic where I put it.

It's udev the principal culprit here... I think.

EDIT: Upon reboot with anotther kernel recompile, the situation still stabilized into what already above stated: no net, X w/ no kbd/mouse, udev don't start. end of EDIT.

----------

## hcaulfield57

 *miroR wrote:*   

> 
> 
> EDIT: Upon reboot with anotther kernel recompile, the situation still stabilized into what already above stated: no net, X w/ no kbd/mouse, udev don't start. end of EDIT.

 

This is very odd, have you made sure to add 'udev' to the run level sysinit? Perhaps udev is not getting started, try 

```

ps aux | grep udev 
```

to see if it got started.

----------

## VoidMage

 *miroR wrote:*   

> 
> 
> What exactly is wrong with these, pls.:
> 
> ```
> ...

 

Before taking an advice, be sure to understand it.

See 'ldd -r /usr/lib/libatasmart.so' for a partial explanation.

----------

## miroR

 *VoidMage wrote:*   

>  *miroR wrote:*   
> 
> What exactly is wrong with these, pls.:
> 
> ```
> ...

 

Now that's a nice maxim which I'll try to remember!

And this is what I could've figured, from `man ldd`:

 *VoidMage wrote:*   

> See 'ldd -r /usr/lib/libatasmart.so' for a partial explanation.

 

 but it sure is a programmer's piece of learning:

 *Quote:*   

>     -r --function-relocs
> 
>               Perform relocations for both data objects and functions, and report
> 
>               any missing objects or functions (ELF only).
> ...

 

hcaulfield57, worth trying simple causes, but I'm not that inexperienced to not have had added:

```
# rc-update add udev default
```

long ago, at the time some guide somewhere said to do it.

OTOH, on a non running kernel (I'm in sysresccd chroot, as explained above), I can't run 

```
# rc-status
```

to check it.

But you do seemm to have a point, hey!

I got three other clones (same model MBO and partitioning, mostly dd made clones, with arfterwords modified /etc/fstab /etc/hosts /etc/confd./hostname /etc/confd.d/net and /etc/udev/rules.d/70-persistent-net.rules that, the last one, I moved to  /lib/udev/rules.d/70-persistent-net.rules but keep a symlink /etc/udev/rules.d -> /lib/udev/rules.d/ end of describing cloning), and only one of those three other cloned boxes shows:

```
# rc-status|grep udev

* udev                                [started]

* udev-mount                          [started]

#
```

and it's the one with the

```
sys-kernel/hardened-sources-3.5.3-r2_120914_0200
```

where "120914_0200" is my local version showing hand written date and hour when I was compiling it.

The other clones show, one

```
# rc-status|grep udev

#
```

that is nada, nichts, nil, and the other

```
# rc-status|grep udev

* udev-mount                           [started]

#
```

Both of them are running the kernel:

```
sys-kernel/3.5.2-hardened-r4_120829_1200
```

and I have only now found why these wouldn't get my /etc/init.d/net.eth0 and /etc/init.d/net.eth1, of which one is no-outside world home network (for safety, I am just not surveilled all the time) and the other is dhcpcd Croatia's poor man's broadband (ADSL max 700kbs, when they're not choking your connection, depends what your're doing)... But I was saying... I have only now found some of the reason why these wouldn't get my eth0 and eth1 configured properly.

It's the fabulous money making and probably (for one program, I do suspect money and corruption must be involved: SELinux) gov money taking or no spine and dignity having (no proof, but how on Earth else?), individuals from RedHat (now Fedora) community's great systemd into udev piece of programming, that so much nicer people, though imperfect, you gentoo developers have to rescue GNU Linux from...

That is what I as Joe User suspect is what we're dealing with here. Just what honest devs like khayyam and others eplained in previous posts in this thread.

As an aside: At first SELinux was introduced as if it was RedHat's and not NSA's! (want a link?), and it almost broke the GNU licence for the kernel! (No more rambling, I promise! I'll even take the flak hands down and speechless!)

Now, I sure have to follow the still timely (it's Good morning to you from Europe, lads!) piece of advice by VoidMage.

```
sysresccd / # ldd -r /usr/lib/libatasmart.so

/usr/lib/libatasmart.so: /usr/lib64/libudev.so.1: no version information available (required by /usr/lib/libatasmart.so)

          linux-vdso.so.1 (0x00007fffe470f000)

          libudev.so.1 => /usr/lib64/libudev.so.1 (0x00007f1fe69f3000)

          librt.so.1 => /lib64/librt.so.1 (0x00007f1fe67e9000)

          libc.so.6 => /lib64/libc.so.6 (0x00007f1fe6445000)

          libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1fe6228000)

          /lib64/ld-linux-x86-64.so.2 (0x00007f1fe6e46000)

sysresccd / # 
```

But it doesn't tell me, the user, much... Thanx for the support so far, and hopefully for solving this issue soon!

EDIT (Sorry, I have flaky connection to www from sysresccd, and also my friend Françoiis Dupoux's zsh is driving me crazy, God, bash is my dear cutie! And a previous edition got in for those reasons, instead of the finer worded last one a.k.a. final edition... and it took time. It's past noon, was still morning when I began this current post, end of EDIT)

----------

## miroR

Just as in the earliest post of mine in this thread (https://forums.gentoo.org/viewtopic-p-7142184.html#7142000), I have on every reboot after all the kernel recompiles and emerge --depclean and revdep-rebuild's, as the system was starting services and angels (oh, they are called 'daemons', but that's so ugly), I have always, ever since the breakage showed up 10-15 hours ago now, seen the same line as in that first post of mine in this thread:

```
start-stop daemon: /usr/lib/systemd/systemd-udevd does not exist          [!!]

* udev failed to start 
```

That is what is currently broken in my system. The line on booting also means that udev is in the default rc services. The thing is, I'm very reluctunt now, to load or experiment in any minimal ways with the other three clones, especially not in the sense of rebooting them, because of the broken udev, shown in this one, but clearly present in the other three clones as well...

I would need expert help here as I don't seem to be able to  fix this on my own, no way!

EDIT: Just, since we're talking, if you go and revisit my last years thread (with a timid unsuccessful but noted and criticized renewal this year), my system IMO was under attack. I can still show you my /var/log/auth.log file is still stumped at this time as well, right at the same time and place where it got stumped probably by the attacker, apparently before I went hardened-kernel with grsecuriy/pax ...), and doesn't seem to be touched by intruders later on. Read this part:  https://forums.gentoo.org/viewtopic-t-905472.html#6901814

I mean, since not other people seem to be experiencing these issues (anyone else has these issues?), could it be someone hacking into and breaking things in my systems when they are open to www?

But if noone else has these issues, I cannot expect too much of anybody else's time on these issues.

Thanks again for the support given so far, though! end of EDITLast edited by miroR on Mon Sep 17, 2012 11:38 am; edited 1 time in total

----------

## khayyam

 *miroR wrote:*   

>  *khayyam wrote:*   miroR ... this just looks to me as though you have installed udev-standalone but haven't installed the udev-init-scripts also from the udev overlay. So, gentoo's init scripts are looking for /usr/lib/systemd/systemd-udevd which of course udev-standalone doesn't have. 
> 
> But no, see this:
> 
> ```
> ...

 

Yes, exactly as I stated, the version you have installed is sys-fs/udev-init-scripts-16::gentoo, which would be replaced by sys-fs/udev-init-scripts-16::udev. So, the wrong package.

Now, assuming the above revdep-rebuild was successful, replacing udev-init-scripts should be all thats needed.

Point of order: please try to focus your report into something that is parsable, and please try to focus on the issue and not digress into all manner of observations. It would also help if you made one succinct post rather than a whole chain of posts, that is, less noise more signal.

best ... khay

----------

## miroR

 *khayyam wrote:*   

>  *miroR wrote:*    *khayyam wrote:*   miroR ... this just looks to me as though you have installed udev-standalone but haven't installed the udev-init-scripts also from the udev overlay. So, gentoo's init scripts are looking for /usr/lib/systemd/systemd-udevd which of course udev-standalone doesn't have. 
> 
> But no, see this:
> 
> ```
> ...

 

I'll try to compy, captain!

I did reinstall udev-init-scripts. It is now ::udev, not anymore ::gentoo.

Subsequent emerge --depclean showed no redundant packaged.

But revdep-rebuild did go for reinstalling the same three packages as in both (there were two I think) previous runs upon other tries at fixing this issue of mine. sys-fs/lvm2,  x11-base/xorg-server (both apparently reinstalled fine) and sys-fs/udisks.

The latter, sys-fs/udisks, didn't go past an obstacle similar to the second of the two obstacles it previously encountered in two separate tries at reinstall, that is, this third try:

/var/log/portage_logs/sys-fs:udisks-1.0.4-r3:20120917-115958.log:

http://pastebin.mozilla.org/1827170

emerge --info  is as in the link already given above:

http://pastebin.mozilla.org/?dl=1826225

emerge -pqv '=sys-fs/udisks is also unchaned from above.

----------

## miroR

However, my system in question booted!

I got all back, www, devices, shiny Gentoo as always.

Thanks, and really sorry for my old man's incumbering ways!

If any more info is possibly needed form me (such as if sys-fs:udisks finally installed, I'll keep an eye on this thread for a while.

Cheers! Thanks again!

----------

## khayyam

grey_d0t, consus, et al ...

I just noticed the following. If kmod is built with the lzma useflag we get:

```
# ldd /sbin/udevd

** /sbin/udevd

    linux-gate.so.1 (0xb77a6000)

    libblkid.so.1 => /lib/libblkid.so.1 (0xb776f000)

    libkmod.so.2 => /lib/libkmod.so.2 (0xb775a000)

    librt.so.1 => /lib/librt.so.1 (0xb7751000)

    libc.so.6 => /lib/libc.so.6 (0xb75c9000)

    libuuid.so.1 => /lib/libuuid.so.1 (0xb75c3000)

    liblzma.so.5 => /usr/lib/liblzma.so.5 (0xb75a0000)

    libz.so.1 => /lib/libz.so.1 (0xb758b000)

    libpthread.so.0 => /lib/libpthread.so.0 (0xb7571000)

    /lib/ld-linux.so.2 (0xb77a7000)

# equery belongs /usr/lib/liblzma.so.5

app-arch/xz-utils-5.0.4 (/usr/lib/liblzma.so.5.0.4)

app-arch/xz-utils-5.0.4 (/usr/lib/liblzma.so.5 -> liblzma.so.5.0.4)
```

This is basically due to kmod linking to liblzma ...

```
# ldd /sbin/kmod

** /sbin/kmod

    linux-gate.so.1 (0xb773e000)

    libkmod.so.2 => /lib/libkmod.so.2 (0xb7716000)

    libc.so.6 => /lib/libc.so.6 (0xb758e000)

    liblzma.so.5 => /usr/lib/liblzma.so.5 (0xb756b000)

    libz.so.1 => /lib/libz.so.1 (0xb7556000)

    /lib/ld-linux.so.2 (0xb773f000)

    libpthread.so.0 => /lib/libpthread.so.0 (0xb753b000)
```

So, we need to either provide an ebuild for xz-utils that installs to /lib or use.mask the lzma use on kmod. Well, I haven't given it too much thought as I just discovered the above, so there may be some other solution here.

best ... khay

----------

## grey_dot

 *khayyam wrote:*   

> 
> 
> So, we need to either provide an ebuild for xz-utils that installs to /lib 
> 
> 

 

done.

----------

## LiamOS

Thanks very much for the fork!

I'll get started using it tomorrow and see what happens.  :Smile: 

----------

## khayyam

 *grey_dot wrote:*   

>  *khayyam wrote:*   
> 
> So, we need to either provide an ebuild for xz-utils that installs to /lib 
> 
> done.

 

grey_dot ...

that fixes it, and so, with  app-arch/xz-utils-5.0.4::udev, and the lzma useflag on sys-apps/kmod-10::udev

```
# ldd /sbin/udevd

   linux-gate.so.1 (0xb77dc000)

   libblkid.so.1 => /lib/libblkid.so.1 (0xb77a5000)

   libkmod.so.2 => /lib/libkmod.so.2 (0xb7790000)

   librt.so.1 => /lib/librt.so.1 (0xb7787000)

   libc.so.6 => /lib/libc.so.6 (0xb75ff000)

   libuuid.so.1 => /lib/libuuid.so.1 (0xb75f9000)

   liblzma.so.5 => /lib/liblzma.so.5 (0xb75d6000)

   libz.so.1 => /lib/libz.so.1 (0xb75c1000)

   libpthread.so.0 => /lib/libpthread.so.0 (0xb75a7000)

   /lib/ld-linux.so.2 (0xb77dd000)
```

Is it now worth thinking about a (package) name change? Currently virtual/dev-manager-0 consists of the following:

sys-fs/udev

sys-apps/busybox[mdev]

sys-fs/devfsd

sys-fs/static-dev

sys-freebsd/freebsd-sbin

... and of course 'udev-standalone' could also provide that virtual, at least if the package was renamed.

At the Gentoo Council Meeting, April 2012, it was voted 5 to 1 in favour of separate /usr as a supported configuration, and there has been much said in other threads, mailing lists, etc, about the issue, sometimes with the refrain "well, if nobody is willing to fork udev then we will just have to accept upstreams decisions" (not a direct quote, but close enough), so I think the question should be raised now (well, perhaps a number of questions).

1. Firstly, should a bug be opened, and are there any devs who are perhaps reading that might care to comment, and/or have any suggestions as to the issues involved here?

2. Can 'udev-standalone' (or whatever name it might go under) be stablised code wise in order that a release could be made? Not that whats currently in git is necessarily unstable, but more in terms of point releases that can be in portage long enough to get user tested.   

3. Besides kmod, and xz-utils what other packages and/or issues need to be accounted for? ie: is seperate /var an issue? I remember a discussion sometime back re alsa being called by udev and expecting /var mounted for a pid or some such, are there other issues that need to be addressed?

[probably more]

I'm not attempting to become a self-appointed spokesman or anything, I just know that these things can take time to work their way into portage, so its more an issue of trying to get/keep the ball rolling and gather momentum, and thats the only reason I feel it worth posing these questions (and no doubt others) now.

best ... khay

----------

## hcaulfield57

 *khayyam wrote:*   

> I remember a discussion sometime back re alsa being called by udev and expecting /var mounted for a pid or some such, are there other issues that need to be addressed?
> 
> 

 

Just a note, because you mentioned alsa. I currently have separate /usr and separate /var, and when udev gets started it complains about not being able to find /usr/bin/alsactl. I believe that it is trying to reset my volumes, which does not work because /usr is not mounted yet. This is not a big deal, because I just set up the alsa script to start in 'default' runlevel after /usr is mounted and my volumes work correctly. There is no reason that alsactl needs to be in /bin, for issues like this changing the script is all that's necessary. Overall, the issues have been minor for my setup, and this is a very non-invasive change. I'm very pleased with the udev-fork and would like to see it something officially sponsored by Gentoo, perhaps other distros will take it up as well.

----------

## khayyam

 *hcaulfield57 wrote:*   

> Just a note, because you mentioned alsa. I currently have separate /usr and separate /var, and when udev gets started it complains about not being able to find /usr/bin/alsactl.

 

hcaulfield57 ... ok, my problem is I don't have a seperate /usr (or /var) and so I'm less likely to encounter these minor issues, a list of problem packages is useful here, and though media-sound/alsa-utils (alsactl) is not essencial to boot it may be possible to fix such things via the init script.

 *hcaulfield57 wrote:*   

> Overall, the issues have been minor for my setup, and this is a very non-invasive change. I'm very pleased with the udev-fork and would like to see it something officially sponsored by Gentoo, perhaps other distros will take it up as well.

 

Personally, I've had no issues at all. My setup is such that I could quite easily drop udev entirely and, with some minor changes here and there, still have a functioning system, but when I read: "udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely" (Lennart Poettering,  Aug 2012), the issue becomes less about udev itself and more and more about a coup de main of init, and that I certainly do not want to see. Some two years prior (LKML, May 2010), Lennart Poettering stated "systemd certainly won't require an initrd or anything else equally intrusive", but from my perspective, this is entrirely disengenious as systemd is the intrusion if something as pervasive as udev is unsupported on anything but systemd.

So, yes, I likewise want to see Gentoo buck this whole trend, but as systemd is becoming more and more a requirement, rather than an option (particularly when it comes to the lovelyishious offerings of the desktop) then it really needs to be addressed quickly and throughly, as otherwise it will be on us, and there will be nothing that can be done about it.

best ... khay

----------

## grey_dot

 *hcaulfield57 wrote:*   

>  *khayyam wrote:*   I remember a discussion sometime back re alsa being called by udev and expecting /var mounted for a pid or some such, are there other issues that need to be addressed?
> 
>  
> 
> Just a note, because you mentioned alsa. I currently have separate /usr and separate /var, and when udev gets started it complains about not being able to find /usr/bin/alsactl. I believe that it is trying to reset my volumes, which does not work because /usr is not mounted yet. This is not a big deal, because I just set up the alsa script to start in 'default' runlevel after /usr is mounted and my volumes work correctly. There is no reason that alsactl needs to be in /bin, for issues like this changing the script is all that's necessary. Overall, the issues have been minor for my setup, and this is a very non-invasive change. I'm very pleased with the udev-fork and would like to see it something officially sponsored by Gentoo, perhaps other distros will take it up as well.

 

That's because of /lib/udev/rules.d/90-alsa-restore.rules which is brought by alsa. Basically, this is not needed during boot because /etc/init.d/alsa does the same. This rule is only necessary if you have hotplugable sound cards. We'll try to fix this issue in the near future so that the rule will be postponed until the necessary binaries become available.

p.s. there is WAIT_FOR udev rule, but it doesn't work the way we want it to :)

----------

## grey_dot

 *grey_dot wrote:*   

>  *hcaulfield57 wrote:*    *khayyam wrote:*   I remember a discussion sometime back re alsa being called by udev and expecting /var mounted for a pid or some such, are there other issues that need to be addressed?
> 
>  
> 
> Just a note, because you mentioned alsa. I currently have separate /usr and separate /var, and when udev gets started it complains about not being able to find /usr/bin/alsactl. I believe that it is trying to reset my volumes, which does not work because /usr is not mounted yet. This is not a big deal, because I just set up the alsa script to start in 'default' runlevel after /usr is mounted and my volumes work correctly. There is no reason that alsactl needs to be in /bin, for issues like this changing the script is all that's necessary. Overall, the issues have been minor for my setup, and this is a very non-invasive change. I'm very pleased with the udev-fork and would like to see it something officially sponsored by Gentoo, perhaps other distros will take it up as well. 
> ...

 

----------

## hcaulfield57

 *khayyam wrote:*   

> 
> 
> Personally, I've had no issues at all. My setup is such that I could quite easily drop udev entirely and, with some minor changes here and there, still have a functioning system,
> 
> 

 

Yes, my setup is similar, I have mdev working properly on another installation of mine (LFS), it works with no problems, everything else works properly with it. Really udev is unnecessary for many systems, and even static /dev works well. This is a desktop, for servers it's very simple to drop udev if you don't rely on something like LVM. 

 *khayyam wrote:*   

> 
> 
> but when I read: "udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely" (Lennart Poettering,  Aug 2012), the issue becomes less about udev itself and more and more about a coup de main of init, and that I certainly do not want to see. Some two years prior (LKML, May 2010), Lennart Poettering stated "systemd certainly won't require an initrd or anything else equally intrusive", but from my perspective, this is entrirely disengenious as systemd is the intrusion if something as pervasive as udev is unsupported on anything but systemd.
> 
> So, yes, I likewise want to see Gentoo buck this whole trend, but as systemd is becoming more and more a requirement, rather than an option (particularly when it comes to the lovelyishious offerings of the desktop) then it really needs to be addressed quickly and throughly, as otherwise it will be on us, and there will be nothing that can be done about it.
> ...

 

I'm absolutely in agreement with you here, I do not want systemd to take over Linux and become the init system that everyone has to use. And for people who do rely on udev they need an alternative to have working systems. Also, once people depend on systemd, who knows what other whims of its developers they will be forced to follow. My guess is that the Gentoo devs are taking a 'wait and see' approach, and will evaluate the best solution once it is no longer possible to build/run udev outside of systemd, which who knows may be tomorrow or a year from now. However, I would like to see this fork get a more official status within Gentoo, and I know other distros will appreciate this. 

I hope to be able to help however I can as well, I'm not a programmer, but at the very least I can test this fork. 

 *grey_dot wrote:*   

> 
> 
> That's because of /lib/udev/rules.d/90-alsa-restore.rules which is brought by alsa. Basically, this is not needed during boot because /etc/init.d/alsa does the same. This rule is only necessary if you have hotplugable sound cards. We'll try to fix this issue in the near future so that the rule will be postponed until the necessary binaries become available.
> 
> p.s. there is WAIT_FOR udev rule, but it doesn't work the way we want it to 

 

Okay thanks grey_dot, and don't feel like this is a pressing issue, it's relatively minor, I just brought it up as an example of something that breaks with separate /usr, it's probably not even udev's fault.

----------

## olek

I'm really looking forward to this fork, just trying it out now.

----------

## grey_dot

For those of you who are still interested, release 190 is out. All major upstream changes are ported as usual, since there was only one there - btrfs raid hotplug support.

Among other things, thanks to consus whos lazy ass I have to kick all the time, we replaced gtk-doc with doxygen, which removes some ugly build-time hacks.

You also should update udev-init-scripts to version 16-r1, since udevd was moved to /sbin in this release. Please, do not forget to report all issues you encounter. Have fun :)

----------

## hcaulfield57

 *grey_dot wrote:*   

> For those of you who are still interested, release 190 is out.
> 
> 

 

I updated right away. Everything seems to be working well. Keep up the good work!

----------

## The Doctor

Thanks for the fork. So far its working very nicely on my hardened desktop.

----------

## olek

So far, everything is working, nice! But I get this on shutdowns: 

 *Quote:*   

> udevd: IMPORT{builtin}: 'btrfs ready $devnode' unknown /lib64/udev/rules.d/64-btrfs.rules:8

 

----------

## grey_dot

 *olek wrote:*   

> So far, everything is working, nice! But I get this on shutdowns: 
> 
>  *Quote:*   udevd: IMPORT{builtin}: 'btrfs ready $devnode' unknown /lib64/udev/rules.d/64-btrfs.rules:8 

 

Do you have btrfs-progs installed?Last edited by grey_dot on Wed Sep 26, 2012 9:50 am; edited 1 time in total

----------

## olek

you mean btrfs-progs? yes: sys-fs/btrfs-progs-0.19.11

----------

## grey_dot

 *olek wrote:*   

> you mean btrfs-progs? yes: sys-fs/btrfs-progs-0.19.11

 

Yeah. Any btrfs partitions present?

----------

## grey_dot

 *olek wrote:*   

> you mean btrfs-progs? yes: sys-fs/btrfs-progs-0.19.11

 

Yeah. Any btrfs partitions present?

----------

## olek

currently not. There isn't even the module loaded currently. I once just played around with the tools, but each partition has been deleted.

----------

## grey_dot

 *olek wrote:*   

> currently not. There isn't even the module loaded currently.

 

That might be the case. Ok, thanks for the report :)

----------

## theBlackDragon

 *mv wrote:*   

> I was hoping for this since Lennart admitted that the originally claimed reasons for the merge were just marketing lies with the actual purpose to force users into systemd (which was of course not a surprising opening; only surprise was that Lennart admitted it in a sense.)

 

Slightly OT, but do you have any links for this? While I wouldn't be surprised at all Google seems to come up blank (at least, insofar Lennart himself stating this).

More on-topic. YAY! Keep up the good work!  :Smile: 

----------

## hcaulfield57

 *theBlackDragon wrote:*   

> 
> 
> Slightly OT, but do you have any links for this? While I wouldn't be surprised at all Google seems to come up blank (at least, insofar Lennart himself stating this).
> 
> 

 

https://forums.gentoo.org/viewtopic-p-7126118.html#7126118

----------

## theBlackDragon

 *hcaulfield57 wrote:*   

>  *theBlackDragon wrote:*   
> 
> Slightly OT, but do you have any links for this? While I wouldn't be surprised at all Google seems to come up blank (at least, insofar Lennart himself stating this).
> 
>  
> ...

 

Oh right, I read that. I just interpreted that remark as him having literally said as much (though I guess that quote isn't all that far off)

----------

## hcaulfield57

 *theBlackDragon wrote:*   

> 
> 
> Oh right, I read that. I just interpreted that remark as him having literally said as much (though I guess that quote isn't all that far off)
> 
> 

 

Yes, I believe that was the implication of the quote, I know that many people probably suspected this from the beginning of the merge.

----------

## aCOSwt

 *consus wrote:*   

> 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  :Shocked: 

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.

----------

## grey_dot

 *aCOSwt wrote:*   

>  *consus wrote:*   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 
> ...

 

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 :)

----------

## asturm

Are you guys all aware of that discussion? http://marc.info/?l=linux-kernel&m=134929242315036&w=2

 :Wink: 

----------

## aCOSwt

 *genstorm wrote:*   

> Are you guys all aware of that discussion? http://marc.info/?l=linux-kernel&m=134929242315036&w=2

 

If this is the one ending with Linus deciding to bypass udev for loading firmware... then...   :Shocked:  There's going to be a real good reason for KV_min > 3.a_lot   :Evil or Very Mad: 

----------

## asturm

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.  :Smile: 

----------

## jathlon

I got a warm fuzzy feeling from this statement by Al Viro;

 *Quote:*   

> 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.
> ...

 

----------

## NeddySeagoon

/me gets ready to drop Gnome when it pulls in systemd

----------

## grey_dot

 *jathlon wrote:*   

> I got a warm fuzzy feeling from this statement by Al Viro;
> 
>  *Quote:*   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
> ...

 

Not a bad idea after all, but methinks this is unlikely to happen.

----------

## asturm

Someone just called for a udev fork if they won't fix it  :Very Happy: 

----------

## The Doctor

 *genstorm wrote:*   

> Someone just called for a udev fork if they won't fix it 

 

Wait... Isn't that what we have here?   :Wink: 

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.

----------

## aCOSwt

 *The Doctor wrote:*   

> 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

 

Formally speaking :

a/ it is not udev which is responsible for starting alsactl before /usr is mounted, it is you!

b/ /usr is not that much responsible for the irritating problem you see, it's /var !

I do not personally understand why I would need alsasound to be set at the boot run level.

OK, I know, the official handbook instructs to do so, but really... I cannot figure out why.

What I did under my system was to remove it from the boot run level and declare it in the default run level.

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

```
# rc-update delete alsasound

# rc-update add alsasound default
```

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

----------

## The Doctor

 *aCOSwt wrote:*   

> That way, alsactl is not required to run when /var is not yet mounted.
> 
> ```
> # rc-update delete alsasound
> 
> ...

 

I did try that already. It seems that did not work for me.  :Confused: 

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?

----------

## grey_dot

 *aCOSwt wrote:*   

> 
> 
> Formally speaking :
> 
> a/ it is not udev which is responsible for starting alsactl before /usr is mounted, it is you!
> ...

 

Well, actually it's udev. Or the rules brought by alsa.

```

> grep -R usr /lib/udev/rules.d 

/lib/udev/rules.d/90-alsa-restore.rules:        RUN+="/usr/sbin/alsactl restore $attr{number}"

```

I've already wrote several pages before that this isn't required during boot stage because /etc/init.d/alsasound does the same.

----------

## The Doctor

 *grey_dot wrote:*   

> I've already wrote several pages before that this isn't required during boot stage because /etc/init.d/alsasound does the same.

 

So to clarify, it is safe to remove these rules? (While making backup, of course.)

I ask because the last time I tried to get cleaver I ended re-installing after a misplaced rm command.

----------

## grey_dot

 *The Doctor wrote:*   

> 
> 
> So to clarify, it is safe to remove these rules? (While making backup, of course.)
> 
> I ask because the last time I tried to get cleaver I ended re-installing after a misplaced rm command.

 

Yes, unless you use a hotplugable soundcard. Otherwise you'll end with running `/etc/init.d/alsasound restart` everytime you plug it in.

----------

## steveL

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.

----------

## gerard27

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.

----------

## khayyam

 *gerard82 wrote:*   

> A big Thank You to grey_dot, consus, khayyam et al.

 

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 ...

best ... khay

----------

## gerard27

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

----------

## asturm

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.

----------

## gerard27

@genstorm,

AFAIK 176-r6 is the highest version that allows you to have /usr & /var on separate partitions w/o an initram.

Gerard.

----------

## hcaulfield57

 *khayyam wrote:*   

> 
> 
> 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.

----------

## grey_dot

 *gerard82 wrote:*   

> @genstorm,
> 
> AFAIK 176-r6 is the highest version that allows you to have /usr & /var on separate partitions w/o an initram.
> 
> Gerard.

 

Nope. I tested with 182 and it worked.

----------

## grey_dot

 *khayyam wrote:*   

> 
> 
> 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.

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

I've just submitted a bug to bugzilla. Lets wait :)

----------

## hcaulfield57

 *grey_dot wrote:*   

> 
> 
> I've just submitted a bug to bugzilla. Lets wait 
> 
> 

 

Thank you, keep up the good work.

----------

## steveL

 *khayyam wrote:*   

> 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 receive full credit for that.

 

Yes, that's true, but I've given you credit for the simple reason that you're doing QA work, and also providing ebuilds for stuff where needed (ie integration.)

 *Quote:*   

> Truth be told I'm actually a little nervous about the whole thing

 

Again, it's good that you've raised those concerns, and action is being taken.

I'd recommend chatting with WilliamH in #openrc (IRC chat.freenode.net) as he was asking about naming conflicts. I only found out a couple of weeks ago that he is blind, and uses a screen-reader, so he may well have difficulty wading through tonnes of forum posts, whereas IRC is much more direct. (Learning that only increased my respect for the amount of code he produces.)

Hopefully he'll respond on the bug, I'll point it out to him. But I still think a "direct" conversation is the best approach, rather than to-and-fro-ing on a bug report.

 *Quote:*   

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

 

That'd be great, as concern about when udev starts is the only thing that's stopping me switching. (Well, I'd rather it was a differently-named package which also satisfied the virtual..;)

Regards,

steveL.

----------

## grey_dot

 *steveL wrote:*   

> 
> 
>  *Quote:*   steveL ... I'll look at integrating these into udev-init-scripts in my overlay ... 
> 
> That'd be great, as concern about when udev starts is the only thing that's stopping me switching. (Well, I'd rather it was a differently-named package which also satisfied the virtual..;)
> ...

 

Hey, check out udev-init-scripts in udev overlay. Consus has moved udev path to /etc/conf.d/udev, so you can adjust it when needed without actually editing init script. Thats the best idea we have for now. Suggestions are welcome :)

----------

## krinn

You should rename it to something and dropping any udev reference from soname lib and init script.

As-is your fork put too much ambiguity with udev. People will get force to revdep-rebuild against the new soname lib, but nobody will mistake your fork with udev, and things will get clear.

I'm saying it because i think, gentoo devs will complain, users might report udev bugs as yours and invert. Preventing any adoption in the tree.

And for the arch linux guy, he just need to make a symbolic link if he wish keep the "i'm udev" hack.

having your script name udev-init-scripts per example can keep confusion and unwanted behavior, while even rename, if endorse, yourprog-init-scripts will be add and handle like any supported program. And the git repo named udev is worst  :Smile: 

----------

## VinzC

Hi. I have absolutely no knowledge of systemd but isn't it wiser or more logical (all personal issues apart) if systemd was split or allowed to split its components into separate parts, e.g. systemd-udev or whatever (just like KDE or Xorg did years ago)? Now that Arch is moving towards systemd, I guess maintaining a split udev branch like this will become more and more likely to absorb much energy to the expense of other projects — it's my own feeling, just tell me if I'm wrong. If that was possible then all Gentoo would need is a meta package to incorporate all systemd components. Now the question is how much work would that require?

Does it make sense? Call me an idiot if necessary  :Very Happy:  .

----------

## DaggyStyle

 *VinzC wrote:*   

> Hi. I have absolutely no knowledge of systemd but isn't it wiser or more logical (all personal issues apart) if systemd was split or allowed to split its components into separate parts, e.g. systemd-udev or whatever (just like KDE or Xorg did years ago)? Now that Arch is moving towards systemd, I guess maintaining a split udev branch like this will become more and more likely to absorb much energy to the expense of other projects — it's my own feeling, just tell me if I'm wrong. If that was possible then all Gentoo would need is a meta package to incorporate all systemd components. Now the question is how much work would that require?
> 
> Does it make sense? Call me an idiot if necessary  .

 

well it seems that the actions of the udev developers is starting to angry the kernel devs and there are some calling to create a udev replacment so IMHO this does make sense until either the udev devs will cave in (extremely not likely) or the kernel devs will decide they had enough and will take action.

----------

## hcaulfield57

 *DaggyStyle wrote:*   

> 
> 
> well it seems that the actions of the udev developers is starting to angry the kernel devs and there are some calling to create a udev replacment so IMHO this does make sense until either the udev devs will cave in (extremely not likely) or the kernel devs will decide they had enough and will take action.
> 
> 

 

It would be great if that happened, but it looks like the thread where they were going off about udev, has cooled down. It would be really awesome if they did something about this. It would be guaranteed to have some effect. 

 *VinzC wrote:*   

> Hi. I have absolutely no knowledge of systemd but isn't it wiser or more logical (all personal issues apart) if systemd was split or allowed to split its components into separate parts, e.g. systemd-udev or whatever (just like KDE or Xorg did years ago)? 

 

That would make sense, but it seems the entire reason udev was merged into systemd was to force the usage of systemd in the first place, so it seems very unlikely that will happen, if ever. 

 *steveL wrote:*   

> 
> 
> I'd recommend chatting with WilliamH in #openrc (IRC chat.freenode.net) as he was asking about naming conflicts. I only found out a couple of weeks ago that he is blind, and uses a screen-reader, so he may well have difficulty wading through tonnes of forum posts, whereas IRC is much more direct. (Learning that only increased my respect for the amount of code he produces.)

 

That's actually really amazing.

-------------------------------------

It's unfortunate that there is so much animosity towards this fork on the part of Gentoo devs, it would seem that this would be something they would quickly accept, but it looks like the bug got rejected. This udev nonsense with upstream is so stupid, I wish it would get sorted out. 

I really think it's time for a name change for the fork, the suggested 'nudev' seems appropriate. I think one of the reasons this is failing to get traction is because of the name, and confusion about what the fork actually is. And then the ebuild could just install the appropriate udev symlinks to whatever the fork is called.

----------

## aCOSwt

 *hcaulfield57 wrote:*   

> It's unfortunate that there is so much animosity towards this fork on the part of Gentoo devs

 

Just a stupid question :

If major distros opt for upstream's udev (with or without systemd) then, on our system we will get either /usr not as a separate partition or initramfs.

=> No longer needed to care for /lib and /bin => Easier work for everybody packaging whatever software. Binaries will get installed in /usr/bin and libraries in /usr/lib period.

If I go for This-Udev-Fork which enables me to keep my /usr in a separate partition without needing initramfs...

Who will take care of my /lib and /bin ?

This-Udev-Fork's maintainers, Me, Nobody or the Gentoo Devs ?

----------

## NeddySeagoon

VinzC,

Unfortunately, the udev devs have yet to learn the lessons that the Xorg and KDE teams did when they broke up their monoliths.

The other thing driving udev into the arms of systemd is it could allow systemd to hold the rest of the Linux world to ransom.

Maybe the good idea fairy will revist systemd ...

----------

## grey_dot

 *aCOSwt wrote:*   

> 
> 
> => No longer needed to care for /lib and /bin => Easier work for everybody packaging whatever software. Binaries will get installed in /usr/bin and libraries in /usr/lib period.
> 
> 

 

In this case we are fucked. Period.

----------

## aCOSwt

 *grey_dot wrote:*   

>  *aCOSwt wrote:*   
> 
> => No longer needed to care for /lib and /bin => Easier work for everybody packaging whatever software. Binaries will get installed in /usr/bin and libraries in /usr/lib period.
> 
>  
> ...

 

So now that we can consider we are anyway...

Let's just think.

You have achieved a great job grey_dot & Co, but only the simplest part of it.

Now, considering that the major originality of your fork is /usr as a separate partition with no initramfs, you've got to sell this idea to those who would have to keep on maintaining installations in /lib and /bin.

Either sell it or... find some automagick way to maintain these dirs effortlessly.

----------

## krinn

 *hcaulfield57 wrote:*   

> 
> 
> It's unfortunate that there is so much animosity towards this fork on the part of Gentoo devs, it would seem that this would be something they would quickly accept, but it looks like the bug got rejected. This udev nonsense with upstream is so stupid, I wish it would get sorted out. 
> 
> 

 

From what i see, what you called dev animosity is that someone (dunno, we "users" could do that, and we do mistake, specially with a program named udev like "udev") assign that bug to udev team, as such, team complain about it as it as no relation to udev. That's why dev told you if you need any udev related change, ring them, else it's not their task.

Now the bug is assign to "Default Assignee for New Packages" : it mean waiting for a dev to endorse the package, if none do it, it will be reject.

If you really wish this add, do it like it should be done, i don't know really the rules and where to catch them, but it should be close to that, from experience and memory, so take it as it is, just hint, could be far from truth. At least, #gentoo-bugs could have help you on that.

1/ a bug to add it to tree (it mean calling a dev to endorse it): because until grey_dot is a gentoo dev, his package won't be accept if no gentoo dev endorse it. Kinda of a sponsoring, and this even the gentoo dev will only submit change to the tree, it will be his account and him that should answer any problem the program might introduce. So this "sponsorship" is not a 0 work for him.

2/ another bug with a called for change to add it to the virtual/udev depending/blocking bug 1

3/ The real way to add it is becoming a gentoo dev and endorse it yourself (again rules exist for that, with test... i won't discuss this, it's just to show another possible solve)

As i said, the ambiguity of the name will harm the project, that's was the first hit. So i won't say it will not be add, but you've taken a bad step in the process for sure.

You should have also notice that this thread should have been drop to unsupport software, now it is in kernel&hardware and even more, made sticky, that's a silent move to help you and another sign that fork isn't considered as bad as you think.

----------

## NeddySeagoon

krinn,

... or add it to the Sunrise overlay so it gets more exposure than it would on a bug.

However, it cannot be called udev. There is already a udev package in the tree, so a name change is required.

A further advantage to Sunrise is the comiters begin to get exposure to Gentoo devs - it makes the path to ebuild dev stauts easier.

----------

## hcaulfield57

 *krinn wrote:*   

> 
> 
> From what i see, what you called dev animosity is that someone (dunno, we "users" could do that, and we do mistake, specially with a program named udev like "udev") assign that bug to udev team, as such, team complain about it as it as no relation to udev. That's why dev told you if you need any udev related change, ring them, else it's not their task.
> 
> [snip]
> ...

 

Thanks for the response krinn. What you said makes sense, and the word I used 'animosity' should probably be retracted, I admit that was emotional and wasn't thought out well enough. I agree with what you said above, but yes the name really needs to be changed. I do hope the /usr merge does not happen, it's so pointless and only creates problems. An interesting rant on the kernel mailing list -> http://marc.info/?l=linux-kernel&m=134931225309449&w=2

----------

## Jubei-Mitsuyoshi

hi have rebuilt most of Archlinux against udev-fork

i am currently running a full cinnamon system ontop of it, EVERYTHING works perfectly, i have removed all traces of systemd from over 60 packages, all thanks to udev-fork ( and gentoo patches, and ebuilds which are the greatest resource any packager can ever draw upon ). I hope other distros take notice of what can be achieved in this direction.

And a public thank you to the gentoo community for the patches and techniques borrowed from ebuilds, without those it would be bloody impossible to build jack shit !

edit....... i no longer have anything to do with Archlinux, hence have removed the repo locations..Last edited by Jubei-Mitsuyoshi on Wed Oct 10, 2012 5:53 pm; edited 1 time in total

----------

## Anon-E-moose

Interesting exchange from the link, hcaulfield57.

I've stuck with running udev-171-r6.

----------

## gerard27

Interesting:

https://lkml.org/lkml/2012/10/2/303

Gerard.

----------

## hcaulfield57

 *Anon-E-moose wrote:*   

> 
> 
> I've stuck with running udev-171-r6.

 

As far as I am aware, Gentoo is going to maintain 171 indefinitely. Unless I am mistaken about this.

EDIT: Well it will be interesting to see what happens with this on LKML.

----------

## Anon-E-moose

If it comes down to it, I can remove udev completely. 

I'm old school as far as unix/linux and X so it wouldn't be a big deal to go that way.

It's a great convenience, but not an absolute necessity. 

This whole udev fiasco reminds me of the total brouhaha over "hal", 

which if I remember right, Kay was involved in that cluster f**k also.

Time marches on  :Wink: 

----------

## hcaulfield57

 *Anon-E-moose wrote:*   

> If it comes down to it, I can remove udev completely. 
> 
> I'm old school as far as unix/linux and X so it wouldn't be a big deal to go that way.
> 
> It's a great convenience, but not an absolute necessity. 
> ...

 

I could remove udev completely as well, in fact mdev or static /dev both work perfectly fine for my setup. The only thing that really depends on udev is auto-mounted volumes and what not in most DEs and LVM as far as I am aware. But it would be nice if people who have to use udev have an opportunity to not drag in all of GNOME with udev.

----------

## krinn

 *Anon-E-moose wrote:*   

> This whole udev fiasco reminds me of the total brouhaha over "hal", 
> 
> which if I remember right, Kay was involved in that cluster f**k also.

 

And lennart is never far -> ?

----------

## Anon-E-moose

 *hcaulfield57 wrote:*   

>  *Anon-E-moose wrote:*   If it comes down to it, I can remove udev completely. 
> 
> I'm old school as far as unix/linux and X so it wouldn't be a big deal to go that way.
> 
> It's a great convenience, but not an absolute necessity. 
> ...

 

I removed almost all traces of gnome a while back, the only parts left don't pull in gconf, etc. 

I refuse to use anything that pulls in tons of gnome dependencies, even if it cause me to use another package or do without.

This is just my personal preference. For those that like/use gnome more power to them. 

Linux/unix has always been about choice.

These are the only gnome packages that I still have left:

gnome-base/libglade

gnome-base/librsvg

x11-libs/gnome-pty-helper

x11-themes/gnome-icon-theme

and though they are "gnome" they're minor things.

I also don't do auto-mount on devices, except for my normal disks. 

I don't even boot into a graphics screen preferring the regular console and doing startx. 

But that's me.

I'm glad to see the fork happening, and with a little perseverance I think that others will start seeing the need/desire for it.

Edit to add:

For those that use udev and want to have another option, then make a tar file of the dev directory as udev sees it.

Then you have as least the basis for getting a system running without udev.

----------

## hcaulfield57

 *Anon-E-moose wrote:*   

> 
> 
> I also don't do auto-mount on devices, except for my normal disks. 
> 
> I don't even boot into a graphics screen preferring the regular console and doing startx. 
> ...

 

Yea, that setup sounds very similar to mine, my only graphical programs are firefox and zathura (for pdf). I tend to prefer minimalism with the software I use, hence why I like mdev so much. But I suppose this is greatly off topic   :Smile: 

----------

## steveL

 *grey_dot wrote:*   

> Hey, check out udev-init-scripts in udev overlay. Consus has moved udev path to /etc/conf.d/udev, so you can adjust it when needed without actually editing init script. Thats the best idea we have for now. Suggestions are welcome :)

 

That's what the linked scripts do too, but in order to actually use the parameter, udev initscripts must also be patched to do something with it. In our case, when initramfs is set to "no", udev sets its dependencies up for start after localmount (and thus needs to change runlevel.) If you want to know what I'm on about, just look at the patches (they're right there in the post itself.)

So yeah, the end-user only tweaks a setting the in conf.d file (but must also know to change runlevels when switching the setting.)

Wait, when you say "moved udev path to /etc/conf.d/udev" do you mean /etc/init.d/udev is now /etc/conf.d/udev? Because I don't want that at all.

I'm happy to wait for khayyam to integrate our changes, and for the package to be renamed. While fulfilling the virtual would be great, it won't happen until Gentoo officially makes it happen, so I'd be happy to use package.provided instead.

I'm not sure soname-renaming is such a great idea, personally, if (and only if) the same ABI is being provided. If it is, or will potentially be, a different ABI, (ie not all of the same functions are provided, or different parameters are used, or exposed structs are a different size) then, yeah, it would be better to have different sonames. But, I'd then question why that was the case: doesn't it ruin the whole point of the project?

----------

## hcaulfield57

Awesome, looks like this will be added to portage. Great work grey_dot and consus!

EDIT: Link for those interested -> https://bugs.gentoo.org/show_bug.cgi?id=437570#c15Last edited by hcaulfield57 on Wed Oct 10, 2012 9:06 pm; edited 1 time in total

----------

## Hypnos

This is great news.

Since there is interaction between kernel code dev and udev code dev, it would be great if some lkml devs took notice of this fork.

----------

## Jubei-Mitsuyoshi

damn right, they should take over maintenance period ( assuming they want to )

----------

## krinn

 *hcaulfield57 wrote:*   

> Awesome, looks like this will be added to portage. Great work grey_dot and consus!

 

faith back ?  :Smile: 

----------

## grey_dot

 *steveL wrote:*   

> 
> 
> Wait, when you say "moved udev path to /etc/conf.d/udev" do you mean /etc/init.d/udev is now /etc/conf.d/udev? Because I don't want that at all.
> 
> 

 

No no no. The path to udev binary is not specified in /etc/conf.d/udev, not in the script itself. Its the same approach xdm (kdm,gdm,slim) uses.

 *steveL wrote:*   

> 
> 
> I'm not sure soname-renaming is such a great idea, personally, if (and only if) the same ABI is being provided. If it is, or will potentially be, a different ABI, (ie not all of the same functions are provided, or different parameters are used, or exposed structs are a different size) then, yeah, it would be better to have different sonames. But, I'd then question why that was the case: doesn't it ruin the whole point of the project?

 

Sonames will not be changed at least in the near future. Yes, we'll try to provide binary compatibility with systemd-udev if it doesn't require porting any systemd insides (and right now it doesn't).

----------

## khayyam

 *steveL wrote:*   

>  *Quote:*   steveL ... I'll look at integrating these into udev-init-scripts in my overlay ... 
> 
> That'd be great, as concern about when udev starts is the only thing that's stopping me switching.

 

steveL ... I grabbed the scripts, I then made some changes to the description given in conf.d/udev and a unified diff, and then thought to myself, are these changes infact necessary? Bascially, the assumption is that udev and helpers are in /usr, which is not the case for the fork, everything required for udev is in /. So, am I missing something? Is there some other reason for changing the order of sysninit/boot other than to account for /usr not being mounted and udev failing for that reason? Isn't the whole "problem [...] that udev [...] has to start after [/usr has] been mounted" solved by havng udev in /? 

I feel a little bit dumb as there I was trying to re-phase the explanation given in conf.d/net so as to make it clear why 'intramfs="no"' existed, and what it would do, and only after have done so thinking I needed my head examined :)

So, as I see it currently (though I'm open to persuasion) the patches add additional complexity for a feature that isn't infact needed.

best ... khay

----------

## steveL

 *khayyam wrote:*   

> steveL ... I grabbed the scripts, I then made some changes to the description given in conf.d/udev and a unified diff, and then thought to myself, are these changes infact necessary? Bascially, the assumption is that udev and helpers are in /usr, which is not the case for the fork, everything required for udev is in /. So, am I missing something? Is there some other reason for changing the order of sysninit/boot other than to account for /usr not being mounted and udev failing for that reason? Isn't the whole "problem [...] that udev [...] has to start after [/usr has] been mounted" solved by havng udev in /?

 

No, the original reason for udev needing to start after /usr and /var (and technically they said anywhere on the FS, including /opt for 3rd-party software) is for udev rules which need either libs, drivers, or scripts from elsewhere, not udev itself. That's why I brought it up in relation to alsasound - that is just the common case which most people see.

udev has always been okay in rootfs, at least in stable. iirc there are some things that link to glib etc in /usr but they're not (or were not) used in startup. Then again I haven't looked at any of it for well over a year, since I haven't had any issues at all (and you'll see my partitioning setup is pretty complex from that thread: just a simple root and lots of lvm, with a few base partitions, so that practically everything which can be separated, is. Certainly nothing else can be split off main /root, and the usual gentoo stuff is separated, as well as standard *nix like /usr/src and /var/tmp.)

 *Quote:*   

> I feel a little bit dumb as there I was trying to re-phase the explanation given in conf.d/net so as to make it clear why 'intramfs="no"' existed, and what it would do, and only after have done so thinking I needed my head examined :)

 

Heh no problem: just remember that it was never about udev itself, only helpers. The reason it really became an issue was that some people need udev-initialised hardware to get through localmount. (Though how that's any easier to solve in an initramfs, I have no idea. I guess the thinking was "we have to support an initrd anyhow, so let's just support that and forget about all other 'legacy' use-cases." Which as we've seen from recent posts on kernel ML is the antithesis of how things are meant to be done.)

 *Quote:*   

> So, as I see it currently (though I'm open to persuasion) the patches add additional complexity for a feature that isn't infact needed.

 

Hopefully the above should show you why it is: the reasoning has not changed since I first started on the patches last August, and is nothing to do with udev itself. We were just told "udev must have all local drives mounted before startup": seeking explanation, we were told about the helpers that rely on /usr /var etc.

This was then followed-up by "just use an initramfs, and oh separate /usr is a useless waste of time," then a year or so later "separate /usr is the basis of our super-new-shiny layout, look what it can do!"

The technical arguments (around initramfs) made zero sense, so I just went with the first bit, the requirement we were given, and did that as simply as possible.

I think it was Kernighan's adage: "Do the simplest thing that could possibly work."

----------

## aCOSwt

 *steveL wrote:*   

> No, the original reason for udev needing to start after /usr and /var (and technically they said anywhere on the FS, including /opt for 3rd-party software) is for udev rules which need either libs, drivers, or scripts from elsewhere, not udev itself. That's why I brought it up in relation to alsasound - that is just the common case which most people see.

 

There are still a couple of things I seem to be missing there.

1/ Who needs alsa mixer levels to be restored as early as boot time ? and why ? Are there real users who want to hear the chorus of the slaves when starting the scheduler ? I just cannot figure this out, but that is very secondary !

2/ On a more general standpoint, there is a feature in udev ~170 that makes all the udev pre-mount rules that failed to be retried post-mount.

Why has this handy feature gone away (was it around 174) ? Why can't we keep things going that way ?

Linus considers that udev broke around #182, and should be forked from there, fair enough. As far as I am concerned and until I get an explanation for 2/ I think udev broke around #174 when support of this feature was dropped and consequently that udev should be forked from <#174.

Edit : Of course I need a more reasonable explanation than just the following diktat :  *udev-174-news wrote:*   

> The support for 'udevadm trigger --type=failed, and the
> 
> RUN{fail_event_on_error} attribute was removed.

   :Twisted Evil: 

----------

## steveL

 *grey_dot wrote:*   

> The path to udev binary is not specified in /etc/conf.d/udev, not in the script itself. Its the same approach xdm (kdm,gdm,slim) uses.

 

Well, assuming that first 'not' is a typo, that makes a lot more sense, thanks :)

 *Quote:*   

>  *steveL wrote:*   
> 
> I'm not sure soname-renaming is such a great idea, personally, if (and only if) the same ABI is being provided. If it is, or will potentially be, a different ABI, (ie not all of the same functions are provided, or different parameters are used, or exposed structs are a different size) then, yeah, it would be better to have different sonames. But, I'd then question why that was the case: doesn't it ruin the whole point of the project? 
> 
> Sonames will not be changed at least in the near future. Yes, we'll try to provide binary compatibility with systemd-udev if it doesn't require porting any systemd insides (and right now it doesn't).

 

That's cool. I was thinking more along the lines of an ENOSYS is acceptable, so long as the function is there, with the correct parameter list. But from the bug-report, you said systemd stuff is only rules at the moment. I can't see that changing too much, as systemd-udev relies on udev alone in initramfs stage, so they are forced to deal with the separation whether they want to or not. (Which just shows the fundamental flaw in their "design".)

Anyhow, good luck with it all, and I look forward to trying it when it is not the same-named ebuild set. ;)

----------

## steveL

 *aCOSwt wrote:*   

> There are still a couple of things I seem to be missing there.
> 
> 1/ Who needs alsa mixer levels to be restored as early as boot time ? and why ? Are there real users who want to hear the chorus of the slaves when starting the scheduler ? I just cannot figure this out, but that is very secondary !

 

You are making the mistake of thinking this only applies, or will ever apply, to alsa. Read the bit you quoted again.

 *Quote:*   

> 2/ On a more general standpoint, there is a feature in udev ~170 that makes all the udev pre-mount rules that failed to be retried post-mount.
> 
> Why has this handy feature gone away (was it around 174) ? Why can't we keep things going that way ?
> 
> Edit : Of course I need a more reasonable explanation than just the following diktat : [quote="udev-174-news"]The support for 'udevadm trigger --type=failed, and the
> ...

 

The problem was that udev was failing to initialise devices because there was no /usr et al, and it is not always as simple as retrying, I assume. Really though, the simple truth is that nowadays scripts and libs are, or can and will be in the future, all over the system. However you do it, there has to be some sort of early bring-up to get access to those partitions, before you start udev. It's just that their scheme to do that was to push it on to the admin in the form of configuring a custom initrd for their specific circumstance, whether they want to or not.

Frysinger vetoed pci- and hw-db libs on rootfs as well, which really messes everything up, if you want to initialise devices from just rootfs. Again, that's what we can use extra_econf for (or whatever it's called) without even needing to patch ebuilds, given a sane autotools setup in the package.

 *Quote:*   

> Linus considers that udev broke around #182, and should be forked from there, fair enough. As far as I am concerned and until I get an explanation for 2/ I think udev broke around #174 when support of this feature was dropped and consequently that udev should be forked from <#174.

 

Yeah 171-r6, current stable, is solid. But then, what you're describing has already been done to make this fork.

----------

## aCOSwt

 *steveL wrote:*   

> Really though, the simple truth is that nowadays scripts and libs are, or can and will be in the future, all over the system.

 

Fair enough ! Where is the problem as long as /lib /bin /sbin... are correctly populated as they have always been and made for ?

To take the   :Rolling Eyes:   alsasound problem you mention just as an example, where is the problem if /var/lib/alsa/asound.state is duplicated in /lib and /usr/sbin/alsactl duplicated into /sbin as they should have been in the real unix world if it had been thought interesting to restore mixer levels at boot time ?

It becomes a problem if and only if (for whatever good reason) you intend to stop supporting these dirs.

So, if this is today a real problem then it means that there is a strong intention to get rid of these dirs, in which case, as grey_dot acknowledged it a couple of posts above, even with this fork, : We are fucked !

----------

## Hypnos

If a hardware service is non-essential, it shouldn't be started at the boot run level.  Loading ALSA drivers and restoring state should be triggered by an init script at some high run level.

If a hardware service essential, its firmware and scripts should be in /lib, /bin, etc.

Isn't this Unix admin 101?  I'm pretty sure udev can handle this.  Is the problem that the userland cannot?

----------

## steveL

 *Hypnos wrote:*   

> If a hardware service is non-essential, it shouldn't be started at the boot run level.  Loading ALSA drivers and restoring state should be triggered by an init script at some high run level.

 

Let's get away from discussing alsa, because yes, it shouldn't be in boot (and I don't recommend it goes there -- comments in /etc/conf.d/udev patch.)

 *Quote:*   

> If a hardware service essential, its firmware and scripts should be in /lib, /bin, etc.
> 
> Isn't this Unix admin 101?

 

Yes.

 *Quote:*   

> I'm pretty sure udev can handle this.  Is the problem that the userland cannot?

 

No, the problem is more to do with development practices, and the difficulty in agreeing what is "critical", though personally I'd rather a distro made that decision, than individual users forced into an initramfs setup. For instance, it's pretty obvious you want lvm tools, and their libs, on root.

It's not always so clear elsewhere, but I think POSIX sh and utils are a good start (along with bash, since this is Linux) along with anything to do with disks, like mdadm. That gives enough to script most anything. Of course, in gentoo there's a system-dependency on python, which requires /usr, so if any package installation is required, you're screwed unless you have FEATURES=buildpkg so you can just decompress an old binpkg to roll back.

Additionally, you can't dictate where supporting firmware, libs and scripts are installed, especially for third-party packages, and to be frank, this is supposed to be a user-land device system.

The problem has come with new-fangled devices like a bluetooth keyboard needed to boot (which requires udev started which requires /usr..). But I agree, there should be capability to have that in root, if you need it, same as you can have it in initramfs. Or y'know, the admin could just move the files and run ldconfig, if all else fails. ;-)

There's also been a traditional lack of concern about excess linkage between / and /usr/lib on Linux, perhaps because it started as a hobby. I wrote a mail to dev ML about the technical reason I think this has happened. Basically, gmake by default expands -lfoo dependencies to files in what it thinks of as system-based directories itself, before ld ever sees the names, so LDFLAGS have no effect on their lookup. That's no good if you want to restrict where it looks to rootfs, and not /usr/lib. (It also borks cross-compiling.)

I got some handwaving about why it doesn't matter, but the third post (at the end) outlines how to correct it in your project, should you work with make.

It's one of those things that if you don't know about (and I couldn't find anyone who was aware of it in ##workingset, nor any discussion on the web, only the gmake info page which I had started from, and been panicked by) will just lead to you giving up and forgetting about the whole problem, since life's too short. It's not something used on any other make, so most packages will not account for it, nor will coders from other systems be aware of it. Given that, and the lack of time available to most developers, it's not surprising that tradition grew up. (I only found out about it as I was researching gmake for work, which involved looking at every variable it sets by default: just run make -p > somefile to see them.)

Autotools doesn't change it either, last time I looked (around the time of those mails.) Most build-systems don't change the default setup (it shows up under emerge ofc.)

----------

## hcaulfield57

 *Hypnos wrote:*   

> 
> 
> Since there is interaction between kernel code dev and udev code dev, it would be great if some lkml devs took notice of this fork.

 

grey_dot: Do you think it would be worth bringing this up on LKML?

----------

## grey_dot

 *hcaulfield57 wrote:*   

>  *Hypnos wrote:*   
> 
> Since there is interaction between kernel code dev and udev code dev, it would be great if some lkml devs took notice of this fork. 
> 
> grey_dot: Do you think it would be worth bringing this up on LKML?

 

I already did write to linux-hotplug@, and many people from lkml are subscribed to it (at least Greg KH and Alan Cox are). So no, not until forked udev makes it to main portage tree and probably some other distros.

----------

## Jubei-Mitsuyoshi

we are using it very successfully, and although i cannot speak for them i think archbang will follow suite, and prob ctk arch.

Not that it counts for anything, way too small.

I used to be quite active in debian, getting it into sid or experimental would be a good step forward.

But hey if its in portage propper that makes it a serious piece of work by itself, doubt need any further accreditation to anyone.

Am about to put my pentoo based unstable together, first thing on my list is this  :Smile: 

----------

## steveL

 *Jubei-Mitsuyoshi wrote:*   

> we are using it very successfully, and although i cannot speak for them i think archbang will follow suite, and prob ctk arch.
> 
> Not that it counts for anything, way too small.

 

No, I think that's excellent: it shows it works in other distros, and the work you're doing can only be helpful in the longer-term, to making the software work everywhere it might be needed.

 *Quote:*   

> I used to be quite active in debian, getting it into sid or experimental would be a good step forward.
> 
> But hey if its in portage proper that makes it a serious piece of work by itself, doubt need any further accreditation to anyone.

 

Yeah, but no knowing how long that will take. If you know enough to put a .deb together, and have an install (or a VM) you can work on it in, that would be incredibly useful, imo. Combined with your other work, it would start to count as a serious contender, since it would now work on 3 distro types.

Well done, anyway.

----------

## Jubei-Mitsuyoshi

yea can put a deb together no problem and run it on a partition ( i dislike vm's , always end up getting surprises when it gets to hardware, thats price of running performance laptops ), they are running 175 so should be a shoehorn, just figure out where they are starting it from and simlink appropriately, they have a strict and clean sysv so yea no worries.

But will NEVER get anywhere near experimental or sid form me, going to have to get it taken up by a sub-dev then it will trickle up the chain, dont expect it anywhere within 6 months, especially since they are all frantic with wheezy and bug killing.

----------

## hcaulfield57

 *grey_dot wrote:*   

> 
> 
> I already did write to linux-hotplug@, and many people from lkml are subscribed to it (at least Greg KH and Alan Cox are). So no, not until forked udev makes it to main portage tree and probably some other distros.

 

Okay, yea I took a look at that. Doesn't seem like they really got the point though, does it? 

systemd is a good operating system, but it needs a decent init system.

----------

## grey_dot

 *Jubei-Mitsuyoshi wrote:*   

> yea can put a deb together no problem and run it on a partition ( i dislike vm's , always end up getting surprises when it gets to hardware, thats price of running performance laptops ), they are running 175 so should be a shoehorn, just figure out where they are starting it from and simlink appropriately, they have a strict and clean sysv so yea no worries.
> 
> 

 

Contact me when you have a deb package. I have several machines to test (amd64, arm, and soon i hope i'll get mips).

 *hcaulfield57 wrote:*   

> 
> 
> Okay, yea I took a look at that. Doesn't seem like they really got the point though, does it? 
> 
> 

 

I can't even guess why it was hard to get. I suppose without a huge userbase they won't think of the fork seriously.

----------

## hcaulfield57

 *grey_dot wrote:*   

> 
> 
> I can't even guess why it was hard to get. I suppose without a huge userbase they won't think of the fork seriously.

 

Yea I don't understand it either. Even if you only look at the fork as preventing 'vender lock-in' as someone put it, it still has tremendous value.

----------

## The Doctor

 *hcaulfield57 wrote:*   

>  *grey_dot wrote:*   
> 
> I can't even guess why it was hard to get. I suppose without a huge userbase they won't think of the fork seriously. 
> 
> Yea I don't understand it either. Even if you only look at the fork as preventing 'vender lock-in' as someone put it, it still has tremendous value.

 

My guess is that they are suspicious about a project that has not had the chance to demonstrate that it has the staying power to be beneficial. Just a guess.

----------

## Jubei-Mitsuyoshi

deb is on its way, the udev maintainer for debian is aware of the situation ( now ) and seems to be very supportive of the idea, ( as i gather not being a great fan of redhats direction himself ) but as i suspected can do nothing even vaguely official until wheezy is safely in bed, but i got fingers crossed that he has time to help me package fork proper, the basics are easy ( as far as anything can be called easy when dealing with debian rules ) but they apply about 10 patches to 175, god knows exactly what they all do.

Im on contract for a week now and posting is difficult cos of all the security at the site, so if i disappear for a while you'll know whats up  :Smile: 

----------

## hcaulfield57

 *Jubei-Mitsuyoshi wrote:*   

> deb is on its way

 

Good work, I look forward to hearing how it goes.

----------

## khayyam

grey_dot ...

just a quick note on bug #438932. Having updated openrc to 0.11 yesterday I'm not sure why I wasn't hit by it, but as the fix effects udev-init-scripts I went and bumped the package to 17-r1 (and of course included the ::udev patches). So, it may be an idea to follow suite in the udev overlay.

I haven't had time to look at what changes are invloved, or the exact nature of the bug, so this is just a red flag just incase anyone using ::udev and openrc-0.11 suffers the same problem.

The udev-init-scripts-17-r1.ebuild

```
# Copyright 1999-2012 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: $

EAPI=4

inherit eutils

if [ "${PV}" = "9999" ]; then

   EGIT_REPO_URI="git://git.overlays.gentoo.org/proj/udev-gentoo-scripts.git"

   inherit git-2

fi

DESCRIPTION="udev startup scripts for openrc"

HOMEPAGE="http://www.gentoo.org"

LICENSE="GPL-2"

SLOT="0"

IUSE=""

if [ "${PV}" != "9999" ]; then

   SRC_URI="http://dev.gentoo.org/~williamh/dist/${P}.tar.bz2"

   KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86"

fi

RESTRICT="test"

DEPEND=""

RDEPEND=">=sys-fs/udev-187

   sys-apps/openrc

   !<sys-fs/udev-186"

src_prepare() {

   epatch "${FILESDIR}"/udev-conf-sbin.diff || die "patch failed"

   epatch "${FILESDIR}"/udev-init.diff || die "patch failed"

   epatch "${FILESDIR}"/libudev-path.patch || die "patch failed"

}

pkg_postinst()

{

   # If we are building stages, add udev to the sysinit runlevel automatically.

   if use build

   then

      if [[ -x "${ROOT}"/etc/init.d/udev \

         && -d "${ROOT}"/etc/runlevels/sysinit ]]

      then

         ln -s /etc/init.d/udev "${ROOT}"/etc/runlevels/sysinit/udev

      fi

   fi

   # migration to >=openrc-0.4

   if [[ -e "${ROOT}"/etc/runlevels/sysinit \

      && ! -e "${ROOT}"/etc/runlevels/sysinit/udev ]]

   then

      ewarn

      ewarn "You need to add the udev init script to the runlevel sysinit,"

      ewarn "otherwise your system will not be able to boot"

      ewarn "after updating to >=openrc-0.4.0"

      ewarn "Run this to enable udev for >=openrc-0.4.0:"

      ewarn "\trc-update add udev sysinit"

      ewarn

   fi

   ewarn "The udev-postmount service has been removed because the reasons for"

   ewarn "its existance have been removed upstream."

   ewarn "Please remove it from your runlevels."

}
```

steveL ... sorry for not replying any sooner, I'll do so in more detail shortly. I just wanted to say that, yes, I can see that it does add some worthwhile functionality, but I think the description needs to be made clearer and the var changed to something more desriptive (ie: "early-udev-mount" or something?). Anyhow, I'll hopefully have more to say when I have more time on my hands.

best ... khay

----------

## grey_dot

 *khayyam wrote:*   

> grey_dot ...
> 
> just a quick note on bug #438932. Having updated openrc to 0.11 yesterday I'm not sure why I wasn't hit by it, but as the fix effects udev-init-scripts I went and bumped the package to 17-r1 (and of course included the ::udev patches). So, it may be an idea to follow suite in the udev overlay.
> 
> I haven't had time to look at what changes are invloved, or the exact nature of the bug, so this is just a red flag just incase anyone using ::udev and openrc-0.11 suffers the same problem.
> ...

 

Added as udev-init-scripts-17.ebuild, though it's the same as -16. Also I didn't have that bug.

----------

## khayyam

 *grey_dot wrote:*   

> Added as udev-init-scripts-17.ebuild, though it's the same as -16. Also I didn't have that bug.

 

grey_dot ... but udev-init-scripts-17-r1::gentoo points to a different SRC_URI (that of William Hubbs, who's assigned to the bug) so I think there is possibly more to the issue than a package bump.

best ... khay

----------

## grey_dot

 *khayyam wrote:*   

>  *grey_dot wrote:*   Added as udev-init-scripts-17.ebuild, though it's the same as -16. Also I didn't have that bug. 
> 
> grey_dot ... but udev-init-scripts-17-r1::gentoo points to a different SRC_URI (that of William Hubbs, who's assigned to the bug) so I think there is possibly more to the issue than a package bump.
> 
> best ... khay

 

Sorry, my bad. Fixed that.

----------

## gerard27

I'm not sure what happened but I read about the bug report and udev-init-scripts.

So I upgraded to 17-r1 and rebooted:

Lots of errors which I can't show here since they weren't logged.

One I remember read something like start stop daemon:/usr/lib/sytemd/systemd-udev not existing.

And sure enough no keyboard,dead system.

Had to do a hard reset and chroot into my system to re-emerge the file from the overlay.

Seems to be running ok again.

What happened?

Gerard.

----------

## khayyam

 *gerard82 wrote:*   

> I'm not sure what happened but I read about the bug report and udev-init-scripts. So I upgraded to 17-r1 and rebooted: Lots of errors which I can't show here since they weren't logged. One I remember read something like start stop daemon:/usr/lib/sytemd/systemd-udev not existing.

 

gerard82 ... I think you installed udev-init-scripts-1.17-r1::gentoo ... hence the init was looking for 'systemd-udev' (and in the wrong location). I'd suggest the following:

/etc/portage/package.mask

```
app-arch/xz-utils::gentoo # assuming xz-utils is installed from the udev overlay

sys-apps/kmod::gentoo # assuming kmod is installed from the udev overlay

sys-fs/udev::gentoo

sys-fs/udev-init-scripts::gentoo
```

You would then keyword from the udev overlay

/etc/portage/package.accept_keywords

```
app-arch/xz-utils::udev

sys-apps/kmod::udev

sys-fs/udev::udev

sys-fs/udev-init-scripts::udev
```

 *gerard82 wrote:*   

> Had to do a hard reset and chroot into my system to re-emerge the file from the overlay. Seems to be running ok again. What happened?

 

basically mixing ::udev and ::gentoo will cause issues as udev-init-scripts::udev expects /sbin/udev (by default) and udev-init-scripts::gentoo /usr/lib/sytemd/systemd-udev

best ... khay

----------

## gerard27

 *Quote:*   

> 
> 
> basically mixing ::udev and ::gentoo will cause issues as udev-init-scripts::udev expects /sbin/udev (by default) and udev-init-scripts::gentoo /usr/lib/sytemd/systemd-udev

 

Yes it does.

Already corrected package.keywords.

Thanks anyway.

Gerard.

----------

## grey_dot

Boys and girls, version 195 is out. The gap of 4 versions is caused by the absense of any significant changes in udev code and our intention to keep the version numbers synchronized.

----------

## gerard27

Hi grey_dot,

Tried to upgrade but it fails with this:

```

configure: error: cannot find install-sh, install.sh, or shtool in build-aux "."/build-aux
```

I also noticed that the distfile I got is a lot smaller than udev-190 (both from overlay).

What could be wrong?

Gerard.

----------

## khayyam

 *gerard82 wrote:*   

> Tried to upgrade but it fails [...]

 

I can verify this ... build.log

best ... khay

----------

## grey_dot

Sorry, my bad. Just uploaded the right file. Please wait a bit for bitbucket to update its mirrors.

----------

## gerard27

Now I get checksum failure.

Gerard.

----------

## khayyam

 *gerard82 wrote:*   

> Now I get checksum failure.

 

gerard82 ... the manifest in the overlay will obviously need updating:

```
# layman --sync udev
```

best ... khay

----------

## gerard27

khayyam,

If I hadn't synced I wouldn't have had the filesize error.

I deleted the whole overlay and then added it again.

Now it installs ok.

Also compared the distfile sizes of 190 and 195:They're now about equal in size.

Gerard.

----------

## khayyam

 *gerard82 wrote:*   

> If I hadn't synced I wouldn't have had the filesize error.

 

gerard82 ... yes, but you didn't say you if you'd sync'ed or that you had the old tarball in distfiles. I'd assumed you had removed the old tarball and then emerged without having also updated the overlay (so having the new tarball but the old manifest).

 *gerard82 wrote:*   

> I deleted the whole overlay and then added it again. Now it installs ok.

 

That shouldn't have made any difference ...

best ... khay

----------

## steveL

 *khayyam wrote:*   

> 
> 
> steveL ... I just wanted to say that, yes, I can see that it does add some worthwhile functionality, but I think the description needs to be made clearer and the var changed to something more desriptive (ie: "early-udev-mount" or something?).

 

I'm not sure how the description could be any clearer:

```
# UNSUPPORTED: Allow people with a separate /usr and /var to                                     

# get away without an initramfs. The problem here is that                                        

# udev helpers live in /usr and /var, so udev has to start                                       

# after they have been mounted.                                                                  

# To use udev, you MUST have CONFIG_DEVTMPFS set in kernel                                       

# If you are not using an initramfs (and are *sure* that you                                     

# don't need one or udev to mount /usr and /var) you can set                                     

# this to "no" to make udev-mount provide dev for devfs and                                      

# udev wait for localmount.

#initramfs="yes"

...more instructions about runlevels...

```

You're welcome to change whatever you want, of course. I can see the utility in prefixing it with udev_ though I thought that's how it's done anyway, if you configure via main rc.conf. When I started I didn't know what else might be affected by the change: at first I tried moving other things to sysinit, which quickly turned into a nightmare. Then just thinking about the simplest thing to fulfil the requirement (which means focussing only on the requirement: that partitions be mounted before udev starts) got me there.

I don't agree with any sort of "early-mount" because that simply is not what it does (that was another approach); rather it delays udev startup til after localmount. So perhaps udev_delay_startup?

The only reason to do that is because you are not using an initramfs, afaik, as if you were using one in the "official" configuration, then at least some mounting would have been done there, and udev started in sysinit. So for my setup, I named it after that: the purpose of the variable, not the mechanism.

After all, it could in the future require a completely different mechanism, but I still wouldn't be using an initramfs.

----------

## tclover

@maintainers:

hullo,

i don't if you saw this bug #438932 that i opened a few days ago but you should take a look especially at comment #24 which resume the two main issues.

i'm using this fork since the beginning but, sorry, i did not have any moment to come here and report back.

i've just merged back openrc-0.11.2 the other day, without reading that comment, sorry i did not have the time too follow the whole bug posts, with updating udev{,-init-scripts}-9999 and got the same issue. i reponned the bug again and i'm going to test comment #24 fix and report backk when i have a moment.

thanks again for this fork!

----------

## grey_dot

 *tclover wrote:*   

> @maintainers:
> 
> hullo,
> 
> i don't if you saw this bug #438932 that i opened a few days ago but you should take a look especially at comment #24 which resume the two main issues.
> ...

 

I believe I have read that before, but I didn't have a chance to run at that issue myself, so I cannot say anything for sure. My laptop is running udev-9999 and udev-init-scripts-17 from udev overlay, and everything seems fine so far.

----------

## gerard27

Since installing this setup everything works ok with the exception of my dvd-rom drive.

Once you push the button to open the tray it refuses to close.

When you push the button to close it it closes and 1 second later it opens again no matter how often you try to close it.

Makes no diff whether there's a disk in it or not.

The dvd-rw is ok.

The rom drive is on /dev/sr1 the rw on /dev/sr0.

```
 60-cdrom_id.rules

# do not edit this file, it will be overwritten on update

ACTION=="remove", GOTO="cdrom_end"

SUBSYSTEM!="block", GOTO="cdrom_end"

KERNEL!="sr[0-9]*|xvd*", GOTO="cdrom_end"

ENV{DEVTYPE}!="disk", GOTO="cdrom_end"

# unconditionally tag device as CDROM

KERNEL=="sr[0-9]*", ENV{ID_CDROM}="1"

# media eject button pressed

ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $devnode", GOTO="cdrom_end"

# import device and media properties and lock tray to

# enable the receiving of media eject button events

IMPORT{program}="cdrom_id --lock-media $devnode"

KERNEL=="sr0", SYMLINK+="cdrom", OPTIONS+="link_priority=-100"

LABEL="cdrom_end"

```

How can I fix this?

I browsed the Gentoo udev guide + the 2 links at the bottom but they're totally obsolete.

I've never written udev rules and am no coder.

Any help will be much appreciated.

Gerard.

----------

## gerard27

I reinstalled udev-171-r8 and all is ok now.

Reading the rule above I wonder if this will only work on laptops since they have only one optical drive.

The sr0 drive works ok,it's the sr1 drive that doesn't.

Gerard.

----------

## infirit

It has been a few years I posted to the forums   :Shocked: 

Sofar all seems well except for some alsactl errors which I have not looked at.

----------

## hcaulfield57

It's been too quiet over here! I upgraded to 195, everything works fine as expected.

----------

## gerard27

@hcaulfield57,

Is this on a laptop or on a desktop with two optical drives?

Gerard.

----------

## hcaulfield57

Gerard, 

This is on my desktop, I only have one optical drive, why do you ask?

----------

## gerard27

Thanks for replying hcaulfield57.

The first optical disk is designated as /dev/sr0.

Any subsequent drives as /dev/sr1,2 ,3 and so on.

I have two drives,the rom and rw drive.

The rw drive is always installed on the first channel by the manufacturer.

This has (had) to do with burning software being picky (not anymore AFAIK).

So you won't have any problem like I have.

I've entered an "issue"  ( ==bugreport) on braindamaged site.

He will check into it but he doesn't have a box with any optical drive nor do his buddies.

Higher up you'll find a post by me with a copy of the 60-cdrom-id.rules which I think should be changed.

Only I haven't got the knowledge how to accomplish that.

Gerard.

----------

## hcaulfield57

Oh okay, I see what your problem is. I would look into it if I had a computer with more than one drive, but unfortunately I only have one. Maybe someone here has more than one. Sorry I can't be more of a help.

----------

## gerard27

Well hcaulfield57 I "fixed" it.

I removed the 60-cdrom_id.rules from /lib64/udev/rules.d.

I then copied the same rules file from udev-171-r8 to /etc/udev/rules.d and added 70-persistent-cd.rules from the same udev.

I did all this on a separate experimental Gentoo install.

Now everything on my box works.

When I load a music cd in the rom drive kde pops up a message what program I want to use to either play it or rip it.

So to me this proves the original rule is wrong.

Gerard.

----------

## hcaulfield57

Glad to hear that you fixed the problem, I know any issue with /dev can be pretty annoying. 

Is it just me, or am I the only one who thinks that dynamically allocated device nodes is a flawed concept? What is the solution that it's trying to solve? Sure, thousands of static nodes is 'messy' and it can be frustrating when a device node exists for a piece of hardware that does not, but overall the solution in the past seems much simpler and I'm unsure why we need dynamic-/dev. At least I can't see why all users need it.

----------

## Hypnos

The motivation for dynamic node allocation is rule-based node naming.  This is useful for removable devices, such as USB disks.

For example, the backup hard disk for my laptop has the volume label "backup", so when it's plugged in it's always at "/dev/disk/by-label/backup" .  This way my backup script won't have to hunt for it.

----------

## infirit

 *infirit wrote:*   

> some alsactl errors which I have not looked at.

 

These errors were unrelated to this fork. Everything is working fine for me.

----------

## gerard27

@infirit,

How many optical drives do you have please?

If you have 2,one rom and one rw could you please try and play a music cd in them?

I'm curious what the result is.

Thanks in advance.

Gerard.

----------

## infirit

 *gerard82 wrote:*   

> @infirit,
> 
> How many optical drives do you have please?
> 
> If you have 2,one rom and one rw could you please try and play a music cd in them?

 

I only have 1 (LG sata bluray drive) and this one works ok with mplaye2 and cdparanoia. I may have a spare one lying around which I can put in the box. What kind of issues are you seeing?

----------

## gerard27

Thanks for replying infirit.

My issue is described in an earlier post in this thread.

What it boils down to is that 

```

60-cdrom_id.rules 

.

.

.

.

KERNEL=="sr0", SYMLINK+="cdrom", OPTIONS+="link_priority=-100" 
```

is wrong.

The drive I have on /dev/sr0 works fine.

The one I have on /dev/sr1 doesn't.

Looking at the code it's not surprising because it implicitly names sr0.

Computers that come with 2 optical drives (one ROM and the other RW) always have the RW on sr0 and the ROM on sr1.

Gerard.

----------

## infirit

 *gerard82 wrote:*   

>  
> 
> ```
> 
> 60-cdrom_id.rules 
> ...

 

You need to more specific what does not work  :Wink: . Is it an application, no device node created or... Does it work with the official udev provided by gentoo?

 *gerard82 wrote:*   

> Looking at the code it's not surprising because it implicitly names sr0.
> 
> Computers that come with 2 optical drives (one ROM and the other RW) always have the RW on sr0 and the ROM on sr1.
> 
> Gerard.

 

I don't think this has ever worked properly which maybe why it was abandoned. See if the below code give any attributes you can match against.

```
udevadm info /dev/sr0
```

If it also does not work the official udev from gentoo it is not related to this fork. If this is the case then I suggest opening a separate topic in multimedia. Or write your own rules, see this howto but be advised that udevinfo has been replaced with udevadm info.

you can also use mplayer/mplayer2 to test as it allow for the device to be used. I use mplayer2 which you may need to change to mplayer (no 2).

```
mplayer2 cdda:// --cdrom-device=/dev/sr1
```

----------

## gerard27

I installed the fork on my day to day Gentoo.

Before that I didn't have this problem.

So I reverted back to the official Gentoo udev-171-r8 and all works fine.

I also have another Gentoo install for experiments.

Here I installed the fork and got it working ok concerning the optical drives by replacing the 

60-cdrom_id.rules file with the one that comes with udev-171-r8 and now it works ok.

I placed it in /etc/udev/rules.d after the removing the one from lib/udev/rules.d.

It looks like this

```

# do not edit this file, it will be overwritten on update

ACTION=="remove", GOTO="cdrom_end"

SUBSYSTEM!="block", GOTO="cdrom_end"

KERNEL!="sr[0-9]*|xvd*", GOTO="cdrom_end"

ENV{DEVTYPE}!="disk", GOTO="cdrom_end"

# this is only a button press event

ENV{DISK_EJECT_REQUEST}=="?*", GOTO="cdrom_end"

KERNEL=="sr[0-9]*", ENV{ID_CDROM}="1"

IMPORT{program}="cdrom_id $tempnode"

LABEL="cdrom_end"
```

Notice the difference.

I don't want to have to use the command line to play a cd while kde provides a pop up with the choice to either play it or rip it.

Gerard.

----------

## infirit

 *gerard82 wrote:*   

> I installed the fork on my day to day Gentoo.
> 
> Before that I didn't have this problem.
> 
> So I reverted back to the official Gentoo udev-171-r8 and all works fine.

 

This is not about an issue with this fork. Because you run a stable system (udev version 171) you have not run into this (yet). The latest unstable version udev 195 has the same 60-cdrom_id.rules file as the fork.

 *gerard82 wrote:*   

> I don't want to have to use the command line to play a cd while kde provides a pop up with the choice to either play it or rip it.
> 
> Gerard.

 I understand that I was only providing a way to test if it was at all possible to play an audio cd (because you did not specify what did not work  :Wink: ).

----------

## gerard27

Please carefully re-read my post.

Gerard.

----------

## grey_dot

 *gerard82 wrote:*   

> Well hcaulfield57 I "fixed" it.
> 
> I removed the 60-cdrom_id.rules from /lib64/udev/rules.d.
> 
> I then copied the same rules file from udev-171-r8 to /etc/udev/rules.d and added 70-persistent-cd.rules from the same udev.
> ...

 

Awesome. Could you please update the issue (https://bitbucket.org/braindamaged/udev/issue/3/dvd-rom-problem) with the rules file you now have? Thanks.

 *hcaulfield57 wrote:*   

> 
> 
> Is it just me, or am I the only one who thinks that dynamically allocated device nodes is a flawed concept? What is the solution that it's trying to solve? Sure, thousands of static nodes is 'messy' and it can be frustrating when a device node exists for a piece of hardware that does not, but overall the solution in the past seems much simpler and I'm unsure why we need dynamic-/dev. At least I can't see why all users need it.
> 
> 

 

Well, some systems (e.g. OpenBSD) still use static /dev for the matter of simplicity. It is annoying sometimes, for example you don't see which hd partitions are present, etc, but it's not that bad.

----------

## hcaulfield57

 *grey_dot wrote:*   

> 
> 
> Well, some systems (e.g. OpenBSD) still use static /dev for the matter of simplicity. It is annoying sometimes, for example you don't see which hd partitions are present, etc, but it's not that bad.

 

That's what I was thinking of specifically. I use OpenBSD, and happen to quite like it, and static /dev works well there. It's also a supported configuration on Slackware and Gentoo, I might add.

Perhaps not so much the concept of dynamic /dev is flawed, because it doesn't entirely make sense to have device nodes present for hardware that is not present, but I think static /dev is much simpler, and removes the added layer of complexity that dynamic /dev creates and removes many points of failure.

----------

## Hypnos

I don't use OpenBSD -- does it address the problem of consistent naming for removable devices?  Certainly, if you can live without this feature you only need static nodes.

----------

## hcaulfield57

 *Hypnos wrote:*   

> I don't use OpenBSD -- does it address the problem of consistent naming for removable devices?  Certainly, if you can live without this feature you only need static nodes.

 

I doubt it, but it's not a feature that I use (although I can see why it would be useful), generally I stick in USB drive and just assume it's sdb1 (on Linux).

----------

## Hypnos

Another question: does the OpenBSD device layer emit signals upon the insertion of devices,  and are there tools to do something with these signals?

Dynamic device naming is easy if you have this in place.  Arguably this is more important/general, as it allows not only device naming, but other policy-driven tasks like permissions, automounting etc.

Of course part of the discussion in this thread is that the drive for policy-based management of various system functions is leading to a bloated software stack.

----------

## hcaulfield57

 *Hypnos wrote:*   

> Another question: does the OpenBSD device layer emit signals upon the insertion of devices,  and are there tools to do something with these signals?
> 
> Dynamic device naming is easy if you have this in place.  Arguably this is more important/general, as it allows not only device naming, but other policy-driven tasks like permissions, automounting etc.
> 
> 

 

On the first point, not sure what you mean, the kernel automatically recognizes devices that are plugged in or whatever, if that's what you're asking. 

On the second point, OpenBSD does not have any /sys directory like Linux where devices are stored. Although I wouldn't really say that Linux takes care of device node permissions, for instance devtmpfs will create device nodes with default permissions (can't remember what they are at the moment). Typically some userspace program is needed for proper permissions, like mdev, or udev through the uevent system in /sys. Someone can correct me if I'm wrong, but that's how I understand permissions taking place.

----------

## Hypnos

uevent is what I was referring to, I had forgotten what it was called.  This allows you to do all kinds of fancy things in userspace, though it'd be nice if doing so weren't *required*

----------

## infirit

 *Hypnos wrote:*   

> uevent is what I was referring to, I had forgotten what it was called.  This allows you to do all kinds of fancy things in userspace, though it'd be nice if doing so weren't *required*

 It looks like it does have a way of emitting an event of some sort for newly added devices. 

What I do know is that the linux kernel caches uevents until userspace can read them. Not sure this is in place for openbsd..

----------

## infirit

So some of the gentoo devs decided to go their own way and create udev-ng. It may be a good idea to pool the resources.

----------

## gerard27

Good news and finally a good name for it too.

Next time I can post in Gentoo's bugzilla when I have a problem like no /dev/sr1,only /dev/sr0.

Gerard.

----------

## Hypnos

I fail to see the logic in having two forks with exactly the same goals.

----------

## cach0rr0

i have nothing to add, but wanted to pop in (again?) and leave a piece of spam -

thanks again for doing this. It's f*cking cool to see users of our humble little source based distro sending a big fat middle finger to systemd takeover, and not only that, but I read through the thread, see this pop up on bugzilla, and see it's gaining significant momentum. Bonus: the kernel devs are as annoyed with the current upstream udev as I am. 

Makes me smile. Truly awesome. Brilliant work gents (consus, grey_dot, and the rest of ya). THIS, is how you start a grassroots movement. "I'm not doing it, you'd better have patches" - well, sirs, we do have patches, what's your next excuse?

----------

## consus

Just to make things clear: yesterday we had a nice chat with gentoo devs behind the other fork and we understand why they are doing this (politics, not technial issues or NIH). So i guess we all should wait for the results. After that we may (no certain plans for now, though) merge codebases or work together in any other way.

----------

## infirit

 *consus wrote:*   

> Just to make things clear: yesterday we had a nice chat with gentoo devs behind the other fork and we understand why they are doing this.

 I am really happy to read that the two teams are talking (civilly, unlike on the b.g.o).   :Very Happy: 

----------

## Hypnos

Mmm, popcorn.

----------

## grey_dot

 *Hypnos wrote:*   

> Mmm, popcorn.

 

I have talked to Mister Kroah-Hartman before. He is extremely unhelpful.

----------

## infirit

 *Hypnos wrote:*   

> Mmm, popcorn.

 The usual shit storm about misunderstandings and presumptions   :Rolling Eyes: 

----------

## hcaulfield57

I completely fail to see where all this antagonism comes from against the various udev forks and even mdev earlier. Who cares what projects people spend their time on, they are trying to code and implement solutions to problems that other people created for them, and then get derided for fixing the problems. The fact of the matter is that many people don't want to use systemd and want to keep separate /usr, this is a solution to solve this problem. 

And where is all this stuff about separate /usr being broken? The whole point of /usr in the first place was for it to be separate. I've never had a problem with separate /usr, things have always worked properly as they should. And yea I know, my system is just so broken that I don't even know it. Well I'd just prefer to stay ignorant about my broken system  :Smile: 

----------

## Hypnos

A lot of old hands in the OSS world are unhappy with what's happen to the culture.  It used to be about duct tape and hacker culture, working around the flaws of corporates OSes and cobbling together desktop software for the fun of it.  If you didn't like something, send in a patch or make a friendly fork.

At around the time OSS became a profit center, this started to change.  A lot of non-developer users were drawn in, and the emphasis shifted from hackability to "usability."  Now there are many people like gregkh asking "why" instead of "why not" whenever you try to do something different, ostensibly because it creates fragmentation.

In the old days, fragmentation was *good* -- it means you had multiple solutions to problems, to suit different tastes.  As long as you followed Unix principles there was no problem with interoperability.

----------

## hcaulfield57

 *Hypnos wrote:*   

> A lot of old hands in the OSS world are unhappy with what's happen to the culture.  It used to be about duct tape and hacker culture, working around the flaws of corporates OSes and cobbling together desktop software for the fun of it.  If you didn't like something, send in a patch or make a friendly fork.
> 
> 

 

Wish it would go back to that, I hate all the corporate/political manipulation.

----------

## Hypnos

 *hcaulfield57 wrote:*   

> Wish it would go back to that, I hate all the corporate/political manipulation.
> 
> 

 

Then suckless and glendix may be for you.

I personally am keen on Glendix, have mixed feelings on Suckless.

EDIT: I'm definitely on the cat-v bandwagon.

----------

## DaggyStyle

 *Hypnos wrote:*   

> 
> 
> EDIT: I'm definitely on the cat-v bandwagon.

 

C++ is bad but google's GO is good?

----------

## Hypnos

 *DaggyStyle wrote:*   

> C++ is bad but google's GO is good?

 

C++ is a crime against humanity, so it's quite easy for another language to be better.  If you want to discuss the horror of C++ or how it compares to Go in greater depth, PM me.

I'll add that if you are using C and garbage collection anyway, there's not much wrong with Objective-C.

----------

## DaggyStyle

 *Hypnos wrote:*   

>  *DaggyStyle wrote:*   C++ is bad but google's GO is good? 
> 
> C++ is a crime against humanity, so it's quite easy for another language to be better.  If you want to discuss the horror of C++ or how it compares to Go in greater depth, PM me.
> 
> I'll add that if you are using C and garbage collection anyway, there's not much wrong with Objective-C.

 

I like C++, I don't trust any of google's initiatives, so for me it is the other way around.

----------

## fourchannel

 *Hypnos wrote:*   

>  *DaggyStyle wrote:*   C++ is bad but google's GO is good? 
> 
> C++ is a crime against humanity, so it's quite easy for another language to be better.  If you want to discuss the horror of C++ or how it compares to Go in greater depth, PM me.
> 
> I'll add that if you are using C and garbage collection anyway, there's not much wrong with Objective-C.

 

You know, you could say that english is a crime against humanity, so it's quite easy for another language to be better.

And you could reason that it's so horribly misused it's a disaster.

And you could reason that another language does have a totally better foundation and you should just move to that.

And you might find yourself being blindsided when this sounds an aweful lot like the introduction of C++ over C.

English does have ways of being used rather effectively, and it's more so that it's being used in the wrong way than it's mathematically impossible for any idea to be constructed with english -> eh... it's not perfect, but it's not quite that broken.

C++ is not perfect, but it does have a lot of ways to use it effectively for the task at hand.

Don't need runtime exception handling for hello world -> 

```
gcc --fno-exceptions
```

 -> boom your program went on an epic diet.

Need even smaller? -> 

```
gcc --fno-exceptions -Os
```

Don't know what those do? -> realize that is a sign that points to misunderstanding, and frustration from others not understanding yet still using.

I suspect that if you promote simply switching to yet another language, as opposed to concentrating on why it's so misused to begin with, you are going to simply repeat history and after a while people will be complaining about how Go is a crime against humanity -> namely for all the wrong ways it is being used which makes people super pissed that it's even around.

I will agree with you C++ has some technical flaws, yes.

Can they be avoided by changing to another language? Probably.

Can they be corrected by first understanding what mechanism(s) are causing the problem, what controls them in what way, and what configuration/compile options/program design changes can be made to resolve problem? Probably.

Sometimes people forget that C++ is intentially not a purebred language. It's like a multitool. Yeah, you can tighten a screw with the knife blade or you can also use the screwdriver, or you can even attempt a blade-screwdriver hybrid solution but that might take some fingers with it.

Holy crap that was ramble factorial.

----------

## Hypnos

From the quality of your prose, I can see why you like C++.

But please, let's not pollute a udev thread with this discussion.  Start another thread.

----------

## fourchannel

 *Hypnos wrote:*   

> From the quality of your prose, I can see why you like C++.
> 
> But please, let's not pollute a udev thread with this discussion.  Start another thread.

 

Yeah, sorry about that. Pretty sure ADD meds didn't help with the brevity.

----------

## Anon-E-moose

 *Hypnos wrote:*   

> Mmm, popcorn.

 

I scrolled down through the link. 

I fail to understand how discussing the problem nicely, 

as it seemed to be being done, is "making the gentoo devs look foolish" or "wannabe's".

One should think given the history of open software that looking foolish 

for doing something, that needs doing, is the last thing one should feel.

Who cares what another thinks, they are entitled to their opinion.

I remember when linux first came out, on the minix discussion area, 

and I'm sure that some thought that Linus was foolish, but look where it is now. 

Just some thoughts, now back to the technical discussion. :^)

----------

## PaulBredbury

 *Anon-E-moose wrote:*   

> Just some thoughts, now back to the technical discussion. :^)

 

Take those thoughts where they belong - in off-the-wall threads:  Udev ...... off Linus and udev was forked  :Evil or Very Mad: 

----------

## Anon-E-moose

 :Rolling Eyes: 

----------

## dwbowyer

We need a new USE flag on the ebuild, acl

After 

```
amd64 dev # emerge --sync && layman -S

amd64 dev # emerge -puvDN system

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  N     ] sys-apps/makedev-3.23.1  USE="-build (-selinux)" 120 kB

[ebuild  N     ] sys-fs/static-dev-0.1  0 kB

```

Which occurs if sys-fs/udev::gentoo is package.masked

This is due to new requirement of

```

virtual/udev[+acl]

```

This is what default udev users get. 

```

[ebuild   R    ] sys-fs/udev-195::gentoo [195::udev] USE="acl%* gudev hwdb keymap openrc -doc -introspection (-selinux) -static-libs (-debug%) (-floppy%)" 1,409 kB

[ebuild  N     ] virtual/udev-0  USE="acl -gudev -hwdb -introspection -keymap (-selinux) -static-libs" 0 kB

```

EDIT: Or I could just 

```
echo "virtual/udev -acl" >> /etc/portage/package.use
```

Since I don't actually use ACL.   :Rolling Eyes: 

----------

## grey_dot

 *dwbowyer wrote:*   

> We need a new USE flag on the ebuild, acl
> 
> 

 

Actually, acl was dropped around udev-180 and latest versions don't have that function.

----------

## grey_dot

Because of new virtual/udev in the portage tree blocks this fork installation from the overlay, and gentoo devs unwilling to include this fork into the tree, I had to include virtual/udev into the udev overlay. So, now in order to have everything working you have to mask virtual/udev::gentoo and install virtual/udev::udev.

My /etc/portage/package.mask as an example:

```

app-arch/xz-utils::gentoo

sys-apps/kmod::gentoo

sys-fs/udev::gentoo

sys-fs/udev-init-scripts::gentoo

virtual/udev::gentoo

```

----------

## dwbowyer

There are 3 virtual/udev packages (and counting), which I guess the overlay will need to shadow. For something that is supposed to make drop in replacements easy, these virtuals sure do seem to be doing the opposite.

```

!!! All ebuilds that could satisfy ">=virtual/udev-180[gudev,hwdb]" have been masked.

!!! One of the following masked packages is required to complete your request:

- virtual/udev-180::gentoo (masked by: package.mask)

(dependency required by "sys-fs/udisks-2.0.0" [installed])

(dependency required by "app-emulation/wine-1.5.18[udisks]" [ebuild])

(dependency required by "app-emulation/winetricks-922" [ebuild])

(dependency required by "@selected" [set])

(dependency required by "@world" [argument])

```

----------

## dwbowyer

*Someone* needs to learn that virtual packages should NOT have versions -- that logic should be in one ebuild. But I'm not naming names.

```

amd64 udev # cp udev-0.ebuild udev-180.ebuild 

amd64 udev # ebuild udev-180.ebuild manifest

>>> Creating Manifest for /var/lib/layman/udev/virtual/udev

amd64 udev # emerge virtual/udev

```

works, but

```

amd64 udev # emerge -puvDN world

!!! All ebuilds that could satisfy ">=virtual/udev-180[gudev,hwdb]" have been masked.

!!! One of the following masked packages is required to complete your request:

- virtual/udev-180::gentoo (masked by: package.mask)

/etc/portage/package.mask:

# udev overlay

(dependency required by "sys-fs/udisks-2.0.0" [installed])

(dependency required by "app-emulation/wine-1.5.18[udisks]" [ebuild])

(dependency required by "app-emulation/winetricks-922" [ebuild])

(dependency required by "@selected" [set])

(dependency required by "@world" [argument])

```

EDIT: And yes, I copy/pasted grey_dots /etc/portage/package.mask entries. I use other */*::gentoo masks, and no problems, so I am think this is maybe something to do with portage logic regarding virtuals + version numbers + overlay.

EDIT2: Either that or the virtual also needs to support the USE flags too. Ideas?

----------

## dwbowyer

Yes just verified that the virtual HAS to support the use flags that other ebuilds unconditionally depend on.

```

# Copyright 1999-2012 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: $

EAPI=2

DESCRIPTION="Virtual for udev implementation"

HOMEPAGE=""

SRC_URI=""

LICENSE=""

SLOT="0"

KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86"

IUSE="acl gudev hwdb introspection keymap selinux static-libs"

DEPEND=""

RDEPEND="|| (

      sys-fs/udev

      )"

```

----------

## grey_dot

 *dwbowyer wrote:*   

> Yes just verified that the virtual HAS to support the use flags that other ebuilds unconditionally depend on.
> 
> 

 

Fixed, Thanks for that.

----------

## grey_dot

I'm sorry to announce this, but both me and consus decided to abandon the development of this fork. Too much of bad [Mod edit for language. — JRG] code and not enough free time. Repo and overlay will still be accessible.

You can either try to use gentoo devs' fork, stick to an older version, or remove udev completely since most of it's functions are moved to the kernel (I chose the later option).

Thanks to everyone who took part in the development. It was cool :)

----------

## olek

Sad, I liked that project. Many thanks for your efforts!

----------

## GFCCAE6xF

 *olek wrote:*   

> Sad, I liked that project. Many thanks for your efforts!

 

I agree, many thanks grey_dot   :Cool: 

----------

## dmpogo

 *grey_dot wrote:*   

>  remove udev completely since most of it's functions are moved to the kernel (I chose the later option).
> 
> 

 

Can you comment on that last point a bit ?    I moved to static /dev on my server some time ago (not new hardware and nothing hot-pluggable in years),

but what needs to be done on a laptop to be udev free ?

----------

## grey_dot

 *dmpogo wrote:*   

>  *grey_dot wrote:*    remove udev completely since most of it's functions are moved to the kernel (I chose the later option).
> 
>  
> 
> Can you comment on that last point a bit ?    I moved to static /dev on my server some time ago (not new hardware and nothing hot-pluggable in years),
> ...

 

Same as with your server, actually. Device nodes creation is done by kernel with devtmpfs. And since kernel 3.7, firmware is also loaded by kernel itself. Just make sure you have the necessary options enabled in your kernel config. The only thing you have to do by hand without udev is loading the kernel modules.

I'm actually thinking about either hotplug2 revival or porting freebsd devd as a sane alternative to udev.

----------

## krinn

 *grey_dot wrote:*   

> I'm actually thinking about either hotplug2 revival or porting freebsd devd as a sane alternative to udev.

 

Happy to see you aren't dropping it because you are bored but to put your time on better tasks.

I was worried a bit you've lost faith after gentoo devs have done a fork too.

It wasn't lost time anyway, without this fork, nothing would have change, and we (users) would have end with systemd crap.

So thank you for beeing the one who start saying "no".

----------

## cach0rr0

 *olek wrote:*   

> Sad, I liked that project. Many thanks for your efforts!

 

 *rorgoroth wrote:*   

> 
> 
> I agree, many thanks grey_dot  

 

 *krinn wrote:*   

> 
> 
> It wasn't lost time anyway, without this fork, nothing would have change, and we (users) would have end with systemd crap.
> 
> So thank you for being the one who start saying "no".

 

++

I have been living with devtmpfs+mdev for a while. I refuse to move to systemd. Ever. I will sooner drop Linux entirely. No matter how insistent people are that the only reason I don't love systemd, is that I'm simply not educated enough to know why it's the best thing since sliced bread (ahhh, takes me back to pulseaudio!). Creating a useful fork that gives us an alternative and spurs a change is huge huge hugely important and awesome. 

 *grey_dot wrote:*   

> 
> 
> I'm actually thinking about either hotplug2 revival or porting freebsd devd as a sane alternative to udev.

 

sweet!

----------

## DaggyStyle

 *cach0rr0 wrote:*   

>  *olek wrote:*   Sad, I liked that project. Many thanks for your efforts! 
> 
>  *rorgoroth wrote:*   
> 
> I agree, many thanks grey_dot   
> ...

 

move to what os?

----------

## miroR

 *grey_dot wrote:*   

> I'm sorry to announce this, but both me and consus decided to abandon the development of this fork. Too much of bad [Mod edit for language. — JRG] code and not enough free time. Repo and overlay will still be accessible.
> 
> You can either try to use gentoo devs' fork, stick to an older version, or remove udev completely since most of it's functions are moved to the kernel (I chose the later option).
> 
> Thanks to everyone who took part in the development. It was cool 

 

Fine, but how do some of us, I bet I'm not alone, figure out how to do that?

Any guides somewhere?

How nice: "remove udev completely"...

I don't have the cogs and wheels of Gentoo in my subconscious like you...

More verbose tips could do the difference... if possible...

----------

## hcaulfield57

 *miroR wrote:*   

> 
> 
> Fine, but how do some of us, I bet I'm not alone, figure out how to do that?
> 
> Any guides somewhere?
> ...

 

Your options are as follows:

1) Use upstream systemd-udev with an initramfs if you have separate /usr, although there has been some talk of fixing the ebuild. 

2) Mask versions of udev above 171. 

3) Switch to eudev, which works nicely with separate /usr and should meet your requirements for udev. 

4) Switch to mdev/devtmpfs which also works well. See: http://wiki.gentoo.org/wiki/Mdev

5) Switch to static-dev. 

You have lots of options.

----------

## cach0rr0

 *DaggyStyle wrote:*   

> 
> 
> move to what os?

 

if linux became nearly impossible to use without systemd, i would cling to every last possible workaround. 

when that became too much - our software at work works perfectly fine on FreeBSD, and has for over a decade - so that would be my next logical choice.I simply will not be forced into using systemd. I refuse. I don't care what other negatives may exist on another platform, I will not be forced into stupid. If the way I have been doing things for years changes into an unrecognizable monstrosity, might as well be because I've moved to a different platform. 

I hope that is never a choice i have to make.

----------

## hcaulfield57

 *cach0rr0 wrote:*   

> 
> 
> if linux became nearly impossible to use without systemd, i would cling to every last possible workaround. 
> 
> 

 

If Linux becomes unusable without a particular init system, it's probably fair to say that it ceases being UNIX, as the kernel should never be tied to any specific userland utility or program. Even the BSD's which maintain the userland along with the kernel can function with different init systems.

----------

## miroR

 *hcaulfield57 wrote:*   

>  *miroR wrote:*   
> 
> Fine, but how do some of us, I bet I'm not alone, figure out how to do that?
> 
> Any guides somewhere?
> ...

 

Thanks!

Your lines will be gone over numerous times. Things are not "developing" fast here (meaning my Gentoo cogs'n'wheels understanding). Hope I won't be too late for related questions (which I couldn't produce pronto no way).

Maybe just one question is ready:

/etc/portage/package.accept_keywords:

```
app-arch/xz-utils::udev

sys-apps/kmod::udev

sys-fs/udev::udev

sys-fs/udev-init-scripts::udev

virtual/udev::udev
```

becomes (does it?):

```
# this is /etc/portage/package.accept_keywords

# and it is empty

# sure, if people have unrelated to ::udev entries, those remain 
```

in all the cases (of which systemd is out of consideration) you suggest?

And, which other things are there to undo before thinking of options.

And, maybe, which one's the easiest one that doesn't put too much strain on avarage user to accomplish, do you think?

----------

## hcaulfield57

 *miroR wrote:*   

> 
> 
> in all the cases (of which systemd is out of consideration) you suggest?
> 
> And, which other things are there to undo before thinking of options.
> ...

 

Of course, systemd is out of the question  :Smile:  I am currently using eudev (and it's working quite well). For reference:

/etc/portage/package.accept_keywords

```

sys-fs/eudev

virtual/udev

sys-fs/udev-init-scripts

```

/etc/portage/package.mask

```

sys-fs/udev

```

 *miroR wrote:*   

> 
> 
> And, maybe, which one's the easiest one that doesn't put too much strain on avarage user to accomplish, do you think?

 

The solution that puts the least amount of strain on the average user is probably to simply mask versions of udev greater than 171. This should allow you to keep a stable system and not run into any problems with portage being annoying because of using keyworded packages. And then to simply wait and see what options develop over time.

----------

## miroR

 *hcaulfield57 wrote:*   

>  *miroR wrote:*   
> 
> in all the cases (of which systemd is out of consideration) you suggest?
> 
> And, which other things are there to undo before thinking of options.
> ...

 

First, here's another undo to do, or the necessary undoing for doing:

/etc/portage/package.mask, the entries to abandon (undo completely) are:

```
app-arch/xz-utils::gentoo # assuming xz-utils is installed from the udev overlay           

sys-apps/kmod::gentoo # assuming kmod is installed from the udev overlay                   

sys-fs/udev::gentoo                                                                        

sys-fs/udev-init-scripts::gentoo                                                           

virtual/udev::gentoo                                                                       
```

becomes:

```
#app-arch/xz-utils::gentoo # assuming xz-utils is installed from the udev overlay           

#sys-apps/kmod::gentoo # assuming kmod is installed from the udev overlay                   

#sys-fs/udev::gentoo                                                                        

#sys-fs/udev-init-scripts::gentoo                                                           

#virtual/udev::gentoo                                                                       
```

till I am certain I got it right.

 *hcaulfield57 wrote:*   

>  *miroR wrote:*   
> 
> in all the cases (of which systemd is out of consideration) you suggest?
> 
> And, which other things are there to undo before thinking of options.
> ...

 

Entries added into there.

 *hcaulfield57 wrote:*   

> 
> 
>  *miroR wrote:*   
> 
> And, maybe, which one's the easiest one that doesn't put too much strain on avarage user to accomplish, do you think? 
> ...

 

Fine, but no. I am already offered eudev by portage, and that is probably best option, long term.

Haven't emerge-updated system in 10 or more days, so it's normal to have a few extra hurdles for solving...

Might be back to ask more questions if I don't solve these so soon.

----------

## hcaulfield57

miroR: That looks correct, there is no reason to mask xz-utils, kmod, udev-init-scripts, or virutal/udev because they should all install correctly from portage. However, if you want to use eudev, you will need to enable testing udev-init-scripts, and virtual/udev as they are dependencies. You should also make sure to have docbook-xsl-stylesheets installed, as eudev needs that (right now) for some reason.

----------

## miroR

 *hcaulfield57 wrote:*   

> miroR: That looks correct, there is no reason to mask xz-utils, kmod, udev-init-scripts, or virutal/udev because they should all install correctly from portage. However, if you want to use eudev, you will need to enable testing udev-init-scripts, and virtual/udev as they are dependencies. You should also make sure to have docbook-xsl-stylesheets installed, as eudev needs that (right now) for some reason.

 

```
>>> Emerging (50 of 98) sys-fs/udev-init-scripts-9999 from udev

>>> Failed to emerge sys-fs/udev-init-scripts-9999, Log file:

>>>  '/var/log/portage_logs/sys-fs:udev-init-scripts-9999:20121220-093408.log'

>>> Jobs: 49 of 98 complete, 1 failed               Load avg: 3.60, 4.55, 3.67

*** Resuming merge...

>>> Starting parallel fetch

```

Because it tried to emerge the wrong one:

```
 # emerge -pvt udev-init-scripts

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!

[ebuild     U *] sys-fs/udev-init-scripts-9999::udev [17::udev] 0 kB

Total: 1 package (1 upgrade), Size of downloads: 0 kB

 #
```

See the "::udev"? Wrong one.

(( The package:

```
app-text/docbook-xsl-stylesheets

      Latest version available: 1.77.1-r1

      Latest version installed: 1.77.1-r1

     
```

is in my system. ))

But I don't get why the wrong udev-init-scripts is being tried to pull in...

 *hcaulfield57 wrote:*   

> there is no reason to mask xz-utils, kmod, udev-init-scripts, or virutal/udev because they should all install correctly from portage

 

But:

https://forums.gentoo.org/viewtopic-t-934678-start-300.html#7207080

(or just scroll a screenful or two up from here)

that was not masking ::gentoo udev. Actually that was removing the masks from ::gentoo udev fork, the one to use.

Warning. Following is non-related to this topic.

BTW, I got a suspicious activity non-related to this thread, but happening at the time about half hour ago from now:

```
 # date

Thu 20 Dec 10:47:54 CET 2012

 # 
```

and this is just to mark the truth about it in real time. Will post about it in less restrictive place on Gentoo forums (and give a link to there in here, since I'm talking about it). Need only to mark it here, because this thread at this time features in the video I am now posting on vimeo.

EDIT start

https://forums.gentoo.org/viewtopic-p-7207178.html

("Preparation to demonstrate strange intrusion into my system")

EDIT endLast edited by miroR on Thu Dec 20, 2012 11:41 am; edited 1 time in total

----------

## hcaulfield57

Remove the overlay, you can use udev-init-scripts that are in portage.

----------

## mv

 *hcaulfield57 wrote:*   

> If Linux becomes unusable without a particular init system, it's probably fair to say that it ceases being UNIX

 

Yes. The goal of these people (systemd freedesktop etc) is GNOME OS which in philosophy and main concepts is something completely different than UNIX. This is the main problem: If they would develop these concept in their own kernel and own users nobody would complain. The problem is that they want to force it over the linux world although it obviously contradicts in its main concepts.

----------

## miroR

 *hcaulfield57 wrote:*   

> Remove the overlay, you can use udev-init-scripts that are in portage.

 

Give us the command, gov!

Which overlay is it?

It takes time warming up here (remember I was telling about cogs'n'wheels of Gentoo in people's subconscious... Well, it's in deeper subconscious here, that's deep fishing for thought less someone comes to the aid of the needy   :Confused:   )

----------

## Anon-E-moose

I walked away from updating udev at 171-r7 when they required adding udev-mount to startup.

Not that that's a problem per se, but I saw the handwriting on the wall for further complexity to come.

I copied udev-171-r6 to my local portage tree and added ">=sys-fs/udev-171-r7" to package.mask.

I've had a /dev directory since before udev and have done a tar backup of /dev that udev has created

so it wouldn't be too hard to do away with it completely and go back to a static /dev.

The only thing I would have to do is go back to the old style xorg.conf (I think that's required if udev goes bye-bye).

Good luck to those fighting the newer udevs.

----------

## hcaulfield57

 *mv wrote:*   

> 
> 
> Yes. The goal of these people (systemd freedesktop etc) is GNOME OS which in philosophy and main concepts is something completely different than UNIX. This is the main problem: If they would develop these concept in their own kernel and own users nobody would complain. The problem is that they want to force it over the linux world although it obviously contradicts in its main concepts.

 

Yes, and therein lies one of the most important issues with this whole systemd/udev thing. 

 *miroR wrote:*   

> 
> 
> Give us the command, gov!
> 
> Which overlay is it?
> ...

 

The problem is you still have the 'udev' overlay installed, which is not necessary if you want to use eudev. You should run `layman -d udev` to get rid of it. The version of udev-init-scripts I'm using is sys-fs/udev-init-scripts-18. Let me know if that helps. 

 *Anon-E-moose wrote:*   

> 
> 
> I've had a /dev directory since before udev and have done a tar backup of /dev that udev has created
> 
> so it wouldn't be too hard to do away with it completely and go back to a static /dev.
> ...

 

That actually should be uncessary, I tested out static-/dev at one point to see it's viability (it works properly, does what it should), and not much is required to get xorg working properly.

----------

## cach0rr0

 *Anon-E-moose wrote:*   

> I walked away from updating udev at 171-r7 when they required adding udev-mount to startup.
> 
> Not that that's a problem per se, but I saw the handwriting on the wall for further complexity to come.
> 
> I copied udev-171-r6 to my local portage tree and added ">=sys-fs/udev-171-r7" to package.mask.
> ...

 

just as a heads up, Chromium will not build without a relatively recent udev 

so even though I moved to mdev ages ago, I've had to at least have the udev package installed as a build dependency for certain things. Nothing from udev is ever run, but it's there so the chromium build doesn't complain. 

this is one of many seemingly trivial things that make me raise an eyebrow, and bring up the idea of "being unusable without systemd" - how long until chromium depends on some library from systemd? 

I've yet to, for example, find a decent systray icon for monitoring my battery that doesn't rely on udev. Yet another "little thing" that makes me particularly nervous about the future. 

So you folk keep an eye out. 

NB: i didnt really mean to deviate from the subject of the thread, i.e. the udev fork, but it's worth noting some things just plain can't exist without udev. Merely having a /dev manager may become insufficient, and at this rate it won't be long before nearly every application we use requires "official" udev. Slipper slope and such, today it's packages linking against udev, tomorrow it's packages linking against systemd.

----------

## grey_dot

 *cach0rr0 wrote:*   

> 
> 
> just as a heads up, Chromium will not build without a relatively recent udev 
> 
> 

 

Wait, what? A web browser, which is by definition pure user application, requires an exact implementation of one of the core system components? Huh...

 *cach0rr0 wrote:*   

> 
> 
> how long until chromium depends on some library from systemd? 
> 
> 

 

Actually, >udev-182 requires libsystemd. It just aint installed as a separate package afaik.

 *cach0rr0 wrote:*   

> 
> 
> Slipper slope and such, today it's packages linking against udev, tomorrow it's packages linking against systemd.
> 
> 

 

I avoid that kind of software. Its an overcomplicated crap anyway.

----------

## asturm

 *cach0rr0 wrote:*   

> I've yet to, for example, find a decent systray icon for monitoring my battery that doesn't rely on udev. Yet another "little thing" that makes me particularly nervous about the future. 
> 
> So you folk keep an eye out.

 

List of rebuilds after udev -> eudev update:

```
[ebuild   R   ~] dev-libs/eeze-1.7.4 

[ebuild   R   ~] sys-apps/util-linux-2.22.1

[ebuild   R   ~] media-libs/mesa-9.0.1

[ebuild   R    ] dev-libs/libatasmart-0.19

[ebuild   R    ] sys-auth/consolekit-0.4.5_p20120320-r1

[ebuild   R    ] dev-libs/libgusb-0.1.3

[ebuild   R    ] x11-base/xorg-server-1.13.1

[ebuild   R   ~] sys-fs/lvm2-2.02.97

[ebuild   R   ~] net-wireless/bluez-4.101-r4

[ebuild   R    ] sys-fs/udisks-1.0.4-r2

[ebuild   R    ] x11-drivers/xf86-input-evdev-2.7.3

[ebuild   R   ~] x11-drivers/xf86-video-intel-2.20.16

[ebuild   R   #] kde-base/kdelibs-4.9.95:4

[ebuild   R   ~] media-video/vlc-2.0.4
```

----------

## Ant P.

 *cach0rr0 wrote:*   

> I've yet to, for example, find a decent systray icon for monitoring my battery that doesn't rely on udev. Yet another "little thing" that makes me particularly nervous about the future. 

 

Try xbattbar.

----------

## miroR

34992 views of this thread at this time.

(in words and rounded up, it's thirty-five thousands, 35,000)...

I'm afraid I haven't solve this for myself, for one. Yet.

I was away for a few days. So....

 *hcaulfield57 wrote:*   

>  *mv wrote:*   
> 
> Yes. The goal of these people (systemd freedesktop etc)
> 
> ... [snip] ... 
> ...

 

And I haven't rid of systemd yet.

The ::gentoo udev, actually what should've been marked with ::gentoo instead of this abandoned ::udev (and I don't know where I lost it if I did), more precisely:

(I tried in vain to post in pastebin.com ... They're boycotting my Tor browser, can't post unless I log in, mozilla already removed some of my pastes... nowhere can I paste)...

So I'll have to post it here... shortened to most relevant.

========= emerge --info sys-fs/udev start ===========

```
Portage 2.1.11.38 (hardened/linux/amd64, ...[snip]...

================================================

                        System Settings

================================================

...[snip]...

Repositories: gentoo multimedia sunrise zugaina vdr-devel vdr-testing seden x-portage x-my_ebuilds

ACCEPT_KEYWORDS="amd64 ~amd64"

...[snip]...

PORTAGE_TMPDIR="/dev/shm"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/var/lib/layman/multimedia /var/lib/layman/sunrise /var/lib/layman/zugaina /var/lib/layman/vdr-devel /var/lib/layman/vdr-testing /var/lib/layman/seden /var/lib/portage /var/lib/layman/my_ebuilds"

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"

USE="acl amd64 berkdb ...[snip]... usertrack vhost_alias" CALLIGRA_...[snip]...account"

Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, MAKEOPTS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON

================================================

                        Package Settings

================================================

sys-fs/udev-196-r1 was built with the following:

USE="acl gudev hwdb kmod (multilib) openrc static-libs -doc -introspection -keymap (-selinux)"

```

========= emerge --info sys-fs/udev end ===========

I know it's incomplete (and I didn't snip so well, never mind my trying), but there it is, the main ::gentoo repo (in top of the shortened paste), where I think this package is from... so my doubt is solved, IIUC.

But how come that package shows these files, I'm following in short intervals this topic right now in real time, if the previous output would need putting in say useflags, or if the following output need be cut shorter, someone tell me, because I'm afraid if I shorten the following upfront, it might be too incomplete. This is a difficult and uncertain decision to post all of the following...

========= equery files sys-fs/udev start ===========

```
 * Searching for udev in sys-fs ...

 * Contents of sys-fs/udev-196-r1:

/etc

/etc/udev

/etc/udev/hwdb.d

/etc/udev/rules.d

/etc/udev/udev.conf

/sbin

/sbin/udevadm -> ../usr/bin/udevadm

/usr

/usr/bin

/usr/bin/udevadm

/usr/include

/usr/include/gudev-1.0

/usr/include/gudev-1.0/gudev

/usr/include/gudev-1.0/gudev/gudev.h

/usr/include/gudev-1.0/gudev/gudevclient.h

/usr/include/gudev-1.0/gudev/gudevdevice.h

/usr/include/gudev-1.0/gudev/gudevenumerator.h

/usr/include/gudev-1.0/gudev/gudevenums.h

/usr/include/gudev-1.0/gudev/gudevenumtypes.h

/usr/include/gudev-1.0/gudev/gudevtypes.h

/usr/include/libudev.h

/usr/lib

/usr/lib/systemd

/usr/lib/systemd/system

/usr/lib/systemd/system/sockets.target.wants

/usr/lib/systemd/system/sockets.target.wants/systemd-udevd-control.socket -> ../systemd-udevd-control.socket

/usr/lib/systemd/system/sockets.target.wants/systemd-udevd-kernel.socket -> ../systemd-udevd-kernel.socket

/usr/lib/systemd/system/sysinit.target.wants

/usr/lib/systemd/system/sysinit.target.wants/systemd-udev-trigger.service -> ../systemd-udev-trigger.service

/usr/lib/systemd/system/sysinit.target.wants/systemd-udevd.service -> ../systemd-udevd.service

/usr/lib/systemd/system/systemd-udev-settle.service

/usr/lib/systemd/system/systemd-udev-trigger.service

/usr/lib/systemd/system/systemd-udevd-control.socket

/usr/lib/systemd/system/systemd-udevd-kernel.socket

/usr/lib/systemd/system/systemd-udevd.service

/usr/lib/systemd/systemd-udevd

/usr/lib/udev

/usr/lib/udev/accelerometer

/usr/lib/udev/ata_id

/usr/lib/udev/cdrom_id

/usr/lib/udev/collect

/usr/lib/udev/mtd_probe

/usr/lib/udev/rules.d

/usr/lib/udev/rules.d/40-gentoo.rules

/usr/lib/udev/rules.d/42-usb-hid-pm.rules

/usr/lib/udev/rules.d/50-udev-default.rules

/usr/lib/udev/rules.d/60-cdrom_id.rules

/usr/lib/udev/rules.d/60-persistent-alsa.rules

/usr/lib/udev/rules.d/60-persistent-input.rules

/usr/lib/udev/rules.d/60-persistent-serial.rules

/usr/lib/udev/rules.d/60-persistent-storage-tape.rules

/usr/lib/udev/rules.d/60-persistent-storage.rules

/usr/lib/udev/rules.d/60-persistent-v4l.rules

/usr/lib/udev/rules.d/61-accelerometer.rules

/usr/lib/udev/rules.d/64-btrfs.rules

/usr/lib/udev/rules.d/75-net-description.rules

/usr/lib/udev/rules.d/75-probe_mtd.rules

/usr/lib/udev/rules.d/75-tty-description.rules

/usr/lib/udev/rules.d/78-sound-card.rules

/usr/lib/udev/rules.d/80-drivers.rules

/usr/lib/udev/rules.d/95-udev-late.rules

/usr/lib/udev/scsi_id

/usr/lib/udev/v4l_id

/usr/lib64

/usr/lib64/libgudev-1.0.a

/usr/lib64/libgudev-1.0.so -> libgudev-1.0.so.0.1.2

/usr/lib64/libgudev-1.0.so.0 -> libgudev-1.0.so.0.1.2

/usr/lib64/libgudev-1.0.so.0.1.2

/usr/lib64/libudev.a

/usr/lib64/libudev.so -> libudev.so.1.2.0

/usr/lib64/libudev.so.1 -> libudev.so.1.2.0

/usr/lib64/libudev.so.1.2.0

/usr/lib64/pkgconfig

/usr/lib64/pkgconfig/gudev-1.0.pc

/usr/lib64/pkgconfig/libudev.pc

/usr/share

/usr/share/doc

/usr/share/doc/udev-196-r1

/usr/share/doc/udev-196-r1/DISTRO_PORTING.bz2

/usr/share/doc/udev-196-r1/NEWS.bz2

/usr/share/doc/udev-196-r1/README.bz2

/usr/share/doc/udev-196-r1/TODO.bz2

/usr/share/man

/usr/share/man/man7

/usr/share/man/man7/udev.7.bz2

/usr/share/man/man8

/usr/share/man/man8/systemd-udevd.8.bz2

/usr/share/man/man8/systemd-udevd.service.8.bz2

/usr/share/man/man8/udevadm.8.bz2

/usr/share/pkgconfig

/usr/share/pkgconfig/udev.pc

```

========= equery files sys-fs/udev end ===========

I haven't rid of systemd.

How come?

 *hcaulfield57 wrote:*   

>  *miroR wrote:*   
> 
> Give us the command, gov!
> 
> Which overlay is it?
> ...

 

I did figure out after I rummaged about it in my subconscious... More verbosity upfront on your part would have helped me figure out sooner back then. But as you can see further above, my problem has probably not gone away. I still have that systemd in there IIUC.

 *hcaulfield57 wrote:*   

> The version of udev-init-scripts I'm using is sys-fs/udev-init-scripts-18. Let me know if that helps. 
> 
> 

 

Nope. I'm afraid I went completely elsewhere, under the systemd creators' claws... or I don't know where exactly.

Because, for shortness this time (I can expand if necessary later):

```

 # emerge -pvt sys-fs/udev-init-scripts

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!

[ebuild   R   *] sys-fs/udev-init-scripts-9999  0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

#
```

 *hcaulfield57 wrote:*   

>  *Anon-E-moose wrote:*   
> 
> I've had a /dev directory since before udev and have done a tar backup of /dev that udev has created
> 
> so it wouldn't be too hard to do away with it completely and go back to a static /dev.
> ...

 

So something seems to be happaning to poor udev, and she might be dying on us... 

Fine, if it's not much, then there maybe someone of you might teach us how to do it, e.g. make a tutorial on http://en.gentoo-wiki.com/ or somewhere...

Because this frightens me sick a little. I had plans with working Gentoo, not for working on my non-booting Gentoo or such...

I haven't rebooted in some week's time yet (it's usual here, TV card is recording a lot of time), exactly for fear that I would have to spend all my skills, mental power and time into fixing a non-booting system.

That much about the state of my Gentoo. 

It just might not boot. All is different now. One detail. On a reboot about a week and a day ago, I think, there was a message to the effect of:

"No /sbin/udevd" and no devices were created...

Previously, with ::udev repo udev bunch:

```
# ls -l /sbin/udev*

-rwxr-xr-x 1 root root 182184 Dec  1 12:00 /sbin/udevadm

-rwxr-xr-x 1 root root 174040 Dec  1 12:00 /sbin/udevd

#
```

And now, it's completely differently.

```
 # ls -l /sbin/udev*

lrwxrwxrwx 1 root root 18 Dec 26 20:36 /sbin/udevadm -> ../usr/bin/udevadm

#
```

and I already had a few days down with the udev a month or two ago, in this thread it should be documented.

Sure, apart from my hate for SELinux and despise of too much, too much NSA's eavesdropping on the world, not only in the U.S.A... (those are definitely interrelated, but things seem to be developing into different stories slowly)...

Sure, apart from that reason, I still very much like Gentoo but with a lot of uncertainty, for the same reason.

I should go and have a nap now, but I won't for an hour more, till I see if there are any necessary corrections for me to do in regard to the extensive pasting in the post instead of in a pastebin (which wasn't possible for my Tor browser).

EDIT: Bump. Thu 27 Dec 04:20:18 CET 2012

----------

## cach0rr0

 *grey_dot wrote:*   

> 
> 
> Wait, what? A web browser, which is by definition pure user application, requires an exact implementation of one of the core system components? Huh...
> 
> 

 

try hacking the ebuild to remove the udev dependency. observe smoke and fire if udev is not installed (presumably eudev or your fork would fulfill the requirements)  :Smile: 

 *genstorm wrote:*   

> 
> 
> List of rebuilds after udev -> eudev update:
> 
> 

 

not too terrible. Course I a)don't use/have consolekit, b)have been udev-free long enough I'm going to have to figure out a valid excuse to try it again (any udev, be it eudev or otherwise). Maybe a new box. 

 *Ant P. wrote:*   

> 
> 
> Try xbattbar.

 

ta

tried that before, but hadn't noticed the -c option (I am, of course, not using APM)

----------

## miroR

 *miroR wrote:*   

> It just might not boot. All is different now. One detail. On a reboot about a week and a day ago, I think, there was a message to the effect of:
> 
> "No /sbin/udevd" and no devices were created...
> 
> 

 

That was because udev-init-scripts wasn't installed, I remember (I was in a rush, for lack of time).

I just now backed up my Gentoo, which is perfectly booting, as 99% of the time.

EDIT start

Confirmed all working fine by cloning the backed up system, as per somewhere in this thread

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

or pointers therefrom I explained.

I now have to go back to:

https://forums.gentoo.org/viewtopic-p-7207178.html

because I promised, and mentioned it in a post in this thread a few days ago.

Only one more remark.

It doesn't matter not having succeeded yet. Devs who tried to fix things with this fork are appreciated for having tried the rught thing! Thanks!

EDIT end

----------

## grey_dot

 *cach0rr0 wrote:*   

>  *grey_dot wrote:*   
> 
> Wait, what? A web browser, which is by definition pure user application, requires an exact implementation of one of the core system components? Huh...
> 
>  
> ...

 

I think I just believe you. Sucks anyway.

----------

## Anon-E-moose

 *cach0rr0 wrote:*   

>  *grey_dot wrote:*   
> 
> Wait, what? A web browser, which is by definition pure user application, requires an exact implementation of one of the core system components? Huh...
> 
>  
> ...

 

Looking at the chromium ebuild it technically requires virtual/udev (under RDEPEND)

which should be able to be built in a local directory and 

changed by adding mdev or whatever other replacement is used. 

From virtual/udev

```
RDEPEND="|| ( ~sys-fs/udev-171[gudev?,hwdb?,introspection?,keymap?,selinux?]

   ~sys-fs/eudev-0[gudev?,hwdb?,introspection?,keymap?,selinux?] )"
```

Note: I haven't chased it down completely but it might even be possible to put in static-dev as a RDEPEND of virtual/udev. 

But thanks for the heads up, I don't have either kde or gnome dependencies on my system 

and simply find a replacement if something is being adamant about trying to force me

to add such silliness when I don't want it

----------

## cach0rr0

 *Anon-E-moose wrote:*   

> 
> 
> Looking at the chromium ebuild it technically requires virtual/udev (under RDEPEND)
> 
> which should be able to be built in a local directory and 
> ...

 

not a runtime failure

it's a build failure, as the chromium build expects libudev

do this:

-unmerge udev (completely - presumably, any package, including this fork and eudev, that provide libudev, will get you past this error)

-hack the chromium ebuild to remove the RDEPEND for virtual/udev

-digest the ebuild

-emerge

-observe the following:

```

>>> Configuring source in /var/tmp/portage/www-client/chromium-24.0.1312.35/work/chromium-24.0.1312.35 ...

build/gyp_chromium --depth=. -Ddisable_sse2=1 -Dlinux_use_tcmalloc=0 -Ddisable_nacl=1 -Dflapper_version_h_file=/var/tmp/portage/www-client/chromium-24.0.1312.35/temp/flapper_version.h -Duse_system_bzip2=1 -Duse_system_flac=1 -Duse_system_icu=1 -Duse_system_libevent=1 -Duse_system_libjpeg=1 -Duse_system_libpng=1 -Duse_system_libusb=1 -Duse_system_libvpx=1 -Duse_system_libwebp=1 -Duse_system_libxml=1 -Duse_system_minizip=1 -Duse_system_opus=1 -Duse_system_speex=1 -Duse_system_v8=1 -Duse_system_xdg_utils=1 -Duse_system_yasm=1 -Duse_system_zlib=1 -Duse_cups=1 -Duse_gconf=0 -Duse_gnome_keyring=0 -Dlinux_link_gnome_keyring=0 -Duse_kerberos=0 -Duse_pulseaudio=0 -Dselinux=0 -Dlinux_link_gsettings=1 -Dlinux_sandbox_path=/usr/lib64/chromium-browser/chrome_sandbox -Dlinux_sandbox_chrome_path=/usr/lib64/chromium-browser/chrome -Dlinux_use_gold_binary=0 -Dlinux_use_gold_flags=0 -Dproprietary_codecs=1 -Dffmpeg_branding=Chrome -Dtarget_arch=x64 -Dwerror=

Updating projects from gyp files...

Package libudev was not found in the pkg-config search path.

Perhaps you should add the directory containing `libudev.pc'

to the PKG_CONFIG_PATH environment variable

No package 'libudev' found

gyp: Call to 'pkg-config --cflags libudev' returned exit status 1. while loading dependencies of /var/tmp/portage/www-client/chromium-24.0.1312.35/work/chromium-24.0.1312.35/base/base.gyp while loading dependencies of /var/tmp/portage/www-client/chromium-24.0.1312.35/work/chromium-24.0.1312.35/build/all.gyp while trying to load /var/tmp/portage/www-client/chromium-24.0.1312.35/work/chromium-24.0.1312.35/build/all.gyp

 * ERROR: www-client/chromium-24.0.1312.35 failed (configure phase):

 *   (no error message)

 * 

 * Call stack:

 *     ebuild.sh, line  89:  Called src_configure

 *   environment, line 6483:  Called die

 * The specific snippet of code:

 *       egyp_chromium ${myconf} || die

 * 

 * If you need support, post the output of `emerge --info '=www-client/chromium-24.0.1312.35'`,

 * the complete build log and the output of `emerge -pqv '=www-client/chromium-24.0.1312.35'`.

 * The complete build log is located at '/var/tmp/portage/www-client/chromium-24.0.1312.35/temp/build.log'.

 * The ebuild environment file is located at '/var/tmp/portage/www-client/chromium-24.0.1312.35/temp/environment'.

 * Working directory: '/var/tmp/portage/www-client/chromium-24.0.1312.35/work/chromium-24.0.1312.35'

 * S: '/var/tmp/portage/www-client/chromium-24.0.1312.35/work/chromium-24.0.1312.35'

>>> Failed to emerge www-client/chromium-24.0.1312.35, Log file:

```

you can, of course, merge udev just for the chromium  build, and then unmerge it after, since it doesnt cause any issues at runtime

but that's a royal pain in the ass. 

I found an issue in the chromium bug tracker (not the gentoo one, as in, the one from google) where, long story short, there is zero interest in ever removing this as a build dependency. So, you will not have an easy time ever unudev'ing your system if you are a chromium user.

----------

## Anon-E-moose

Interesting. 

1st off I don't use chromium, and with the (to me) insane need for any part of udev available to compile I probably never will.

It seems to be looking for "libudev.pc" which makes me wonder if a dummy udev package would work.

I have something similar for sys-kernel/sources, as I roll my own kernels.

I may look into it simply out of curiousity.

Note: I'm not trying to be argumentative, but if this is cropping up in chromium 

it may show up in other apps and a work around to installing *udev* would be nice.

Edit to add: The latest chromium also appears to need "dbus" to compile. 

It does appear to link to libudev.so, so not sure if it would run without udev.

----------

## cach0rr0

 *Anon-E-moose wrote:*   

> 
> 
> Note: I'm not trying to be argumentative, but if this is cropping up in chromium 
> 
> it may show up in other apps and a work around to installing *udev* would be nice.
> ...

 

didnt take it as argument. methinks we're seeing eye to eye on this one. 

if a f**king web browser is requiring udev, what sort of other crap is it going to pollute? 

how long until you are having to apply crude hacks for every application you use? 

i wouldnt be so worried had chromium upstream said "go kick rocks, we're not removing the udev dependency or making it configurable"

at this rate it won't be long before openssl depends on pulseaudio  :Laughing: 

----------

## PaulBredbury

 *cach0rr0 wrote:*   

> a f**king web browser is requiring udev

 

Reason.

----------

## Anon-E-moose

 *PaulBredbury wrote:*   

>  *cach0rr0 wrote:*   a f**king web browser is requiring udev 
> 
> Reason.

 

From the link.

 *Quote:*   

> you need to think bigger. Chromium supports joystick inputs (which come and
> 
> go) for playing games in the browser, so udev makes sense. it also supports
> 
> looking up your location, detecting when the network comes up/down, and
> ...

 

Seriously, how many people use joysticks for running their browser   :Rolling Eyes: 

Firefox supports looking up location without dbus.

I don't run either kde or gnome, so that is just bloat.

Etc.

I think they do it just because they can not because there is some overriding reason

and when questioned out come the ignorant excuses.

There should be flags to shut out udev, dbus, gconf and other crap that isn't necessary

when one isn't running gnome or kde.

The real problem is that chrome/chromium/google wants to be in the OS business and

they've tried for years (so did firefox but they stopped a while back). 

They also think they have to right to all my personal data. They are wrong

really though, I don't like Chrome and I don't use it and never will. (response to mikes ridiculous close in the quote)

I don't give a flying flip what many people do. 

This is linux after all, choice is king.

Edit to add: in red

----------

## Hypnos

 *PaulBredbury wrote:*   

>  *cach0rr0 wrote:*   a f**king web browser is requiring udev 
> 
> Reason.

 

I'm not sure that's a good reason -- are there not apps which use a joystick that *don't* depend on udev?

----------

## Anon-E-moose

 *Hypnos wrote:*   

>  *PaulBredbury wrote:*    *cach0rr0 wrote:*   a f**king web browser is requiring udev 
> 
> Reason. 
> 
> I'm not sure that's a good reason -- are there not apps which use a joystick that *don't* depend on udev?

 

Seriously what's next, requiring systemd, a certain version of compiler, signed over rights to my first born?

The quote was an excuse for all the cr*p, not a reason.

----------

## PaulBredbury

For God's sake, the majority of this thread is just moan, moan, moan, despite there being other threads (yes plural) for such moaning.

Write patches (Edit: added link) to make the objectionable stuff optional. It's their app, not yours, you have no rights. They don't even need to provide reasons or excuses, so enough with the bitchin' already  :Evil or Very Mad: 

Oh, and happy new year  :Wink: 

 *Quote:*   

> are there not apps which use a joystick that *don't* depend on udev?

 

Yeah. So if more effort were put into patch-writing than hot-air-expulsion, this thread would be much nicer.Last edited by PaulBredbury on Mon Dec 31, 2012 9:54 pm; edited 1 time in total

----------

## cach0rr0

 *PaulBredbury wrote:*   

>  *cach0rr0 wrote:*   a f**king web browser is requiring udev 
> 
> Reason.

 

sure looks like a great 'reason' for udev support being *optional'

not a particularly great reason to make it a mandatory build dependency. 

 *PaulBredbury wrote:*   

> For God's sake, the majority of this thread is just moan, moan, moan, despite there being other threads (yes plural) for such moaning.
> 
> Write patches to make the objectionable stuff optional. It's their app, not yours, you have no rights. They don't even need to provide reasons or excuses, so enough with the bitchin' already 
> 
> Oh, and happy new year 
> ...

 

Not sure if you've quite noticed, bit you're bitching about people bitching in a thread about a now-abandoned udev fork. 

Of note: the next time you see Linus bitching about the udev team being "braindead" as he put it once, please do make sure to inform him he has no rights, it's their app not his, and to stop his whinging. Because bitching about someone else's work is a faux pas, especially in the linux world you see...

----------

## PaulBredbury

Well, if a moderator says this thread's about bitchin', then that's what it's about  :Wink: 

There was silly me, hoping that this would be a thread to facilitate maintaining the code.

Linus in a unique situation, that's why people listen to him. I doubt Google are monitoring this thread with trepidation.

Thank you consus and grey_dot (and anyone else involved), for a fork which I thought was a fantastic idea, and am still using. I'll switch to Gentoo's fork when a problem appears.

----------

## cach0rr0

 *PaulBredbury wrote:*   

> Well, if a moderator says this thread's about bitchin', then that's what it's about 
> 
> There was silly me, hoping that this would be a thread to facilitate maintaining the code.
> 
> 

 

pffttt. I'm a human spam filter (and a poor one at that) 

If this were still alive I would have bit my tongue and not gone off on a tangent. 

But as of this post I'm under the impression the project is pretty much dead and abandoned (understandably so)

----------

## grey_dot

 *PaulBredbury wrote:*   

> 
> 
> Write patches (Edit: added link) to make the objectionable stuff optional. It's their app, not yours, you have no rights. They don't even need to provide reasons or excuses, so enough with the bitchin' already :evil: 
> 
> Oh, and happy new year :wink:
> ...

 

Patch this, patch that, patch everything again and again... You know, I'm getting really tired of _HAVING_TO_ write patches to many programs I use on a daily basis. Yeah, I know that those are open source softwares, and developers made them open so that anybody could participate in the development process. But there is a huge difference between participating voluntarily like when adding new features and making cool things, and participating because you have to do it or your system will drown in megatons of bloated crap. I'd really like to help developers, not to fight with them because they have their brains somewhere inside their asses, but most of the time things don't go along with my expectations. So I got mdev instead of udev now, openbsd on most of my servers instead of linux, and a real headache about using a bluetooth headset in linux without having to struggle with dbus/python/gobject/other-bloated-piece-of-crap.

But you're right, it's developers' right to produce unusable unmaintainable crap. I'll just try to avoid it.

----------

## dmpogo

 *grey_dot wrote:*   

> 
> 
> Patch this, patch that, patch everything again and again... You know, I'm getting really tired of _HAVING_TO_ write patches to many programs I use on a daily basis. Yeah, I know that those are open source softwares, and developers made them open so that anybody could participate in the development process. 

 

Part of it, is because we are here not treating our computers utilitarinly,   but play with them too much continously updating them.

On my machines I would have been better off if I left then in as of a year ago state.  After this spring-summer updates thay are all running worse or a bit flaky.

Just had to use my CPU time on Compute Canada high performance facilities - has noted that vast majority of the machines it links from coast to coast  still use 2.6.18 kernel.  And the rest - 2.6.32.

----------

## Dominique_71

I have a simple question. In a system with udev and openrc, with an initrd that just load a boot splash theme, to install eudev, is it as simple than to mask sys-apps/systemd and sys-fs/udev, uninstall udev and update world (which just want to install eudev) ?

----------

## lost+found

 *Dominique_71 wrote:*   

> I have a simple question. In a system with udev and openrc, with an initrd that just load a boot splash theme, to install eudev, is it as simple than to mask sys-apps/systemd and sys-fs/udev, uninstall udev and update world (which just want to install eudev) ?

 

I only did "emerge --oneshot sys-fs/eudev" and sys-fs/udev was unmerged automatically. I didn't mask udev/systemd either, and no changes to bootsplash/initrd. It just worked with eudev. I didn't notice anything unusual, eudev works fine on my desktop (it's running *kitless KDE+pmount+bluetooth...etc.).

```
1364734201: Started emerge on: Mar 31, 2013 14:50:01

1364734201:  *** emerge --oneshot sys-fs/eudev

1364734215:  >>> emerge (1 of 1) sys-fs/eudev-1_beta2-r2 to /

1364734215:  === (1 of 1) Cleaning (sys-fs/eudev-1_beta2-r2::/usr/portage/sys-fs/eudev/eudev-1_beta2-r2.ebuild)

1364734215:  === (1 of 1) Compiling/Merging (sys-fs/eudev-1_beta2-r2::/usr/portage/sys-fs/eudev/eudev-1_beta2-r2.ebuild)

1364734265:  === (1 of 1) Merging (sys-fs/eudev-1_beta2-r2::/usr/portage/sys-fs/eudev/eudev-1_beta2-r2.ebuild)

1364734268:  >>> AUTOCLEAN: sys-fs/eudev:0

1364734271:  === (1 of 1) Post-Build Cleaning (sys-fs/eudev-1_beta2-r2::/usr/portage/sys-fs/eudev/eudev-1_beta2-r2.ebuild)

1364734271:  ::: completed emerge (1 of 1) sys-fs/eudev-1_beta2-r2 to /

1364734272: === Unmerging... (sys-fs/udev-197-r8)

1364734274:  >>> unmerge success: sys-fs/udev-197-r8

1364734274:  *** Finished. Cleaning up...

1364734277:  *** exiting successfully.

1364734287:  *** terminating.
```

Elog output gives important steps to add udev-postmount to the default runlevel, and to restart udev!!!

Good luck!  :Smile: 

----------

## Dominique_71

Just to say it worked fine.   :Very Happy: 

----------

