Re: failed to fetch Sid InRelease
On 1/27/16, Haines Brown <haines@histomat.net> wrote:
> My sense there is something strange going on, but I don't want to mess
> things up more by mindless experimenting.
Unfortunately all that I have for you is some mindless experimenting!
But hopefully something in what I've written here will be fruitful.
You've mentioned a number of clues throughout this e-mail chain. I'll
see what I can address before submitting some of my own ideas.
On Tue, 26 Jan 2016 17:19:09 -0500 Haines Brown <haines@histomat.net>
wrote:
> I discovered that /etc/apt/preferences/systemd had these two lines:
> [snip: apt_preferences file with \ line continuation]
> When I changed it to
> [snip: apt_preferences file with proper newline]
> pulseaudio and pauvucontrol could be installed.
This is strange for a number of reasons:
1) How did Pin: and Pin-Priority: wind up on the same line with a \
character separating them in the first place? Possibly this was a
copy-paste from a website that lost its formatting?
2) If the old file suffered from invalid syntax, how did apt fail to
notice until recently, when you tried to install pulseaudio and
pavucontrol? Presumably you've had systemd pinned at -1 priority
for some time now.
This is all academic, though. I don't think this is where the problem
lies, so let's set it aside for now.
On Tue, 26 Jan 2016 17:19:09 -0500 Haines Brown <haines@histomat.net>
wrote:
> I did # dpkg --add-architecture i386 in order to install the i386
> skype. However, # dpkg --print-architecture only reports amd64. Don't
> I need both architectures in order to install or update mixed
> architecture packages?
I suspect that if you ran # dpkg --print-foreign-architectures, it would
show i386 as expected. # dpkg --print-architecture only prints amd64 on
my machine, which features working multiarch.
On 1/27/16, Haines Brown <haines@histomat.net> wrote:
> I can access ftp.us.debian.org/debian/dists from another machine to
> update Wheezy. I can access .../unstable/InReleases with a web
> browser.
But can you access ftp.us.debian.org from the Sid machine which is
exhibiting problems? You mentioned that you can access the site from
"another machine" and "with a web browser," the latter of which might
also refer to another machine.
If you haven't already, I'd suggest running the following from the sid
machine:
$ wget http://ftp.us.debian.org/debian/dists/unstable/InRelease
On 1/27/16, Haines Brown <haines@histomat.net> wrote:
> 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
I've seen these messages plenty of times before when I forget to su - or
sudo apt-get. Are you sure you were running as root? (Not trying to
patronize, just considering all options :-)
On 1/27/16, Haines Brown <haines@histomat.net> wrote:
> The only difference between my working Wheezy and broken Sid is that
> the permissions for /var/lib/apt/lists/partial/ in Wheezy is 755 and
> owned by root root, while in Sid it is 700 and owned by _apt root.
> In both cases, the lock file is 620 and owned by root root.
I can confirm that my working Stretch/Testing installation is configured
exactly as you have described your Sid installation, EXCEPT that my lock
file (/var/lib/apt/lists/lock) is 640 rather than 620. Maybe check on
that?
On 1/27/16, Haines Brown <haines@histomat.net> wrote:
> This returns nothing: # cat /etc/group | grep _apt
Same as on my (working) installation.
On Wednesday, January 27, 2016 09:29, Haines Brown <haines@histomat.net>
wrote:
> # cat /etc/passwd | grep apt
> _apt:x:116:65534::/nonexistent:/bin/false
> I get the impression this is normal, but shouldn't _apt be in
> /etc/group file as user?
As mentioned above, I don't have an _apt group either. Note the GID of
65534 in /etc/passwd, which indicates that the _apt user belongs to the
group named "nogroup" rather than its own, dedicated group.
On Wednesday, January 27, 2016 09:29, Haines Brown <haines@histomat.net>
wrote:
> Desperate I tried without luck:
> # adduser --force-badname --system -home /var/empty --no-create-home \
> --quiet _apt
I'm sure that command didn't do any harm to your system, seeing as you
already have an _apt user. It won't do any good, I suspect, based on the
fact that my (working) system's _apt user is configured the same way as
yours without needing to run any auxiliary commands, but it also won't
have done any harm.
On Wednesday, January 27, 2016 09:29, Haines Brown <haines@histomat.net>
wrote:
> Changing debian packages repository did not help.
Did you try completely replacing /etc/apt/sources.list? Maybe try
backing up your current copy, and starting from scratch with just the
basics:
deb http://ftp.us.debian.org/debian/ sid main
Who knows -- maybe an invisible Unicode character snuck into your "deb"
line and is causing all of this trouble? That sounds paranoid (and it
is), but I've seen "nonbreaking spaces" wreak havoc on other systems
before.
So here's what you can try, assuming you haven't reinstalled yet:
1) As mentioned before, try to "wget" from the sick machine
2) Again as mentioned before, try to replace sources.list completely
(make a backup first!) (and yes, replace it completely, don't just
edit it in-place)
3) Back up /etc/resolv.conf and replace it with a brand-new file
containing this one line (pointing to Google's public nameserver):
nameserver 8.8.8.8
After each attempt, try running an "apt-get update" and look for that
"Temporary failure resolving" error. Hopefully it goes away.
- Louis
Reply to: