I want to do some parallel programming on my nvidia GPU, and for that I
need cuda. The latest is cuda 7.5 and that requires gcc 4.9. I installed
cuda on my machine, but little did I know that fedora 24, which I recently
installed, came with gcc 6.1. I wasn't able to compile any of the cuda
examples. I asked on the nvidia forums about this and the next cuda
(version 8.0) will require gcc-5.3 or so. No indication when cuda will
work with gcc-6.1.
So what do I do now? From some posts I read it appears that debian
provides a gcc49 package, and so I hoped fedora would provide one too, but
no such luck. Can I rebuild the gcc-4.9 rpm on F24 without messing up the
stock gcc-6.1? Or, can I convert the gcc49.deb package into the equivalent
rpm? I can try these things and try to be careful not to mess up, but I
was wondering if anyone had any experience with this or any suggestions.
systemd and autofs/nfs are at war and have been ever since systemd
Specifically, if machine A has an open connection to machine B
and B goes down or become inaccessible, then A cannot shutdown.
A's shutdown sequence hangs, waiting for B to respond to an unmount
command, which will not/cannot happen.
WAITING WILL NOT HELP.
Only a dirty disconnect will work; there's no way to avoid it.
Here's what I've tried:
- Precede 'shutdown' or 'reboot' or 'systemctl reboot' with
umount -fl -t nfs <each nfs-mounted-filesystem>
(You might expect a forced lazy umount to do the job.
It doesn't work; umount just hangs)
- Change nfs mount option to 'soft' instead of 'hard'.
Edit /etc/nfsmount.conf to say:
(This did change the autofs/nfs mount option, but didn't improve
the tolerance for a dirty disconnect. Shutdown still hangs.)
- Reduce systemd's timeout values from 90 to 10 sec;
edit /etc/systemd/system.conf to say:
(During shutdown, systemd displays two times; the time it has waited
for an unmount event, and the time limit to wait. Incomprehensibly,
when the time limit is reached, it bumps it up and continues to wait.
Changing the default timeout values seems to accelerate this recycling,
but doesn't do anything for the actual time limit.)
- Change the nfs timeout from 600 (default) to 20 decisec to reduce
the time nfs waits for any response, including umount, before
declaring a timeout. Edit /etc/nfsmount.conf to say:
(The option displayed by the mount command did change, but it did not
help the shutdown hangup.)
- That leaves ONLY TWO WAYS to shutdown machine A, both ugly:
SysReq R E I S U B - which forces a reboot NOW
Hold the Power button - which just stops everything.
This is NOT NEW. Systemd has had this design defect from day one.
SysV never hung on shutdown. It Just Knew when a dirty disconnect
was the only viable way and handled it.
How many more years must we wait?
Have I overlooked something obvious? Is there a way to make systemd
perform the simple function 'shutdown' smoothly, reliably and quickly?
If anyone knows how, I would love to hear it.
David A. De Graaf DATIX, Inc. Hendersonville, NC
"Tolerance becomes a crime when applied to evil."
-- Thomas Mann
My F22 randomly crashes to a frozen state that requires a power cycle to restart.
When this happens, the time stamp on log files such as /var/log/messages
changes for a while before reverting to the correct date and time.
Today,the sequence was:
Jul 24 10:55:55 mustang rsyslogd: [origin software="rsyslogd"
swVersion="8.8.0" x-pid="853" x-info="http://www.rsyslog.com"] start
Jul 15 11:19:20 mustang systemd: Stopped target Default.
Jul 15 11:19:25 mustang systemd: Stopping Default.
followed by some 17,000 lines with Jul 15 through to:
Jul 15 19:28:11 mustang named: client 188.8.131.52#39431 (isc.org):
query (cache) 'isc.org/ANY/IN' denied
Jul 24 10:56:14 mustang rsyslogd-2177: imjournal: begin to drop messages due
Sun Jul 24 10:56:16 ACST 2016 rc.fw
Jul 24 11:06:11 mustang rsyslogd-2177: imjournal: 2971956 messages lost due to
A similar thing happens in /var/log/secure (though with fewer Jul 15 entries).
The Jul 15 dates have been appearing at/after the last two or three crashes.
Even though the Jul 15 entries look to span over eight hours, the actual time
span was only a minute or so.
Any suggestions as to what is happening here?
Cheers and thanks,
I moved from fc22 to fc24.
I used to connect to a 3G mobile broadband connection by doing:
mcli -m 0 --pin=xxx -i /org/freedesktop/ModemManager1/SIM/0 --simple-connect="apn=3G"
systemctl stop NetworkManager
ma connection to the provider
Unfortunately, after I moved to fc24, this does not work:
I get connection fails, Activation: failed for connection,
here is a part of /var/log/messages:
Jul 31 12:48:27 sophocle NetworkManager: <info> (ttyUSB4): device state change: config -> ip-config (reason 'none') [50 70 0]
Jul 31 12:48:27 sophocle NetworkManager: <warn> (ttyUSB4): interface ttyUSB4 not up for IP configuration
Jul 31 12:48:27 sophocle NetworkManager: <info> (ttyUSB4): using modem-specified IP timeout: 20 seconds
Jul 31 12:48:27 sophocle NetworkManager: <error> [1469962107.287907] [NetworkManagerUtils.c:352] nm_utils_modprobe(): modprobe: '/sbin/modprobe ppp_generic' exited with error 256 (modprobe: FATAL: Module ppp_generic not found in directory /lib/modules/4.4.13-200.fc22.i686)
Jul 31 12:48:27 sophocle NetworkManager: <info> starting PPP connection
Jul 31 12:48:27 sophocle NetworkManager: <info> pppd started with pid 5020
Jul 31 12:48:27 sophocle pppd: Plugin /usr/lib/pppd/2.4.7/nm-pppd-plugin.so loaded.
Jul 31 12:48:27 sophocle pppd: Couldn't open the /dev/ppp device: No such file or directory
Jul 31 12:48:27 sophocle pppd: You need to create the /dev/ppp device node by#012executing the following command as root:#012#011mknod /dev/ppp c 108 0
Jul 31 12:48:27 sophocle NetworkManager: <warn> pppd pid 5020 exited with error: No ppp module error
Jul 31 12:48:27 sophocle NetworkManager: <info> (ttyUSB4): device state change: ip-config -> failed (reason 'ip-config-unavailable') [70 120 5]
Jul 31 12:48:27 sophocle NetworkManager: <info> NetworkManager state is now CONNECTED_LOCAL
Can somebody help me?
Patrick DUPRÉ | | email: pdupre(a)gmx.com
Laboratoire de Physico-Chimie de l'Atmosphère | |
Université du Littoral-Côte d'Opale | |
Tel. (33)-(0)3 28 23 76 12 | | Fax: 03 28 65 82 44
189A, avenue Maurice Schumann | | 59140 Dunkerque, France
I came across this video; https://youtu.be/jwhFr5Ax3Fk
Setting aside the cheese at the end, it actually seems like a
brilliant idea. I wonder if anyone knows of anything like this for using
android tablets as second/third displays on Fedora? This would make dev
work sooooo much nicer!
I generally don't use an external monitor simply because they're not
portable. A tablet or two though... :D
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?
I have an old Dell Vostro 1500 laptop. It was running
Fedora 17 with no problems with the bluetooth mouse I use.
After a fresh install of Fedora 24 Workstation I can't
get the mouse to reconnect after a boot. Systemctl
reports bluetoothd 'Failed to obtain handles for
"Serviced Changed" characteristic'. Both blueman-manager
and blueman-applet report the adapter is off and are
unable to turn it on.
I can go into bluetoothctl, power on the adapter and
connect to the mouse. Things are fine until a reboot.
lshw reports the bluetooth adapter is a Broadcom BCM2045.
Any thoughts on how to get the adapter powered on at boot
and the mouse auto-reconnected as it nicely did 7 Fedora
Jon H. LaBadie jonfu(a)jgcomp.com
My problem is this --- on Fedora 23 I was managing my network interface
my self since Network Manager was causing problems. Now in F24, I
noticed that my nic now has the SLAVE flag on. I do not have any
network access at all. I tried allowing Network Manager to control the
device but still had the same problem.
I am writing this using the F23 kernel. My configuration looks like
There was a thread on here recently about ssh agent forwarding. Usually
I start it like this:
I came across a situation where I couldn't establish a connection to the
agent when I tried to "ssh-add" my keys. ssh-agent had been executed
already. It had somehow become discombobulated.
The solution was to invoke ssh-agent differently:
eval `ssh-agent -s`
Hope that saves somebody else some headaches ;D
Something changed (although not fatally):
I use Bluetooth speakers quite often.
Back in F22 or so after pairing the device merely turning it on caused
Fedora to connect to it.
Several months ago, now on F23, (not sure when this problem appeared)
that changed and after turning the speaker on, I have to go into
Bluetooth Settings where the device appears as "Disconnected", select it
and activate the "Connection" switch several times and it will
eventually connect and be available for selection in the "Sound
Settings" after which it works fine.
Is there a path back?
The setup is up to date Fedora 23 using Gnome 3.18.1-1.fc23.x86_64
Roger Wells, P.E.
221 Third St
Newport, RI 02840