Filesystem filling up due to large uvcydnctrl-udev.log file
up vote
10
down vote
favorite
Now my installation of Ubuntu costs me more than 100 GB of the hard drive space. And whenever I try fslint
and fdupes
, they say Permission denied
to delete the duplicates. Please help me guys.
Additional Info
Output of df
:
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 296G 191G 90G 68% /
udev 993M 4.0K 993M 1% /dev
tmpfs 401M 824K 401M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 1003M 552K 1002M 1% /run/shm
/home/zipro/.Private 296G 191G 90G 68% /home/zipro
The faulty file is a 174GB /var/log/uvcydnctrl-udev.log
filesystem log duplicate-files maintenance
add a comment |
up vote
10
down vote
favorite
Now my installation of Ubuntu costs me more than 100 GB of the hard drive space. And whenever I try fslint
and fdupes
, they say Permission denied
to delete the duplicates. Please help me guys.
Additional Info
Output of df
:
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 296G 191G 90G 68% /
udev 993M 4.0K 993M 1% /dev
tmpfs 401M 824K 401M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 1003M 552K 1002M 1% /run/shm
/home/zipro/.Private 296G 191G 90G 68% /home/zipro
The faulty file is a 174GB /var/log/uvcydnctrl-udev.log
filesystem log duplicate-files maintenance
2
This is still a problem in Ubuntu 14.04 LTS
– Andrew Fielden
Nov 8 '14 at 20:39
add a comment |
up vote
10
down vote
favorite
up vote
10
down vote
favorite
Now my installation of Ubuntu costs me more than 100 GB of the hard drive space. And whenever I try fslint
and fdupes
, they say Permission denied
to delete the duplicates. Please help me guys.
Additional Info
Output of df
:
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 296G 191G 90G 68% /
udev 993M 4.0K 993M 1% /dev
tmpfs 401M 824K 401M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 1003M 552K 1002M 1% /run/shm
/home/zipro/.Private 296G 191G 90G 68% /home/zipro
The faulty file is a 174GB /var/log/uvcydnctrl-udev.log
filesystem log duplicate-files maintenance
Now my installation of Ubuntu costs me more than 100 GB of the hard drive space. And whenever I try fslint
and fdupes
, they say Permission denied
to delete the duplicates. Please help me guys.
Additional Info
Output of df
:
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 296G 191G 90G 68% /
udev 993M 4.0K 993M 1% /dev
tmpfs 401M 824K 401M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 1003M 552K 1002M 1% /run/shm
/home/zipro/.Private 296G 191G 90G 68% /home/zipro
The faulty file is a 174GB /var/log/uvcydnctrl-udev.log
filesystem log duplicate-files maintenance
filesystem log duplicate-files maintenance
edited Feb 22 '14 at 20:30
Seth♦
33.4k25109159
33.4k25109159
asked Aug 18 '12 at 6:36
user84055
108129
108129
2
This is still a problem in Ubuntu 14.04 LTS
– Andrew Fielden
Nov 8 '14 at 20:39
add a comment |
2
This is still a problem in Ubuntu 14.04 LTS
– Andrew Fielden
Nov 8 '14 at 20:39
2
2
This is still a problem in Ubuntu 14.04 LTS
– Andrew Fielden
Nov 8 '14 at 20:39
This is still a problem in Ubuntu 14.04 LTS
– Andrew Fielden
Nov 8 '14 at 20:39
add a comment |
6 Answers
6
active
oldest
votes
up vote
10
down vote
accepted
1. Step: Find out what problem you actually have
When your filesystem is unexpectedly full, there are a lot of possible causes. See Eliah Kagan's answer for some more about this. In the vast majority of cases it should be easy to identify (and eventually repair) the real cause, so reformatting/reinstalling would not be necessary.
So the first step is to find out, what exactly is the problem, i.e., where has the missing space gone. So first execute
df -hl -x tmpfs -x devtmpfs
This shows a list of all the used partitions of the disks in your machine, their size, how full they are and their mount point. From this list, take the one which you think is too full and note its mount point. In your case, it is the root file system which is mounted at /
.
Now we analyze where inside this file system the space is used. Execute
sudo du -xhsc /* 2> /dev/null
(Replace /
with the mount point identified above.)
It needs sudo because not all directories might be readable for your user. It may take some time (especially on large file systems) because it needs to visit every single directory on them.
What this command does is to show you each file and directory inside the given directory together with its size (including subdirectories).
So from this list take the one(s) which you think is larger than it should be, and call the command again on this directory. (That is, run the command again, but with the name of a big directory from a previous listing replacing /
.)
For example, in your case it was clear /var
was the only big directory, so you would need to execute
sudo du -xhsc /var/* 2> /dev/null
Continue with these steps until you have either found a single file which is so big, or you have found a directory with lots of files that together take up all that space.
In your case the next step was to execute
sudo du -xhsc /var/log/* 2> /dev/null
because /var/log
was so big, and this showed you that there was a single log file named uvcdynctrl-udev.log
with 174GB (which is obviously bad).
2. Step: Identify why the files are there and why there are so big
Now we need to find out why the identified are there, or why they are so big, if they are expected to be there.
In your case, a log file in /var/log
is nothing suspicious, but its size surely is. Fortunately, a Google search simply with the file name brings up the following bug report as the first hit, which is clearly the same problem as we have: http://bugs.launchpad.net/ubuntu/+source/libwebcam/+bug/811604
3. Step: Solve the problem
In this case, a log file of some webcam-related stuff seems not to be interesting, so we can easily delete it with the command sudo rm /var/log/uvcdynctrl-udev.log
and free all the space.
Unfortunately, the bug report is still open, and there are no solutions or workarounds in the comments, so you probably have to live with this bug for now. You can delete the log file from time to time to free some space.
add a comment |
up vote
6
down vote
If you copied and pasted the system files, manually reproducing them, then you should provide more information about what you did to copy and paste them, where you pasted them, anything you can remember. Even making an extra copy of all the system files on your machine is unlikely to cause anywhere near 100 GB of disk usage. Ubuntu requires less than 5 GB of available space to be installed, and even an Ubuntu system with many packages installed is unlikely for its system files to take up more than several times that size. You would probably have to make many copies to take up that much space. Or perhaps you copied files other than system files?
If your Ubuntu system has expanded by itself (from log files and updates‽) to take up 100 GB of space (or 50 GB of space), just in system files (as opposed to your documents, pictures, videos, virtual machines, and so forth), something is very wrong. The three most likely general causes of this are probably:
- This is not really happening, and you have misinterpreted information that your system has provided you. (Please note that I am not telling you that you are mistaken; if you know how you came to have 100 GB of system files, then neither this nor the other two suggested causes below is correct.)
- There is a bug, which affects your system, and which causes used and free space to be reported incorrectly.
- There is a pretty serious bug, which affects your system, and which causes files (perhaps log files in
/var/log
) to grow at an extremely high rate and without bound.
As Sergey has said, indiscriminately deleting all files that have the same contents will quite likely cause damage to your system. For example, there are a number of blank files that might exist in your system and are used as locks or to signify some condition. You may also have programs that contain separate copies of identical files (when the files provide the same functionality for both programs, which has not been removed to a separate library or package).
You can probably get it to delete the "duplicate" files by running it as root
. But you should really not do that--it will likely wreak grave harm on your Ubuntu system.
You asked in a comment:
IS there anyway to command fdupes to delete all the duplicates without asking or notifying me?
fdupes -f
might do what you want. See the fdupes
manpage. But you should really not do this.
Instead, you should figure out what is going on. If you want us to help you with that, we certainly will. If you expand your question to explain that you want help figuring out what's taking up space, then you'll either get answers providing that information, or this may be closed as a duplicate of another question that provides information about how to find that out. (Either situation would be likely to benefit you.) Of course, this is assuming you want us to help you find the cause of your system taking up so much space (or seeming to).
The first step to investigate this is to examine (and post, by editing your question) the output of these commands, which provide detailed information about what disks you have and how much space is free on them:
mount
df -h
sudo du -sh /*
You can run those commands in a Terminal window (Ctrl+Alt+T). The last command will take a while. You may also get some Permission denied
errors (even though you're running it as root), mostly regarding .gvfs
folders in users' home directories. That's nothing to worry about.
add a comment |
up vote
4
down vote
I have a quick and dirty solution(definitely prevent log file writing, but doesn't solve the root problem):
this log file is written by /lib/udev/uvcdynctrl
- Backup original
sudo cp /lib/udev/uvcdynctrl /lib/udev/uvcdynctrl_backup
- Edit original
gksu gedit /lib/udev/uvcdynctrl
- Look up all elements that are in such form "debug=1"
- Change to "debug=0"
- Delete the log file once and for all
sudo rm /var/log/uvcdynctrl-udev.log
add a comment |
up vote
2
down vote
Go into the Terminal
(short cut is Ctrl+Alt+t) and type:
gksudo nautilus
This will open Nautilus with root permissions. Now delete your files.
Hope this helps you!
it doesn’t help,there are 10000s of files
– user84055
Aug 18 '12 at 7:22
How did you make 10000s of copies. Do the duplicates look like this. If so, can't you just select one file, press shift, and then select all of them, and then delete them.
– Max Tither
Aug 18 '12 at 7:27
the problem is i cant find the specific files which have been duplicated because i dont know which files haven copied and the locations of them.
– user84055
Aug 18 '12 at 7:37
I found a bash script to find duplicate files. It will find them and move them to a folder. Then you can just delete the duplicate folder.
– Max Tither
Aug 18 '12 at 7:42
no luck with it.It quits after running for 2minutes.
– user84055
Aug 18 '12 at 8:43
|
show 1 more comment
up vote
1
down vote
The problem IS this package: uvcdynctrl-udev.
It's a useles and buggie program. It should be simply removed from debian and ubuntu repos. It shoudn't be installed. This package not only creates this HUGE log files, but it also causes Cheese and other web-cam apps to crash or work very badly (Can't capture video at full resolution with Cheese or Guvcview? REMOVE THIS PACKAGE AND IT WORKS AS IT SHOULD!
This bug has been around for years and the manteiner of uvcdyn.... doesn't seem to care about it.
The solution is simple: sudo apt-get remove uvcdynctrl-udev.
If you wanna be sure about what you are doing, use Synaptic instead. Serch for the buggie package uvcdynctrl-udev and uvcdynctrl-udev-data. Mark'em for complete removal. You'll notice it wont affect other programs, they're not dependencies, so you can safely remove it. Do it.
Then check /var/log, search this huge uvcdynctrl-udev.log, as root, delete it. (open a terminal
**
cd /var/log
sudo rm uvcdynctrl-udev.log
**
)
Believe me, you wont miss this package.
add a comment |
up vote
-1
down vote
I think the best thing here is to just reinstall, considering the apparent amount of damage, the fact it's fairly unclear what's actually happened, and your low comfort level in manually repairing it.
Preserve your home directory (do not reformat or repartition) and reinstall and that should clear out the system directories.
1
While reinstallation is certainly an option, it's usually pretty easy to figure out where large files have been copied, or if there are system files increasing uncontrollably in size, which files they are.
– Eliah Kagan
Aug 18 '12 at 10:45
@Eliah, I'm sure you and I would find it easy, but I'm not sure the OP will. And, if not a lot of time has been invested in the machine (I'm not going to even mention config backups) blowing it away may be the most efficient choice.
– poolie
Aug 18 '12 at 10:47
1
Note that this wouldn't help here. His/home
is on the same partition as/
, so he cant clear that partition. And I don
t think the installer deletes any superfluous files on the partition it is going to use for installation (either all or none).
– Philipp Wendler
Aug 18 '12 at 10:59
2
The installer will remove everything in /var except /var/local so this answer is a viable option.
– Jorge Castro
Aug 18 '12 at 15:16
add a comment |
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
10
down vote
accepted
1. Step: Find out what problem you actually have
When your filesystem is unexpectedly full, there are a lot of possible causes. See Eliah Kagan's answer for some more about this. In the vast majority of cases it should be easy to identify (and eventually repair) the real cause, so reformatting/reinstalling would not be necessary.
So the first step is to find out, what exactly is the problem, i.e., where has the missing space gone. So first execute
df -hl -x tmpfs -x devtmpfs
This shows a list of all the used partitions of the disks in your machine, their size, how full they are and their mount point. From this list, take the one which you think is too full and note its mount point. In your case, it is the root file system which is mounted at /
.
Now we analyze where inside this file system the space is used. Execute
sudo du -xhsc /* 2> /dev/null
(Replace /
with the mount point identified above.)
It needs sudo because not all directories might be readable for your user. It may take some time (especially on large file systems) because it needs to visit every single directory on them.
What this command does is to show you each file and directory inside the given directory together with its size (including subdirectories).
So from this list take the one(s) which you think is larger than it should be, and call the command again on this directory. (That is, run the command again, but with the name of a big directory from a previous listing replacing /
.)
For example, in your case it was clear /var
was the only big directory, so you would need to execute
sudo du -xhsc /var/* 2> /dev/null
Continue with these steps until you have either found a single file which is so big, or you have found a directory with lots of files that together take up all that space.
In your case the next step was to execute
sudo du -xhsc /var/log/* 2> /dev/null
because /var/log
was so big, and this showed you that there was a single log file named uvcdynctrl-udev.log
with 174GB (which is obviously bad).
2. Step: Identify why the files are there and why there are so big
Now we need to find out why the identified are there, or why they are so big, if they are expected to be there.
In your case, a log file in /var/log
is nothing suspicious, but its size surely is. Fortunately, a Google search simply with the file name brings up the following bug report as the first hit, which is clearly the same problem as we have: http://bugs.launchpad.net/ubuntu/+source/libwebcam/+bug/811604
3. Step: Solve the problem
In this case, a log file of some webcam-related stuff seems not to be interesting, so we can easily delete it with the command sudo rm /var/log/uvcdynctrl-udev.log
and free all the space.
Unfortunately, the bug report is still open, and there are no solutions or workarounds in the comments, so you probably have to live with this bug for now. You can delete the log file from time to time to free some space.
add a comment |
up vote
10
down vote
accepted
1. Step: Find out what problem you actually have
When your filesystem is unexpectedly full, there are a lot of possible causes. See Eliah Kagan's answer for some more about this. In the vast majority of cases it should be easy to identify (and eventually repair) the real cause, so reformatting/reinstalling would not be necessary.
So the first step is to find out, what exactly is the problem, i.e., where has the missing space gone. So first execute
df -hl -x tmpfs -x devtmpfs
This shows a list of all the used partitions of the disks in your machine, their size, how full they are and their mount point. From this list, take the one which you think is too full and note its mount point. In your case, it is the root file system which is mounted at /
.
Now we analyze where inside this file system the space is used. Execute
sudo du -xhsc /* 2> /dev/null
(Replace /
with the mount point identified above.)
It needs sudo because not all directories might be readable for your user. It may take some time (especially on large file systems) because it needs to visit every single directory on them.
What this command does is to show you each file and directory inside the given directory together with its size (including subdirectories).
So from this list take the one(s) which you think is larger than it should be, and call the command again on this directory. (That is, run the command again, but with the name of a big directory from a previous listing replacing /
.)
For example, in your case it was clear /var
was the only big directory, so you would need to execute
sudo du -xhsc /var/* 2> /dev/null
Continue with these steps until you have either found a single file which is so big, or you have found a directory with lots of files that together take up all that space.
In your case the next step was to execute
sudo du -xhsc /var/log/* 2> /dev/null
because /var/log
was so big, and this showed you that there was a single log file named uvcdynctrl-udev.log
with 174GB (which is obviously bad).
2. Step: Identify why the files are there and why there are so big
Now we need to find out why the identified are there, or why they are so big, if they are expected to be there.
In your case, a log file in /var/log
is nothing suspicious, but its size surely is. Fortunately, a Google search simply with the file name brings up the following bug report as the first hit, which is clearly the same problem as we have: http://bugs.launchpad.net/ubuntu/+source/libwebcam/+bug/811604
3. Step: Solve the problem
In this case, a log file of some webcam-related stuff seems not to be interesting, so we can easily delete it with the command sudo rm /var/log/uvcdynctrl-udev.log
and free all the space.
Unfortunately, the bug report is still open, and there are no solutions or workarounds in the comments, so you probably have to live with this bug for now. You can delete the log file from time to time to free some space.
add a comment |
up vote
10
down vote
accepted
up vote
10
down vote
accepted
1. Step: Find out what problem you actually have
When your filesystem is unexpectedly full, there are a lot of possible causes. See Eliah Kagan's answer for some more about this. In the vast majority of cases it should be easy to identify (and eventually repair) the real cause, so reformatting/reinstalling would not be necessary.
So the first step is to find out, what exactly is the problem, i.e., where has the missing space gone. So first execute
df -hl -x tmpfs -x devtmpfs
This shows a list of all the used partitions of the disks in your machine, their size, how full they are and their mount point. From this list, take the one which you think is too full and note its mount point. In your case, it is the root file system which is mounted at /
.
Now we analyze where inside this file system the space is used. Execute
sudo du -xhsc /* 2> /dev/null
(Replace /
with the mount point identified above.)
It needs sudo because not all directories might be readable for your user. It may take some time (especially on large file systems) because it needs to visit every single directory on them.
What this command does is to show you each file and directory inside the given directory together with its size (including subdirectories).
So from this list take the one(s) which you think is larger than it should be, and call the command again on this directory. (That is, run the command again, but with the name of a big directory from a previous listing replacing /
.)
For example, in your case it was clear /var
was the only big directory, so you would need to execute
sudo du -xhsc /var/* 2> /dev/null
Continue with these steps until you have either found a single file which is so big, or you have found a directory with lots of files that together take up all that space.
In your case the next step was to execute
sudo du -xhsc /var/log/* 2> /dev/null
because /var/log
was so big, and this showed you that there was a single log file named uvcdynctrl-udev.log
with 174GB (which is obviously bad).
2. Step: Identify why the files are there and why there are so big
Now we need to find out why the identified are there, or why they are so big, if they are expected to be there.
In your case, a log file in /var/log
is nothing suspicious, but its size surely is. Fortunately, a Google search simply with the file name brings up the following bug report as the first hit, which is clearly the same problem as we have: http://bugs.launchpad.net/ubuntu/+source/libwebcam/+bug/811604
3. Step: Solve the problem
In this case, a log file of some webcam-related stuff seems not to be interesting, so we can easily delete it with the command sudo rm /var/log/uvcdynctrl-udev.log
and free all the space.
Unfortunately, the bug report is still open, and there are no solutions or workarounds in the comments, so you probably have to live with this bug for now. You can delete the log file from time to time to free some space.
1. Step: Find out what problem you actually have
When your filesystem is unexpectedly full, there are a lot of possible causes. See Eliah Kagan's answer for some more about this. In the vast majority of cases it should be easy to identify (and eventually repair) the real cause, so reformatting/reinstalling would not be necessary.
So the first step is to find out, what exactly is the problem, i.e., where has the missing space gone. So first execute
df -hl -x tmpfs -x devtmpfs
This shows a list of all the used partitions of the disks in your machine, their size, how full they are and their mount point. From this list, take the one which you think is too full and note its mount point. In your case, it is the root file system which is mounted at /
.
Now we analyze where inside this file system the space is used. Execute
sudo du -xhsc /* 2> /dev/null
(Replace /
with the mount point identified above.)
It needs sudo because not all directories might be readable for your user. It may take some time (especially on large file systems) because it needs to visit every single directory on them.
What this command does is to show you each file and directory inside the given directory together with its size (including subdirectories).
So from this list take the one(s) which you think is larger than it should be, and call the command again on this directory. (That is, run the command again, but with the name of a big directory from a previous listing replacing /
.)
For example, in your case it was clear /var
was the only big directory, so you would need to execute
sudo du -xhsc /var/* 2> /dev/null
Continue with these steps until you have either found a single file which is so big, or you have found a directory with lots of files that together take up all that space.
In your case the next step was to execute
sudo du -xhsc /var/log/* 2> /dev/null
because /var/log
was so big, and this showed you that there was a single log file named uvcdynctrl-udev.log
with 174GB (which is obviously bad).
2. Step: Identify why the files are there and why there are so big
Now we need to find out why the identified are there, or why they are so big, if they are expected to be there.
In your case, a log file in /var/log
is nothing suspicious, but its size surely is. Fortunately, a Google search simply with the file name brings up the following bug report as the first hit, which is clearly the same problem as we have: http://bugs.launchpad.net/ubuntu/+source/libwebcam/+bug/811604
3. Step: Solve the problem
In this case, a log file of some webcam-related stuff seems not to be interesting, so we can easily delete it with the command sudo rm /var/log/uvcdynctrl-udev.log
and free all the space.
Unfortunately, the bug report is still open, and there are no solutions or workarounds in the comments, so you probably have to live with this bug for now. You can delete the log file from time to time to free some space.
edited Aug 21 '12 at 18:20
answered Aug 18 '12 at 10:45
Philipp Wendler
961629
961629
add a comment |
add a comment |
up vote
6
down vote
If you copied and pasted the system files, manually reproducing them, then you should provide more information about what you did to copy and paste them, where you pasted them, anything you can remember. Even making an extra copy of all the system files on your machine is unlikely to cause anywhere near 100 GB of disk usage. Ubuntu requires less than 5 GB of available space to be installed, and even an Ubuntu system with many packages installed is unlikely for its system files to take up more than several times that size. You would probably have to make many copies to take up that much space. Or perhaps you copied files other than system files?
If your Ubuntu system has expanded by itself (from log files and updates‽) to take up 100 GB of space (or 50 GB of space), just in system files (as opposed to your documents, pictures, videos, virtual machines, and so forth), something is very wrong. The three most likely general causes of this are probably:
- This is not really happening, and you have misinterpreted information that your system has provided you. (Please note that I am not telling you that you are mistaken; if you know how you came to have 100 GB of system files, then neither this nor the other two suggested causes below is correct.)
- There is a bug, which affects your system, and which causes used and free space to be reported incorrectly.
- There is a pretty serious bug, which affects your system, and which causes files (perhaps log files in
/var/log
) to grow at an extremely high rate and without bound.
As Sergey has said, indiscriminately deleting all files that have the same contents will quite likely cause damage to your system. For example, there are a number of blank files that might exist in your system and are used as locks or to signify some condition. You may also have programs that contain separate copies of identical files (when the files provide the same functionality for both programs, which has not been removed to a separate library or package).
You can probably get it to delete the "duplicate" files by running it as root
. But you should really not do that--it will likely wreak grave harm on your Ubuntu system.
You asked in a comment:
IS there anyway to command fdupes to delete all the duplicates without asking or notifying me?
fdupes -f
might do what you want. See the fdupes
manpage. But you should really not do this.
Instead, you should figure out what is going on. If you want us to help you with that, we certainly will. If you expand your question to explain that you want help figuring out what's taking up space, then you'll either get answers providing that information, or this may be closed as a duplicate of another question that provides information about how to find that out. (Either situation would be likely to benefit you.) Of course, this is assuming you want us to help you find the cause of your system taking up so much space (or seeming to).
The first step to investigate this is to examine (and post, by editing your question) the output of these commands, which provide detailed information about what disks you have and how much space is free on them:
mount
df -h
sudo du -sh /*
You can run those commands in a Terminal window (Ctrl+Alt+T). The last command will take a while. You may also get some Permission denied
errors (even though you're running it as root), mostly regarding .gvfs
folders in users' home directories. That's nothing to worry about.
add a comment |
up vote
6
down vote
If you copied and pasted the system files, manually reproducing them, then you should provide more information about what you did to copy and paste them, where you pasted them, anything you can remember. Even making an extra copy of all the system files on your machine is unlikely to cause anywhere near 100 GB of disk usage. Ubuntu requires less than 5 GB of available space to be installed, and even an Ubuntu system with many packages installed is unlikely for its system files to take up more than several times that size. You would probably have to make many copies to take up that much space. Or perhaps you copied files other than system files?
If your Ubuntu system has expanded by itself (from log files and updates‽) to take up 100 GB of space (or 50 GB of space), just in system files (as opposed to your documents, pictures, videos, virtual machines, and so forth), something is very wrong. The three most likely general causes of this are probably:
- This is not really happening, and you have misinterpreted information that your system has provided you. (Please note that I am not telling you that you are mistaken; if you know how you came to have 100 GB of system files, then neither this nor the other two suggested causes below is correct.)
- There is a bug, which affects your system, and which causes used and free space to be reported incorrectly.
- There is a pretty serious bug, which affects your system, and which causes files (perhaps log files in
/var/log
) to grow at an extremely high rate and without bound.
As Sergey has said, indiscriminately deleting all files that have the same contents will quite likely cause damage to your system. For example, there are a number of blank files that might exist in your system and are used as locks or to signify some condition. You may also have programs that contain separate copies of identical files (when the files provide the same functionality for both programs, which has not been removed to a separate library or package).
You can probably get it to delete the "duplicate" files by running it as root
. But you should really not do that--it will likely wreak grave harm on your Ubuntu system.
You asked in a comment:
IS there anyway to command fdupes to delete all the duplicates without asking or notifying me?
fdupes -f
might do what you want. See the fdupes
manpage. But you should really not do this.
Instead, you should figure out what is going on. If you want us to help you with that, we certainly will. If you expand your question to explain that you want help figuring out what's taking up space, then you'll either get answers providing that information, or this may be closed as a duplicate of another question that provides information about how to find that out. (Either situation would be likely to benefit you.) Of course, this is assuming you want us to help you find the cause of your system taking up so much space (or seeming to).
The first step to investigate this is to examine (and post, by editing your question) the output of these commands, which provide detailed information about what disks you have and how much space is free on them:
mount
df -h
sudo du -sh /*
You can run those commands in a Terminal window (Ctrl+Alt+T). The last command will take a while. You may also get some Permission denied
errors (even though you're running it as root), mostly regarding .gvfs
folders in users' home directories. That's nothing to worry about.
add a comment |
up vote
6
down vote
up vote
6
down vote
If you copied and pasted the system files, manually reproducing them, then you should provide more information about what you did to copy and paste them, where you pasted them, anything you can remember. Even making an extra copy of all the system files on your machine is unlikely to cause anywhere near 100 GB of disk usage. Ubuntu requires less than 5 GB of available space to be installed, and even an Ubuntu system with many packages installed is unlikely for its system files to take up more than several times that size. You would probably have to make many copies to take up that much space. Or perhaps you copied files other than system files?
If your Ubuntu system has expanded by itself (from log files and updates‽) to take up 100 GB of space (or 50 GB of space), just in system files (as opposed to your documents, pictures, videos, virtual machines, and so forth), something is very wrong. The three most likely general causes of this are probably:
- This is not really happening, and you have misinterpreted information that your system has provided you. (Please note that I am not telling you that you are mistaken; if you know how you came to have 100 GB of system files, then neither this nor the other two suggested causes below is correct.)
- There is a bug, which affects your system, and which causes used and free space to be reported incorrectly.
- There is a pretty serious bug, which affects your system, and which causes files (perhaps log files in
/var/log
) to grow at an extremely high rate and without bound.
As Sergey has said, indiscriminately deleting all files that have the same contents will quite likely cause damage to your system. For example, there are a number of blank files that might exist in your system and are used as locks or to signify some condition. You may also have programs that contain separate copies of identical files (when the files provide the same functionality for both programs, which has not been removed to a separate library or package).
You can probably get it to delete the "duplicate" files by running it as root
. But you should really not do that--it will likely wreak grave harm on your Ubuntu system.
You asked in a comment:
IS there anyway to command fdupes to delete all the duplicates without asking or notifying me?
fdupes -f
might do what you want. See the fdupes
manpage. But you should really not do this.
Instead, you should figure out what is going on. If you want us to help you with that, we certainly will. If you expand your question to explain that you want help figuring out what's taking up space, then you'll either get answers providing that information, or this may be closed as a duplicate of another question that provides information about how to find that out. (Either situation would be likely to benefit you.) Of course, this is assuming you want us to help you find the cause of your system taking up so much space (or seeming to).
The first step to investigate this is to examine (and post, by editing your question) the output of these commands, which provide detailed information about what disks you have and how much space is free on them:
mount
df -h
sudo du -sh /*
You can run those commands in a Terminal window (Ctrl+Alt+T). The last command will take a while. You may also get some Permission denied
errors (even though you're running it as root), mostly regarding .gvfs
folders in users' home directories. That's nothing to worry about.
If you copied and pasted the system files, manually reproducing them, then you should provide more information about what you did to copy and paste them, where you pasted them, anything you can remember. Even making an extra copy of all the system files on your machine is unlikely to cause anywhere near 100 GB of disk usage. Ubuntu requires less than 5 GB of available space to be installed, and even an Ubuntu system with many packages installed is unlikely for its system files to take up more than several times that size. You would probably have to make many copies to take up that much space. Or perhaps you copied files other than system files?
If your Ubuntu system has expanded by itself (from log files and updates‽) to take up 100 GB of space (or 50 GB of space), just in system files (as opposed to your documents, pictures, videos, virtual machines, and so forth), something is very wrong. The three most likely general causes of this are probably:
- This is not really happening, and you have misinterpreted information that your system has provided you. (Please note that I am not telling you that you are mistaken; if you know how you came to have 100 GB of system files, then neither this nor the other two suggested causes below is correct.)
- There is a bug, which affects your system, and which causes used and free space to be reported incorrectly.
- There is a pretty serious bug, which affects your system, and which causes files (perhaps log files in
/var/log
) to grow at an extremely high rate and without bound.
As Sergey has said, indiscriminately deleting all files that have the same contents will quite likely cause damage to your system. For example, there are a number of blank files that might exist in your system and are used as locks or to signify some condition. You may also have programs that contain separate copies of identical files (when the files provide the same functionality for both programs, which has not been removed to a separate library or package).
You can probably get it to delete the "duplicate" files by running it as root
. But you should really not do that--it will likely wreak grave harm on your Ubuntu system.
You asked in a comment:
IS there anyway to command fdupes to delete all the duplicates without asking or notifying me?
fdupes -f
might do what you want. See the fdupes
manpage. But you should really not do this.
Instead, you should figure out what is going on. If you want us to help you with that, we certainly will. If you expand your question to explain that you want help figuring out what's taking up space, then you'll either get answers providing that information, or this may be closed as a duplicate of another question that provides information about how to find that out. (Either situation would be likely to benefit you.) Of course, this is assuming you want us to help you find the cause of your system taking up so much space (or seeming to).
The first step to investigate this is to examine (and post, by editing your question) the output of these commands, which provide detailed information about what disks you have and how much space is free on them:
mount
df -h
sudo du -sh /*
You can run those commands in a Terminal window (Ctrl+Alt+T). The last command will take a while. You may also get some Permission denied
errors (even though you're running it as root), mostly regarding .gvfs
folders in users' home directories. That's nothing to worry about.
edited Apr 13 '17 at 12:24
Community♦
1
1
answered Aug 18 '12 at 9:37
Eliah Kagan
80.8k20226363
80.8k20226363
add a comment |
add a comment |
up vote
4
down vote
I have a quick and dirty solution(definitely prevent log file writing, but doesn't solve the root problem):
this log file is written by /lib/udev/uvcdynctrl
- Backup original
sudo cp /lib/udev/uvcdynctrl /lib/udev/uvcdynctrl_backup
- Edit original
gksu gedit /lib/udev/uvcdynctrl
- Look up all elements that are in such form "debug=1"
- Change to "debug=0"
- Delete the log file once and for all
sudo rm /var/log/uvcdynctrl-udev.log
add a comment |
up vote
4
down vote
I have a quick and dirty solution(definitely prevent log file writing, but doesn't solve the root problem):
this log file is written by /lib/udev/uvcdynctrl
- Backup original
sudo cp /lib/udev/uvcdynctrl /lib/udev/uvcdynctrl_backup
- Edit original
gksu gedit /lib/udev/uvcdynctrl
- Look up all elements that are in such form "debug=1"
- Change to "debug=0"
- Delete the log file once and for all
sudo rm /var/log/uvcdynctrl-udev.log
add a comment |
up vote
4
down vote
up vote
4
down vote
I have a quick and dirty solution(definitely prevent log file writing, but doesn't solve the root problem):
this log file is written by /lib/udev/uvcdynctrl
- Backup original
sudo cp /lib/udev/uvcdynctrl /lib/udev/uvcdynctrl_backup
- Edit original
gksu gedit /lib/udev/uvcdynctrl
- Look up all elements that are in such form "debug=1"
- Change to "debug=0"
- Delete the log file once and for all
sudo rm /var/log/uvcdynctrl-udev.log
I have a quick and dirty solution(definitely prevent log file writing, but doesn't solve the root problem):
this log file is written by /lib/udev/uvcdynctrl
- Backup original
sudo cp /lib/udev/uvcdynctrl /lib/udev/uvcdynctrl_backup
- Edit original
gksu gedit /lib/udev/uvcdynctrl
- Look up all elements that are in such form "debug=1"
- Change to "debug=0"
- Delete the log file once and for all
sudo rm /var/log/uvcdynctrl-udev.log
edited Oct 5 '12 at 11:42
devav2
24.1k126879
24.1k126879
answered Oct 4 '12 at 11:55
Des
511
511
add a comment |
add a comment |
up vote
2
down vote
Go into the Terminal
(short cut is Ctrl+Alt+t) and type:
gksudo nautilus
This will open Nautilus with root permissions. Now delete your files.
Hope this helps you!
it doesn’t help,there are 10000s of files
– user84055
Aug 18 '12 at 7:22
How did you make 10000s of copies. Do the duplicates look like this. If so, can't you just select one file, press shift, and then select all of them, and then delete them.
– Max Tither
Aug 18 '12 at 7:27
the problem is i cant find the specific files which have been duplicated because i dont know which files haven copied and the locations of them.
– user84055
Aug 18 '12 at 7:37
I found a bash script to find duplicate files. It will find them and move them to a folder. Then you can just delete the duplicate folder.
– Max Tither
Aug 18 '12 at 7:42
no luck with it.It quits after running for 2minutes.
– user84055
Aug 18 '12 at 8:43
|
show 1 more comment
up vote
2
down vote
Go into the Terminal
(short cut is Ctrl+Alt+t) and type:
gksudo nautilus
This will open Nautilus with root permissions. Now delete your files.
Hope this helps you!
it doesn’t help,there are 10000s of files
– user84055
Aug 18 '12 at 7:22
How did you make 10000s of copies. Do the duplicates look like this. If so, can't you just select one file, press shift, and then select all of them, and then delete them.
– Max Tither
Aug 18 '12 at 7:27
the problem is i cant find the specific files which have been duplicated because i dont know which files haven copied and the locations of them.
– user84055
Aug 18 '12 at 7:37
I found a bash script to find duplicate files. It will find them and move them to a folder. Then you can just delete the duplicate folder.
– Max Tither
Aug 18 '12 at 7:42
no luck with it.It quits after running for 2minutes.
– user84055
Aug 18 '12 at 8:43
|
show 1 more comment
up vote
2
down vote
up vote
2
down vote
Go into the Terminal
(short cut is Ctrl+Alt+t) and type:
gksudo nautilus
This will open Nautilus with root permissions. Now delete your files.
Hope this helps you!
Go into the Terminal
(short cut is Ctrl+Alt+t) and type:
gksudo nautilus
This will open Nautilus with root permissions. Now delete your files.
Hope this helps you!
answered Aug 18 '12 at 6:43
Max Tither
1,364819
1,364819
it doesn’t help,there are 10000s of files
– user84055
Aug 18 '12 at 7:22
How did you make 10000s of copies. Do the duplicates look like this. If so, can't you just select one file, press shift, and then select all of them, and then delete them.
– Max Tither
Aug 18 '12 at 7:27
the problem is i cant find the specific files which have been duplicated because i dont know which files haven copied and the locations of them.
– user84055
Aug 18 '12 at 7:37
I found a bash script to find duplicate files. It will find them and move them to a folder. Then you can just delete the duplicate folder.
– Max Tither
Aug 18 '12 at 7:42
no luck with it.It quits after running for 2minutes.
– user84055
Aug 18 '12 at 8:43
|
show 1 more comment
it doesn’t help,there are 10000s of files
– user84055
Aug 18 '12 at 7:22
How did you make 10000s of copies. Do the duplicates look like this. If so, can't you just select one file, press shift, and then select all of them, and then delete them.
– Max Tither
Aug 18 '12 at 7:27
the problem is i cant find the specific files which have been duplicated because i dont know which files haven copied and the locations of them.
– user84055
Aug 18 '12 at 7:37
I found a bash script to find duplicate files. It will find them and move them to a folder. Then you can just delete the duplicate folder.
– Max Tither
Aug 18 '12 at 7:42
no luck with it.It quits after running for 2minutes.
– user84055
Aug 18 '12 at 8:43
it doesn’t help,there are 10000s of files
– user84055
Aug 18 '12 at 7:22
it doesn’t help,there are 10000s of files
– user84055
Aug 18 '12 at 7:22
How did you make 10000s of copies. Do the duplicates look like this. If so, can't you just select one file, press shift, and then select all of them, and then delete them.
– Max Tither
Aug 18 '12 at 7:27
How did you make 10000s of copies. Do the duplicates look like this. If so, can't you just select one file, press shift, and then select all of them, and then delete them.
– Max Tither
Aug 18 '12 at 7:27
the problem is i cant find the specific files which have been duplicated because i dont know which files haven copied and the locations of them.
– user84055
Aug 18 '12 at 7:37
the problem is i cant find the specific files which have been duplicated because i dont know which files haven copied and the locations of them.
– user84055
Aug 18 '12 at 7:37
I found a bash script to find duplicate files. It will find them and move them to a folder. Then you can just delete the duplicate folder.
– Max Tither
Aug 18 '12 at 7:42
I found a bash script to find duplicate files. It will find them and move them to a folder. Then you can just delete the duplicate folder.
– Max Tither
Aug 18 '12 at 7:42
no luck with it.It quits after running for 2minutes.
– user84055
Aug 18 '12 at 8:43
no luck with it.It quits after running for 2minutes.
– user84055
Aug 18 '12 at 8:43
|
show 1 more comment
up vote
1
down vote
The problem IS this package: uvcdynctrl-udev.
It's a useles and buggie program. It should be simply removed from debian and ubuntu repos. It shoudn't be installed. This package not only creates this HUGE log files, but it also causes Cheese and other web-cam apps to crash or work very badly (Can't capture video at full resolution with Cheese or Guvcview? REMOVE THIS PACKAGE AND IT WORKS AS IT SHOULD!
This bug has been around for years and the manteiner of uvcdyn.... doesn't seem to care about it.
The solution is simple: sudo apt-get remove uvcdynctrl-udev.
If you wanna be sure about what you are doing, use Synaptic instead. Serch for the buggie package uvcdynctrl-udev and uvcdynctrl-udev-data. Mark'em for complete removal. You'll notice it wont affect other programs, they're not dependencies, so you can safely remove it. Do it.
Then check /var/log, search this huge uvcdynctrl-udev.log, as root, delete it. (open a terminal
**
cd /var/log
sudo rm uvcdynctrl-udev.log
**
)
Believe me, you wont miss this package.
add a comment |
up vote
1
down vote
The problem IS this package: uvcdynctrl-udev.
It's a useles and buggie program. It should be simply removed from debian and ubuntu repos. It shoudn't be installed. This package not only creates this HUGE log files, but it also causes Cheese and other web-cam apps to crash or work very badly (Can't capture video at full resolution with Cheese or Guvcview? REMOVE THIS PACKAGE AND IT WORKS AS IT SHOULD!
This bug has been around for years and the manteiner of uvcdyn.... doesn't seem to care about it.
The solution is simple: sudo apt-get remove uvcdynctrl-udev.
If you wanna be sure about what you are doing, use Synaptic instead. Serch for the buggie package uvcdynctrl-udev and uvcdynctrl-udev-data. Mark'em for complete removal. You'll notice it wont affect other programs, they're not dependencies, so you can safely remove it. Do it.
Then check /var/log, search this huge uvcdynctrl-udev.log, as root, delete it. (open a terminal
**
cd /var/log
sudo rm uvcdynctrl-udev.log
**
)
Believe me, you wont miss this package.
add a comment |
up vote
1
down vote
up vote
1
down vote
The problem IS this package: uvcdynctrl-udev.
It's a useles and buggie program. It should be simply removed from debian and ubuntu repos. It shoudn't be installed. This package not only creates this HUGE log files, but it also causes Cheese and other web-cam apps to crash or work very badly (Can't capture video at full resolution with Cheese or Guvcview? REMOVE THIS PACKAGE AND IT WORKS AS IT SHOULD!
This bug has been around for years and the manteiner of uvcdyn.... doesn't seem to care about it.
The solution is simple: sudo apt-get remove uvcdynctrl-udev.
If you wanna be sure about what you are doing, use Synaptic instead. Serch for the buggie package uvcdynctrl-udev and uvcdynctrl-udev-data. Mark'em for complete removal. You'll notice it wont affect other programs, they're not dependencies, so you can safely remove it. Do it.
Then check /var/log, search this huge uvcdynctrl-udev.log, as root, delete it. (open a terminal
**
cd /var/log
sudo rm uvcdynctrl-udev.log
**
)
Believe me, you wont miss this package.
The problem IS this package: uvcdynctrl-udev.
It's a useles and buggie program. It should be simply removed from debian and ubuntu repos. It shoudn't be installed. This package not only creates this HUGE log files, but it also causes Cheese and other web-cam apps to crash or work very badly (Can't capture video at full resolution with Cheese or Guvcview? REMOVE THIS PACKAGE AND IT WORKS AS IT SHOULD!
This bug has been around for years and the manteiner of uvcdyn.... doesn't seem to care about it.
The solution is simple: sudo apt-get remove uvcdynctrl-udev.
If you wanna be sure about what you are doing, use Synaptic instead. Serch for the buggie package uvcdynctrl-udev and uvcdynctrl-udev-data. Mark'em for complete removal. You'll notice it wont affect other programs, they're not dependencies, so you can safely remove it. Do it.
Then check /var/log, search this huge uvcdynctrl-udev.log, as root, delete it. (open a terminal
**
cd /var/log
sudo rm uvcdynctrl-udev.log
**
)
Believe me, you wont miss this package.
answered Jan 3 '15 at 5:01
tuprofe demusica
111
111
add a comment |
add a comment |
up vote
-1
down vote
I think the best thing here is to just reinstall, considering the apparent amount of damage, the fact it's fairly unclear what's actually happened, and your low comfort level in manually repairing it.
Preserve your home directory (do not reformat or repartition) and reinstall and that should clear out the system directories.
1
While reinstallation is certainly an option, it's usually pretty easy to figure out where large files have been copied, or if there are system files increasing uncontrollably in size, which files they are.
– Eliah Kagan
Aug 18 '12 at 10:45
@Eliah, I'm sure you and I would find it easy, but I'm not sure the OP will. And, if not a lot of time has been invested in the machine (I'm not going to even mention config backups) blowing it away may be the most efficient choice.
– poolie
Aug 18 '12 at 10:47
1
Note that this wouldn't help here. His/home
is on the same partition as/
, so he cant clear that partition. And I don
t think the installer deletes any superfluous files on the partition it is going to use for installation (either all or none).
– Philipp Wendler
Aug 18 '12 at 10:59
2
The installer will remove everything in /var except /var/local so this answer is a viable option.
– Jorge Castro
Aug 18 '12 at 15:16
add a comment |
up vote
-1
down vote
I think the best thing here is to just reinstall, considering the apparent amount of damage, the fact it's fairly unclear what's actually happened, and your low comfort level in manually repairing it.
Preserve your home directory (do not reformat or repartition) and reinstall and that should clear out the system directories.
1
While reinstallation is certainly an option, it's usually pretty easy to figure out where large files have been copied, or if there are system files increasing uncontrollably in size, which files they are.
– Eliah Kagan
Aug 18 '12 at 10:45
@Eliah, I'm sure you and I would find it easy, but I'm not sure the OP will. And, if not a lot of time has been invested in the machine (I'm not going to even mention config backups) blowing it away may be the most efficient choice.
– poolie
Aug 18 '12 at 10:47
1
Note that this wouldn't help here. His/home
is on the same partition as/
, so he cant clear that partition. And I don
t think the installer deletes any superfluous files on the partition it is going to use for installation (either all or none).
– Philipp Wendler
Aug 18 '12 at 10:59
2
The installer will remove everything in /var except /var/local so this answer is a viable option.
– Jorge Castro
Aug 18 '12 at 15:16
add a comment |
up vote
-1
down vote
up vote
-1
down vote
I think the best thing here is to just reinstall, considering the apparent amount of damage, the fact it's fairly unclear what's actually happened, and your low comfort level in manually repairing it.
Preserve your home directory (do not reformat or repartition) and reinstall and that should clear out the system directories.
I think the best thing here is to just reinstall, considering the apparent amount of damage, the fact it's fairly unclear what's actually happened, and your low comfort level in manually repairing it.
Preserve your home directory (do not reformat or repartition) and reinstall and that should clear out the system directories.
answered Aug 18 '12 at 10:40
poolie
7,08823158
7,08823158
1
While reinstallation is certainly an option, it's usually pretty easy to figure out where large files have been copied, or if there are system files increasing uncontrollably in size, which files they are.
– Eliah Kagan
Aug 18 '12 at 10:45
@Eliah, I'm sure you and I would find it easy, but I'm not sure the OP will. And, if not a lot of time has been invested in the machine (I'm not going to even mention config backups) blowing it away may be the most efficient choice.
– poolie
Aug 18 '12 at 10:47
1
Note that this wouldn't help here. His/home
is on the same partition as/
, so he cant clear that partition. And I don
t think the installer deletes any superfluous files on the partition it is going to use for installation (either all or none).
– Philipp Wendler
Aug 18 '12 at 10:59
2
The installer will remove everything in /var except /var/local so this answer is a viable option.
– Jorge Castro
Aug 18 '12 at 15:16
add a comment |
1
While reinstallation is certainly an option, it's usually pretty easy to figure out where large files have been copied, or if there are system files increasing uncontrollably in size, which files they are.
– Eliah Kagan
Aug 18 '12 at 10:45
@Eliah, I'm sure you and I would find it easy, but I'm not sure the OP will. And, if not a lot of time has been invested in the machine (I'm not going to even mention config backups) blowing it away may be the most efficient choice.
– poolie
Aug 18 '12 at 10:47
1
Note that this wouldn't help here. His/home
is on the same partition as/
, so he cant clear that partition. And I don
t think the installer deletes any superfluous files on the partition it is going to use for installation (either all or none).
– Philipp Wendler
Aug 18 '12 at 10:59
2
The installer will remove everything in /var except /var/local so this answer is a viable option.
– Jorge Castro
Aug 18 '12 at 15:16
1
1
While reinstallation is certainly an option, it's usually pretty easy to figure out where large files have been copied, or if there are system files increasing uncontrollably in size, which files they are.
– Eliah Kagan
Aug 18 '12 at 10:45
While reinstallation is certainly an option, it's usually pretty easy to figure out where large files have been copied, or if there are system files increasing uncontrollably in size, which files they are.
– Eliah Kagan
Aug 18 '12 at 10:45
@Eliah, I'm sure you and I would find it easy, but I'm not sure the OP will. And, if not a lot of time has been invested in the machine (I'm not going to even mention config backups) blowing it away may be the most efficient choice.
– poolie
Aug 18 '12 at 10:47
@Eliah, I'm sure you and I would find it easy, but I'm not sure the OP will. And, if not a lot of time has been invested in the machine (I'm not going to even mention config backups) blowing it away may be the most efficient choice.
– poolie
Aug 18 '12 at 10:47
1
1
Note that this wouldn't help here. His
/home
is on the same partition as /
, so he cant clear that partition. And I don
t think the installer deletes any superfluous files on the partition it is going to use for installation (either all or none).– Philipp Wendler
Aug 18 '12 at 10:59
Note that this wouldn't help here. His
/home
is on the same partition as /
, so he cant clear that partition. And I don
t think the installer deletes any superfluous files on the partition it is going to use for installation (either all or none).– Philipp Wendler
Aug 18 '12 at 10:59
2
2
The installer will remove everything in /var except /var/local so this answer is a viable option.
– Jorge Castro
Aug 18 '12 at 15:16
The installer will remove everything in /var except /var/local so this answer is a viable option.
– Jorge Castro
Aug 18 '12 at 15:16
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f177312%2ffilesystem-filling-up-due-to-large-uvcydnctrl-udev-log-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
This is still a problem in Ubuntu 14.04 LTS
– Andrew Fielden
Nov 8 '14 at 20:39