| View previous topic :: View next topic |
| Author |
Message |
hcaulfield57
Tux's lil' helper
Joined: 13 Mar 2012
Posts: 148
|
 Posted: Thu Sep 27, 2012 4:35 pm Post subject: |
 |
|
| 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. |
|
| Back to top |
|
 |
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Mon Oct 01, 2012 10:41 am Post subject: Re: Announce: just another one udev fork |
|
|
| 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 
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.
_________________
|
|
| Back to top |
|
|
grey_dot
Tux's lil' helper
Joined: 15 Jul 2012
Posts: 142
|
| Posted: Tue Oct 02, 2012 9:37 pm Post subject: Re: Announce: just another one udev fork |
|
|
| 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
Having still a couple of 2.6.38 running, I'd be happy to read that your fork is still compatible with KV >= 2.6.34
BTW, I would be grateful if someone could point a link to any discussion supporting the increase of KV_min to 2.6.39. |
It was the upstream guys decision, not ours. We haven't tested anything with pre 3.0 kernels, so we can't say for sure. However, if you try to run udev on 2.6.38, and it works, we'll decrease the required kernel number :) |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9338
|
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Wed Oct 03, 2012 7:51 pm Post subject: |
|
|
If this is the one ending with Linus deciding to bypass udev for loading firmware... then... There's going to be a real good reason for KV_min > 3.a_lot 
_________________
|
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9338
|
| Posted: Wed Oct 03, 2012 8:16 pm Post subject: |
|
|
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.  |
|
| Back to top |
|
|
jathlon
Tux's lil' helper
Joined: 26 Sep 2006
Posts: 89
Location: Canada
|
| Posted: Wed Oct 03, 2012 9:08 pm Post subject: |
|
|
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.
|
|
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54850
Location: 56N 3W
|
| Posted: Wed Oct 03, 2012 9:30 pm Post subject: |
|
|
/me gets ready to drop Gnome when it pulls in systemd
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
grey_dot
Tux's lil' helper
Joined: 15 Jul 2012
Posts: 142
|
| Posted: Wed Oct 03, 2012 10:22 pm Post subject: |
|
|
| 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
critical userland bits they can play leverage games with, the safer we are.
|
|
Not a bad idea after all, but methinks this is unlikely to happen. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9338
|
| Posted: Wed Oct 03, 2012 10:54 pm Post subject: |
|
|
Someone just called for a udev fork if they won't fix it  |
|
| Back to top |
|
|
The Doctor
Moderator
Joined: 27 Jul 2010
Posts: 2678
|
| Posted: Wed Oct 03, 2012 11:23 pm Post subject: |
|
|
| genstorm wrote: | | Someone just called for a udev fork if they won't fix it |
Wait... Isn't that what we have here? 
By the way, its working great with a separate /usr (and /var), root on lvm, and (almost) complete disk encryption. The only minor irritation is that udev-190 is still trying to start alsactl before /usr is mounted. It would be nice if there was something we could do about that, like maybe alter a udev rule or make a package that fixes the rule whenever alsa is re-installed or something?
Anyway, great work on the fork guys. I really appreciate not having upstream try to dictate my partition scheme or try to push me into systemd.
_________________
First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Thu Oct 04, 2012 6:48 am Post subject: |
|
|
| 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.
| Code: | # rc-update delete alsasound
# rc-update add alsasound default |
And the problem, (that has been irritating me too ) went away ! 
_________________
|
|
| Back to top |
|
|
The Doctor
Moderator
Joined: 27 Jul 2010
Posts: 2678
|
| Posted: Thu Oct 04, 2012 7:14 am Post subject: |
|
|
| aCOSwt wrote: | That way, alsactl is not required to run when /var is not yet mounted.
| Code: | # rc-update delete alsasound
# rc-update add alsasound default |
And the problem, (that has been irritating me too ) went away ! |
I did try that already. It seems that did not work for me. 
I wonder what difference is between our setups. The only time I have not noticed this occurring is when an fscheck comes up, then I actually specifically noticed its not being started until /usr is mounted.
As I indicated before I am running udev-190. Are you one of the brave souls testing udev-9999?
_________________
First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
| Back to top |
|
|
grey_dot
Tux's lil' helper
Joined: 15 Jul 2012
Posts: 142
|
| Posted: Thu Oct 04, 2012 9:59 pm Post subject: |
|
|
| aCOSwt wrote: |
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.
| Code: | # rc-update delete alsasound
# rc-update add alsasound default |
And the problem, (that has been irritating me too :wink: ) went away ! 8) |
Well, actually it's udev. Or the rules brought by alsa.
| Code: |
> 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. |
|
| Back to top |
|
|
The Doctor
Moderator
Joined: 27 Jul 2010
Posts: 2678
|
| Posted: Thu Oct 04, 2012 11:19 pm Post subject: |
|
|
| 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.
_________________
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 |
|
|
grey_dot
Tux's lil' helper
Joined: 15 Jul 2012
Posts: 142
|
| Posted: Thu Oct 04, 2012 11:48 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Oct 05, 2012 4:46 am Post subject: |
|
|
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.
_________________
| creaker wrote: | | systemd. It is a really ass pain |
update - "a most excellent portage wrapper"
#friendly-coders -- We're still here for you™ ;) |
|
| Back to top |
|
|
gerard27
Advocate
Joined: 04 Jan 2004
Posts: 2377
Location: Netherlands
|
| Posted: Sat Oct 06, 2012 3:30 pm Post subject: |
|
|
A big Thank You to grey_dot,consus,khayyam et al.
I installed from overlay,everything works out of the box after running revdep-rebuild.
Printer,scanner,wacom tablet,mice (I have 2,wired),sound.
No problem having /usr and /var on separate partitions.
Maybe some native speaker could write a howto.
Anyway thanks again.
Gerard.
_________________
To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Oct 06, 2012 5:20 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
gerard27
Advocate
Joined: 04 Jan 2004
Posts: 2377
Location: Netherlands
|
| Posted: Sat Oct 06, 2012 5:47 pm Post subject: |
|
|
Thanks for the warning khayyam.
Well you contributed a lot I think so that's why I mentioned you.
If this peters out I'll go back to udev-176.
I for one will not have systemd forced down my throat.
Never used initram,why complicate things.
Gerard
_________________
To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9338
|
| Posted: Sat Oct 06, 2012 5:51 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
gerard27
Advocate
Joined: 04 Jan 2004
Posts: 2377
Location: Netherlands
|
| Posted: Sat Oct 06, 2012 6:22 pm Post subject: |
|
|
@genstorm,
AFAIK 176-r6 is the highest version that allows you to have /usr & /var on separate partitions w/o an initram.
Gerard.
_________________
To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download |
|
| Back to top |
|
|
hcaulfield57
Tux's lil' helper
Joined: 13 Mar 2012
Posts: 148
|
| Posted: Sat Oct 06, 2012 8:28 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
grey_dot
Tux's lil' helper
Joined: 15 Jul 2012
Posts: 142
|
| Posted: Mon Oct 08, 2012 4:16 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
grey_dot
Tux's lil' helper
Joined: 15 Jul 2012
Posts: 142
|
| Posted: Mon Oct 08, 2012 4:27 am Post subject: |
|
|
| 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 :) |
|
| Back to top |
|
|
|
Kernel & Hardware
