Bug#776910: apt: upgrade from wheezy to jessie breaks in the middle
W dniu 03.02.2015 o 15:17, David Kalnischkies pisze:
Control: tag -1 - newcomer
Hi Rafal,
On Tue, Feb 03, 2015 at 10:20:26AM +0100, Rafal Pietrak wrote:
My guess is that some limit on number of errors was taken into account
unneceserly during an upgrade - upgrades are expected to rise trancient errors.
Your report seems to error into the total opposite unfortunately by not
mentioning a single error. Upgrading is a tricky business and basically
OK. I can see it looks that way.
different for everyone (as which packages you have installed can vary
widely as you have ~30000 to choose from). Your report is hence as
actionable as a weather report saying: "It is going to rain tomorrow
somewhere on earth". That isn't really telling me much about if I should
carry an umbrella around or not on my adventure around my little patch of
dirt. For this, as well as here, we need "details, details, details" to
actually do something about it.
But my crystalball tells me that you might mean #776063 as dpkg shows in
this context a "too many errors" message (litmus test: the word "dbus"
was printed all over the place, right?).
It might, but I don't think so.
1. in my case there was no such thing a long trail of lines with "dbus"
word in them.
2. I do _vaguely_ remember last line above the shell prompt (after
upgrade stopped) saying: "too many errors" (after quite long running
upgrade).
3. to my surprise, "apt-get -f install; apt-get dist-upgrade" did help
... to some extend: the upgrade finished without next stop, but the
system is "not actually usable" (I've filed two more bugreports
regarding that).
4. the entire process/failure resembles what I've experiences while
upgrading to wheezy some two years ago: at that time, I didn't have
correct cpufreq-control and the upgrade did overheated the system, which
rebooted during the process. After that I did numerous manual "pushing"
of the upgrade, and (again _vaguely_ ) remember finding some
"apt-max-errors", which I've (remember) increasing then, which helped a lot.
5. I'm filing this bugreport, because this time there was no
"reboot-in-the middle", so I'd expect, the "apt-max-errors" (if it
really exists - I cannot find it now) is truely too low for "an average
system" .... I'd imagine, that upgrade from one major release to another
should set it temporarly to infinity ;7, but may be not.
If not we need at the very least the actual error message(s). The
current system state (/var/lib/dpkg/status) as well as the state before
the upgrade (the /var/backups/dpkg.status* file dated before the update)
could also be helpful.
The pervious dpkg.status is gone, sorry.
But current "dpkg.status" is c.a. 4.5MB. Is it all right to upload it
anyway?
On a more general note: Try not to guess in bugreports. You are the
eyewitness, you know the facts. I am the guy on jury duty who has to
come up with a coherent story of what happened and why. I know its
tempting to "add" evidence as a witness, but that can spoil the whole
process.
Yes, It is tempting :)
In that case I should say, that I've only witnessed an unexpected and
unprovoked single break during the upgrade. Which was "fully" mended by
only running "apt -f install" followed by a single "apt-get
dist-upgrade". Yet, the system (although reported by apt-get as "fully
up to date") is not fully functional.
Best regards
David Kalnischkies
P.S.: The 'newcomer' tag is for maintainers to indicate "bitsized" bugs
which a newcomer to the project/package can try to tackle to get
started. I wouldn't recommend these sort of upgrade bugs as a starting
point… and we certainly don't need to label bugs from newcomers as such
(which I guess is what you meant it to mean) as a bug is a bug, it isn't
worse just because a longtime contributor reported it.
Ups. (I thought it defines the reporting person). Sorry for misleading tag.
-R
Reply to: