FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 09-12-2011, 03:33 PM
Michael Schreckenbauer
 
Default udev + /usr

Hi Alan,

On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote:
> Hi, everybody.
>
> Hope nobody minds me starting a new thread with an accurate name.
>
> Which version of udev is it that has this nauseating feature of needing
> /usr loaded to boot?

> Somewhere in that version's source will be several (or lots of) "/usr".
> Just how difficult is it going to be to replace "/usr/bin" with "/bin"
> throughout the source?

you misunderstood something. udev is able to run arbitrary scripts. Some of
those scripts are located in /usr/* or need something there. I doubt you will
find references to /usr in the udev-sources.

> udev is part of the kernel.

No. udev is usperspace.

> How come the kernel hackers aren't up in
> arms about this as much as we are? Or are they, maybe? In which case,
> maybe the kernel people would welcome an option to disrequire the early
> mounting of /usr as much as we would.
>
> Anyhow, I'd like to take a peek at the source code which does this evil
> thing. Would somebody please tell me which version of udev is involved.

Every udev version works this way.
Fixing udev to continue working with separate /usr is far from trivial imo.
Changing some paths is not the way to go for sure.
First of all, udev has to distinguish between "device not present" and "script
error of some kind". Failing scripts have to be queued somehow for later
execution. If a script keeps failing, it has to be removed from that queue,
with a message to syslog or something like that. If udev needs a script in
/usr/* to mount /usr then there's a chicken-egg-problem, which could be hard
to solve (if possible at all without moving things from /usr/ to /).
Note, that I am wild guessing here, I did not study the udev sources or any
related script/rule

> Thanks.

Best,
Michael
 
Old 09-12-2011, 03:35 PM
Canek Peláez Valdés
 
Default udev + /usr

On Mon, Sep 12, 2011 at 11:02 AM, Alan Mackenzie <acm@muc.de> wrote:
> Hi, everybody.
>
> Hope nobody minds me starting a new thread with an accurate name.
>
> Which version of udev is it that has this nauseating feature of needing
> /usr loaded to boot?
>
> Somewhere in that version's source will be several (or lots of) "/usr".
> Just how difficult is it going to be to replace "/usr/bin" with "/bin"
> throughout the source?
>
> udev is part of the kernel. *How come the kernel hackers aren't up in
> arms about this as much as we are? *Or are they, maybe? *In which case,
> maybe the kernel people would welcome an option to disrequire the early
> mounting of /usr as much as we would.
>
> Anyhow, I'd like to take a peek at the source code which does this evil
> thing. *Would somebody please tell me which version of udev is involved.
>
> Thanks.

(This would be my only post in this new thread: I think I have made my
point of view clear in the other thread).

I have seen a lot of disinformation going on in the other threads
(like some people suggesting that /var would not be able to be on its
own partition at some point in the future). Just before everyone start
to wildy conjecture, please take a look at this:

http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

Also, a look at this thread is maybe justified:

http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/

Both things are in the context of systemd, but it's related to the
discussion at hand. I know not everybody wants to use systemd, and
think Lennart and Kay are the root of all that is wrong and evil on
the world, but I will recommend everyone interested in the reasons of
the push for a recommended initramfs to take a look at the page in
fd.org, and the thread in the systemd mailing list. Even if you don't
agree with the reasoning, it is worth to take a look at it.

As for me, I would say one last time my POV: Linux strives to be much
more than Unix, and that means do things differently. It will always
be capable of do anything that Unix does, and most of the time it will
do it better. But that doesn't (necessarily) means that it will do it
in the same way.

And many of us don't take "but my config/setup/partition works now" as
a valid argument to restrain progress.

Change happens.

Regards everyone.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
 
Old 09-12-2011, 03:59 PM
Michael Schreckenbauer
 
Default udev + /usr

Hi Canek,

On Monday, 12. September 2011 11:35:13 Canek Peláez Valdés wrote:
> (This would be my only post in this new thread: I think I have made my
> point of view clear in the other thread).
>
> I have seen a lot of disinformation going on in the other threads
> (like some people suggesting that /var would not be able to be on its
> own partition at some point in the future). Just before everyone start
> to wildy conjecture, please take a look at this:
>
> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

well, the culprit here is:
"The binaries called from these rules are sometimes located on /usr/bin, or
link against libraries in /usr/lib, or use data files from /usr/share. If these
rules fail udev will proceed with the next one, however later on applications
will then not properly detect these udev devices or features of these
devices."

Why doesn't udev queue failing scripts for later execution? It just assumes
everything is in place in the moment it needs it. This is bad design for a
tool, coming in so early in the boot process.

> Also, a look at this thread is maybe justified:
> http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/

Same thing here. This all basically reads "We did some really bad design
choices, now let's fix the surroundings."
The following sentence really made me laugh:

"> If so, what does LSB say to this new directory?

Nothing really, they just document current common practice. We might
request an update to LSB after it is used for a while and has shown
that it is what we want."

He does not know, if the thing he designed is the thing he wants.
That's ridiculous!

> Change happens.

We already know this.

> Regards everyone.

Best,
Michael
 
Old 09-12-2011, 04:21 PM
Dale
 
Default udev + /usr

Canek Peláez Valdés wrote:

On Mon, Sep 12, 2011 at 11:02 AM, Alan Mackenzie<acm@muc.de> wrote:

Hi, everybody.

Hope nobody minds me starting a new thread with an accurate name.

Which version of udev is it that has this nauseating feature of needing
/usr loaded to boot?

Somewhere in that version's source will be several (or lots of) "/usr".
Just how difficult is it going to be to replace "/usr/bin" with "/bin"
throughout the source?

udev is part of the kernel. How come the kernel hackers aren't up in
arms about this as much as we are? Or are they, maybe? In which case,
maybe the kernel people would welcome an option to disrequire the early
mounting of /usr as much as we would.

Anyhow, I'd like to take a peek at the source code which does this evil
thing. Would somebody please tell me which version of udev is involved.

Thanks.

(This would be my only post in this new thread: I think I have made my
point of view clear in the other thread).

I have seen a lot of disinformation going on in the other threads
(like some people suggesting that /var would not be able to be on its
own partition at some point in the future). Just before everyone start
to wildy conjecture, please take a look at this:

http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

Also, a look at this thread is maybe justified:

http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/

Both things are in the context of systemd, but it's related to the
discussion at hand. I know not everybody wants to use systemd, and
think Lennart and Kay are the root of all that is wrong and evil on
the world, but I will recommend everyone interested in the reasons of
the push for a recommended initramfs to take a look at the page in
fd.org, and the thread in the systemd mailing list. Even if you don't
agree with the reasoning, it is worth to take a look at it.

As for me, I would say one last time my POV: Linux strives to be much
more than Unix, and that means do things differently. It will always
be capable of do anything that Unix does, and most of the time it will
do it better. But that doesn't (necessarily) means that it will do it
in the same way.

And many of us don't take "but my config/setup/partition works now" as
a valid argument to restrain progress.

Change happens.

Regards everyone.


You say it was disinformation about /var. Care to explain why me and
one other person read the same thing? It was mentioned on -dev. I was
pretty sure it was and then another person posted they read the same.
So, I'm almost certain it was said at this point. Surely we can't both
be wrong.


Dale

:-) :-)
 
Old 09-12-2011, 04:42 PM
Canek Peláez Valdés
 
Default udev + /usr

On Mon, Sep 12, 2011 at 12:21 PM, Dale <rdalek1967@gmail.com> wrote:
> Canek Peláez Valdés wrote:
>>
>> On Mon, Sep 12, 2011 at 11:02 AM, Alan Mackenzie<acm@muc.de> *wrote:
>>>
>>> Hi, everybody.
>>>
>>> Hope nobody minds me starting a new thread with an accurate name.
>>>
>>> Which version of udev is it that has this nauseating feature of needing
>>> /usr loaded to boot?
>>>
>>> Somewhere in that version's source will be several (or lots of) "/usr".
>>> Just how difficult is it going to be to replace "/usr/bin" with "/bin"
>>> throughout the source?
>>>
>>> udev is part of the kernel. *How come the kernel hackers aren't up in
>>> arms about this as much as we are? *Or are they, maybe? *In which case,
>>> maybe the kernel people would welcome an option to disrequire the early
>>> mounting of /usr as much as we would.
>>>
>>> Anyhow, I'd like to take a peek at the source code which does this evil
>>> thing. *Would somebody please tell me which version of udev is involved.
>>>
>>> Thanks.
>>
>> (This would be my only post in this new thread: I think I have made my
>> point of view clear in the other thread).
>>
>> I have seen a lot of disinformation going on in the other threads
>> (like some people suggesting that /var would not be able to be on its
>> own partition at some point in the future). Just before everyone start
>> to wildy conjecture, please take a look at this:
>>
>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>>
>> Also, a look at this thread is maybe justified:
>>
>> http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/
>>
>> Both things are in the context of systemd, but it's related to the
>> discussion at hand. I know not everybody wants to use systemd, and
>> think Lennart and Kay are the root of all that is wrong and evil on
>> the world, but I will recommend everyone interested in the reasons of
>> the push for a recommended initramfs to take a look at the page in
>> fd.org, and the thread in the systemd mailing list. Even if you don't
>> agree with the reasoning, it is worth to take a look at it.
>>
>> As for me, I would say one last time my POV: Linux strives to be much
>> more than Unix, and that means do things differently. It will always
>> be capable of do anything that Unix does, and most of the time it will
>> do it better. But that doesn't (necessarily) means that it will do it
>> in the same way.
>>
>> And many of us don't take "but my config/setup/partition works now" as
>> a valid argument to restrain progress.
>>
>> Change happens.
>>
>> Regards everyone.
>
> You say it was disinformation about /var. *Care to explain why me and one
> other person read the same thing? *It was mentioned on -dev. *I was pretty
> sure it was and then another person posted they read the same. *So, I'm
> almost certain it was said at this point. *Surely we can't both be wrong.

Where did you guys read it? Who said /var could not be in its own
partition anymore? What piece of code stops working if /var it's in
its own partition? Who is proposing that a separated /var will not be
supported in the future?

The thread I post talks about /var/run and /var/lock needing to be
symbolic links to /run and /lock, but AFAIK (and I tend to follow this
sort of things) /var not only can be in its own partition, it is the
recommended setup.

Saying that proposing /run and /lock to be available at boot time
means that in the future a separated /var partition could be not
supported is, in my book, disinformation. /var/run and /var/lock (by
definition) are almost empty (in space). /var/lib usually stores whole
databases. The difference is important and relevant.

Damn, this list is like crack.

Regards everyone.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
 
Old 09-12-2011, 04:52 PM
Michael Schreckenbauer
 
Default udev + /usr

On Monday, 12. September 2011 12:42:00 Canek Peláez Valdés wrote:
> On Mon, Sep 12, 2011 at 12:21 PM, Dale <rdalek1967@gmail.com> wrote:
> > You say it was disinformation about /var. Care to explain why me and
> > one
> > other person read the same thing? It was mentioned on -dev. I was
> > pretty sure it was and then another person posted they read the same.
> > So, I'm almost certain it was said at this point. Surely we can't
> > both be wrong.
> Where did you guys read it? Who said /var could not be in its own
> partition anymore? What piece of code stops working if /var it's in
> its own partition? Who is proposing that a separated /var will not be
> supported in the future?

Just have a look in /var/lib/* for example.
You guarantee, that nothing of this stuff is or will be needed by udev?

> The thread I post talks about /var/run and /var/lock needing to be
> symbolic links to /run and /lock, but AFAIK (and I tend to follow this
> sort of things) /var not only can be in its own partition, it is the
> recommended setup.

Yes. Until this dev has his next brilliant idea.

> Saying that proposing /run and /lock to be available at boot time
> Damn, this list is like crack.

For sure

> Regards everyone.

Best,
Michael
 
Old 09-12-2011, 04:55 PM
Michael Mol
 
Default udev + /usr

On Mon, Sep 12, 2011 at 12:42 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Mon, Sep 12, 2011 at 12:21 PM, Dale <rdalek1967@gmail.com> wrote:
>> Canek Peláez Valdés wrote:
>>>
>>> On Mon, Sep 12, 2011 at 11:02 AM, Alan Mackenzie<acm@muc.de> *wrote:
>>>>
>>>> Hi, everybody.
>>>>
>>>> Hope nobody minds me starting a new thread with an accurate name.
>>>>
>>>> Which version of udev is it that has this nauseating feature of needing
>>>> /usr loaded to boot?
>>>>
>>>> Somewhere in that version's source will be several (or lots of) "/usr".
>>>> Just how difficult is it going to be to replace "/usr/bin" with "/bin"
>>>> throughout the source?
>>>>
>>>> udev is part of the kernel. *How come the kernel hackers aren't up in
>>>> arms about this as much as we are? *Or are they, maybe? *In which case,
>>>> maybe the kernel people would welcome an option to disrequire the early
>>>> mounting of /usr as much as we would.
>>>>
>>>> Anyhow, I'd like to take a peek at the source code which does this evil
>>>> thing. *Would somebody please tell me which version of udev is involved.
>>>>
>>>> Thanks.
>>>
>>> (This would be my only post in this new thread: I think I have made my
>>> point of view clear in the other thread).
>>>
>>> I have seen a lot of disinformation going on in the other threads
>>> (like some people suggesting that /var would not be able to be on its
>>> own partition at some point in the future). Just before everyone start
>>> to wildy conjecture, please take a look at this:
>>>
>>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>>>
>>> Also, a look at this thread is maybe justified:
>>>
>>> http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/
>>>
>>> Both things are in the context of systemd, but it's related to the
>>> discussion at hand. I know not everybody wants to use systemd, and
>>> think Lennart and Kay are the root of all that is wrong and evil on
>>> the world, but I will recommend everyone interested in the reasons of
>>> the push for a recommended initramfs to take a look at the page in
>>> fd.org, and the thread in the systemd mailing list. Even if you don't
>>> agree with the reasoning, it is worth to take a look at it.
>>>
>>> As for me, I would say one last time my POV: Linux strives to be much
>>> more than Unix, and that means do things differently. It will always
>>> be capable of do anything that Unix does, and most of the time it will
>>> do it better. But that doesn't (necessarily) means that it will do it
>>> in the same way.
>>>
>>> And many of us don't take "but my config/setup/partition works now" as
>>> a valid argument to restrain progress.
>>>
>>> Change happens.
>>>
>>> Regards everyone.
>>
>> You say it was disinformation about /var. *Care to explain why me and one
>> other person read the same thing? *It was mentioned on -dev. *I was pretty
>> sure it was and then another person posted they read the same. *So, I'm
>> almost certain it was said at this point. *Surely we can't both be wrong.
>
> Where did you guys read it? Who said /var could not be in its own
> partition anymore? What piece of code stops working if /var it's in
> its own partition? Who is proposing that a separated /var will not be
> supported in the future?
>
> The thread I post talks about /var/run and /var/lock needing to be
> symbolic links to /run and /lock, but AFAIK (and I tend to follow this
> sort of things) /var not only can be in its own partition, it is the
> recommended setup.
>
> Saying that proposing /run and /lock to be available at boot time
> means that in the future a separated /var partition could be not
> supported is, in my book, disinformation. /var/run and /var/lock (by
> definition) are almost empty (in space). /var/lib usually stores whole
> databases. The difference is important and relevant.
>
> Damn, this list is like crack.

http://xkcd.com/386/


--
:wq
 
Old 09-12-2011, 05:17 PM
Alan Mackenzie
 
Default udev + /usr

Hi, Michael.

On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote:
> Hi Alan,

> On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote:

> > Hope nobody minds me starting a new thread with an accurate name.

> > Which version of udev is it that has this nauseating feature of needing
> > /usr loaded to boot?

> > Somewhere in that version's source will be several (or lots of) "/usr".
> > Just how difficult is it going to be to replace "/usr/bin" with "/bin"
> > throughout the source?

> you misunderstood something. udev is able to run arbitrary scripts. Some of
> those scripts are located in /usr/* or need something there. I doubt you will
> find references to /usr in the udev-sources.

Well, I'm a hacker. udev is free source, therefore fair game. I don't
intend to put up with this nonsense without a fight. As far as I can
make out, this is just one guy, Kay Sievers, who's on a power trip. Are
there any indications at all that he actually talked to anybody in the
wide world before making such a far reaching decision?

On my current system, udev (164-r2) works without an earlily loaded /usr.
Seemingly, later versions don't. That was why I was asking for somebody
to identify one of these later versions for me.

> > udev is part of the kernel.

> No. udev is usperspace.

OK, udev is in userspace, _very_ _close_ to the kernel. ;-)

> > How come the kernel hackers aren't up in arms about this as much as
> > we are? Or are they, maybe? In which case, maybe the kernel people
> > would welcome an option to disrequire the early mounting of /usr as
> > much as we would.

> > Anyhow, I'd like to take a peek at the source code which does this evil
> > thing. Would somebody please tell me which version of udev is involved.

> Every udev version works this way.

My udev (164-r2) is just fine at the moment. I'm not sure what you mean
by that statement.

> Fixing udev to continue working with separate /usr is far from trivial imo.
> Changing some paths is not the way to go for sure.

Maybe, maybe not. But it seems a changing of paths (/ -> /usr) is
precisely what is breaking newer udevs. It might be possible to change
them back. This could involve moving a fair amount of stuff from /usr to
/, but not half as much as moving the entire /usr partition.

> First of all, udev has to distinguish between "device not present" and "script
> error of some kind". Failing scripts have to be queued somehow for later
> execution. If a script keeps failing, it has to be removed from that queue,
> with a message to syslog or something like that. If udev needs a script in
> /usr/* to mount /usr then there's a chicken-egg-problem, which could be hard
> to solve (if possible at all without moving things from /usr/ to /).
> Note, that I am wild guessing here, I did not study the udev sources or any
> related script/rule

This sounds like a separate (if related) problem.

> > Thanks.

> Best,
> Michael

--
Alan Mackenzie (Nuremberg, Germany).
 
Old 09-12-2011, 05:39 PM
Michael Mol
 
Default udev + /usr

On Mon, Sep 12, 2011 at 1:17 PM, Alan Mackenzie <acm@muc.de> wrote:
> On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote:
>> On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote:
>
>> > Hope nobody minds me starting a new thread with an accurate name.
>
>> > Which version of udev is it that has this nauseating feature of needing
>> > /usr loaded to boot?
>
>> > Somewhere in that version's source will be several (or lots of) "/usr".
>> > Just how difficult is it going to be to replace "/usr/bin" with "/bin"
>> > throughout the source?
>
>> you misunderstood something. udev is able to run arbitrary scripts. Some of
>> those scripts are located in /usr/* or need something there. I doubt you will
>> find references to /usr in the udev-sources.
>
> Well, I'm a hacker. *udev is free source, therefore fair game. *I don't
> intend to put up with this nonsense without a fight. *As far as I can
> make out, this is just one guy, Kay Sievers, who's on a power trip. *Are
> there any indications at all that he actually talked to anybody in the
> wide world before making such a far reaching decision?

udev has always been able to run arbitrary scripts. The trouble is
that the arbitrary scripts other packages provide sometimes call for
things under /usr.

If I've read messages over the last couple days correctly, I think the
recent change is that some stuff udev *directly* depends on, as part
of the udev package itself, is being moved into /usr.

My best guess is that this allows udev to force the issue; it gets
blamed for other packages not loading correctly (when those other
packages put things in places which may or may not be available yet),
so the udev developer chose to force systems to have all of /usr
available before udev is run.

The first step in a clean solution, IMO, is to revert that change. The
second step is to fix the 'silent failure' problem for packages which
depend on /usr before /usr is available.

You might do it with a dependency tree which would control the order
things are done, but some packages may not be able to know what they
depend on. (take dhcpd, for example; it doesn't know what kind of
weird magic someone else put in exit-hooks)

Another solution would be to have a retry queue like what
Schreckenbauer (sorry; too many Mikes) was suggesting. It might be
difficult to discern a rulescript failure that stems from another rule
needing to be run first versus a rulescript failure that stems from,
e.g. a syntax error.

--
:wq
 
Old 09-12-2011, 05:50 PM
Michael Schreckenbauer
 
Default udev + /usr

Hi Alan,

On Monday, 12. September 2011 17:17:37 Alan Mackenzie wrote:
> Hi, Michael.
>
> On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote:
> > Hi Alan,
> >
> > On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote:
> > > Hope nobody minds me starting a new thread with an accurate name.
> > >
> > > Which version of udev is it that has this nauseating feature of
> > > needing
> > > /usr loaded to boot?
> > >
> > > Somewhere in that version's source will be several (or lots of)
> > > "/usr".
> > > Just how difficult is it going to be to replace "/usr/bin" with
> > > "/bin"
> > > throughout the source?
> >
> > you misunderstood something. udev is able to run arbitrary scripts. Some
> > of those scripts are located in /usr/* or need something there. I doubt
> > you will find references to /usr in the udev-sources.
>
> Well, I'm a hacker. udev is free source, therefore fair game. I don't
> intend to put up with this nonsense without a fight. As far as I can
> make out, this is just one guy, Kay Sievers, who's on a power trip. Are
> there any indications at all that he actually talked to anybody in the
> wide world before making such a far reaching decision?
> On my current system, udev (164-r2) works without an earlily loaded /usr.
> Seemingly, later versions don't. That was why I was asking for somebody
> to identify one of these later versions for me.

it works for you, because your udev-rules need nothing from /usr/*
It's *not* udev requiring /usr, it's the scripts triggered by the rules.

> > > udev is part of the kernel.
> >
> > No. udev is usperspace.
>
> OK, udev is in userspace, _very_ _close_ to the kernel. ;-)
>
> > > How come the kernel hackers aren't up in arms about this as much as
> > > we are? Or are they, maybe? In which case, maybe the kernel people
> > > would welcome an option to disrequire the early mounting of /usr as
> > > much as we would.
> > >
> > > Anyhow, I'd like to take a peek at the source code which does this
> > > evil
> > > thing. Would somebody please tell me which version of udev is
> > > involved.>
> > Every udev version works this way.
>
> My udev (164-r2) is just fine at the moment. I'm not sure what you mean
> by that statement.

It works for you.
Every udev-version I know of, is able to run any script you like it to.

> > Fixing udev to continue working with separate /usr is far from trivial
> > imo. Changing some paths is not the way to go for sure.
>
> Maybe, maybe not.

No, I wrote "for sure", because I *know* this.

> But it seems a changing of paths (/ -> /usr) is
> precisely what is breaking newer udevs.

No, it is *not*

> It might be possible to change
> them back. This could involve moving a fair amount of stuff from /usr to
> /, but not half as much as moving the entire /usr partition.

Again, udev can run arbitrary scripts.

> > First of all, udev has to distinguish between "device not present" and
> > "script error of some kind". Failing scripts have to be queued somehow
> > for later execution. If a script keeps failing, it has to be removed
> > from that queue, with a message to syslog or something like that. If
> > udev needs a script in /usr/* to mount /usr then there's a
> > chicken-egg-problem, which could be hard to solve (if possible at all
> > without moving things from /usr/ to /). Note, that I am wild guessing
> > here, I did not study the udev sources or any related script/rule
>
> This sounds like a separate (if related) problem.

No, this *is* the problem.Canek has posted some links in the other thread,
some other guy, I have forgotten who it was, posted others. If interested read
them. I really don't want to offend you, but unless you understand, how things
work and what the problem is, don't waste your time looking at udev's sources.

Best,
Michael
 

Thread Tools




All times are GMT. The time now is 01:50 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org