Problem with udev and ethX naming in latest Fedora 19.
I'm having all sorts of trouble trying to get udev to rename
my interfaces based on MAC address. Please don't suggest
I use biosdevname or other such things: I really do want names
to be ethX and I want them in a specific order base on MAC address.
[root@localhost ~]# cat /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{address}==00:e0:ed:1c:ec:e4,
ATTR{dev_id}==0x0, ATTR{type}==1, NAME=eth2
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{address}==00:e0:ed:1c:ec:e5,
ATTR{dev_id}==0x0, ATTR{type}==1, NAME=eth3
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{address}==00:30:48:fc:17:a2,
ATTR{dev_id}==0x0, ATTR{type}==1, NAME=eth0
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{address}==00:30:48:fc:17:a3,
ATTR{dev_id}==0x0, ATTR{type}==1, NAME=eth1
If I change the NAME=ethX to NAME=ethXr, then it seems to work. But, if I
leave it as is above,
it does not appear to make any changes at all to the naming. I turned on
debugging:
[root@localhost ~]# cat /etc/udev/udev.conf
# see udev(7) for details
udev_log=debug
But, I never see anything at all about 'ethX'.
I do not see any errors in /var/log/messages about it failing to rename due to
'File Exists'.
I read this thread about similar issue in Fedora 18, but towards the bottom,
there is
a claim the bug was fixed. Maybe it came back?
http://comments.gmane.org/gmane.linux.redhat.fedora.general/427615
[root@localhost ~]# rpm -qa|grep systemd
systemd-python-204-9.fc19.x86_64
systemd-204-9.fc19.x86_64
systemd-libs-204-9.fc19.x86_64
systemd-sysv-204-9.fc19.x86_64
I'd be grateful for any help..Fedora 17 has become unstable for us due to
gnome-fallback mode crashing,
so I'd like to be able to move forward to Fedora 19, but I really have to get
udev working properly
first...
Thanks,
Ben
--
Ben Greear gree...@candelatech.com
Candela Technologies Inc http://www.candelatech.com
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Re: Slow initialization of something during boot
On 15.08.2013 01:53, Frank wrote: On 08/14/2013 07:02 PM, poma wrote: To opt out of the equation an Xorg driver for Intel integrated graphics chipsets - man 4 intel, you can try the following: /boot/grub2/grub.cfg linux …nomodeset Didn't work - put me into Vesa mode I guess but the delay remains For further testing, you can also try the following: systemctl mask accounts-daemon.service Ditto. Delay remains And of course, perform tests gradually s'il vous plaît, so can be seen where the bunny is - 1st intel, 2nd accountsservice, … You must be running out of ideas by now :) Regards Frank :) 3rd: - without -background none in /etc/lightdm/lightdm.conf i.e. xserver-command=X - comment all directives in /etc/lightdm/lightdm-gtk-greeter.conf i.e. # background=… # theme-name=… # icon-theme-name=… # font-name=… etc. 4th: - remove rhgb quiet and - add plymouth.enable=0 in /boot/grub2/grub.cfg i.e. linux … plymouth.enable=0 5th: cp /usr/lib/systemd/system/lightdm.service /etc/systemd/system - add 10s delay in /etc/systemd/system/lightdm.service i.e. … [Service] ExecStartPre=/usr/bin/sleep 10 ExecStart=/usr/sbin/lightdm … - enable it i.e. systemctl enable lightdm.service --force If it works, and those 10s show as the only delay, you can try to lower the value of it. poma -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Problem with udev and ethX naming in latest Fedora 19.
On 15.08.2013 08:11, Ben Greear wrote:
I'm having all sorts of trouble trying to get udev to rename
my interfaces based on MAC address. Please don't suggest
I use biosdevname or other such things: I really do want names
to be ethX and I want them in a specific order base on MAC address.
[root@localhost ~]# cat /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:e0:ed:1c:ec:e4, ATTR{dev_id}==0x0,
ATTR{type}==1, NAME=eth2
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:e0:ed:1c:ec:e5, ATTR{dev_id}==0x0,
ATTR{type}==1, NAME=eth3
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:30:48:fc:17:a2, ATTR{dev_id}==0x0,
ATTR{type}==1, NAME=eth0
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:30:48:fc:17:a3, ATTR{dev_id}==0x0,
ATTR{type}==1, NAME=eth1
If I change the NAME=ethX to NAME=ethXr, then it seems to work. But, if
I leave it as is above,
it does not appear to make any changes at all to the naming. I turned
on debugging:
[root@localhost ~]# cat /etc/udev/udev.conf
# see udev(7) for details
udev_log=debug
But, I never see anything at all about 'ethX'.
I do not see any errors in /var/log/messages about it failing to rename
due to 'File Exists'.
I read this thread about similar issue in Fedora 18, but towards the
bottom, there is
a claim the bug was fixed. Maybe it came back?
http://comments.gmane.org/gmane.linux.redhat.fedora.general/427615
[root@localhost ~]# rpm -qa|grep systemd
systemd-python-204-9.fc19.x86_64
systemd-204-9.fc19.x86_64
systemd-libs-204-9.fc19.x86_64
systemd-sysv-204-9.fc19.x86_64
I'd be grateful for any help..Fedora 17 has become unstable for us due
to gnome-fallback mode crashing,
so I'd like to be able to move forward to Fedora 19, but I really have
to get udev working properly
first...
Thanks,
Ben
Last time I checked, the lan alias should do, i.e. lan0, lan1, …, but
not the eth one.[1]
However I leave rename to systemd.
lspci
01:09.0 Ethernet controller:
ifconfig
enp1s9:
dmesg
systemd-udevd: renamed network interface eth0 to enp1s9
If you contemplate it from the perspective of the NetworkManager/nmcli
you'll understand. ;)
poma
[1]
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Re: Fedora to Android
Ralf Corsepius wrote: I'd like to transfer a directory of personal information (not just contacts) from my Fedora-19/KDE laptop to my Samsung Galaxy S2 android phone. What is the best way currently to do this? I'd prefer if possible to use rsync. Like I said in reply to another similar mail before, I am using SSHelper for exactly this kind of jobs (rsync). I tried the various suggestions I received, but SSHelper seemed easily the best. It is rather awkward to install - it does not seem to appear in (Google) Play Store on my phone, but I followed the installation (and other) instructions at http://arachnoid.com/android/SSHelper/. Now I have a very clear view of the filesystem on my phone, and I can edit and add files on the phone from my Fedora laptop. The only thing I am missing is a method to read and edit files on the phone. If I click on the Terminal icon in SSHelper I get the message sh: can't access tty; job control turned off which I don't understand. Is there a standard way to turn job control on? Has anyone a favourite app for reading/editing text files on an Android phone? -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 School of Mathematics, Trinity College, Dublin 2, Ireland -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Fedora to Android
On 08/15/2013 11:30 AM, Timothy Murphy wrote: Ralf Corsepius wrote: I'd like to transfer a directory of personal information (not just contacts) from my Fedora-19/KDE laptop to my Samsung Galaxy S2 android phone. What is the best way currently to do this? I'd prefer if possible to use rsync. Like I said in reply to another similar mail before, I am using SSHelper for exactly this kind of jobs (rsync). I tried the various suggestions I received, but SSHelper seemed easily the best. It is rather awkward to install - Not for me. I installed it the normal way via Play Store. it does not seem to appear in (Google) Play Store on my phone, It does so on my phone's (Galaxy S2+/Android 4.2.2), my wife's phone's (Galaxy S2+/Android 4.1.2) and our low-end couch-surfing tablet (Acer Iconia B1-A71/Android 4.1.2) play store. but I followed the installation (and other) instructions at http://arachnoid.com/android/SSHelper/. Now I have a very clear view of the filesystem on my phone, and I can edit and add files on the phone from my Fedora laptop. I am using SSHelper primarily to ssh and rsync from my fedora boxes into the android devices via WLAN/WiFi. Works without any problems. The built-in vi also seems to work via ssh, but I haven't really used it, yet. The only thing I am missing is a method to read and edit files on the phone. If I click on the Terminal icon in SSHelper I get the message sh: can't access tty; job control turned off which I don't understand. I am seeing the same. The terminal doesn't work for me, either. Is there a standard way to turn job control on? Has anyone a favourite app for reading/editing text files on an Android phone? Ralf -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Problem with udev and ethX naming in latest Fedora 19.
Am 15.08.2013 08:11, schrieb Ben Greear: I'm having all sorts of trouble trying to get udev to rename my interfaces based on MAC address. Please don't suggest I use biosdevname or other such things: I really do want names to be ethX and I want them in a specific order base on MAC address. [root@localhost ~]# cat /etc/udev/rules.d/70-persistent-net.rules is no longer used here you go, but in case of *four* network cards you may consider rename them to lan0, lan1, lan2, lan3 to avoid the race-condition kernel-naming / renaming which is the reason that biosdevname and all this unholy crap was introduced instead go away from eth as udev-default but let it be a option wherever it works cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 HWADDR=24:be:05:1a:c0:27 [root@srv-rhsoft:~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth1 DEVICE=eth1 HWADDR=68:05:ca:0d:62:c1 signature.asc Description: OpenPGP digital signature -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Problem with udev and ethX naming in latest Fedora 19.
On Wed, 14 Aug 2013 23:11:04 -0700 Ben Greear gree...@candelatech.com wrote: I'm having all sorts of trouble trying to get udev to rename my interfaces based on MAC address. Please don't suggest I use biosdevname or other such things: I really do want names to be ethX and I want them in a specific order base on MAC address. Also try net.iframes=0 on the kernel line: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ -- Regards, Frank When in doubt PANIC! I check for new mail app. 20min www.frankly3d.com -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Problem with udev and ethX naming in latest Fedora 19.
On 08/15/2013 01:55 AM, poma wrote: On 15.08.2013 08:11, Ben Greear wrote: Last time I checked, the lan alias should do, i.e. lan0, lan1, …, but not the eth one.[1] However I leave rename to systemd. lspci 01:09.0 Ethernet controller: ifconfig enp1s9: dmesg systemd-udevd: renamed network interface eth0 to enp1s9 If you contemplate it from the perspective of the NetworkManager/nmcli you'll understand. ;) I end up disabling NetworkManager because is has no ability to white-list interfaces and I only would want it messing with the one 'management' network interface on the system..not the others that I do my own special network configuration upon. http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ I read this, and option 2 to disable it is what I tried. There is no particular reason for it to have trouble renaming the interfaces to ethX, it might just have to do a ethY.rename naming first. udev has been dealing with this for many years successfully, at least up to Fedora 17. Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Problem with udev and ethX naming in latest Fedora 19.
On 08/15/2013 12:56 AM, Reindl Harald wrote: Am 15.08.2013 08:11, schrieb Ben Greear: I'm having all sorts of trouble trying to get udev to rename my interfaces based on MAC address. Please don't suggest I use biosdevname or other such things: I really do want names to be ethX and I want them in a specific order base on MAC address. [root@localhost ~]# cat /etc/udev/rules.d/70-persistent-net.rules is no longer used This page claims that it is, and it partially works..it is just particular about what names you choose for the new names it seems. http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ here you go, but in case of *four* network cards you may consider rename them to lan0, lan1, lan2, lan3 to avoid the race-condition kernel-naming / renaming which is the reason that biosdevname and all this unholy crap was introduced instead go away from eth as udev-default but let it be a option wherever it works cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 HWADDR=24:be:05:1a:c0:27 [root@srv-rhsoft:~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth1 DEVICE=eth1 HWADDR=68:05:ca:0d:62:c1 I have ifcfg-eth0 defined with proper HWADDR, and still that physical port is not always called eth0 when the system boots. I do not have the other NICs defined in ifcfg-ethX files. Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Problem with udev and ethX naming in latest Fedora 19.
On 08/15/2013 06:49 AM, Reindl Harald wrote: I have ifcfg-eth0 defined with proper HWADDR, and still that physical port is not always called eth0 when the system boots. I do not have the other NICs defined in ifcfg-ethX files and you did read what i said? *consider rename them to lan0, lan1, lan2, lan3 to avoid the race-condition kernel-naming / renaming * Yes, and I considered it, but I do not want my networks named like that. I've been using ethX in my application and products for more than a decade, and do not want to change the naming scheme if at all possible. with 4 NIC's this was never predictable and mostly luck the only stupid thing is that this this new crap names also appear if there is only one NIC or at least only identical ones with the same driver what makes race-conditions unlikely I understand why the names come up jumbled on bootup, but there is no excuse for udev not being able to properly rename them as requested. Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: More antivirus talk - comodo antivirus for linux
On 08/15/2013 12:52 AM, Jatin K wrote: On Thursday 15 August 2013 03:49 AM, linuxnuts...@videotron.ca wrote: Has anybody heard of this, or even tried it? http://www.comodo.com/home/internet-security/antivirus-for-linux.php Might come in handy for scanning windows partitions Yes ... I'm using it on my Ubuntu machine, as I used to share thumb drives with my friends who are using M$ os. obviously I don't need to protect my Linux machine, I've installed it to test it, it works like charm and clears virus from drives ?? Warm Regards That's what I wanted to know. I actually installed it and it started finding malware in windows backups I made from another machine. Look good so far -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: More antivirus talk - comodo antivirus for linux
On 08/15/2013 08:54 AM, linuxnuts...@videotron.ca wrote: On 08/15/2013 12:52 AM, Jatin K wrote: On Thursday 15 August 2013 03:49 AM, linuxnuts...@videotron.ca wrote: Has anybody heard of this, or even tried it? http://www.comodo.com/home/internet-security/antivirus-for-linux.php Might come in handy for scanning windows partitions Yes ... I'm using it on my Ubuntu machine, as I used to share thumb drives with my friends who are using M$ os. obviously I don't need to protect my Linux machine, I've installed it to test it, it works like charm and clears virus from drives ?? Warm Regards That's what I wanted to know. I actually installed it and it started finding malware in windows backups I made from another machine. Look good so far I use ClamAV. What does Comodo add to the party? Can anyone do a side-by-side review? -- -- Steve -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Problem with udev and ethX naming in latest Fedora 19.
On 08/15/2013 07:18 AM, Reindl Harald wrote: Am 15.08.2013 16:05, schrieb Ben Greear: with 4 NIC's this was never predictable and mostly luck the only stupid thing is that this this new crap names also appear if there is only one NIC or at least only identical ones with the same driver what makes race-conditions unlikely I understand why the names come up jumbled on bootup, but there is no excuse for udev not being able to properly rename them as requested ask Kay Sievers , he is able to explain it to you too in short: the kernel may also rename the devices as they come up if kernel want make one nic to eth1 and udev at the same time another one - collision That's fine. Udev can just detect the collision and try again, potentially moving the other one to a new name. That is what it has done for years, in between bugs that caused eth0.rename devices to be left lying around. Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
systemd-logind unable to create a new session
This is the result of running 'at', but I suspect its not related to 'at' per se. Aug 14 16:00:00 puget systemd-logind[446]: New session 18 of user geoff. Aug 14 16:00:00 puget atd[2098]: Cannot make/remove an entry for the specified session Aug 14 16:00:00 puget systemd-logind[446]: Removed session 18. Environment: Fedora 19, up-to-date. Kernel is 3.10.5-201.fc19.x86_64 #1 SMP -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
use of suspend leads to random unwanted shutdown
Since I use F19, I have toubles with suspend. I do not know if it is really related to F19 because I do not use suspend very often when at home but more often on holidays... What happens: If I use suspend some time and until I turn off the computer completely (i.e. not by using suspend), when the computer is on, it is susceptible to shutdown automatically at any time. Attached is the content of /var/log/messages just before the crash. I can see for example: CPU3: Package temperature above threshold, cpu clock throttled (total events = 1229) Hardware event. This is not a software error. mcelog[528]: MCE 0 mcelog[528]: CPU 3 THERMAL EVENT TSC 43df5e39a80 This seems to indicate that I have troubles with the temperature of my CPU. However, this happens only after suspend, this is why I was wondering if there is anything related to F19 and its kernel (3.10.5-201.fc19.x86_64). Frédéric -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: use of suspend leads to random unwanted shutdown
Sorry, attached is the messages log. Frédéric 2013/8/15 Frédéric Bron frederic.b...@m4x.org: Since I use F19, I have toubles with suspend. I do not know if it is really related to F19 because I do not use suspend very often when at home but more often on holidays... What happens: If I use suspend some time and until I turn off the computer completely (i.e. not by using suspend), when the computer is on, it is susceptible to shutdown automatically at any time. Attached is the content of /var/log/messages just before the crash. I can see for example: CPU3: Package temperature above threshold, cpu clock throttled (total events = 1229) Hardware event. This is not a software error. mcelog[528]: MCE 0 mcelog[528]: CPU 3 THERMAL EVENT TSC 43df5e39a80 This seems to indicate that I have troubles with the temperature of my CPU. However, this happens only after suspend, this is why I was wondering if there is anything related to F19 and its kernel (3.10.5-201.fc19.x86_64). messages.bz2 Description: BZip2 compressed data -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Problem with udev and ethX naming in latest Fedora 19.
On 08/15/2013 08:14 AM, Reindl Harald wrote:
Am 15.08.2013 16:53, schrieb Ben Greear:
On 08/15/2013 07:18 AM, Reindl Harald wrote:
Am 15.08.2013 16:05, schrieb Ben Greear:
with 4 NIC's this was never predictable and mostly luck
the only stupid thing is that this this new crap names also appear
if there is only one NIC or at least only identical ones with
the same driver what makes race-conditions unlikely
I understand why the names come up jumbled on bootup, but there is no excuse
for udev not being able to properly rename them as requested
ask Kay Sievers , he is able to explain it to you too
in short:
the kernel may also rename the devices as they come up
if kernel want make one nic to eth1 and udev at the same time another one -
collision
That's fine. Udev can just detect the collision and try again, potentially
moving the other one to a new name. That is what it has done for years,
in between bugs that caused eth0.rename devices to be left lying around.
well complain at the udev/systemd-guys and the ones before who came up with
biosdevname
you know that, i know that, you asked, i gave you an answer
more can hardly do a *user* in this case
I opened a bug against udev..will see if it gets any response.
In the meantime, here is a perl script that will rename. I wasn't sure the
limitations of other rename tools, but perhaps they would have worked fine.
You would use it like this:
lf_ifrename.pl eth0 00:30:48:fc:17:a2
lf_ifrename.pl eth1 00:30:48:fc:17:a3
lf_ifrename.pl eth2 00:e0:ed:1c:ec:e4
lf_ifrename.pl eth3 00:e0:ed:1c:ec:e5
It *should* deal with races and device name conflicts.
Someday I'll make this parse the udev 70-persistent-net.rules file (if it
exists) and use that instead of having to specify the MAC on the command line.
That should kludge around the current udev limitations while being backwards
compat with working udev, and still keeping the configuration all in one
place.
#!/usr/bin/perl
use strict;
my $ignore_err = 1;
my $dev = $ARGV[0];
my $mac = $ARGV[1];
if ((length($mac) == 0) || (length($dev) == 0)) {
print USAGE: lf_ifrename.pl [dev] [mac]\n;
print MAC: $mac DEV: $dev\n;
exit 0;
}
my $emac = `cat /sys/class/net/$dev/address`;
chomp($emac);
if ($emac eq $mac) {
print(rename: Device $dev is already configured properly, mac: $emac\n);
exit 0;
}
my $rdev = ;
# Find existing dev with this MAC.
my @lns = `ls /sys/class/net/*/address`;
my $i;
for ($i = 0; $i@lns; $i++) {
my $ln = $lns[$i];
chomp($ln);
my $addr = `cat $ln`;
chomp($addr);
if ($addr =~ /$mac/i) {
$ln =~ /\/sys\/class\/net\/(\S+)\/address/;
$rdev = $1;
}
}
if ($rdev eq ) {
print ERROR: rename: Could not find network device with address: $mac\n;
exit 1;
}
# Try 10 times, this works around possible races with new devices
# being created..though that should not happen in most cases.
my $mx = 10;
for ($i = 0; $i$mx; $i++) {
if (-e /sys/class/net/$dev/address) {
# Need to change it, first admin down
print Attempting rename of device: $dev to $dev.r\n;
do_cmd(ifdown $dev /dev/null 21, 1);
do_cmd(ip link set dev $dev down /dev/null 21, 1); # Just to be sure
do_cmd(ip link set dev $dev name $dev.r /dev/null 21, 1);
}
# And now rename target device.
print Attempting rename of device: $rdev to $dev\n;
do_cmd(ifdown $rdev /dev/null 21, 1);
do_cmd(ip link set dev $rdev down /dev/null 21, 1); # Just to be sure
do_cmd(ip link set dev $rdev name $dev /dev/null 21, 1);
# Bring up newly renamed device
do_cmd(ifup $dev /dev/null 21, 1);
# And switch names in case if we had to rename a target
# temporarily.
if (-e /sys/class/net/$dev.r/address) {
print Attempting rename of device: $dev.r to $rdev.\n;
do_cmd(ifdown $dev.r /dev/null 21, 1);
do_cmd(ip link set dev $dev.r down /dev/null 21, 1); # Just to be sure
do_cmd(ip link set dev $dev.r name $rdev /dev/null 21, 1);
# Bring up newly renamed device
do_cmd(ifup $rdev /dev/null 21, 1);
}
# Check everything worked...exit peacefully if so.
my $cmac = `cat /sys/class/net/$dev/address`;
chomp($cmac);
if ($cmac eq $mac) {
print(Completed rename of device: Dev: $dev mac: $mac\n);
exit 0;
}
print(Failed to properly rename device, will try again.\n);
}
print(ERROR: Failed to properly rename device, giving up!\n);
exit 1;
sub do_cmd {
my $err = 1;
my $cmd = shift;
my $ok_to_fail = shift;
print($cmd\n);
$err = system($cmd);
if ($err != 0) {
if (!($ok_to_fail || $ignore_err)) {
note(\n\n# FATAL: Command failed, lf_ifrename.pl script is
aborting!!\n);
die($cmd $!\n\n);
}
else {
print # WARNING: Command failed, not fatal: $cmd\n;
}
}
return $err
}
--
Ben Greear gree...@candelatech.com
Candela Technologies Inc http://www.candelatech.com
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
Re: Slow initialization of something during boot
… 5th: cp /usr/lib/systemd/system/lightdm.service /etc/systemd/system - add 10s delay in /etc/systemd/system/lightdm.service i.e. … [Service] ExecStartPre=/usr/bin/sleep 10 ExecStart=/usr/sbin/lightdm … - enable it i.e. systemctl enable lightdm.service --force If it works, and those 10s show as the only delay, you can try to lower the value of it. I've managed to produce a lag via NetworkManager disabled, systemctl status NetworkManager NetworkManager.service - Network Manager Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; disabled) Active: inactive (dead) These are the results of the application of the 'ExecStartPre' directive in the 'lightdm.service' - default - no sleep systemd-analyze blame … 30.903s lightdm.service … /var/log/lightdm/lightdm.log … [+0.04s] DEBUG: Launching X Server … [+30.87s] DEBUG: Greeter connected, display is ready [+30.87s] DEBUG: New display ready, switching to it [+30.87s] DEBUG: Activating VT 1 … - 10s sleep /etc/systemd/system/lightdm.service … ExecStartPre=/usr/bin/sleep 10 … systemd-analyze blame … 10.058s lightdm.service … /var/log/lightdm/lightdm.log … [+0.04s] DEBUG: Launching X Server … [+1.23s] DEBUG: Greeter connected, display is ready [+1.23s] DEBUG: New display ready, switching to it [+1.23s] DEBUG: Activating VT 1 … - 2s sleep /etc/systemd/system/lightdm.service … ExecStartPre=/usr/bin/sleep 2 … systemd-analyze blame … 2.146s lightdm.service … /var/log/lightdm/lightdm.log … [+0.12s] DEBUG: Launching X Server … [+2.88s] DEBUG: Greeter connected, display is ready [+2.88s] DEBUG: New display ready, switching to it [+2.88s] DEBUG: Activating VT 1 … poma -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Slow initialization of something during boot
On 08/15/2013 04:19 AM, poma wrote: On 15.08.2013 01:53, Frank wrote: On 08/14/2013 07:02 PM, poma wrote: To opt out of the equation an Xorg driver for Intel integrated graphics chipsets - man 4 intel, you can try the following: /boot/grub2/grub.cfg linux …nomodeset Didn't work - put me into Vesa mode I guess but the delay remains For further testing, you can also try the following: systemctl mask accounts-daemon.service Ditto. Delay remains And of course, perform tests gradually s'il vous plaît, so can be seen where the bunny is - 1st intel, 2nd accountsservice, … You must be running out of ideas by now :) Regards Frank :) 3rd: - without -background none in /etc/lightdm/lightdm.conf i.e. xserver-command=X - comment all directives in /etc/lightdm/lightdm-gtk-greeter.conf i.e. # background=… # theme-name=… # icon-theme-name=… # font-name=… etc. 4th: - remove rhgb quiet and - add plymouth.enable=0 in /boot/grub2/grub.cfg i.e. linux … plymouth.enable=0 Up to here nothing worked. 5th: cp /usr/lib/systemd/system/lightdm.service /etc/systemd/system - add 10s delay in /etc/systemd/system/lightdm.service i.e. … [Service] ExecStartPre=/usr/bin/sleep 10 ExecStart=/usr/sbin/lightdm … - enable it i.e. systemctl enable lightdm.service --force Haven't done these yet. If it works, and those 10s show as the only delay, you can try to lower the value of it. Regards Frank -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Slow initialization of something during boot
On 08/15/2013 01:58 PM, poma wrote: … 5th: cp /usr/lib/systemd/system/lightdm.service /etc/systemd/system - add 10s delay in /etc/systemd/system/lightdm.service i.e. … [Service] ExecStartPre=/usr/bin/sleep 10 ExecStart=/usr/sbin/lightdm … - enable it i.e. systemctl enable lightdm.service --force If it works, and those 10s show as the only delay, you can try to lower the value of it. I've managed to produce a lag via NetworkManager disabled, systemctl status NetworkManager NetworkManager.service - Network Manager Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; disabled) Active: inactive (dead) These are the results of the application of the 'ExecStartPre' directive in the 'lightdm.service' - default - no sleep systemd-analyze blame … 30.903s lightdm.service … /var/log/lightdm/lightdm.log … [+0.04s] DEBUG: Launching X Server … [+30.87s] DEBUG: Greeter connected, display is ready [+30.87s] DEBUG: New display ready, switching to it [+30.87s] DEBUG: Activating VT 1 … - 10s sleep /etc/systemd/system/lightdm.service … ExecStartPre=/usr/bin/sleep 10 … systemd-analyze blame … 10.058s lightdm.service … /var/log/lightdm/lightdm.log … [+0.04s] DEBUG: Launching X Server … [+1.23s] DEBUG: Greeter connected, display is ready [+1.23s] DEBUG: New display ready, switching to it [+1.23s] DEBUG: Activating VT 1 … - 2s sleep /etc/systemd/system/lightdm.service … ExecStartPre=/usr/bin/sleep 2 … systemd-analyze blame … 2.146s lightdm.service … /var/log/lightdm/lightdm.log … [+0.12s] DEBUG: Launching X Server … [+2.88s] DEBUG: Greeter connected, display is ready [+2.88s] DEBUG: New display ready, switching to it [+2.88s] DEBUG: Activating VT 1 … With all due respect, I don't understand what's going on here---my network manager is not disabled. What effect does adding sleep to lightdm.service produce ?? I think I am missing the point :) Regards Frank -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Undetected Fresco Logic FL1000G USB 3.0 controller in Asus N43SN after replace a motherboard
On 2013-08-12 19:27, poma wrote: On 12.08.2013 13:03, Marcin Zajączkowski wrote: Hi, I had no problem with a USB 3.0 port in my Asus N43SN since I bought a laptop (~2 years). Recently I replaced a motherboard to the new one (N43SL.413 looked the same as the first one) due to a problem with a graphical chipset and after that a USB3 controller stopped to be even detected. $ modinfo -F author xhci-hcd.ko Sarah Sharp http://vger.kernel.org/vger-lists.html#linux-usb Thanks for a hint. Marcin -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Problem with udev and ethX naming in latest Fedora 19.
On Thu, 15 Aug 2013 10:42:03 -0700 Ben Greear gree...@candelatech.com wrote: On 08/15/2013 08:14 AM, Reindl Harald wrote: Am 15.08.2013 16:53, schrieb Ben Greear: On 08/15/2013 07:18 AM, Reindl Harald wrote: Am 15.08.2013 16:05, schrieb Ben Greear: Yes, and I considered it, but I do not want my networks named like that. I've been using ethX in my application and products for more than a decade, and do not want to change the naming scheme if at all possible. [snip] I understand why the names come up jumbled on bootup, but there is no excuse for udev not being able to properly rename them as requested the kernel may also rename the devices as they come up if kernel want make one nic to eth1 and udev at the same time another one - collision That's fine. Udev can just detect the collision and try again, potentially moving the other one to a new name. That is what it has done for years, in between bugs that caused eth0.rename devices to be left lying around. well complain at the udev/systemd-guys and the ones before who came up with biosdevname you know that, i know that, you asked, i gave you an answer more can hardly do a *user* in this case I opened a bug against udev..will see if it gets any response. Bugzilla link please? Btw, I doubt that you'll be taken seriously enough. I can bet that the devs are going to argue like this: if your software makes explicit use of the eth# NIC naming, it is broken to begin with. Fix your software, and that will remove the need for your complaint. I remember seeing this argument before --- this was one of the reasons why the biosdevname NIC names were designed as p#p# and em#, while ignoring the traditional eth naming. I cannot find any of the links now, but all discussions were basically like this: User: Why this stupid p#p# numbering scheme? Couldn't you use eth# instead? Dev: There is no way to name the NIC's in a linear way, so eth# names are unsuitable. User: But can't you at least make aliases from p#p# to eth# in udev? Dev: There is no way to do that uniquely either, so we won't do it. User: But my firewall rules are all written up using eth# names, and now they are broken! Dev: If your firewall rules made explicit usage of eth#, they were broken to begin with. You should fix the rules, rather than insist on using eth#. User: How come my firewall rules were broken to begin with? They worked! Dev: They worked by accident, because you didn't happen to experience any race conditions in naming the NIC's. But they were broken nevertheless. So I basically expect that you'll be told to fix your software, so that it doesn't use eth# names. If it is important for your software to know which NIC is which, use biosdevname and p#p# naming. And bug will be closed WONTFIX. Sorry. Best, :-) Marko -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Problem with udev and ethX naming in latest Fedora 19.
On 08/15/2013 02:50 PM, Marko Vojinovic wrote: On Thu, 15 Aug 2013 10:42:03 -0700 Ben Greear gree...@candelatech.com wrote: On 08/15/2013 08:14 AM, Reindl Harald wrote: Am 15.08.2013 16:53, schrieb Ben Greear: On 08/15/2013 07:18 AM, Reindl Harald wrote: Am 15.08.2013 16:05, schrieb Ben Greear: Yes, and I considered it, but I do not want my networks named like that. I've been using ethX in my application and products for more than a decade, and do not want to change the naming scheme if at all possible. [snip] I understand why the names come up jumbled on bootup, but there is no excuse for udev not being able to properly rename them as requested the kernel may also rename the devices as they come up if kernel want make one nic to eth1 and udev at the same time another one - collision That's fine. Udev can just detect the collision and try again, potentially moving the other one to a new name. That is what it has done for years, in between bugs that caused eth0.rename devices to be left lying around. well complain at the udev/systemd-guys and the ones before who came up with biosdevname you know that, i know that, you asked, i gave you an answer more can hardly do a *user* in this case I opened a bug against udev..will see if it gets any response. Bugzilla link please? Btw, I doubt that you'll be taken seriously enough. I can bet that the devs are going to argue like this: if your software makes explicit use of the eth# NIC naming, it is broken to begin with. Fix your software, and that will remove the need for your complaint. I remember seeing this argument before --- this was one of the reasons why the biosdevname NIC names were designed as p#p# and em#, while ignoring the traditional eth naming. I cannot find any of the links now, but all discussions were basically like this: User: Why this stupid p#p# numbering scheme? Couldn't you use eth# instead? Dev: There is no way to name the NIC's in a linear way, so eth# names are unsuitable. User: But can't you at least make aliases from p#p# to eth# in udev? Dev: There is no way to do that uniquely either, so we won't do it. User: But my firewall rules are all written up using eth# names, and now they are broken! Dev: If your firewall rules made explicit usage of eth#, they were broken to begin with. You should fix the rules, rather than insist on using eth#. User: How come my firewall rules were broken to begin with? They worked! Dev: They worked by accident, because you didn't happen to experience any race conditions in naming the NIC's. But they were broken nevertheless. So I basically expect that you'll be told to fix your software, so that it doesn't use eth# names. If it is important for your software to know which NIC is which, use biosdevname and p#p# naming. And bug will be closed WONTFIX. Sorry. Quite close actually. They closed the bug within about 10 minutes :) But, I still think it all can be made to work..if nothing else, by allowing the kernel to use a different default name space. https://bugzilla.redhat.com/show_bug.cgi?id=997573 I'm not actually complaining about their default naming..just the inability of udev to over-ride names based on a MAC address *with the new name being ethX* instead of fooX. Thanks, Ben Best, :-) Marko -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Problem with udev and ethX naming in latest Fedora 19.
Am 15.08.2013 15:09, schrieb Ben Greear: On 08/15/2013 12:56 AM, Reindl Harald wrote: Am 15.08.2013 08:11, schrieb Ben Greear: I'm having all sorts of trouble trying to get udev to rename my interfaces based on MAC address. Please don't suggest I use biosdevname or other such things: I really do want names to be ethX and I want them in a specific order base on MAC address. [root@localhost ~]# cat /etc/udev/rules.d/70-persistent-net.rules is no longer used This page claims that it is, and it partially works..it is just particular about what names you choose for the new names it seems. http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ *partially* here you go, but in case of *four* network cards you may consider rename them to lan0, lan1, lan2, lan3 to avoid the race-condition kernel-naming / renaming which is the reason that biosdevname and all this unholy crap was introduced instead go away from eth as udev-default but let it be a option wherever it works cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 HWADDR=24:be:05:1a:c0:27 [root@srv-rhsoft:~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth1 DEVICE=eth1 HWADDR=68:05:ca:0d:62:c1 I have ifcfg-eth0 defined with proper HWADDR, and still that physical port is not always called eth0 when the system boots. I do not have the other NICs defined in ifcfg-ethX files and you did read what i said? *consider rename them to lan0, lan1, lan2, lan3 to avoid the race-condition kernel-naming / renaming * with 4 NIC's this was never predictable and mostly luck the only stupid thing is that this this new crap names also appear if there is only one NIC or at least only identical ones with the same driver what makes race-conditions unlikely signature.asc Description: OpenPGP digital signature -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Problem with udev and ethX naming in latest Fedora 19.
Am 15.08.2013 16:05, schrieb Ben Greear: with 4 NIC's this was never predictable and mostly luck the only stupid thing is that this this new crap names also appear if there is only one NIC or at least only identical ones with the same driver what makes race-conditions unlikely I understand why the names come up jumbled on bootup, but there is no excuse for udev not being able to properly rename them as requested ask Kay Sievers , he is able to explain it to you too in short: the kernel may also rename the devices as they come up if kernel want make one nic to eth1 and udev at the same time another one - collision signature.asc Description: OpenPGP digital signature -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Problem with udev and ethX naming in latest Fedora 19.
Am 15.08.2013 16:53, schrieb Ben Greear: On 08/15/2013 07:18 AM, Reindl Harald wrote: Am 15.08.2013 16:05, schrieb Ben Greear: with 4 NIC's this was never predictable and mostly luck the only stupid thing is that this this new crap names also appear if there is only one NIC or at least only identical ones with the same driver what makes race-conditions unlikely I understand why the names come up jumbled on bootup, but there is no excuse for udev not being able to properly rename them as requested ask Kay Sievers , he is able to explain it to you too in short: the kernel may also rename the devices as they come up if kernel want make one nic to eth1 and udev at the same time another one - collision That's fine. Udev can just detect the collision and try again, potentially moving the other one to a new name. That is what it has done for years, in between bugs that caused eth0.rename devices to be left lying around. well complain at the udev/systemd-guys and the ones before who came up with biosdevname you know that, i know that, you asked, i gave you an answer more can hardly do a *user* in this case signature.asc Description: OpenPGP digital signature -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Sound problem on fc 19 - xmms no longer can play
Last weekend I did a clean install of Fedora 19 on my main workstation replacing fc17 which had been there. (As I usually do, I pulled the drive containing /, /tmp, /var, and swap and replaced it there. That drive is in another machine and I can compare the diffs.) Suddenly although alsaplayer works just fine, xmms cannot play anything. When I attempt to run xmms, I get a show-box with the error message: Please check that Your soundcard is configured properly You have the correct output plugin selected No other program is blocking the soundcard I've done that and the card is configured correctly, and the correct output plugin is selected - and no other program that I can find is blocking the card. I've even gone so far as to do a yum remove pulseaudio (which worked just fine to solve this same problem up through at least fc17), but that didn't help either. So I suspect that something else is going on here. lsof doesn't show anything holding any of the sound devices open. The rpms all verify correctly root gets the same result as a non-privileged user. So any suggestions would be greatly appreciated. Thanks, - Bill -- william w. austin aire...@att.net life is just another phase i'm going through. this time, anyway ...` -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Two (related?) problems in fresh install of Fedora 19
This weekend I did a clean install of fedora 19 on my main workstation (I pulled the drive containing /, /tmp, and /var (plus swap) running fedora 17, and it's available to compare). I didn't care for the installer changes since 17, but I got through it alive. HOWEVER, I am now having some network problems (at least 2) and I think they are related. The first sounds trivial and isn't. The system thinks its hostname is nick even though the contents of /etc/sysconfig/network say otherwise. That is, the hostname is set correctly there. Also a recursive grep through /etc finds no instance of the string nick anywhere (nor in /boot, /boot/grub2, etc). Setting the hostname manually works up to a point but of course some things never reference the hostname after boot up and they are somewhat hosed. The other main problem may be related - it's a network issue, probably connected with PackageKit. Every few minutes I am getting a message saying: No network connection available cannot refresh cache when offline So I suspect that PackageKit may be hosed and may be trying to reference the wrong hostname. I have a second problem but it's related to sound not network and I'll put it in a second post. Thanks in advance for any help - yes I did a bugzilla search but if it's there I missed it, and I didn't see this problem in any email about fc19 (although I admittedly may have missed it). - Bill -- william w. austin aire...@att.net life is just another phase i'm going through. this time, anyway ... -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Sound problem on fc 19 - xmms no longer can play
On Thu, 15 Aug 2013 13:44:10 -0400 William W. Austin aire...@att.net wrote: Last weekend I did a clean install of Fedora 19 on my main workstation replacing fc17 which had been there. (As I usually do, I pulled the drive containing /, /tmp, /var, and swap and replaced it there. That drive is in another machine and I can compare the diffs.) Suddenly although alsaplayer works just fine, xmms cannot play anything. When I attempt to run xmms, I get a show-box with the error message: Please check that Your soundcard is configured properly You have the correct output plugin selected No other program is blocking the soundcard I've done that and the card is configured correctly, and the correct output plugin is selected - and no other program that I can find is blocking the card. I've even gone so far as to do a yum remove pulseaudio (which worked just fine to solve this same problem up through at least fc17), but that didn't help either. So I suspect that something else is going on here. lsof doesn't show anything holding any of the sound devices open. The rpms all verify correctly root gets the same result as a non-privileged user. So any suggestions would be greatly appreciated. Thanks, - Bill What on earth are you using antiquated software like XMMS for? Why don't you try an up-to-date fork of it like Audacious? It has a gui that mimics XMMS if you desire that. Ananda signature.asc Description: PGP signature -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Two (related?) problems in fresh install of Fedora 19
On 08/16/13 01:36, William W. Austin wrote: This weekend I did a clean install of fedora 19 on my main workstation (I pulled the drive containing /, /tmp, and /var (plus swap) running fedora 17, and it's available to compare). I didn't care for the installer changes since 17, but I got through it alive. HOWEVER, I am now having some network problems (at least 2) and I think they are related. The first sounds trivial and isn't. The system thinks its hostname is nick even though the contents of /etc/sysconfig/network say otherwise. That is, the hostname is set correctly there. Also a recursive grep through /etc finds no instance of the string nick anywhere (nor in /boot, /boot/grub2, etc). That is because things have changed in F18/F19. The hostname is now stored in /etc/hostname and is manipulated using the command hostnamectl. -- Getting tired of non-Fedora discussions and self-serving posts -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Problem with udev and ethX naming in latest Fedora 19.
On Thu, 15 Aug 2013 14:54:41 -0700 Ben Greear wrote: I'm not actually complaining about their default naming..just the inability of udev to over-ride names based on a MAC address *with the new name being ethX* instead of fooX. Yea, me too, especially since the whole immutable thing is an absolute joke. The original biosdevname was updated several times, and in many of the updates, the immutable name changed. This new scheme apparently uses the exact same algorithms (which broke in all the previous updates), to invent different names that are better in the opinion of the OCD moron who happened to have git commit rights, but of course since they are better that means they changed once again. How long will it be before some new developer with a different case of OCD decides they need to change again? How long will it be before a new motherboard manufacturer generates some new glitch they need to fix, which once again changes the immutable names. This would all be so much better if they went ahead and made their stupid immutable names, but also created the persistent name udev rules to remember the stupid immutable names and keep them the same across updates to the algorithms. This may be one of the more utterly absurd and useless improvements to ever land in linux. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Problem with udev and ethX naming in latest Fedora 19.
On 08/16/13 06:34, Tom Horsley wrote: to invent different names that are better in the opinion of the OCD moron who happened to have git commit rights, but of course since they are better that means they changed once again. How long will it be before some new developer with a different case of OCD decides Just wondering Do you know these people personally and you have first hand knowledge they are afflicted with OCD? (FYI, it is a disease with very real effects on family and friends and I have first hand experience with a tragedy brought on in part by OCD.) Or are you just in the mood for personal attacks on nameless individuals for your amusement? -- Getting tired of non-Fedora discussions and self-serving posts -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Two (related?) problems in fresh install of Fedora 19
Am 15.08.2013 19:36, schrieb William W. Austin: This weekend I did a clean install of fedora 19 on my main workstation (I pulled the drive containing /, /tmp, and /var (plus swap) running fedora 17, and it's available to compare). I didn't care for the installer changes since 17, but I got through it alive. HOWEVER, I am now having some network problems (at least 2) and I think they are related. The first sounds trivial and isn't. The system thinks its hostname is nick even though the contents of /etc/sysconfig/network say otherwise. /etc/sysconfig/network has nothing to do with the hostname, hence it was even removed due yum-dist-upgrades and moved to /etc/hostname [root@srv-rhsoft:~]$ cat /etc/hostname srv-rhsoft.rhsoft.net [root@srv-rhsoft:~]$ hostname srv-rhsoft.rhsoft.net signature.asc Description: OpenPGP digital signature -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Problem with Matrox MGA G200eW video driver.
I have a fancy and quite new E5 processor server system that has a Matrox VGA port in it: e:04.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200eW WPCM450 (rev 0a) This appears to use the mgag200 kernel module. When this module is loaded, the Xorg log complains saying the module must be unloaded and I end up running 'llvmpipe' and performance is horrible. If I blacklist the module, it still runs in emulation mode and performance is horrible. Here is what I think is the interesting part for the black-list variant: [26.079] (II) Module vgahw: vendor=X.Org Foundation [26.079]compiled for 1.14.2, module version = 0.1.0 [26.079]ABI class: X.Org Video Driver, version 14.1 [26.079] (--) MGA(0): Chipset: mgag200 eW Nuvoton [26.079] (--) MGA(0): Linear framebuffer at 0xF900 [26.079] (--) MGA(0): MMIO registers at 0xFB80 [26.079] (--) MGA(0): Pseudo-DMA transfer window at 0xFB00 [26.150] (II) MGA(0): Creating default Display subsection in Screen section Default Screen Section for depth/fbbpp 24/32 [26.150] (==) MGA(0): Depth 24, (--) framebuffer bpp 32 [26.150] (==) MGA(0): RGB weight 888 [26.150] (**) MGA(0): Enabling KVM [26.150] (==) MGA(0): Using HW cursor [26.150] (**) MGA(0): Using Shadow Framebuffer - acceleration disabled [26.150] (--) MGA(0): Video BIOS info block at offset 0x07D60 [26.150] (==) MGA(0): VideoRAM: 16320 kByte So, first question: Should I be blacklisting the driver? And second, any idea on how to either get the acceleration working, or make gnome work OK w/out it? I don't care at all about 3D affects, I just need basic desktop functionality to work w/out too much overhead. Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: More antivirus talk - comodo antivirus for linux
On 08/15/2013 10:50 AM, Steven Stern wrote: On 08/15/2013 08:54 AM, linuxnuts...@videotron.ca wrote: On 08/15/2013 12:52 AM, Jatin K wrote: On Thursday 15 August 2013 03:49 AM, linuxnuts...@videotron.ca wrote: Has anybody heard of this, or even tried it? http://www.comodo.com/home/internet-security/antivirus-for-linux.php Might come in handy for scanning windows partitions Yes ... I'm using it on my Ubuntu machine, as I used to share thumb drives with my friends who are using M$ os. obviously I don't need to protect my Linux machine, I've installed it to test it, it works like charm and clears virus from drives ?? Warm Regards That's what I wanted to know. I actually installed it and it started finding malware in windows backups I made from another machine. Look good so far I use ClamAV. What does Comodo add to the party? Can anyone do a side-by-side review? I received some phishing scams with executables in attached zip files. ClamAv didn't find anything wrong, but when I scanned the same zip files with Kaspersky, it found malware. When I decompressed the zip files Clam still didn't find anything wrong. I'm going to try comodo on these files and see... -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: More antivirus talk - comodo antivirus for linux
On 08/15/2013 12:48 AM, NOSpaze wrote: On Wed, 2013-08-14 at 18:19 -0400, linuxnuts...@videotron.ca wrote: Has anybody heard of this, or even tried it? http://www.comodo.com/home/internet-security/antivirus-for-linux.php In fact, a quick search at your mail domain (.com) shows a lot of windows software useful for windows, including this antivirus. Not related to this list, thanks. http://pages.videotron.com/g225/index.html ;) -- nosp...@gmail.com otbits.blogspot.com / counter.li.org: #367962 -- Es gibt kein unmoralisches Buch. Bücher sind gut geschrieben oder schlecht geschrieben. Das ist alles. - Oscar Wilde I was enquiring regarding the Linux version of this particular anti-virus as per the link I posted ( anti-virus-for-linux.php ). I wanted to know if anybody had any experience with this Linux version. The link you provided may have proven useful had I been searching for windows based troubleshooting. Thanks. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Slow initialization of something during boot
On 15.08.2013 20:10, Frank wrote: With all due respect, I don't understand what's going on here---my network manager is not disabled. What effect does adding sleep to lightdm.service produce ?? I think I am missing the point :) Regards Frank It is a famous the dodge by braking maneuver. ;) poma -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Undetected Fresco Logic FL1000G USB 3.0 controller in Asus N43SN after replace a motherboard
On 15.08.2013 22:13, Marcin Zajączkowski wrote: On 2013-08-12 19:27, poma wrote: On 12.08.2013 13:03, Marcin Zajączkowski wrote: Hi, I had no problem with a USB 3.0 port in my Asus N43SN since I bought a laptop (~2 years). Recently I replaced a motherboard to the new one (N43SL.413 looked the same as the first one) due to a problem with a graphical chipset and after that a USB3 controller stopped to be even detected. $ modinfo -F author xhci-hcd.ko Sarah Sharp http://vger.kernel.org/vger-lists.html#linux-usb Thanks for a hint. Marcin It is resolved? poma -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Slow initialization of something during boot
On 08/15/2013 08:46 PM, poma wrote: On 15.08.2013 20:10, Frank wrote: With all due respect, I don't understand what's going on here---my network manager is not disabled. What effect does adding sleep to lightdm.service produce ?? I think I am missing the point :) Regards Frank It is a famous the dodge by braking maneuver. ;) poma Well in this case it didn't work - I tried adding 10 sec sleep...5 sec sleep and 2 sec sleep...same 20-25 sec delay before lightdm greeter appears. Maybe I'll go back to lxdm..or learn patience :) Regards Frank -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Problem with udev and ethX naming in latest Fedora 19.
On 15.08.2013 15:04, Ben Greear wrote: On 08/15/2013 01:55 AM, poma wrote: On 15.08.2013 08:11, Ben Greear wrote: Last time I checked, the lan alias should do, i.e. lan0, lan1, …, but not the eth one.[1] However I leave rename to systemd. lspci 01:09.0 Ethernet controller: ifconfig enp1s9: dmesg systemd-udevd: renamed network interface eth0 to enp1s9 If you contemplate it from the perspective of the NetworkManager/nmcli you'll understand. ;) I end up disabling NetworkManager because is has no ability to white-list interfaces and I only would want it messing with the one 'management' network interface on the system..not the others that I do my own special network configuration upon. http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ I read this, and option 2 to disable it is what I tried. There is no particular reason for it to have trouble renaming the interfaces to ethX, it might just have to do a ethY.rename naming first. udev has been dealing with this for many years successfully, at least up to Fedora 17. Thanks, Ben You're a little late for the wedding. They were already divorced. ;) It would be better to talk to people on the networkmanager-l...@gnome.org of features you are missing. Sooner or later everything you use now will become obsolete. poma -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Slow initialization of something during boot
On 16.08.2013 02:55, Frank wrote: On 08/15/2013 08:46 PM, poma wrote: On 15.08.2013 20:10, Frank wrote: With all due respect, I don't understand what's going on here---my network manager is not disabled. What effect does adding sleep to lightdm.service produce ?? I think I am missing the point :) Regards Frank It is a famous the dodge by braking maneuver. ;) poma Well in this case it didn't work - I tried adding 10 sec sleep...5 sec sleep and 2 sec sleep...same 20-25 sec delay before lightdm greeter appears. Maybe I'll go back to lxdm..or learn patience :) Regards Frank Looks like you're not as skilled as Maverick. ;) https://bugs.launchpad.net/lightdm poma -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Slow initialization of something during boot
Looks like you're not as skilled as Maverick. ;) Neither am I. :) Bummer! poma -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Problem with Matrox MGA G200eW video driver.
On Thu, 15 Aug 2013 16:36:24 -0700 Ben Greear gree...@candelatech.com wrote: I have a fancy and quite new E5 processor server system that has a Matrox VGA port in it: e:04.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200eW WPCM450 (rev 0a) This appears to use the mgag200 kernel module. When this module is loaded, the Xorg log complains saying the module must be unloaded and I end up running 'llvmpipe' and performance is horrible. If I blacklist the module, it still runs in emulation mode and performance is horrible. Here is what I think is the interesting part for the black-list variant: [26.079] (II) Module vgahw: vendor=X.Org Foundation [26.079]compiled for 1.14.2, module version = 0.1.0 [26.079]ABI class: X.Org Video Driver, version 14.1 [26.079] (--) MGA(0): Chipset: mgag200 eW Nuvoton [26.079] (--) MGA(0): Linear framebuffer at 0xF900 [26.079] (--) MGA(0): MMIO registers at 0xFB80 [26.079] (--) MGA(0): Pseudo-DMA transfer window at 0xFB00 [26.150] (II) MGA(0): Creating default Display subsection in Screen section Default Screen Section for depth/fbbpp 24/32 [26.150] (==) MGA(0): Depth 24, (--) framebuffer bpp 32 [26.150] (==) MGA(0): RGB weight 888 [26.150] (**) MGA(0): Enabling KVM [26.150] (==) MGA(0): Using HW cursor [26.150] (**) MGA(0): Using Shadow Framebuffer - acceleration disabled [26.150] (--) MGA(0): Video BIOS info block at offset 0x07D60 [26.150] (==) MGA(0): VideoRAM: 16320 kByte So, first question: Should I be blacklisting the driver? And second, any idea on how to either get the acceleration working, or make gnome work OK w/out it? I don't care at all about 3D affects, I just need basic desktop functionality to work w/out too much overhead. While I know basically nothing about Matrox cards, the log line [26.150] (**) MGA(0): Using Shadow Framebuffer - acceleration disabled apparently says that acceleration was deliberately disabled in the config file (i.e. somewhere inside /etc/X11/xorg.conf or inside xorg.conf.d directory). This is the meaning of the (**). Also, AFAIK Gnome3 requires accelerated graphics (at least it did last time I checked). You may be better off trying Mate, XFCE, LXDE, KDE, or some lightweight window manager without a full DE. HTH, :-) Marko -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Slow initialization of something during boot
snip Didn't work - put me into Vesa mode I guess but the delay remains /snip None of those worked for me either Roger -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
