On 2015-12-14 at 12:47, David Kalnischkies wrote: > Control: notfound -1 1.0.10.2 > Control: found -1 1.1.3 > > (fixing up metadata to reflect report) Looks like my attempt got there a bit earlier, but thanks anyway, since I wasn't sure I'd gotten it right. (Is the use of -1 to represent "current bug" or suchlike documented anywhere? I remembered seeing it used, but I couldn't find it in https://wiki.debian.org/HowtoUseBTS, https://www.debian.org/Bugs/server-control, or 'man bts', so I didn't risk trying it.) > On Mon, Dec 14, 2015 at 11:42:34AM -0500, The Wanderer wrote: > >> Couldn't create tempfiles for splitting up >> /var/lib/apt/lists/ftp.us.debian.org_debian_dists_testing_InRelease > > The code doing the splitting is present since 0.9.8 (~2013), so that > is probably really about the tempfiles rather than this code itself > as it didn't change much. > > I guess its permission related as this code is now executed as _apt > rather than as root. You can disable privilege dropping temporarily > with -o APT::Sandbox::User=root Agreed, that sounds likely - and thanks for the tip. > Interesting might be the permissions of your $TMPDIR: stat /tmp > $TMPDIR $ stat /tmp $TMPDIR File: ‘/tmp’ Size: 53248 Blocks: 112 IO Block: 4096 directory Device: fd02h/64770d Inode: 2 Links: 73 Access: (0775/drwxrwxr-x) Uid: ( 1000/wanderer) Gid: ( 1004/ tmpdir) Access: 2013-08-30 09:47:13.901246241 -0400 Modify: 2015-12-14 23:14:47.519608765 -0500 Change: 2015-12-14 23:14:47.519608765 -0500 Birth: - IOW, it's not world-writable, and the group involved is probably not a standard one. By comparison, on a different machine which doesn't have the problem, /tmp is drwxrwxrwx root:root. Now that I've looked at this, I vaguely recall that I set /tmp up this way intentionally, not long after I built this system - but I can't remember why. I think it was simply that I couldn't write to /tmp as my normal user otherwise, but that doesn't seem to hold with the other system; there may also have been a bit of thinking that the way /tmp looked in 'ls / --color=auto' with drwxrwxrwx root:root was ugly, but if so I haven't noticed it on the other system in the past few years. This is probably the culprit. I'll investigate changing this in the morning, when I have more time and less of a headache. It might be worth trying to detect /tmp or $TMPDIR writability at some point in the process, but I entirely understand if it's considered not worth the code and/or the hassle. > Potentially also how you mount it (if you do it): mount | grep tmpfs This returns a bunch of things, starting with udev and including several things under /run and one under /sys, but no /tmp or similar. > [I see that you haven't followed the systemd switch yet, which > suggests you could have other "new" default options not as default > like a non- persistent /tmp as well] As it happens, /tmp is currently persistent on this computer, but is non-persistent on the one which doesn't have the problem. That's got nothing to do with the systemd switch AFAIK, however, and I'm pretty sure it's orthogonal to the current problem. > You could also try moving /var/lib/apt/lists away. There is no > 'partial' in this file path, so maybe some bad file is stuck in there > doing bad things. While at it: Anything interesting in the partial/ > subdirectory and does the mention file looks at least reasonable? The > files are all Hit's – what modification time have the files in the > lists/ dir? I don't have this information ready to hand, since I always run the update again after downgrading back to the working version, and that's going to update the timestamps and suchlike. If it's important, which I now think it probably isn't, I can do the dance to get it tomorrow or so. > I presume 1.1.3 was the first apt you tried of the 1.1 series, > right? It's the first to make it to testing, so yes. >> Could not execute 'apt-key' to verify signature (is gnupg >> installed?) > > (That is a catch-all message printed after we had a failure higher > up the chain [which was probably very technical like this one] – with > the "most likely" cause added in a few layman terms as we do it in a > few other error messages as well.) I rather expected this would be the case. I mentioned gnupg just to confirm that, yes, I had investigated the cause suggested in the error message and it didn't seem to apply. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature