Debian 9 (stretch) - why 'apt-get update' cannot write tmp files?
 

I just added a foreign architeture¹ to this Debian 9 machine. In Debian's wiki², they ask an 'apt-get update' too, so I tried it. But I am receiving weird errors from apt. Look at my terminal:

What is wrong here? I cannot understand. /tmp is normally writable by anything or anyone, as it always were, so...

--------------------

¹ ² wiki.debian.org/Multiarch/HOWTO

$ mount

make sure that " / " isn't mounted read-only. With systemd if you do not setup /etc/fstab it will default to read-only. Or that the filesystem isn't 100% full. Otherwise try using httpredir instead deb.

change

deb http://deb.debian.org/debian stretch main contrib non-free

to

deb http://httpredir.debian.org/debian stretch main contrib non-free

This will try to select a mirror for you. Change it to that mirror if it works well for you. This is for your /etc/apt/sources.list. Be sure to include the stretch-updates and security lines as well.

deb http://security.debian.org stretch/updates main contrib non-free
deb http://httpredir.debian.org/debian stretch main contrib non-free
deb http://httpredir.debian.org/debian stretch-updates main contrib non-free

I think archive works too for the main repository. I don't think deb is a valid repo and the source of some of that fluff. deb https://archive.debian.org/..... Not sure though, but archive is a valid subdomain for raspbian versions.

There's also a few keyring things to make apt less grumpy.

$ sudo apt-get install debian-keyring debian-archive-keyring

May I keep lines with 'httpredir' in /etc/apt/sources.list ?
 

Thank you for these comments, Shadow_7!

(before) I tested for write permissions with explicit touch'es, both with root and my normal user. Both normal.

Full partition was not something I wondered - this computer is new, with plenty space for everything. But gparted tells me this for root partition, where /tmp is: 19% free, which is ~1.77 GiB. /tmp is not a separate partition there.

And 'mount' command shows what is below, everything normal too. I just trimmed to show only lines that you should want to see:

A question to what you suggested:

If I keep some lines with "http://httpredir.debian.org/debian" in /etc/apt/sources.list, will it do any harm? Anything bad besides repetitively querying for a good mirror?

My full /etc/apt/sources.list now (with no changes made now!) is:

I know some available repositories are note there, and you suggested them. It is a kind of choice. I have installed only a few packages manually, without the help of aptitude or synaptic. Seems fine here.

Besides these differences, may I only change the "deb.debian.org" lines to a good mirror?

About those keyreing packages. 35 MiB of installed keyrings! A lot! But both are here now.
(:

That is likely your only change needed.

keeping httpredir shouldn't hurt, but could. If the service goes down or away it stops working even though everything else functions and is "normal". There's some URL somewhere on debian.org that lists the actual mirrors and you should technically select one that's dependable and close to you. They're not as bad as DNS servers that wreck your day and need to be changed more often than underwear IMO. But under load, the httpredir is probably the first thing to break / have a bad day.

Ok, I will do these changes now. I will keep the "httpredir" there for sometime. All users in this machine do not use package installing or updating often. So it should not upset the service to redir to a good mirror.

When downloading a package manually, I am given a list of several mirrors for that file. For example, check ....debian /.../wine32/download. A country subdomain can be a different server? For example, in that page there are:

(south america)
ftp.br.debian.org/debian
ftp.cl.debian.org/debian

Both in debian.org domain! But they will be different servers, right?

And there is a complete mirror list here:

debian /mirror/list

I will look that page now and maybe choose to use one of them instead of httpredir. A few times before, I have seen mirrors that didn't have all files (no example to give now, sorry). Is this somehow predictable? Or was it an error and should not happen?

By the way... only now I have "clicked" in this idea: are the /tmp errors 'apt-get updt' gave me due broken addresses in my sources.list? How strange!

If that deb subdomain I had is somehow what explain these problems (which have existed since I access this computer, some weeks ago), that will be a great "side" (although not much) effect of this change.
(:

There is still some problem
 

I changed the sources.list and right after tried an 'apt-get update'. Much less than before, but it still gave one error. There are several warnings, but I understand that they may happening only because of my use of "httpredir" instead of a specific mirror (right?).

My source.list now (a few comments removed) is:

The new output of apt-get is:

I repeated the 'apt-get update' command, to see if the error persisted. It did, but the problem seems to be only with security.debian.org. Is this a problem I should somehow report?

You could try commenting out the security line for now to let apt cleanly finish. Otherwise make sure your clock is sync'd.

# ntpdate pool.ntp.org

I've had key issues with that before when the day of the change happened on UTC and my system was configured for regional time (CST), and wouldn't work until both UTC and CST were the same date. Or at least a date later than the key change. Probably not your issue though.

deb http://security.debian.org/debian-security stretch/updates main

should probably be...

deb http://security.debian.org stretch/updates main

It's a bit different than the other sources and doesn't afaik have a sources branch (deb-src).

A problem still exist, but it should be due the use off httpredir URLs. I changed the security URLs as you said in #9. I also commented the entry for deb-src in security (I do not remember if I created it by almost copying the normal URL... possibly, but not sure). After this change, I ran apt-get 3 times, also with errors.

After commenting both security lines, I ran 'apt-get update' a few more times, but it had a few *different* errors in each run! Two of them, I think. I will copy 3 runs with different ends, or almost that (I did not skim each to check everything, the lines seem to also change order, dunno).


There is a final error that did not repeat (much more than only 3 times I show above) after I commented both security lines. It happened two or three times during this last test session. It is this, look mainly the final lines:

The only thing waiting to be done here are the changes to use specific mirror. I will do that tomorrow, sleep time now. After I run that update command without errors (I believe that will happen) I will uncomment the security line.

Just a note, deb.debian.org is a redirector URL also, like httpredir. It's flaky though currently, takes a while to get it to work right, probably about the time Buster releases it should be easily usable.

A bit old school... but:

$ sudo apt-get install dselect
$ sudo dselect update

Something about that tool the cleans out junk and merges sources when you've changed your sources.list. AFAIK the only thing that populates /var/lib/dpkg/available as well, which is a nice text file to browse when wondering what's available without a whole bunch of apt-cache search plus apt-cache show.

Beyond this I wonder if there's not some DNS funk or other, these are not the packets you're looking for, going on. Lower your MTU setting? Change your nameserver lines in /etc/resolv.conf. Perhaps some import/export limits too with regards to encryption since you're in a different hemisphere. It's a bit odd, the debian-keyring stuff normally resolves those types of quirks. If you were running something older and out of support it'd be a little more likely, but not with stretch the latest stable release.

I wonder if you have extras in /etc/apt/sources.list.d/ and such? Not that common, but a few games seem to favor setting that up. And maybe a few three letter agencies.

Mmm... now I did read about dselect, which was suposedly superseded by APT things. Maybe updating APT DB will work with it, since it seems to have a problem with apt-get? Is that the idea?

I checked my nameservers here. They came as a gift with this computer. Searching for the IPs I have there, did not bring any bells. In the other computer I use the DNS provided by my ISP (if I remember correctly, it has been 4 years since I last played with that).

My /etc/apt/sources.list.d/ folder has no file. "(...) and such" -> I am not sure what I can show from our apt folder. The only unusual thing I am sure to have there is the untouched backups of sources.list file before I made any changes to it.

What would solve this thread? The problem I have with apt-get is normal?

I wouldn't call the issue normal. It probably wouldn't be an issue if you installed with the installer and setup multi-arch at that time. But it's not a rare issue, especially as ISPs get more creative with your packets and shape your experience in weird ways. There's "apt-transport-https" for more exotic repo needs. Which might become the minimal need now that net neutrality was shot in the head and left for dead.

Sometime ago, I have tried to install the same Debian 9 in this machine, in a different partition. But I had other difficulties in the end. I was even planning making threads to solve those (new) remaining problems... in the end, I started with simple threads to solve some minor problems the received (and partially working) setup had, and now we are kind of attached to this "gifted setup" (with everything we already changed in it).

I never noticed a multi-arch option during any *nix install process! Good to know. If we almost always need tricks to install common things now (with multi arch option chosen), I will study about trying that second setup again.

And, if I am right to think that, the only country which seems in a bit more fragile situation with net neutrality is USA. Is this correct? Or your comment sense is toward the influence that can have in other countries taking similar steps or making anything toward the same direction?

I ran into the same problem on my debian system and goofled to this posting.

In my case the fix was simple: chmod 777 on /tmp. The protections on /tmp somehow got changed so that only system had write access.

/tmp on tmpfs
 

I ran into the same problem on raspbian, I solved it by unmounting /tmp before using apt-get.

I suspect that the 500M /tmp in ram is not big enough for apt-get

It's an annoying solution having to unmount /tmp before using apt-get and remounting it afterwards, but on the raspberry with 1GB of ram I can't afford a bigger /tmp on tmpfs.

If you're not so short on ram you could try making /tmp bigger.