Recently I have been having problems with my machine completely freezing up
seemingly randomly. The display freezes in its current frame, and all I/O
is completely unresponsive. It is not possible to SSH into it at this stage
(ssh fails with a Host Unreachable error). The only remedy is a manual
I was wondering how I could go about trying to figure out what is going on?
What log files can I look at to figure out what happened just before the
reset etc? Would be grateful for any help.
My specs are the following:
Fedora 17 standard desktop version, completely updated as of June 17, 2012.
i7-3930K clocked at 4.2Ghz with 1.240 vcore (stable)
Nvidia GTX285 (main suspect, since it is provably broken. However, I have
not had these problems earlier)
SATA HDD from Seagate.
Pretty much as the subject says, I guess...
I can't seem to find the definitive (or any) answer on the web site.
The 'Upgrading Fedora using yum' section goes through the necessary
steps using dracut. I'm assuming these steps are not required before
running preupgrade in F16?
Warp Universal Limited
Just installed F17 on an old laptop. Gnome 3 is coming up in fallback;
is there any way to get Gnome shell instead?
My Googling on on the subject seems to indicate that:
* the Intel 8xx graphics have buggy 3D, so are blanket disabled
in Gnome 3;
* but that starting in F17, Gnome Shell should be able to work with 2D
You live and learn (although usually you just live).
Does anyone know how to allow root and users other than me to use the
Ever since pulseaudio was introduced in Fedora 8 and Mr. Lennart
Poettering inflicted his peculiar ideas of security on us, the default
installation hasn't worked properly, despite many BZ's and copious
complaints! Specifically, pulseaudio invents the "seat" and only the
one person in the "seat" can use the sound system. This precludes
having root, or anyone else, from generating sounds - presumably it's a
security risk. Bosh!
A simple workaround was found - remove the alsa-plugins-pulseaudio
package, and edit /etc/group, adding everyone on the system to the
audio group (what a nutty idea). That removed the restrictions and
restored sanity. Root could even generate a login tune via the
/etc/rc.d/rc.local script, before anyone had logged on.
With F17, this escape hatch has been removed.
With the alsa-plugins-pulseaudio package absent, a simple command to
play a sound yields a core dump:
$ play /usr/share/sounds/KDE-Sys-Log-In.ogg
dsp_protocol_open_node(): Could not open pcm device file /dev/dsptask/pcm2
Segmentation fault (core dumped)
The pcm device file is, indeed, absent from the file system.
In fact, no sounds whatever can be generated by any of the standard
methods I use. (Except that Windows running inside VirtualBox seems
able to manage it.)
To get any sound at all, I've had to reinstall the
alsa-plugins-pulseaudio package, but this allows only me to generate
sound and destroys my crontab-simulated grandfather clock, among other
On an i386 netbook, F17 sound works fine, as it always has, with the
alsa-plugins-pulseaudio package removed. The play program doesn't
complain about the absence of /dev/dsptask/pcm2, but just plays the
What new magic incantation is now required that I may be permitted
to use my x86_64 sound system fully?
David A. De Graaf DATIX, Inc. Hendersonville, NC
This problem has been submitted to Bugzilla (836657), but I thought I'd
ask here to see if there are any fixes lurking.
System is running 3.4.3-1.fc17.x86_64. When I systemctl poweroff the
kernel reboots instead of powering off. Under Windows 7, power off
works as expected. All packages are up-to-date.
Hi, I in danger of making this a rant, but is XDMCP no longer something
that Fedora supports?
I have just installed F17 x64 in a VM to tinker with it and systemd and
I'd like to enable XDMCP. Or what is the favoured remote access method
I've put DisallowTCP=0 in the [security] section and Enable=1 in the
[xdmcp] section of custom.conf in /etc/gdm/ and opened port 177 UDP in
the firewall on the F17 machine.
Oddly, on my remote X server when I run "X -query machinename :1" the
desktop of the remote X server freezes when connecting to this rogue F17
install. As I would expect I can see an open UDP session on UDP 177 but
I don't see any traffic on TCP 6000 or 6001 that I would expect. The
same remote X server connects to FC6, Centos5.6 etc etc without any issue.
Thanks for any hints and guidance.
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
what is this in dmesg?
why is "--log-prefix" here loggd instead the --log-prefix from whatever rule it was?
--log-prefixIN=eth1 OUT= MAC=00:50:8d:b5:cc:de:00:01:5c:24:68:01:08:00 SRC=22.214.171.124 DST=126.96.36.199 LEN=60
TOS=0x00 PREC=0x00 TTL=51 ID=58168 DF PROTO=TCP SPT=39903 DPT=19 WINDOW=5840 RES=0x00 SYN URGP=0
is this more likely a kernel-bug or rsyslog?
After last google chrome update I have problem to display any flash
contents in full screen mode. After investigation in chrome://plugins I
find 2 plugins under flash. One is from google installation directory
PaperFlash/libpepflashplayer.so and second one is in
libpepflashplayer.so - 188.8.131.52
libflashplayer.so - 11.2 r202
For now only solution I found is to disable PepperFlash from chrome and
leave flash-plugin enabled.
Fortunately Firefox is not affected with google PepperFlush bug.