Re: Re: Middle mouse button stopped pasting
I have also noticed a change to middle mouse button pasting in Fedora 20. The middle mouse button used to paste into gvim at the position of the cursor regardless of where I clicked. Now, all of a sudden, it moves the cursor then inserts text (Yuck!) I am using fluxbox as my window manager. What window manager or desktop environment are you using? The only recent and relevant update I see in /var/log/yum.log is ibus-libs. 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: Re: Sometimes problems with the visibility of threads in thunderbird
Oh boy do I ever have this problem. I hadn't noticed before but since you mentioned threads I've noticed that what I see is entirely dependent on a thread being collapsed. If all threads are expanded I can move up and down in the message list without trouble. If a thread is collapsed, then moving down to the top of the collapsed thread or below causes the messages below it to be miss-rendered. I can move around above the collapsed thread all I want without error. Swiping the mouse over the miss-rendered threads causes them to be rendered correctly. 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: Re: FedUp 18 - 19 Orphans
Michael Young said: You need to do both at the same time. Here yum shell is useful as it lets you gather a series of yum commands and run them in one batch. Try something like yum shell remove perl-5.16.3-245.fc18.x86_64 install perl-autodie run and if that works exit you may need to add other commands as well to sort out the dependencies. Wow, Michael, thank you very much for that. I don't know how I managed not to know about yum shell. 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
FedUp 18 - 19 Orphans
I just updated from Fedora 18 to 19 with fedup. After the update I have many orphaned packages : # package-cleanup --orphans | wc -l 635 When I examine them I see things like fedora-release, zlib, and such. They mostly exist alongside their identical fedora 19 versions : # package-cleanup --orphans | grep libogg libogg-1.3.0-5.fc18.x86_64 # yum list libogg Loaded plugins: auto-update-debuginfo, verify Installed Packages libogg.x86_64 2:1.3.0-5.fc18 installed libogg.i686 2:1.3.0-5.fc19 installed libogg.x86_64 2:1.3.0-5.fc19 installed Any idea what's going on? 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: Re: FedUp 18 - 19 Orphans
Frank wrote: package-cleanup --dupes packagecleanup --cleandupes Somewhere in there some some dependency leaves fc18 and starts ripping out large parts of fc19.. It looks to be perl # yum remove `package-cleanup --dupes | grep perl | grep fc18` ... Remove 67 Packages (+32 Dependent packages)... It looks like I'm going to have to fix these in small batches... 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: FedUp 18 - 19 Orphans
Michael wrote: You may also need to use yum or rpm to remove some of the duplicates by hand if package-cleanup can't work out how to solve all the dependencies. The only bits of perl that I could not clean up seem to be perl and perl libs. I did : # rpm -q --provides perl-5.16.3-266.fc19.x86_64 /tmp/p19.txt # rpm -q --provides perl-5.16.3-245.fc18.x86_64 /tmp/p18.txt # diff /tmp/p18.txt /tmp/p19.txt and among the interesting bits of output was : 90d61 perl(Fatal) = 2.10 so then I did : # rpm -q --whatrequires perl(Fatal) perl-5.16.3-245.fc18.x86_64 redhat-lsb-languages-4.1-14.fc19.x86_64 # rpm -q --whatprovides perl(Fatal) perl-5.16.3-245.fc18.x86_64 so there is a F19 package that depends on a F18 package Yum tells me that perl(Fatal) comes from : # yum provides perl(Fatal) Loaded plugins: auto-update-debuginfo, verify perl-autodie-2.16-1.fc19.noarch : Replace functions with ones that succeed or die Repo: fedora Matched from: Provides: perl(Fatal) = 2.16 4:perl-5.16.3-245.fc18.x86_64 : Practical Extraction and Report Language Repo: @updates/18 Matched from: Provides: perl(Fatal) = 2.10 # yum list perl-autodie Loaded plugins: auto-update-debuginfo, verify Available Packages perl-autodie.noarch 2.16-1.fc19 fedora which did not get installed... # yum install perl-autodie ... Transaction check error: file /usr/share/man/man3/Fatal.3pm.gz from install of perl-autodie-2.16-1.fc19.noarch conflicts with file from package perl-4:5.16.3-245.fc18.x86_64 file /usr/share/man/man3/autodie.3pm.gz from install of perl-autodie-2.16-1.fc19.noarch conflicts with file from package perl-4:5.16.3-245.fc18.x86_64 file /usr/share/man/man3/autodie::exception.3pm.gz from install of perl-autodie-2.16-1.fc19.noarch conflicts with file from package perl-4:5.16.3-245.fc18.x86_64 file /usr/share/man/man3/autodie::exception::system.3pm.gz from install of perl-autodie-2.16-1.fc19.noarch conflicts with file from package perl-4:5.16.3-245.fc18.x86_64 file /usr/share/man/man3/autodie::hints.3pm.gz from install of perl-autodie-2.16-1.fc19.noarch conflicts with file from package perl-4:5.16.3-245.fc18.x86_64 because it conflicts with perl from f18... 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: Re: /dev/md[12] vanished
dracut doesn't copy etc/mdadm.conf into the initramfs image So IIUC #mdadmconf=no was enough in a previous version for mdadm.conf to be copied into the initramfs but you now need mdadmconf=yes? That's my understanding as well. Much of the discussion in the bug talks about failure to boot. I can still boot because my /etc/fstab has all UUID's not device names. My only symptom is that mdadm complains when it tries to monitor the arrays... 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: Re: /dev/md[12] vanished
I found this bug: dracut doesn't copy etc/mdadm.conf into the initramfs image https://bugzilla.redhat.com/show_bug.cgi?id=1015204 which looks exactly like what I'm describing. Thank you for your response. 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
/dev/md[12] vanished
On October 4 this : - Mdadm Begin mdadm: cannot open /dev/md1: No such file or directory /dev/md1 : mdadm: cannot open /dev/md2: No such file or directory /dev/md2 : -- Mdadm End - and this : - Disk Space Begin Filesystem Size Used Avail Use% Mounted on devtmpfs2.0G 0 2.0G 0% /dev /dev/md127 48G 16G 31G 34% / /dev/md126 475M 118M 328M 27% /boot /dev/sdc1 917G 73G 798G 9% /mnt/WD1TB /dev/md0173G 65G 101G 40% /home -- Disk Space End - began appearing in the logwatch e-mails of at least two of my computers that run Fedora 18. Somehow md1 and md2 became md127 and md126. On October 3 and 4 there were lots of updates including a kernel and dracut. Does anybody have a clue what might have changed? Everything works from my perspective but I don't want my arrays to disappear on me if I haven't made some configuration change before some later update 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: /dev/md[12] vanished
On 11/16/2013 10:06 AM, Tom H wrote: Somehow md1 and md2 became md127 and md126 Have you changed your hostname? No, do you suspect the October 3rd dracut-network update? 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: Re: Open MPI problem After F17 - F18 Upgrade
On Sun Jul 21 11:47:51 UTC 2013 Susi Lehtola wrote : Are you sure you have the correct MPI runtime loaded? All sorts of strange things can happen if you try running an MPI binary with the wrong runtime libraries, e.g. mpich2 binary with openmpi. Yes, I had only one MPI installed at the time, and I did ldd every which way. There are more details in bugzilla : https://bugzilla.redhat.com/show_bug.cgi?id=986409 and in the openmpi users list : http://www.open-mpi.org/community/lists/users/2013/07/22346.php but basically on my home workstation openmpi does not get along with the hwloc to which it is linked in Fedora 18. 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Open MPI problem After F17 - F18 Upgrade
After I updated my home computer from Fedora 17 to 18 MPI programs
stopped working.
I have a very simple program :
#include stdlib.h
#include stdio.h
#include mpi.h
int main( int argc, char * argv[] )
{
int rank, size;
MPI_Init(argc, argv);
MPI_Comm_rank(MPI_COMM_WORLD, rank);
MPI_Comm_size(MPI_COMM_WORLD, size);
printf(my rank is %i of %i\n, rank, size );
MPI_Finalize();
return EXIT_SUCCESS;
}
I can compile it with :
mpicc -g -o mpi_simple mpi_simple.c
but when I run it with :
mpirun -n 1 ./mpi_simple
I get :
[murron.hobbs-hancock:05668] [[55801,1],0] ORTE_ERROR_LOG: Error in file
util/nidmap.c at line 148
[murron.hobbs-hancock:05668] [[55801,1],0] ORTE_ERROR_LOG: Error in file
ess_env_module.c at line 174
--
It looks like orte_init failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems. This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):
orte_util_nidmap_init failed
-- Returned value Error (-1) instead of ORTE_SUCCESS
--
--
It looks like orte_init failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems. This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):
orte_ess_set_name failed
-- Returned value Error (-1) instead of ORTE_SUCCESS
--
--
It looks like MPI_INIT failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during MPI_INIT; some of which are due to configuration or environment
problems. This failure appears to be an internal failure; here's some
additional information (which may only be relevant to an Open MPI
developer):
ompi_mpi_init: orte_init failed
-- Returned Error (-1) instead of Success (0)
--
[murron.hobbs-hancock:05668] [[55801,1],0] ORTE_ERROR_LOG: Error in file
runtime/orte_init.c at line 128
[murron.hobbs-hancock:5668] *** An error occurred in MPI_Init
[murron.hobbs-hancock:5668] *** on a NULL communicator
[murron.hobbs-hancock:5668] *** Unknown error
[murron.hobbs-hancock:5668] *** MPI_ERRORS_ARE_FATAL: your MPI job will
now abort
--
An MPI process is aborting at a time when it cannot guarantee that all
of its peer processes in the job will be killed properly. You should
double check that everything has shut down cleanly.
Reason: Before MPI_INIT completed
Local host: murron.hobbs-hancock
PID:5668
--
--
mpirun has exited due to process rank 0 with PID 5668 on
node murron.hobbs-hancock exiting improperly. There are two reasons this
could occur:
1. this process did not call init before exiting, but others in
the job did. This can cause a job to hang indefinitely while it waits
for all processes to call init. By rule, if one process calls init,
then ALL processes must call init prior to termination.
2. this process called init, but exited without calling finalize.
By rule, all processes that call init MUST call finalize prior to
exiting or it will be considered an abnormal termination
This may have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).
--
I'm actually able to run the generated executable on another computer
just fine.
I tried using gdb to step through util/nidmap.c from 148 but whatever
goes wrong is too far away for me to find it.
Does anybody have any clue where I should look?
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
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Re: Re: Screen stopped blanking
I'm having a similar problem but with one monitor on a dual monitor workstation: http://lists.fedoraproject.org/pipermail/users/2012-August/423737.html I have a Dell Latitude E6410 with an nVidia graphics card, using the nouveau driver and the GNOME desktop on F17. I also use the nouveau driver but with KDE on F17 Recently, the laptop screen stopped blanking when idle in X mode. Mine never blanked in F17 but blanking worked in previous fedora releases. Do you know _how_ recently it stopped blanking? I've modified the screen-blank settings, to no avail. Same here. If I switch to a virtual console, blanking works fine. Hmm, I get the same behavior in a virtual console as I do in X, that is on monitor suspended one remains on. Maybe our problems are different. Any hints what might have changed or what I might look for to get it working again? What happens when you do : xset dpms force off When I do it my monitors appear to shut down but then one turns back on. 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: selinux blocking ganglia-web
On 09/29/2012 06:59 AM, Daniel J Walsh wrote: Sometimes those reports are worth reading... Yes, yes they are. I should have piped it to less. The specific solution was at the top where it's the first thing the reader sees in a pager like less or in the GUI selinux debugger. This is the correct placement. I missed the specific solution the first time I read the message because I read from bottom to top as I scrolled backwards through my terminal output where I saw first a description of how to let httpd make arbitrary connections (bad), followed by some very general information about the selinux alert itself, where I stopped reading. Google was _very_ unhelpful on the subject of selinux, ganglia, and httpd. All I got were recommendations for some cluster suit that selinux had to be disabled entirely (it does not.) Dear Google, The command : semanage port -a -t http_port_t -p tcp 8652 allows httpd to talk to ganglia's gmetad despite the selinux restriction on httpd making arbitrary connections. I misspelled gmetad in the earlier message. 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
selinux blocking ganglia-web
I just replaced the machine that runs ganglia. httpd is being prevented from connecting to gmond. All that is displayed is: There was an error collecting ganglia data (127.0.0.1:8652): fsockopen error: Permission denied There's a message in /var/log/messages that blames selinux every time I load the page. and sealert says that I could change the behavior by setting allow_ypbind or httpd_can_network_connect allow httpd_t unreserved_port_t:tcp_socket name_connect; I can see how letting httpd make arbitrary connections is bad, so how can I punch a hole in the rule just for ganglia? 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Re: selinux blocking ganglia-web
From: Jack Craig jack.craig.ap...@gmail.com doesnt the selinux troubleshooter offer suggestions? I'm a bit embarrassed to admit that other than the very general boolians that sudo sealert -l $UUID suggests setting at the end of it's output, it also suggested a very specific fix at the top of it's output way off my terminal : sudo semanage port -a -t http_port_t -p tcp 8652 allowed httpd to connect to gmeted. Thank you for your time. 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
2nd monitor won't powersave
One of my monitors does not enter any power saving mode. Can anybody tell me where to look to figure out what's going on? I have a Fedora 17 workstation with two acer x223w monitors connected to a nvidia GeForce 9800 GTX+ using the nouveau driver. I used to have Fedora 14 installed with nvidia drivers and both monitors would enter a power saving mode. I installed Fedora 17 with the minimal setting and then added KDE and told systemd to use the graphical login. Among the things I see with : $ sudo cat /var/log/Xorg.0.log | grep -B 7 DPMS are : [ 26125.818] (II) NOUVEAU(0): EDID for output DVI-I-1 [ 26125.818] (II) NOUVEAU(0): Manufacturer: ACR Model: 50 Serial#: 2449480058 [ 26125.818] (II) NOUVEAU(0): Year: 2009 Week: 20 [ 26125.818] (II) NOUVEAU(0): EDID Version: 1.3 [ 26125.818] (II) NOUVEAU(0): Digital Display Input [ 26125.818] (II) NOUVEAU(0): Max Image Size [cm]: horiz.: 47 vert.: 30 [ 26125.818] (II) NOUVEAU(0): Gamma: 2.20 [ 26125.818] (II) NOUVEAU(0): DPMS capabilities: StandBy Suspend -- [ 26125.849] (II) NOUVEAU(0): EDID for output DVI-I-2 [ 26125.849] (II) NOUVEAU(0): Manufacturer: ACR Model: d Serial#: 2442237862 [ 26125.849] (II) NOUVEAU(0): Year: 2009 Week: 19 [ 26125.849] (II) NOUVEAU(0): EDID Version: 1.3 [ 26125.849] (II) NOUVEAU(0): Digital Display Input [ 26125.849] (II) NOUVEAU(0): Max Image Size [cm]: horiz.: 47 vert.: 30 [ 26125.849] (II) NOUVEAU(0): Gamma: 2.20 [ 26125.849] (II) NOUVEAU(0): DPMS capabilities: StandBy Suspend Off 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: 3w-9xxx f14-f15 breakage
Since I have the messages up again I see something about IRQ 35 rerouted to legacy IRQ 19 Michael, what does /proc/interrupts say for you? I may be obsessing a bit but this IRQ rerouting is very interesting to me. In the f15 dracut shell I took a look at /proc/interrupts. Rerouting IRQ 35 to 19 put the 3ware card on an interrupt with a bunch of other things. In the f14 kernel IRQ 35 is not rerouted to IRQ 19 and the card works fine. 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: 3w-9xxx f14-f15 breakage
/etc/modprobe.d/3w-9xxx.conf:options 3w-9xxx use_msi=1 I created this file to add this option, reran dracut, and the f15 kernel boots right up. The 3ware controller gets it's own interrupt and everything. 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
3w-9xxx f14-f15 breakage
I just updated (with yum) our backup server from Fedora 14 to Fedora 15. This server has a 3ware 9550SX-8LP RAID card. When I boot with the new kernel-2.6.41.1-1.fc15.x86_64 the machine complains that it can not find the root device by id and drops to a dracut shell. It then prints out warnings about the RAID card over and over in a slow (20s or so) loop where the RAID card is reset once per loop. I rebooted with the old kernel-2.6.35.14-106.fc14.x86_64 and Fedora comes right up. The RAID controller has the newest firmware FE9X 3.08.00.029 The RAID controller has no schedule limiting when it can do a verify and it has been doing one about once a day. I've restarted the machine several times to track down this problem and so it has always been trying a verify when it booted the new kernel. Does anybody have any ideas? 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: 3w-9xxx f14-f15 breakage
Do you have the UUID contents of /etc/fstab for your root partition matching /boot/grub/grub.conf ? fstab : UUID=51b92885-d3c8-4f81-99f3-d4b3b211fe71 / ext3defaults1 1 grub.conf : kernel /vmlinuz-2.6.41.1-1.fc15.x86_64 ro root=UUID=51b92885-d3c8-4f81-99f3-d4b3b211fe71 SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us so yes they match. 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: 3w-9xxx f14-f15 breakage
My second, probably bad, guess is that the initramfs has not been built correctly. I used preupgrade to upgrade my box so it was running on an F15 kernel when it installed the F15 kernel. Can you try to boot the system off a Live image (Usb stick will work) and see if that detects your root partition? Yup the install DVD could mount the array. While in the rescue environment I removed and reinstalled the f15 kernel. The same thing happened when I rebooted. Since I have the messages up again I see something about IRQ 35 rerouted to legacy IRQ 19 before dacut drops me to a shell. The first warning I get is: WARNING: (0x06:0x002c) command (0x12) timed out resseting card The f14 kernel does not do the IRQ rerouting or so says dmesg. 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: 3w-9xxx f14-f15 breakage
Kevin H. Hobbs wrote: Since I have the messages up again I see something about IRQ 35 rerouted to legacy IRQ 19 If the DVD boots and you can modify the array it must be something in /etc. Do you have any custom modprobe configuration files? $ grep 3w-9xxx /etc/modprobe.d/* just : $ grep 3w- /etc/modprobe.d/* /etc/modprobe.d/local.conf:alias scsi_hostadapter 3w-9xxx and : $ grep scsi_hostadapter /etc/modprobe.d/* /etc/modprobe.d/dist.conf:install scsi_hostadapter /bin/true /etc/modprobe.d/local.conf:alias scsi_hostadapter 3w-9xxx /etc/modprobe.d/local.conf:alias scsi_hostadapter1 ata_piix Otherwise, I'm pretty much out of ideas. Thanks for trying. 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
e1000e startup problem
I have a fedora 14 server here who's ethernet interface seems to take just a bit too long to establish a link. Whenever it starts it is inaccessible over the network, which is a real pain for a server. I have to go over with the monitor and keyboard, crawl under the desk... When I try to restart the network interface with service network restart I get something that looks like : Bringing up interface eth0: Determining IP information for eth0...[big number] ADDRCONF(NETDEV_UP): eth0: link is not ready. [FAILED] [big number] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex... Which sounds to me like a timeout was just a bit too short. If I try a few times in a row suddenly it works. [kevin@backup ~]$ uname -a Linux backup.hooperlab 2.6.35.14-96.fc14.x86_64 #1 SMP Thu Sep 1 11:59:56 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux [kevin@backup ~]$ lspci -nn | grep -i eth 04:00.0 Ethernet controller [0200]: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) [8086:108c] (rev 03) 05:05.0 Ethernet controller [0200]: Intel Corporation 82541GI Gigabit Ethernet Controller [8086:1076] (rev 05) [kevin@backup ~]$ dmesg | tail [ 1633.233297] e1000e :04:00.0: irq 73 for MSI/MSI-X [ 1633.284094] e1000e :04:00.0: irq 73 for MSI/MSI-X [ 1633.285079] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 1642.265283] e1000e :04:00.0: irq 73 for MSI/MSI-X [ 1642.316094] e1000e :04:00.0: irq 73 for MSI/MSI-X [ 1642.317556] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 1647.280547] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX [ 1647.285563] e1000e :04:00.0: eth0: 10/100 speed: disabling TSO [ 1647.291153] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 1657.802008] eth0: no IPv6 routers present 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Selinux blocking denyhosts
On 05/31/2011 09:21 AM, Daniel J Walsh wrote: On 05/29/2011 08:02 AM, Kevin H. Hobbs wrote: sealert says: /var/lock default label should be var_lock_t. restorecon -R -v /var Mmm that did it. denyhosts now starts. What made me doubt the advice sealert gave me was that /var/lock did have the label var_lock_t. So I knew the problem was over my head. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Selinux blocking denyhosts
I tried to install and enable denyhosts on a fresh Fedora 15 install. I did systemctl enable denyhosts.service. systemctl ran chkconfig. When I started the service I got this in /var/log/messages: May 29 07:49:33 murron setroubleshoot: SELinux is preventing /usr/bin/python from read access on the lnk_file /var/lock. For complete SELinux messages. run sealert -l fc8b6153-e359-409b-9310-9f0f3b3a20c7 sealert says: SELinux is preventing /usr/bin/python from read access on the lnk_file /var/lock. * Plugin restorecon (94.8 confidence) suggests * If you want to fix the label. /var/lock default label should be var_lock_t. Then you can run restorecon. Do # /sbin/restorecon -v /var/lock * Plugin catchall_labels (5.21 confidence) suggests If you want to allow python to have read access on the lock lnk_file Then you need to change the label on /var/lock Do # semanage fcontext -a -t FILE_TYPE '/var/lock' where FILE_TYPE is one of the following: var_run_t, var_lock_t, bin_t, cert_t, usr_t, device_t, devlog_t, locale_t, abrt_t, etc_t, lib_t, proc_t, root_t, device_t, ld_so_t, proc_t, denyhosts_t, textrel_shlib_t, rpm_script_tmp_t, var_run_t. Then execute: restorecon -v '/var/lock' * Plugin catchall (1.44 confidence) suggests *** If you believe that python should be allowed read access on the lock lnk_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep denyhosts.py /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
KDE Laggy in Fresh F15
I just did a fresh install of Fedora 15 x86_64 with KDE. KDE is mostly unusable in Fedora 15 while it was fine in Fedora 14 (with nvidia driver). The display seems to freeze for a few seconds every few seconds. Menus take seconds to open. Windows leave garbage on the display when they are moved or re-sized. New windows are often filled with garbage before they are drawn all the way. KDE automatically disables the desktop effects. I installed and switched to fluxbox and everything is snappy. Without all of the KDE decoration firefox went from unusable to normal under fluxbox. I have not installed any software not in Fedora's repository (no nvidia drivers). System details that might be usefull: lenovo S10 Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz 4 GB of DDR3 1067 MHz RAM nVidia Corporation G86 [Quadro NVS 290] nouveau driver is loaded and in /etc/X11/xorg.conf Screen spans two 1600x1200 CRTs -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: KDE Laggy in Fresh F15
From: Clemens Eissererlinuxhi...@gmail.com I have not installed any software not in Fedora's repository (no nvidia drivers). Yeah, I guess you are hitting nouveau bugs here. So why don't you simply install the nvidia drivers? Do the problems also happen with desktop effects disabled? - Clemens I'd like to at least try to isolate the bugs and report them first. If everybody immediately switches to the proprietary drivers then the nouveau drivers and/or KDE will never improve. I'll eventually try the nvidia drivers so I can be sure it's a KDE/nouveau issue but first if anybody can say try this mesa patch, strace this or gdb that I'll do it. KDE automatically disables desktop effects. I can not disable them because I can not enable them... Well I could also disable the performance checks but I don't want KDE any slower. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: F14 to F15 Did not go well
Casimiro said: What I noticed is that lots of rpmdb registers kept pointing to fc14 stuff and things like libxxxyyyzzz is needed for aaa.fc14.xxx and even aaa.fc13.xxx (in fact, there were zombie dependencies dating back to fc12). Hmm, I did the whole: rpmconf -a find /etc /var -name '*.rpm?*' package-cleanup --orphans thing prior to doing the DVD update. I now realize that my post upgrade system was stopping during the systemd process not init. 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
F14 to F15 Did not go well
I just tried to upgrade Fedora 14 x86_64 to Fedora 15 x86_64 using the DVD. It did not go well. I couldn't figure out what went wrong so I did a fresh install. The system is a lenovo S10 with two drives and software RAID 1 partitions for /, /boot, and /home all ext3, and swap. There were ... contaminants ( nvidia drivers from rpmfusion repo, flash from adobe repo, and chrome from google-chrome repo). During init something bad flashed by but I couldn't catch it and I was presented with the Control-D or root password for maintenance prompt. There was nothing useful in /var/log/messages, /var/log/boot.log, /root/upgrade.log, /root/upgrade.log.syslog, nor dmesg I figured I'd try a yum update after chrooting into the system from the DVD in rescue mode but yum complained that it couldn't open the RPM database. I believe it mentioned corruption but I was still on my first coffee. It all could be a fluke or it could point to a pattern so I'll try and provide more details if anybody has questions. 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
OpenMPI broken on host of virtual machine
Our F13 cluster is primarily used to run OpenMPI applications. I installed a virtual guest using the instructions at : http://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/part-Virtualization-Installation.html to do some development builds of a package I use and now OpenMPI jobs fail to start with : [bubbles.hooperlab][[55228,1],0][btl_tcp_endpoint.c:638:mca_btl_tcp_endpoint_complete_connect] connect() to 192.168.122.1 failed: Connection refused (111) on node 0, bubbles 192.168.122.1 belongs to virbr0 on bubbles bubbles and all of the compute nodes are on 192.168.0.* If I take down virbr0 on bubbles everything works. Where might things be going wrong? 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Talloc
Why do : nm /usr/lib64/libtalloc.so.2.0.0 nm: /usr/lib64/libtalloc.so.2.0.0: no symbols and : rpmbuild -bi SPECS/libtalloc.spec nm BUILDROOT/libtalloc-2.0.0-0.fc12.x86_64/usr/lib64/libtalloc.so.2.0.0 nm: BUILDROOT/libtalloc-2.0.0-0.fc12.x86_64/usr/lib64/libtalloc.so.2.0.0: no symbols while : tar -xzf rpmbuild/SOURCES/talloc-2.0.0.tar.gz cd talloc-2.0.0/ ./configure --prefix=/opt/talloc-2.0.0/ --enable-talloc-compat1 make sudo make install nm /opt/talloc-2.0.0/lib/libtalloc.so.2.0.0 00206700 a _DYNAMIC 002068d8 a _GLOBAL_OFFSET_TABLE_ w _Jv_RegisterClasses 002066d8 d __CTOR_END__ 002066d0 d __CTOR_LIST__ 002066e8 d __DTOR_END__ 0 and on and on 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Talloc
Can you explain what trouble the linker had with the installed talloc? I run the nightly tests of VTK and ParaView built with nightly Mesa (software rendering). It's sort of an early warning system that tells me if there will be problems with the next versions. Mesa git just merged it's glsl2 branch which pulled in a talloc requirement. Mesa builds fine if have libtalloc-devel installed but then VTK fails to build the tests with : /home/kevin/mesa/lib/libGL.so: undefined reference to `talloc_strdup' /home/kevin/mesa/lib/libGL.so: undefined reference to `_talloc_array' /home/kevin/mesa/lib/libGL.so: undefined reference to `_talloc_free' and on and on... Maybe mesa isn't adding -ltalloc All of this building from git/cvs repositories has me actually checking that nm will show me the symbols and I've never encountered a library for which nm said there were no symbols. 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Talloc
ALL? That hasn't been done. See nm -D ... Oh, nm -D does show me a lot of mostly unreadable text. Thank you. 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Talloc
ALL? That hasn't been done. See nm -D ... Oh, nm -D does show me a lot of mostly unreadable text. Thank you. Gah! All is good if I type : nm -D /usr/lib64/libtalloc.so.2.0.0 instead of : man -D /usr/lib64/libtalloc.so.2.0.0 which is what showed me all that junk. 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Breakin attempts
On 04/21/2010 02:07 AM, users-requ...@lists.fedoraproject.org wrote: Of course, combining methods can work nicely. Don't forget about the denyhosts package which will watch /var/log/secure for repeated failed login attempts and attempts for accounts like root and add the host to /etc/hosts.deny. 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Breakin attempts
On 04/21/2010 11:34 AM, users-requ...@lists.fedoraproject.org wrote: On 4/21/10, Kevin H. Hobbs hob...@ohiou.edu wrote: Don't forget about the denyhosts package which will watch /var/log/secure for repeated failed login attempts and attempts for accounts like root and add the host to /etc/hosts.deny. How can I tell if I have this package denyhosts package installed in F-12?? TIA Marvin Type rpm -q denyhosts in a terminal. 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 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
