Re: failed to fetch Sid InRelease
On 1/27/16, Haines Brown <haines@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 <haines@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. *
Reply to: