Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: User

udevd boot messages

 

 

Gentoo user RSS feed   Index | Next | Previous | View Threaded


jmontier at gmail

May 21, 2012, 2:15 AM

Post #1 of 22 (1419 views)
Permalink
udevd boot messages

Hi everybody,

I updated udev from 171-r5 to 171-r6 and now i get several udevd boot
message as :
udevd[1389]: can not find '/lib/udev/rules.d/90-network.rules': No such
file or directory
udevd[1389]: can not find '/lib/udev/rules.d/95-keymap.rules': No such
file or directory
......................
and so on.

/lib is a symlink pointing to /lib64.
/lib64/udev/rules.d is ok with all the rules that udevd does not find at
boot.
Is it because /boot, / and /usr are on separate partitions ?

Thank you for your help.

Best regards,

--
Jacques


gentoo-user at hadt

May 21, 2012, 7:27 AM

Post #2 of 22 (1389 views)
Permalink
Re: udevd boot messages [In reply to]

> I updated udev from 171-r5 to 171-r6 and now i get several udevd boot
> message as :
> udevd[1389]: can not find '/lib/udev/rules.d/90-network.rules': No such
> file or directory
> udevd[1389]: can not find '/lib/udev/rules.d/95-keymap.rules': No such
> file or directory
> ......................
> and so on.
>
> /lib is a symlink pointing to /lib64.
> /lib64/udev/rules.d is ok with all the rules that udevd does not find at
> boot.

No I would guess it was because of the upgrade of sys-apps/baselayout to
2.1-r1. Things got crazy here with that upgrade. I had to re-merge every
package with files under /lib/
In your case re-merging udev should to the trick.


hwoarang at gentoo

May 21, 2012, 2:00 PM

Post #3 of 22 (1389 views)
Permalink
Re: udevd boot messages [In reply to]

On 05/21/2012 03:27 PM, Michael Hampicke wrote:
>> I updated udev from 171-r5 to 171-r6 and now i get several udevd
>> boot message as : udevd[1389]: can not find
>> '/lib/udev/rules.d/90-network.rules': No such file or directory
>> udevd[1389]: can not find '/lib/udev/rules.d/95-keymap.rules': No
>> such file or directory ...................... and so on.
>>
>> /lib is a symlink pointing to /lib64. /lib64/udev/rules.d is ok
>> with all the rules that udevd does not find at boot.
>
> No I would guess it was because of the upgrade of
> sys-apps/baselayout to 2.1-r1. Things got crazy here with that
> upgrade. I had to re-merge every package with files under /lib/ In
> your case re-merging udev should to the trick.
>
The package clearly informed you that you need to reboot for things to
work properly

"You should reboot the system now to get /run mounted with tmpfs!"

Have a look on pkg_postinst() function in that ebuild. You chose to
ignore it and this is why you had these problems after the update.

--
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2


tanstaafl at libertytrek

May 23, 2012, 9:24 AM

Post #4 of 22 (1386 views)
Permalink
Re: udevd boot messages [In reply to]

On 2012-05-21 5:00 PM, Markos Chandras <hwoarang [at] gentoo> wrote:
> On 05/21/2012 03:27 PM, Michael Hampicke wrote:
>>> I updated udev from 171-r5 to 171-r6 and now i get several udevd
>>> boot message as : udevd[1389]: can not find
>>> '/lib/udev/rules.d/90-network.rules': No such file or directory
>>> udevd[1389]: can not find '/lib/udev/rules.d/95-keymap.rules': No
>>> such file or directory ...................... and so on.
>>>
>>> /lib is a symlink pointing to /lib64. /lib64/udev/rules.d is ok
>>> with all the rules that udevd does not find at boot.
>>
>> No I would guess it was because of the upgrade of
>> sys-apps/baselayout to 2.1-r1. Things got crazy here with that
>> upgrade. I had to re-merge every package with files under /lib/ In
>> your case re-merging udev should to the trick.

> The package clearly informed you that you need to reboot for things to
> work properly
>
> "You should reboot the system now to get /run mounted with tmpfs!"
>
> Have a look on pkg_postinst() function in that ebuild. You chose to
> ignore it and this is why you had these problems after the update.

<pet-peeve>
I asked about this a while back but never got a decent answer...

*Especially* for servers, there really, REALLY needs to be a way to see
this kind of warning BEFORE updating... ie, the warning should be
printed to the screen during an 'emerge -pvuDN world' or something, so I
know that a reboot will be required for this update.
</pet-peeve>


wonko at wonkology

May 23, 2012, 9:49 AM

Post #5 of 22 (1386 views)
Permalink
Re: udevd boot messages [In reply to]

Tanstaafl writes:

> *Especially* for servers, there really, REALLY needs to be a way to see
> this kind of warning BEFORE updating... ie, the warning should be
> printed to the screen during an 'emerge -pvuDN world' or something, so
> I know that a reboot will be required for this update.
> </pet-peeve>

Indeed! I think eselect news read should show this, at least.

Wonko


tanstaafl at libertytrek

May 23, 2012, 10:18 AM

Post #6 of 22 (1386 views)
Permalink
Re: udevd boot messages [In reply to]

On 2012-05-23 12:49 PM, Alex Schuster <wonko [at] wonkology> wrote:
> Tanstaafl writes:
>
>> *Especially* for servers, there really, REALLY needs to be a way to see
>> this kind of warning BEFORE updating... ie, the warning should be
>> printed to the screen during an 'emerge -pvuDN world' or something, so
>> I know that a reboot will be required for this update.
>> </pet-peeve>
>
> Indeed! I think eselect news read should show this, at least.

That would work for me... anytime I saw an update for system critical
stuff (like baselayout or udev or openrc) I'd be sure to check things...

As it stands, I'm now very glad for my self imposed policy of waiting a
few days for critical things like this...


hwoarang at gentoo

May 23, 2012, 2:25 PM

Post #7 of 22 (1392 views)
Permalink
Re: udevd boot messages [In reply to]

On 05/23/2012 05:24 PM, Tanstaafl wrote:
> On 2012-05-21 5:00 PM, Markos Chandras <hwoarang [at] gentoo> wrote:
>> On 05/21/2012 03:27 PM, Michael Hampicke wrote:
>>>> I updated udev from 171-r5 to 171-r6 and now i get several udevd
>>>> boot message as : udevd[1389]: can not find
>>>> '/lib/udev/rules.d/90-network.rules': No such file or directory
>>>> udevd[1389]: can not find '/lib/udev/rules.d/95-keymap.rules': No
>>>> such file or directory ...................... and so on.
>>>>
>>>> /lib is a symlink pointing to /lib64. /lib64/udev/rules.d is ok
>>>> with all the rules that udevd does not find at boot.
>>>
>>> No I would guess it was because of the upgrade of
>>> sys-apps/baselayout to 2.1-r1. Things got crazy here with that
>>> upgrade. I had to re-merge every package with files under /lib/ In
>>> your case re-merging udev should to the trick.
>
>> The package clearly informed you that you need to reboot for things to
>> work properly
>>
>> "You should reboot the system now to get /run mounted with tmpfs!"
>>
>> Have a look on pkg_postinst() function in that ebuild. You chose to
>> ignore it and this is why you had these problems after the update.
>
> <pet-peeve>
> I asked about this a while back but never got a decent answer...
>
> *Especially* for servers, there really, REALLY needs to be a way to see
> this kind of warning BEFORE updating... ie, the warning should be
> printed to the screen during an 'emerge -pvuDN world' or something, so I
> know that a reboot will be required for this update.
> </pet-peeve>
>
This kind of messages are also printed at the end of -uDNav world so if
you scroll your screen up you can see all the warning/log messages from
every package that you have updated. Also, these kind of messages are
logged in /var/log/portage/

--
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2


alan.mckinnon at gmail

May 23, 2012, 2:47 PM

Post #8 of 22 (1384 views)
Permalink
Re: udevd boot messages [In reply to]

On Wed, 23 May 2012 22:25:37 +0100
Markos Chandras <hwoarang [at] gentoo> wrote:

> On 05/23/2012 05:24 PM, Tanstaafl wrote:
> > On 2012-05-21 5:00 PM, Markos Chandras <hwoarang [at] gentoo> wrote:
> >> On 05/21/2012 03:27 PM, Michael Hampicke wrote:
> >>>> I updated udev from 171-r5 to 171-r6 and now i get several udevd
> >>>> boot message as : udevd[1389]: can not find
> >>>> '/lib/udev/rules.d/90-network.rules': No such file or directory
> >>>> udevd[1389]: can not find '/lib/udev/rules.d/95-keymap.rules': No
> >>>> such file or directory ...................... and so on.
> >>>>
> >>>> /lib is a symlink pointing to /lib64. /lib64/udev/rules.d is ok
> >>>> with all the rules that udevd does not find at boot.
> >>>
> >>> No I would guess it was because of the upgrade of
> >>> sys-apps/baselayout to 2.1-r1. Things got crazy here with that
> >>> upgrade. I had to re-merge every package with files under /lib/ In
> >>> your case re-merging udev should to the trick.
> >
> >> The package clearly informed you that you need to reboot for
> >> things to work properly
> >>
> >> "You should reboot the system now to get /run mounted with tmpfs!"
> >>
> >> Have a look on pkg_postinst() function in that ebuild. You chose to
> >> ignore it and this is why you had these problems after the update.
> >
> > <pet-peeve>
> > I asked about this a while back but never got a decent answer...
> >
> > *Especially* for servers, there really, REALLY needs to be a way to
> > see this kind of warning BEFORE updating... ie, the warning should
> > be printed to the screen during an 'emerge -pvuDN world' or
> > something, so I know that a reboot will be required for this update.
> > </pet-peeve>
> >
> This kind of messages are also printed at the end of -uDNav world so
> if you scroll your screen up you can see all the warning/log messages
> from every package that you have updated. Also, these kind of
> messages are logged in /var/log/portage/

You are missing the point.

Tanstaafl wants to know if a reboot *will* be required *before* he does
the update. What you are describing tells him that after the update
completes when it is already too late.

I face the same issue at work. We have a change policy requiring 14
days advance notice of any change affecting service. If I do a routine
world update then have to log an emergency change for an unexpected
reboot, the change manager will have my nuts for breakfast.

If it happens more than once, I'd be having a really unusual
conversation with the CTO which probably ends with him standing behind
me watching while I migrate every single box that isn't RHEL6 (all 200
of them) over to RHEL6 where I *do* have exact knowledge in advance of
the impact of a change.



--
Alan McKinnnon
alan.mckinnon [at] gmail


hwoarang at gentoo

May 23, 2012, 2:54 PM

Post #9 of 22 (1383 views)
Permalink
Re: udevd boot messages [In reply to]

On 05/23/2012 10:47 PM, Alan McKinnon wrote:
> On Wed, 23 May 2012 22:25:37 +0100
> Markos Chandras <hwoarang [at] gentoo> wrote:
>
>> On 05/23/2012 05:24 PM, Tanstaafl wrote:
>>> On 2012-05-21 5:00 PM, Markos Chandras <hwoarang [at] gentoo> wrote:
>>>> On 05/21/2012 03:27 PM, Michael Hampicke wrote:
>>>>>> I updated udev from 171-r5 to 171-r6 and now i get several udevd
>>>>>> boot message as : udevd[1389]: can not find
>>>>>> '/lib/udev/rules.d/90-network.rules': No such file or directory
>>>>>> udevd[1389]: can not find '/lib/udev/rules.d/95-keymap.rules': No
>>>>>> such file or directory ...................... and so on.
>>>>>>
>>>>>> /lib is a symlink pointing to /lib64. /lib64/udev/rules.d is ok
>>>>>> with all the rules that udevd does not find at boot.
>>>>>
>>>>> No I would guess it was because of the upgrade of
>>>>> sys-apps/baselayout to 2.1-r1. Things got crazy here with that
>>>>> upgrade. I had to re-merge every package with files under /lib/ In
>>>>> your case re-merging udev should to the trick.
>>>
>>>> The package clearly informed you that you need to reboot for
>>>> things to work properly
>>>>
>>>> "You should reboot the system now to get /run mounted with tmpfs!"
>>>>
>>>> Have a look on pkg_postinst() function in that ebuild. You chose to
>>>> ignore it and this is why you had these problems after the update.
>>>
>>> <pet-peeve>
>>> I asked about this a while back but never got a decent answer...
>>>
>>> *Especially* for servers, there really, REALLY needs to be a way to
>>> see this kind of warning BEFORE updating... ie, the warning should
>>> be printed to the screen during an 'emerge -pvuDN world' or
>>> something, so I know that a reboot will be required for this update.
>>> </pet-peeve>
>>>
>> This kind of messages are also printed at the end of -uDNav world so
>> if you scroll your screen up you can see all the warning/log messages
>> from every package that you have updated. Also, these kind of
>> messages are logged in /var/log/portage/
>
> You are missing the point.
>
> Tanstaafl wants to know if a reboot *will* be required *before* he does
> the update. What you are describing tells him that after the update
> completes when it is already too late.
>
> I face the same issue at work. We have a change policy requiring 14
> days advance notice of any change affecting service. If I do a routine
> world update then have to log an emergency change for an unexpected
> reboot, the change manager will have my nuts for breakfast.
>
> If it happens more than once, I'd be having a really unusual
> conversation with the CTO which probably ends with him standing behind
> me watching while I migrate every single box that isn't RHEL6 (all 200
> of them) over to RHEL6 where I *do* have exact knowledge in advance of
> the impact of a change.
>
>
>
Did either of you ever open a bug about this or even discuss it in the
gentoo-dev mailing list? What you say sounds like a valid concern to me
but unless you express your needs to maintainers, nothing is ever going
to happen. However, in this particular case, yes a news item would be
the ideal solution.

--
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2


alan.mckinnon at gmail

May 23, 2012, 3:11 PM

Post #10 of 22 (1383 views)
Permalink
Re: udevd boot messages [In reply to]

On Wed, 23 May 2012 22:54:23 +0100
Markos Chandras <hwoarang [at] gentoo> wrote:

> On 05/23/2012 10:47 PM, Alan McKinnon wrote:
> > On Wed, 23 May 2012 22:25:37 +0100
> > Markos Chandras <hwoarang [at] gentoo> wrote:
> >
> >> On 05/23/2012 05:24 PM, Tanstaafl wrote:
> >>> On 2012-05-21 5:00 PM, Markos Chandras <hwoarang [at] gentoo>
> >>> wrote:
> >>>> On 05/21/2012 03:27 PM, Michael Hampicke wrote:
> >>>>>> I updated udev from 171-r5 to 171-r6 and now i get several
> >>>>>> udevd boot message as : udevd[1389]: can not find
> >>>>>> '/lib/udev/rules.d/90-network.rules': No such file or directory
> >>>>>> udevd[1389]: can not find '/lib/udev/rules.d/95-keymap.rules':
> >>>>>> No such file or directory ...................... and so on.
> >>>>>>
> >>>>>> /lib is a symlink pointing to /lib64. /lib64/udev/rules.d is ok
> >>>>>> with all the rules that udevd does not find at boot.
> >>>>>
> >>>>> No I would guess it was because of the upgrade of
> >>>>> sys-apps/baselayout to 2.1-r1. Things got crazy here with that
> >>>>> upgrade. I had to re-merge every package with files under /lib/
> >>>>> In your case re-merging udev should to the trick.
> >>>
> >>>> The package clearly informed you that you need to reboot for
> >>>> things to work properly
> >>>>
> >>>> "You should reboot the system now to get /run mounted with
> >>>> tmpfs!"
> >>>>
> >>>> Have a look on pkg_postinst() function in that ebuild. You chose
> >>>> to ignore it and this is why you had these problems after the
> >>>> update.
> >>>
> >>> <pet-peeve>
> >>> I asked about this a while back but never got a decent answer...
> >>>
> >>> *Especially* for servers, there really, REALLY needs to be a way
> >>> to see this kind of warning BEFORE updating... ie, the warning
> >>> should be printed to the screen during an 'emerge -pvuDN world' or
> >>> something, so I know that a reboot will be required for this
> >>> update. </pet-peeve>
> >>>
> >> This kind of messages are also printed at the end of -uDNav world
> >> so if you scroll your screen up you can see all the warning/log
> >> messages from every package that you have updated. Also, these
> >> kind of messages are logged in /var/log/portage/
> >
> > You are missing the point.
> >
> > Tanstaafl wants to know if a reboot *will* be required *before* he
> > does the update. What you are describing tells him that after the
> > update completes when it is already too late.
> >
> > I face the same issue at work. We have a change policy requiring 14
> > days advance notice of any change affecting service. If I do a
> > routine world update then have to log an emergency change for an
> > unexpected reboot, the change manager will have my nuts for
> > breakfast.
> >
> > If it happens more than once, I'd be having a really unusual
> > conversation with the CTO which probably ends with him standing
> > behind me watching while I migrate every single box that isn't
> > RHEL6 (all 200 of them) over to RHEL6 where I *do* have exact
> > knowledge in advance of the impact of a change.
> >
> >
> >
> Did either of you ever open a bug about this or even discuss it in the
> gentoo-dev mailing list? What you say sounds like a valid concern to
> me but unless you express your needs to maintainers, nothing is ever
> going to happen. However, in this particular case, yes a news item
> would be the ideal solution.


I haven't opened a bug myself, mostly because I've never been bitten
by this. My Gentoo servers run stable so I've always known from this
list and other places when something requiring a reboot is coming down
the line.

I agree, a news item is the perfect solution. Having portage do it will
be highly cumbersome, it will require some kind of new magic flag in
ebuilds that portage must parse. All that work for something that
doesn't happen often? Nah, it'll never fly.



--
Alan McKinnnon
alan.mckinnon [at] gmail


pandu at poluan

May 23, 2012, 5:55 PM

Post #11 of 22 (1384 views)
Permalink
Re: udevd boot messages [In reply to]

On May 24, 2012 5:19 AM, "Alan McKinnon" <alan.mckinnon [at] gmail> wrote:
>
> On Wed, 23 May 2012 22:54:23 +0100
> Markos Chandras <hwoarang [at] gentoo> wrote:
>

[znip]

> > Did either of you ever open a bug about this or even discuss it in the
> > gentoo-dev mailing list? What you say sounds like a valid concern to
> > me but unless you express your needs to maintainers, nothing is ever
> > going to happen. However, in this particular case, yes a news item
> > would be the ideal solution.
>
>
> I haven't opened a bug myself, mostly because I've never been bitten
> by this. My Gentoo servers run stable so I've always known from this
> list and other places when something requiring a reboot is coming down
> the line.
>

+1

I love this list :-)

In my previous place, I have one 'experimental' server which gets updated
before all others. It's the 'designated fall guy'.

Which reminds me of Project Management 101: What's the first thing you must
do before embarking on a project? Answer: Designate a fall guy and prepare
implicating evidences. ;-)

> I agree, a news item is the perfect solution. Having portage do it will
> be highly cumbersome, it will require some kind of new magic flag in
> ebuilds that portage must parse. All that work for something that
> doesn't happen often? Nah, it'll never fly.
>

Also a heartfelt +1 for this.

That said, I'm going to repost this 'news' to the Gentoo-server list,
unless someone beats me to it.

Rgds,


tanstaafl at libertytrek

May 24, 2012, 2:35 AM

Post #12 of 22 (1385 views)
Permalink
Re: udevd boot messages [In reply to]

On 2012-05-23 5:25 PM, Markos Chandras <hwoarang [at] gentoo> wrote:
> On 05/23/2012 05:24 PM, Tanstaafl wrote:
>> *Especially* for servers, there really, REALLY needs to be a way to see
>> this kind of warning BEFORE updating... ie, the warning should be
>> printed to the screen during an 'emerge -pvuDN world' or something, so I
>> know that a reboot will be required for this update.
>> </pet-peeve>

> This kind of messages are also printed at the end of -uDNav world so if
> you scroll your screen up you can see all the warning/log messages from
> every package that you have updated. Also, these kind of messages are
> logged in/var/log/portage/

Ummm... yes, I know that, I get my elogs via email...

You must have missed the words 'BEFORE updating' above... I put BEFORE
in caps, not sure what else I could have done to make it more plain... ;)


tanstaafl at libertytrek

May 24, 2012, 2:45 AM

Post #13 of 22 (1385 views)
Permalink
Re: udevd boot messages [In reply to]

On 2012-05-23 5:54 PM, Markos Chandras <hwoarang [at] gentoo> wrote:
> On 05/23/2012 10:47 PM, Alan McKinnon wrote:
>> Tanstaafl wants to know if a reboot*will* be required*before* he does
>> the update. What you are describing tells him that after the update
>> completes when it is already too late.
>>
>> I face the same issue at work. We have a change policy requiring 14
>> days advance notice of any change affecting service. If I do a routine
>> world update then have to log an emergency change for an unexpected
>> reboot, the change manager will have my nuts for breakfast.
>>
>> If it happens more than once, I'd be having a really unusual
>> conversation with the CTO which probably ends with him standing behind
>> me watching while I migrate every single box that isn't RHEL6 (all 200
>> of them) over to RHEL6 where I*do* have exact knowledge in advance of
>> the impact of a change.

> Did either of you ever open a bug about this or even discuss it in the
> gentoo-dev mailing list? What you say sounds like a valid concern to me
> but unless you express your needs to maintainers, nothing is ever going
> to happen. However, in this particular case, yes a news item would be
> the ideal solution.

I didn't discuss it on the dev list (I'm not a dev), but I did ask a
question about this, but it was more general in nature (how to get
ewarn/einfo during --pretend):

http://forums.gentoo.org/viewtopic.php?p=5930125#5930125

As a result of that thread, I then opened this bug which was
subsequently closed:

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


mikemol at gmail

May 24, 2012, 4:24 PM

Post #14 of 22 (1403 views)
Permalink
Re: udevd boot messages [In reply to]

On Mon, May 21, 2012 at 5:00 PM, Markos Chandras <hwoarang [at] gentoo> wrote:
> On 05/21/2012 03:27 PM, Michael Hampicke wrote:
>>> I updated udev from 171-r5 to 171-r6 and now i get several udevd
>>>  boot message as : udevd[1389]: can not find
>>> '/lib/udev/rules.d/90-network.rules': No such file or directory
>>> udevd[1389]: can not find '/lib/udev/rules.d/95-keymap.rules': No
>>> such file or directory ...................... and so on.
>>>
>>> /lib is a symlink pointing to /lib64. /lib64/udev/rules.d is ok
>>> with all the rules that udevd does not find at boot.
>>
>> No I would guess it was because of the upgrade of
>> sys-apps/baselayout to 2.1-r1. Things got crazy here with that
>> upgrade. I had to re-merge every package with files under /lib/ In
>>  your case re-merging udev should to the trick.
>>
> The package clearly informed you that you need to reboot for things to
> work properly
>
> "You should reboot the system now to get /run mounted with tmpfs!"
>
> Have a look on pkg_postinst() function in that ebuild. You chose to
> ignore it and this is why you had these problems after the update.

Ok, now I'm coming up on a bind. I've spent the last few days trying
to get my laptop back up to snuff, cycling emerge updates,
revdep-rebuilds and eix-syncs. That particular warning, for me, was
buried in a mountain of ruby and libicu build failures.

I just now started going through /var/log/portage/messages, and was
reminded of this thread.

I just wanted to note that deleting the rules.d directory, and then
only re-emerging udev, strikes me as setting oneself up for more
problems in the future. Turns out, there are a lot of packages on my
system I might want to look at re-emerging. A lot of it belongs to
udev, but a lot of it...doesn't. I'm going to try Jacques's method of
removing the old rules.d folder, and re-emerging the packages equery
identified. Hopefully, I won't see the same boot messages that hit
other people.

saffron rules.d # for pkg in $(ls); do equery b $pkg; done
* Searching for 10-dm.rules ...
sys-fs/lvm2-2.02.88 (/lib/udev/rules.d/10-dm.rules)
* Searching for 11-dm-lvm.rules ...
sys-fs/lvm2-2.02.88 (/lib/udev/rules.d/11-dm-lvm.rules)
* Searching for 13-dm-disk.rules ...
sys-fs/lvm2-2.02.88 (/lib/udev/rules.d/13-dm-disk.rules)
* Searching for 30-kernel-compat.rules ...
sys-fs/udev-171-r6 (/lib/udev/rules.d/30-kernel-compat.rules)
* Searching for 40-gentoo.rules ...
sys-fs/udev-171-r6 (/lib/udev/rules.d/40-gentoo.rules)
* Searching for 42-qemu-usb.rules ...
sys-fs/udev-171-r6 (/lib/udev/rules.d/42-qemu-usb.rules)
* Searching for 50-firmware.rules ...
sys-fs/udev-171-r6 (/lib/udev/rules.d/50-firmware.rules)
* Searching for 50-udev-default.rules ...
sys-fs/udev-171-r6 (/lib/udev/rules.d/50-udev-default.rules)
* Searching for 60-cdrom_id.rules ...
sys-fs/udev-171-r6 (/lib/udev/rules.d/60-cdrom_id.rules)
* Searching for 60-persistent-alsa.rules ...
sys-fs/udev-171-r6 (/lib/udev/rules.d/60-persistent-alsa.rules)
* Searching for 60-persistent-input.rules ...
sys-fs/udev-171-r6 (/lib/udev/rules.d/60-persistent-input.rules)
* Searching for 60-persistent-serial.rules ...
sys-fs/udev-171-r6 (/lib/udev/rules.d/60-persistent-serial.rules)
* Searching for 60-persistent-storage.rules ...
sys-fs/udev-171-r6 (/lib/udev/rules.d/60-persistent-storage.rules)
* Searching for 60-persistent-storage-tape.rules ...
sys-fs/udev-171-r6 (/lib/udev/rules.d/60-persistent-storage-tape.rules)
* Searching for 60-persistent-v4l.rules ...
sys-fs/udev-171-r6 (/lib/udev/rules.d/60-persistent-v4l.rules)
* Searching for 70-libgphoto2.rules ...
media-libs/libgphoto2-2.4.12 (/lib/udev/rules.d/70-libgphoto2.rules)
* Searching for 70-udev-acl.rules ...
sys-auth/consolekit-0.4.5_p20120320 (/lib/udev/rules.d/70-udev-acl.rules)
* Searching for 75-cd-aliases-generator.rules ...
sys-fs/udev-171-r6 (/lib/udev/rules.d/75-cd-aliases-generator.rules)
* Searching for 75-persistent-net-generator.rules ...
sys-fs/udev-171-r6 (/lib/udev/rules.d/75-persistent-net-generator.rules)
* Searching for 75-probe_mtd.rules ...
sys-fs/udev-171-r6 (/lib/udev/rules.d/75-probe_mtd.rules)
* Searching for 77-nm-olpc-mesh.rules ...
net-misc/networkmanager-0.8.4.0-r2 (/lib/udev/rules.d/77-nm-olpc-mesh.rules)
* Searching for 80-drivers.rules ...
sys-fs/udev-171-r6 (/lib/udev/rules.d/80-drivers.rules)
* Searching for 80-udisks.rules ...
sys-fs/udisks-1.0.4-r1 (/lib/udev/rules.d/80-udisks.rules)
* Searching for 90-alsa-restore.rules ...
media-sound/alsa-utils-1.0.25-r1 (/lib/udev/rules.d/90-alsa-restore.rules)
* Searching for 90-network.rules ...
sys-fs/udev-171-r6 (/lib/udev/rules.d/90-network.rules)
* Searching for 95-dm-notify.rules ...
sys-fs/lvm2-2.02.88 (/lib/udev/rules.d/95-dm-notify.rules)
* Searching for 95-udev-late.rules ...
sys-fs/udev-171-r6 (/lib/udev/rules.d/95-udev-late.rules)
* Searching for 95-upower-battery-recall-dell.rules ...
sys-power/upower-0.9.16 (/lib/udev/rules.d/95-upower-battery-recall-dell.rules)
* Searching for 95-upower-battery-recall-fujitsu.rules ...
sys-power/upower-0.9.16
(/lib/udev/rules.d/95-upower-battery-recall-fujitsu.rules)
* Searching for 95-upower-battery-recall-gateway.rules ...
sys-power/upower-0.9.16
(/lib/udev/rules.d/95-upower-battery-recall-gateway.rules)
* Searching for 95-upower-battery-recall-ibm.rules ...
sys-power/upower-0.9.16 (/lib/udev/rules.d/95-upower-battery-recall-ibm.rules)
* Searching for 95-upower-battery-recall-lenovo.rules ...
sys-power/upower-0.9.16
(/lib/udev/rules.d/95-upower-battery-recall-lenovo.rules)
* Searching for 95-upower-battery-recall-toshiba.rules ...
sys-power/upower-0.9.16
(/lib/udev/rules.d/95-upower-battery-recall-toshiba.rules)
* Searching for 95-upower-csr.rules ...
sys-power/upower-0.9.16 (/lib/udev/rules.d/95-upower-csr.rules)
* Searching for 95-upower-hid.rules ...
sys-power/upower-0.9.16 (/lib/udev/rules.d/95-upower-hid.rules)
* Searching for 95-upower-wup.rules ...
sys-power/upower-0.9.16 (/lib/udev/rules.d/95-upower-wup.rules)
* Searching for 99-fuse.rules ...
sys-fs/fuse-2.8.6 (/lib/udev/rules.d/99-fuse.rules)
* Searching for 99-laptop-mode.rules ...
app-laptop/laptop-mode-tools-1.60-r1 (/lib/udev/rules.d/99-laptop-mode.rules)
--
:wq


tanstaafl at libertytrek

May 25, 2012, 4:17 AM

Post #15 of 22 (1371 views)
Permalink
Re: udevd boot messages [In reply to]

On 2012-05-24 7:24 PM, Michael Mol <mikemol [at] gmail> wrote:
> I just now started going through /var/log/portage/messages, and was
> reminded of this thread.

It is much easier if you set up portage to email you these individually...


peterk2 at coolmail

May 25, 2012, 1:13 PM

Post #16 of 22 (1365 views)
Permalink
Re: udevd boot messages [In reply to]

On 2012-05-25 13:17, Tanstaafl wrote:
> On 2012-05-24 7:24 PM, Michael Mol <mikemol [at] gmail> wrote:
>> I just now started going through /var/log/portage/messages, and was
>> reminded of this thread.
>
> It is much easier if you set up portage to email you these individually...
>

app-portage/elogviewer is also nice... :-)

Best regards

Peter K


peter at humphrey

May 25, 2012, 4:52 PM

Post #17 of 22 (1368 views)
Permalink
Re: udevd boot messages [In reply to]

On Friday 25 May 2012 21:13:14 pk wrote:

> app-portage/elogviewer is also nice... :-)

I thought I'd give this a try, but after installing it and its two
dependencies (pygtk and libglade - this is a KDE box) I get this:

$ elogviewer --help
File "/usr/local/bin/elogviewer", line 11
"""
^
SyntaxError: invalid syntax

I messed about with that file but couldn't make the syntax work, so I ran
"emerge -Cav elogviewer" and the file was left behind. Qfile and "equery b
/usr/local/bin/elogviewer" turned nothing up so I deleted the file.

Now, after remerging elogviewer and the two dependencies I get this:

$ elogviewer --help
bash: /usr/local/bin/elogviewer: No such file or directory

What's going on here? Where did that file come from originally, and why
is it not being installed now? I've retrieved it from a backup, but how
did it get in there? It dates from 2007!

Maybe it's just too late at night.

--
Rgds
Peter


mikemol at gmail

May 25, 2012, 7:10 PM

Post #18 of 22 (1366 views)
Permalink
Re: udevd boot messages [In reply to]

On Fri, May 25, 2012 at 7:17 AM, Tanstaafl <tanstaafl [at] libertytrek> wrote:
> On 2012-05-24 7:24 PM, Michael Mol <mikemol [at] gmail> wrote:
>>
>> I just now started going through /var/log/portage/messages, and was
>> reminded of this thread.
>
>
> It is much easier if you set up portage to email you these individually...

The file isn't that difficult. Also, this is a laptop whose only
working network connection is its wifi NIC.

--
:wq


peterk2 at coolmail

May 26, 2012, 1:36 AM

Post #19 of 22 (1359 views)
Permalink
Re: udevd boot messages [In reply to]

On 2012-05-26 01:52, Peter Humphrey wrote:

> $ elogviewer --help
> File "/usr/local/bin/elogviewer", line 11
> """
> ^
> SyntaxError: invalid syntax

Huh? Mine (latest stable 0.5.2-r2, official Gentoo portage - not some
overlay) is installed in /usr/bin/...

Have you changed the install path or installed it through some other means?

Best regards

Peter K


peter at humphrey

May 26, 2012, 2:34 AM

Post #20 of 22 (1360 views)
Permalink
Re: udevd boot messages [In reply to]

On Saturday 26 May 2012 09:36:50 pk wrote:
> On 2012-05-26 01:52, Peter Humphrey wrote:
> > $ elogviewer --help
> > File "/usr/local/bin/elogviewer", line 11
> > """
> > ^
> > SyntaxError: invalid syntax
>
> Huh? Mine (latest stable 0.5.2-r2, official Gentoo portage - not some
> overlay) is installed in /usr/bin/...

So is mine (same version), so I don't know why it's looking in
/usr/local/bin. I have no alias mentioning elogviewer.

$ find /usr -name elogviewer 2> /dev/null
/usr/portage/app-portage/elogviewer
/usr/bin/elogviewer
$

$ grep /local/ /usr/bin/elogviewer
$

> Have you changed the install path or installed it through some other
> means?

Nope. Unless I did something odd in 2007, I suppose. I don't like
mysteries :-(

--
Rgds
Peter
Attachments: emerge.info (4.33 KB)


hwoarang at gentoo

May 26, 2012, 2:37 AM

Post #21 of 22 (1359 views)
Permalink
Re: udevd boot messages [In reply to]

On 05/26/2012 10:34 AM, Peter Humphrey wrote:
> On Saturday 26 May 2012 09:36:50 pk wrote:
>> On 2012-05-26 01:52, Peter Humphrey wrote:
>>> $ elogviewer --help
>>> File "/usr/local/bin/elogviewer", line 11
>>> """
>>> ^
>>> SyntaxError: invalid syntax
>>
>> Huh? Mine (latest stable 0.5.2-r2, official Gentoo portage - not some
>> overlay) is installed in /usr/bin/...
>
> So is mine (same version), so I don't know why it's looking in
> /usr/local/bin. I have no alias mentioning elogviewer.
>
> $ find /usr -name elogviewer 2> /dev/null
> /usr/portage/app-portage/elogviewer
> /usr/bin/elogviewer
> $
>
> $ grep /local/ /usr/bin/elogviewer
> $
>
>> Have you changed the install path or installed it through some other
>> means?
>
> Nope. Unless I did something odd in 2007, I suppose. I don't like
> mysteries :-(
>
Portage *never* installs anything in /usr/local. My best bet is that you
have been experimenting back in 2007 and probably copied the original
file in /usr/local. Remove it and then emerge elogviewer again ;)

--
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2


peter at humphrey

May 26, 2012, 5:48 AM

Post #22 of 22 (1360 views)
Permalink
Re: udevd boot messages [In reply to]

On Saturday 26 May 2012 10:37:38 Markos Chandras wrote:

> Portage *never* installs anything in /usr/local.

Indeed so.

> My best bet is that you have been experimenting back in 2007 and
> probably copied the original file in /usr/local. Remove it and then
> emerge elogviewer again ;)

As I said before, I've already done that - twice or three times now. I
get the same result. Something is apparently causing bash to seek the
file in /usr/local/bin/ instead of in /usr/bin/ .

[OT]
I have a more pressing problem now - someone has hacked into a
supposedly protected part of my website, so I must find what's failed and
fix it, or else find another package. No sleep for the wicked...
[/OT]

--
Rgds
Peter

Gentoo user RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.