On 1/27/16, Haines Brown <hai...@histomat.net> wrote: > On Wed, Jan 27, 2016 at 05:39:36AM +0300, Adam Wilson wrote: >> On Tue, 26 Jan 2016 17:19:09 -0500 Haines Brown <hai...@histomat.net> >> wrote: >> >> > # aptitude update >> > Err: http://ftp.us.debian.org/debian unstable InRelease >> > temporary failure resolving 'ftp.us.debian.org' >> > W: Failed to fetch >> > http://ftp.us.debian.org/debian/dists/unstable/InRelease: >> > temporary failure resolving ftp.us.debian.org >> >> I suspect this is a problem either server-side or something to do with >> your connection. Note the 'failure resolving ftp.us.debian.org'. It >> can't even access the server, let alone download the InRelease file. > > That was my first assumption, so waited a day for things to get > fixed. When no one reported problems with the repository, I began to > suspect the problem was at my end. > > I can access ftp.us.debian.org/debian/dists from another machine to > update Wheezy. I can access .../unstable/InReleases with a web browser. > > When I shut X server down and do # aptitude update from console, I get > this: > > W: chmod 0700 of directory /var/lib/apt/lists/partial failed - \ > SetupAPTPartialDirectory (1: Operation not permitted) > E: Could not open lock file /var/lib/apt/lists/lock - \ > (13: Permission denied) > E: Unable to lock directory /var/lib/apt/lists
This is *NOT* something I advise (because I don't know the ultimate ramifications), but when I get the "Could not open lock file" error, I learned by trial and error to.... delete the one I think is causing the problem. My rationale is that it doesn't exist in a brand new debootstrap (how I install Debian) so it's something created on the fly by APT (my *_CHOICE_* for package manager). The lock file I'm referencing is found in /var/cache/apt/archive.... Another thing that can cause the "Could not open lock file" error is that something else is running that locks up usage of the/a shared lock file. I've had that happen only once and unfortunately cannot remember the other program involved that would hint where to look for other similar possibilities. Common sense says that instance possibly involved another package manager.. While proofreading this, I just went in to verify that the directory I gave is correct. I just happened to have run into something apparently recently because I see a file named "lockOLD" in there. For some odd unrelated reason, it then triggered the memory that the whole deleting the lock file thing for me I THINK also came about from once stumbling upon a hidden "~" or "#" + lock named file.... or something like that. Purely based on personal observation of it in action, it stuck in my brain that those occasionally indicate something volatile (self-destructing at job's end) that is generated temporarily on the fly for something else tied up in use. The point there would be that there's one more avenue to pursue in times of trouble when every single other thing else has failed to fix an error. If one of those hidden files remains instead of self-destructing, it's going to logjam (block) things from working ever after that until it's deleted. Who knows, maybe sometimes when we resign ourselves to a package uninstall followed by a then successfully functioning reinstall, that's exactly what we've done without ever knowing it...... :) Ok, one more paragraph because I started doubting myself again. I ran "locate /lock" to see what's shaking out there. A directory named /var/lock, for one. Almost think I already knew that, but it didn't hold any special significance until now. Mine holds apache2, lockdev, and subsys subdirectories that are all currently empty. /var/lock additionally holds a file named "LCK..ttyACM0". It's recognizable as belonging to my USB dialup modem that is currently in use. In the spirit of continually discovering just what makes Debian tick, I logged off the Internet. As anticipated, /var/LCK..ttyACM0 vanished into thin air.... and then graciously reappeared upon Internet reconnect. *phew!* Just thinking out loud... again. ) Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * sometimes words #fail me. *
