"Size mismatch" error is unhelpful

Bug #77528 reported by Elliott Hughes on 2006-12-30
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Software Updater
Invalid
Undecided
Unassigned
update-manager (Ubuntu)
Undecided
Unassigned

Bug Description

i don't actually know where the "Size mismatch" errors come from, but i think it's if an "apt-get update" is done (either manually or by the system?), and then the package on the server is replaced with a newer one without the client doing another "apt-get update". if there's a way for the server maintainer to fix this, it would be good to have a message saying that there's a problem with the server and that the user should point the server administrator to <some document that explains how to avoid inflicting this on users>.

but i'm getting ahead of myself...

if you're in the situation above, where "apt-get upgrade" would report:

Failed to fetch http://software.jessies.org/debian/./org.jessies.evergreen.deb Size mismatch
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

update manager shows you the first line but not the second. so you're given no clue as to what "size mismatch" means (mismatch between what sizes, exactly?), or whether that's a server problem, a client problem, or -- as i believe -- a client/server mismatch problem. and you're not given any clue about how to resolve the problem.

ideally, i guess, update manager would either "apt-get update" as a matter of course when it starts. or it could do it if it gets these kind of errors. or as a minimum, it could do what "apt-get upgrade" does and suggest that a sufficiently clueful user (and presumably this can only really happen if you or your system administrator has added lines to your /etc apt sources?) run a specific command.

even if this is something a sufficiently clever .deb repository maintainer can avoid, it would be nice to have some kind of "repository <x> in your <sources file> if maintained by bozos; please point them at <useful URL> which explains what they need to do to avoid this problem; in the meantime try <end-user work-around>".

John Vivirito (gnomefreak) wrote :

Can you please attach the files in /var/log/dist-upgrade to this bug report. Thank you for reporting this with us today.

Changed in update-manager:
status: Unconfirmed → Needs Info
Elliott Hughes (enh) wrote :

/var/log/dist-upgrade/ is empty.

Michael Vogt (mvo) wrote :

Thanks for your bugreport.

I agree that the error message is not very helpfull.

What triggers this message for you?

Cheeers,
 Michael

Changed in update-manager:
status: Needs Info → Confirmed
Elliott Hughes (enh) wrote :
Download full text (9.4 KiB)

if i follow the instructions on http://software.jessies.org/salma-hayek/ to install the jessies.org packages:

sudo bash <<EOF
echo deb http://software.jessies.org/downloads/debian/ ./ >> /etc/apt/sources.list
EOF
wget -O - http://software.jessies.org/downloads/debian/software.jessies.org.gpg | sudo apt-key add -
sudo aptitude update
sudo aptitude install ~norg.jessies.

then pretty much every day, something's changed and there's a new update to install. as long as i install every version, it works fine. but if i ever miss one, it seems, then until i manually run "apt-get update", i get this error.

like i say, the worst part is that "apt-get upgrade" would have told me what to do:

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
  org.jessies.evergreen org.jessies.scm org.jessies.terminator
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 3074kB of archives.
After unpacking 12.3kB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 http://software.jessies.org ./ org.jessies.evergreen 4.37.1970 [1332kB]
Get:2 http://software.jessies.org ./ org.jessies.scm 1.243.1970 [767kB]
Get:3 http://software.jessies.org ./ org.jessies.terminator 4.158.1970 [975kB]
Fetched 3B in 0s (3B/s)
Failed to fetch http://software.jessies.org/debian/./org.jessies.evergreen_4.37.1970_i386.deb Size mismatch
Failed to fetch http://software.jessies.org/debian/./org.jessies.scm_1.243.1970_i386.deb Size mismatch
Failed to fetch http://software.jessies.org/debian/./org.jessies.terminator_4.158.1970_i386.deb Size mismatch
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

but "Software Updates", by trying to be clever, actually makes things worse. ideally, i think, it would run "apt-get update" for me.

apt-get could be improved too; "Size mismatch" doesn't tell me (a) what size it expected, (b) why it expected that size , or (c) what size it got. and looking at the whole sequence i'll include at the bottom of this comment, i'm really not sure my claim above about what causes this problem is right. i mean, the version numbers from the failed attempt are the same as the version numbers in the successful attempt. so what exact file did apt-get have the cached size of? is it actually caching the size of the last-seen file corresponding to a package, but storing just the package name rather than the specific file name? in which case, apt-get could avoid this whole situation by remembering what file size it's cached.

but why does it even cache file sizes? to save an "apt-get update"? in that case, couldn't it use the modification date to infer that its cache is out of date and *know* that it needs to "apt-get update"?

anyway, here's a whole sequence on the command line, after seeing the "Size mismatch" errors in "Software Update":

helium:~$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
  org.jessies.evergreen org.jessies.scm org.jessies.terminator
3 upgraded, 0 newly...

Read more...

 Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

Changed in update-manager:
status: Confirmed → Incomplete
Changed in update-manager:
status: New → Invalid

why is this invalid? afaics, no-one has attempted to fix this, and no-one
has re-tested it. it's being closed because there's been no activity for a
while, and no other reason?

On Thu, February 5, 2009 12:02, Michele Mangili wrote:
> ** Changed in: update-manager
> Status: New => Invalid
>
>
> --
> "Size mismatch" error is unhelpful
> https://bugs.launchpad.net/bugs/77528
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Elliott Hughes, http://www.jessies.org/~enh/

John Vivirito (gnomefreak) wrote :

This is not a updatre-manager bug it is a repo bug. seems as if the index wasnt updated on the repo. We also dont support unofficial repos. And we dont support Debian binaries installing on Ubuntu as there can be big issues with depends.

John Vivirito (gnomefreak) wrote :

see my last comment for reasons why it is invalid.

Changed in update-manager:
status: Incomplete → Invalid
Elliott Hughes (enh) wrote :

On Fri, February 6, 2009 07:53, John Vivirito wrote:
> This is not a updatre-manager bug it is a repo bug. seems as if the
> index wasnt updated on the repo.

not true. the repo is fine, but update-manager(1) isn't doing [the
equivalent of] an "apt-get update". it's using out-of-date data, and
claiming surprise when it doesn't get what it (incorrectly) expects.

> We also dont support unofficial repos.

whose policy is that?

> And
> we dont support Debian binaries installing on Ubuntu as there can be big
> issues with depends.

that's not relevant to this bug.

--
Elliott Hughes, http://www.jessies.org/~enh/

John Vivirito (gnomefreak) wrote :

You do know that the repo is a debian repo right? that carries debian binaries with it.
Ubuntu has never supported unofficial repos since we cant control what is uploaded to them its been like that since before dapper release.

Elliott Hughes (enh) wrote :

On Wed, February 11, 2009 08:48, John Vivirito wrote:
> You do know that the repo is a debian repo right? that carries debian
> binaries with it. Ubuntu has never supported unofficial repos since we
> cant control what is uploaded to them its been like that since before
> dapper release.

as maintainer of the repository in question, i have a pretty good idea of
exactly what's in it.

--
Elliott Hughes, http://www.jessies.org/~enh/

John Vivirito (gnomefreak) wrote :

On 02/11/2009 01:35 PM, Elliott Hughes wrote:
> On Wed, February 11, 2009 08:48, John Vivirito wrote:
>> You do know that the repo is a debian repo right? that carries debian
>> binaries with it. Ubuntu has never supported unofficial repos since we
>> cant control what is uploaded to them its been like that since before
>> dapper release.
>
> as maintainer of the repository in question, i have a pretty good idea of
> exactly what's in it.
>
you stated that debian repo has nothing to do with this bug, see comment:
https://bugs.launchpad.net/update-manager/+bug/77528/comments/9
It has everything to do with it. Since we dont support it we wont try to
allow it in u-m.
If you want to use a repo for Ubuntu why dont you convert the debian
packages to ubuntu packages and use your PPA for Ubuntu packages?

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers