On Tue, Feb 24, 2015 at 09:53:11AM +0100, Rafał Pietrak wrote: > W dniu 23.02.2015 22:27, Niels Thykier pisze: > >On 2015-02-03 16:34, Rafal Pietrak wrote: > [--------------------] > >>2. I do _vaguely_ remember last line above the shell prompt (after > >>upgrade stopped) saying: "too many errors" (after quite long running > >>upgrade). > >> > >I suspect that line is from dpkg. There are example of: > > > >""" > >dpkg: too many errors, stopping > >""" > > > >Maybe you were looking for "dpkg <...> --abort-after=999999"? At least > >that is what a quick googling suggests. > > Possibly. No, you are not looking for this, like ever. apt and dpkg are tidily coupled so people usually have their problems figuring out which message comes from which program, but that is okay as there is just on general rule: If apt exits non-zero (= it fails) then something really bad happened, which shouldn't have happened and which needs to be fixed for the release. No strange workarounds for users. End of story. apt and dpkg have various points at which they consider something to be "really bad" and you can configure some of them to a certain degree, but that isn't advisable. It will usually fail anyway in the best case and open an all consuming crack in the space-time continuum in the worst case. The reason is simply that they aren't failing just for fun and try really hard to avoid any kind of problem to begin with. They also have various points which they consider "bad" and complain about it, but carry on anyway in the hope it will work out anyway. It usually does, but if it doesn't, these messages give hints where it all started to go downhill. > >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. > > > >Rather, there should be no errors during an upgrade - ever. That is one > >of the goals for upgrades. Somehow, setting such a (fictive?) option to > >infinite seems to be working around a problem that should not exist in > >the first place. > > Yes and no. > > *actual errors* yes; but I don't think I've seen them during the upgrade. > > 1. During the upgrade I have seen some "errors"/complains about unresolved > dependencies, or conflicts "... but continiueing anyway as requested" the > apt-get said. > > 2. at one point it said "too many errors" and stopped. > > 3. then a simple "apt-get -f install; apt-get dist-upgrade" completed the > task (sort of) cleanly. > > MHC (e.g. Conclusion) is, that there were "kind of errors", which were > *expected* during the *dist-upgrade* from release to release, but apt-get > counted them anyway....and checked against a treshold .... which it > shouldn't in that particular situation of major release change. The "1." you mention are complains of dpkg about how apt is talking to it. They are 'normal' and 'okay' and are unlimited. (As a user) Ignore them. "2." is very very likely dpkg running into a trigger loop and unrelated to the "1.". (Well, they could be related potentially, but they aren't counting for the 'too many errors', but just influence the formation of loops). The errors leading to "2." look a lot like "1." through, but they are different in such a way that they aren't recoverable if they can't be resolved, so dpkg is trying hard to find a solution, but at some point it has to give up or it would just run forever in circles (it did, in certain buggy versions). "3." works (sometimes) because apt rethinks the upgrade, might come to a different solution (still with the same packages involved, but in a different order) and in this one dpkg doesn't end in a loop. That works ONLY in this case as apt and dpkg have a deep communication problem here. Just rerunning apt usually doesn't work (otherwise we could just do that by default, right?). The think is that I figured out a while back that the way apt is talking to dpkg, dpkg can create a loop for itself without apt knowing before it is actually too late. That is made worse by the fact that apt doesn't know that dpkg cares about these loops anyhow (it didn't until very recently) and apt doesn't know such loops can exist – in fact it pretends that the things (= triggers) which create these loops do not even exist as they are in theory an implementation detail of dpkg. The other RC bugs apt currently has deal with this looping, so if you really want to you can look into them if you want more details, but I would avoid it if I could. Also requires a fair bit of deep knowledge even most DDs do not concern themselves with… so don't say I haven't warned you. ;) The important part is that loop detection was dropped from jessie by request of Nils (thanks a million), so that what you saw will not be seen with released jessie and hence in a wheezy to jessie upgrade. > >I believe the BTS will accept it (you may want to gzip it though), but > >lists.d.o will silently discard it. So follow up with a separate mail > >afterwards to ensure we notice once you have done it. > > I've learned, that attachments are OK. So here is my (most relevant) > dpkg.status after the upgrade. Regretably, at this point I don't have the > one from the date of an upgrade. Thanks, but the status is indeed 'too late'. Its your system already fully upgraded to jessie. Good would have been your wheezy status, or the one in between, but well, that can be attributed to me being such a slowpoke in replying, sorry. :/ I am inclined to close this as "not an issue anymore" instead of merging it with the other trigger loop bugs as we have enough of them already with very similar information (to be fair, I am inclined to close them as well, but I guess it will be a jessie-ignore by Nils [or another release teamer] instead to scare me). Or is there anything left unanswered/open? Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature