Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Announce: just another one udev fork
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 8, 9, 10 ... 12, 13, 14  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
Hypnos
Advocate
Advocate


Joined: 18 Jul 2002
Posts: 2889
Location: Omnipresent

PostPosted: Wed Oct 10, 2012 8:49 pm    Post subject: Reply with quote

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.
_________________
Personal overlay | Simple backup scheme
Back to top
View user's profile Send private message
Jubei-Mitsuyoshi
n00b
n00b


Joined: 05 Sep 2012
Posts: 12

PostPosted: Wed Oct 10, 2012 9:33 pm    Post subject: Reply with quote

damn right, they should take over maintenance period ( assuming they want to )
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7470

PostPosted: Wed Oct 10, 2012 10:06 pm    Post subject: Reply with quote

hcaulfield57 wrote:
Awesome, looks like this will be added to portage. Great work grey_dot and consus!


faith back ? :)
Back to top
View user's profile Send private message
grey_dot
Tux's lil' helper
Tux's lil' helper


Joined: 15 Jul 2012
Posts: 142

PostPosted: Thu Oct 11, 2012 6:30 am    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Thu Oct 11, 2012 7:26 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Thu Oct 11, 2012 9:55 am    Post subject: Reply with quote

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."
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Thu Oct 11, 2012 10:42 am    Post subject: Reply with quote

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


Last edited by aCOSwt on Thu Oct 11, 2012 12:28 pm; edited 1 time in total
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Thu Oct 11, 2012 12:22 pm    Post subject: Reply with quote

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. ;)
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Thu Oct 11, 2012 12:45 pm    Post subject: Reply with quote

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
RUN{fail_event_on_error} attribute was removed.

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.
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Thu Oct 11, 2012 1:37 pm    Post subject: Reply with quote

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 :roll: 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 !
_________________
Back to top
View user's profile Send private message
Hypnos
Advocate
Advocate


Joined: 18 Jul 2002
Posts: 2889
Location: Omnipresent

PostPosted: Thu Oct 11, 2012 2:10 pm    Post subject: Reply with quote

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?
_________________
Personal overlay | Simple backup scheme
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Thu Oct 11, 2012 4:03 pm    Post subject: Reply with quote

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.)
Back to top
View user's profile Send private message
hcaulfield57
Tux's lil' helper
Tux's lil' helper


Joined: 13 Mar 2012
Posts: 148

PostPosted: Thu Oct 11, 2012 6:22 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
grey_dot
Tux's lil' helper
Tux's lil' helper


Joined: 15 Jul 2012
Posts: 142

PostPosted: Fri Oct 12, 2012 8:32 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Jubei-Mitsuyoshi
n00b
n00b


Joined: 05 Sep 2012
Posts: 12

PostPosted: Fri Oct 12, 2012 10:08 am    Post subject: Reply with quote

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 :)
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri Oct 12, 2012 11:04 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Jubei-Mitsuyoshi
n00b
n00b


Joined: 05 Sep 2012
Posts: 12

PostPosted: Fri Oct 12, 2012 5:50 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
hcaulfield57
Tux's lil' helper
Tux's lil' helper


Joined: 13 Mar 2012
Posts: 148

PostPosted: Fri Oct 12, 2012 6:31 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
grey_dot
Tux's lil' helper
Tux's lil' helper


Joined: 15 Jul 2012
Posts: 142

PostPosted: Fri Oct 12, 2012 6:53 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
hcaulfield57
Tux's lil' helper
Tux's lil' helper


Joined: 13 Mar 2012
Posts: 148

PostPosted: Fri Oct 12, 2012 7:56 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2678

PostPosted: Fri Oct 12, 2012 8:37 pm    Post subject: Reply with quote

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.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.
Back to top
View user's profile Send private message
Jubei-Mitsuyoshi
n00b
n00b


Joined: 05 Sep 2012
Posts: 12

PostPosted: Sun Oct 14, 2012 7:38 am    Post subject: Reply with quote

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 :)
Back to top
View user's profile Send private message
hcaulfield57
Tux's lil' helper
Tux's lil' helper


Joined: 13 Mar 2012
Posts: 148

PostPosted: Sun Oct 14, 2012 6:32 pm    Post subject: Reply with quote

Jubei-Mitsuyoshi wrote:
deb is on its way

Good work, I look forward to hearing how it goes.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Sat Oct 20, 2012 12:11 pm    Post subject: Reply with quote

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
Code:
# 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
Back to top
View user's profile Send private message
grey_dot
Tux's lil' helper
Tux's lil' helper


Joined: 15 Jul 2012
Posts: 142

PostPosted: Sat Oct 20, 2012 1:55 pm    Post subject: Reply with quote

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.

The udev-init-scripts-17-r1.ebuild


Added as udev-init-scripts-17.ebuild, though it's the same as -16. Also I didn't have that bug.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3 ... 8, 9, 10 ... 12, 13, 14  Next
Page 9 of 14

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