pazhosch's questions

I have a 10-years old 320 Gb HDD which I've used as an external drive, and it traveled with me for much of those 10 years. Needless to say, it survived more than a few falls (including those while in operation), and got some bad sectors. When I actually started to get read errors, not just SMART sector relocation warnings, I moved away everything important from it (using ddrescue for some files). Sure I can't trust this drive anymore, but I still want to use it to copy once and keep some movies/FLACs, to free some space on laptop's SSD+HDD, as long as the external drive still works. I don't care losing some or all of these files, as I either have backups at home and/or can re-download easily.

The problem is, if I format this drive and start copying the files there, somewhere around 25% I get a write failure, necessitating USB cable unplug (^C is not enough!), same happens with badblocks both in read and write mode. After playing a bit with badblocks' "from" and "to" parameters, I've found that 90%+ of the drive is OK, and there are basically 3 bad block areas. A short script and I got a text file with block numbers (yes I didn't forget -b 4096 for badblocks) covering these areas and lots of extra space around to be safe. But when I did e2fsck -l badblocks.txt, it still hangs! seems like it's trying to read those bad blocks anyway, not just to mark as bad and forget. Is there any other way to get around this? Or maybe other filesystem (thought about FAT, but I don't see any way to feed badblocks.txt to fsck.vfat)? Or 4 separate partitions covering the "good" areas is the best solution for this case?

Update: some quotes from man to make the case more clear

man e2fsck:

-i input_file Read a list of already existing known bad blocks. Badblocks will skip testing these blocks since they are known to be bad.

thus, badblocks promises to skip the blocks listed (and it does, as it doesn't hang with all the suspicious ranges in badblocks.txt!)

man badblocks:

-l filename Add the block numbers listed in the file specified by filename to the list of bad blocks. The format of this file is the same as the one generated by the badblocks(8) program.

there's no promise it will not try to access these blocks, though. But why the hell it may want to access them?

Note that the block numbers are based on the blocksize of the filesystem. Hence, badblocks(8) must be given the blocksize of the filesys‐ tem in order to obtain correct results. As a result, it is much simpler and safer to use the -c option to e2fsck, since it will assure that the correct parameters are passed to the badblocks program.

I'd be happy but it hangs on a first bad block. Plus, -c is incompatible with -l - thus, I either scan the disk or manually mark the bad sectors. But why, if I choose the latter option, it still wants to access these supposedly "bad" sectors is beyond my understanding...

Recently I got CUDA upgraded to version 9.2 and nvidia driver to nvidia-396 with a regular auto-update on my Ubuntu 16.04 Optimus-enabled laptop, with Intel video adapter active by default and NVidia accessed via bumblebee. Shortly after, I've tried to run a CUDA apllication (using optirun <command>), and found it doesn't work.

First thing I did was replacing all the entries of "nvidia-390" (if I remember right it was 390) in /etc/bumblebee/bumblebee.conf to "nvidia-396" - this helped me before more than once.

Still doesn't work (Cannot access secondary GPU - error: Could not load GPU driver). dmesg, and there is a reason:

[  314.733284] NVRM: The NVIDIA GeForce GT 520M GPU installed in this system is
               NVRM:  supported through the NVIDIA 390.xx Legacy drivers. Please
               NVRM:  visit http://www.nvidia.com/object/unix.html for more
               NVRM:  information.  The 396.26 NVIDIA driver will ignore
               NVRM:  this GPU.  Continuing probe...

Yes, my laptop is quite old, but with SSD and 12 Gb RAM I still don't feel much need to replace it. OK, looks like then I must live with nvidia-390:

sudo apt install nvidia-390

Was told that a lot of dependent packages will be uninstalled, including, it seems, all of CUDA 9.2. Damn. So likely I'm stuck with CUDA 9.0 as well. So, after uninstalling everything (and checkin in synaptic no packages from nvidia-396 or cuda-9.2 are left) I've tried to get it back:

sudo dpkg -i cuda-repo-ubuntu1604_9.0.176-1_amd64.deb
sudo apt-key adv --fetch-keys http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/7fa2af80.pub
sudo apt-get update
sudo apt-get install cuda

as per https://developer.nvidia.com/cuda-90-download-archive?target_os=Linux&target_arch=x86_64&target_distro=Ubuntu&target_version=1604&target_type=debnetwork

Three commands ok, but the last one... Houston, we have a problem!

$ sudo apt install cuda
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package cuda

I've tried the solution from an answer on this Installing CUDA 8 on Ubuntu 16: Unable to locate package cuda question, that is:

dpkg -l | grep '^rc' | awk '{print $2}' | sudo xargs dpkg --purge

It did clean indeed lots of stuff, including some from cuda-9.2 related packages. However, the problem is still there - I can't install CUDA again, no matter I'm trying 9.0 or another version.

Any ideas?