This seems to happen in many different drivers but it happened more often in newer versions such as 530 vs 525. Then nvidia-modeset goes to 100% There are many reports of this appearing since driver 4.70 and I can confirm I've seen this in various machines. https://forums.de........

You can read lots of posts about this issue but there is not much information about why this is the case or how grub determines the root= device name. Some even suggest modifying grub.cfg manually which is a disaster as the next kernel update will cause grub to revert back to the device name. For most people this won't be an issue but those using template system, automated deployments and working in embedded may run into this issue with custom embedded and created minimal kernel........

It may appear to be an Xorg or lightdm/gdm/mdm error but in reality for many users with this issue, it's a driver conflict and issue. I had a system that had two GPUs, an Intel and Nvidia GPU. The only thing that got it working was to remove the nouveau driver and blacklist it so it never came back, then the Intel GPU works fine without these issues. Solution sudo rmmod nouveau add nouveau/other driver to blacklist edit th........

One simple flag to configure will create a makefile that statically links all the shared objects and embeds them instead the binary execute. This means as long as you have the same architecture that things should run. Eg. if you have an old version of Debian with a different version of glibc, then this will solve that problem. ./configure LDFLAGS="-static" To test that it is really statically linked run ldd: ldd src/wget........

This is not so much of a vi error as it is a physical filesystem error in the sense that the file you are trying to write to is a symlink and the destination doesn't exist or for some other reason is inacessible. So vi is tellng you "you're writing to a symlinked file and the file the symlink points to cannot be written to". This is especially highlighted byt he fact that if you are using wq! to write and you still get the error.........

When running cudaminer once it tries to initialize the card the entire screen freezes. The computer itself is still running but the Xorg is done for, you cannot even switch to another console window and must reboot (even an mdm or Xorg restart does not help). At first cudaminer will give you these errors: stratrum_recv_line failed ...retry after 15 seconds GPU #0: Geforce 210 with compute ca........

ecryptfs-mount-private Enter your login passphrase: Inserted auth tok with sig [ee16d84] "into the user session keyring mount: No such file or directory" [ 156.118113] ecryptfs_mount: kern_path() failed [ 156.118431] Reading sb failed; rc = [-2] [ 164.233055] traps: mate-notificati[3472] trap int3 ip:7f43d7002c13 sp:7fff162c6600 error:0 [ 166.017061] ecryptfs_mount: kern_path() failed........

The solution is simple but strange, if you copy your /var/lib/mysql directory to another server and think it will work, be sure to check if you have /var/log/mysql and binary log files. If you do, the server will not work and will give you errors like below and crash without the proper log files. UPDATE user SET password=password("newpass") WHERE user='root'; flush privileges; ERROR 2013 (HY000): Lost connection to MySQL server durin........

This can be very tricky, say you are doing development on a file that is symlinked. Doing a "cp dev.file dev.file-bk" won't do what you expect, it just links back to the same file so you haven't copied or backed anything up. You need the "-H" switch to copy the actual file that is referenced by the symlink: cp -Hdev.file dev.file-bk........

/scripts/phpextensionmgr install PHPSuHosin Updating md5sum list Fetching http://httpupdate.cpanel.net/cpanelsync/easy/targz.yaml (connected:0).......(request attempt 1/12)...Resolving httpupdate.cpanel.net...(resolve attempt 1/65)... Fetching http://httpupdate.cpanel.net/mirror_addr_list (connected:0).......(request attempt 1/3)......connecting to 74.50.120.123...@74.50.120.123......connected......receiving...100%......request success......Done........

I thought only a faster CPUand SSDwould help but I already have a Quad-Core CPU and it wasn't being maxed out. The actual tests were performed on an AMD-V enabled 128MB dual core VMWare container though. There is a flag that can be passed to make in order to start multiple threads, by specifying 4 threads I was able to reduce the whole kernel compilation time from scratch by about 50%! (65minutes vs 31minutes!). *Yes I did do a make clean before each co........

CPU/Kernel/MB/RAID problem? Jan 5 12:45:05 testbox kernel: [653298.890004] BUG: soft lockup - CPU#0 stuck for 61s! [hal-acl-tool:4168] Jan 5 12:45:05 testbox kernel: [653298.890005] Modules linked in: vmnet vmci vmmon binfmt_misc drbd video output input_polldev ocfs2_stackglue ocfs2_dlmfs ocfs2_dlm ocfs2_nodemanager configfs k8temp hwmon_vid lp snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi........

Nov 29 20:17:58 ubuntu kernel: [ 1157.180789] md: md1 stopped. Nov 29 20:17:58 ubuntu kernel: [ 1157.180829] md0: unknown partition table filesystem not responding/reading properly with du or rsync (this needed an fsck). [ 2571.489217] EXT3-fs error (device md2): ext3_lookup: deleted inode referenced: 35923106 [ 2571.942299] EXT3-fs error (device md2): ext3_lookup: deleted inode referenced: 35923110 [ 2571.9568........

This is obviously a bug in the r8169 kernel module and it seems to affect a lot of people. I upgraded to the latest kernel and hope this won't happen anymore, as it is a very serious error. This is especially serious for those who are running servers with this chipset, who can afford for the NIC to randomly go off-line for no apparent reason? [655548.189113] type=1505 audit(1277067560.902:5): operation="profile_load" name="/usr/bin/freshclam&q........

When trying to even cd or ls the mounted OCFS2 partition it crashes. Ithink this is a combination of VMWare Server's problem and the way I mounted and symlinked to it. More than anything this shows the problem and lack of forsight with VMWare, but also that OCFS2 is easily crashed if you do strange things. Output of /var/log/messages for OCFS2 Apr 10 15:57:45 localhost kernel: [84331.691258] Modules linked in: vmnet vmci vmmon ocfs2_stac........