[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#765458: apt: broken cdrom support, breaking installation from weekly ISO images


David Kalnischkies <david@kalnischkies.de> (2014-10-15):
> On Wed, Oct 15, 2014 at 11:47:44AM +0200, Cyril Brulebois wrote:
> > [ X-D-Cc: debian-boot@, please keep it in the loop when replying. ]
> [Done, although I don't see the header… (bad mutt, bad).]

IIRC it's munged when the submitted report is processed, that's why I'm
mentioning this every time I use this header.

> > we received several bug reports about weekly installation images being
> > unable to find a kernel package to install on the freshly debootstrapped
> > system. I've been able to replicate this issue with apt Various
> Is the "apt-get update" call from which you have included the output
> a recent addition or was it 'always' there?
> I am asking as 'apt-cdrom add' actually does the work of copying the
> indexes to disk, which (should) mean that 'apt-get update' is a no-op,
> making the call useless if cdroms are really the only possible source in
> that stage.
> That 'update' isn't really supposed to be called here is reinforced by
> the ugly warnings/errors you showcase and which existed since ever. Our
> only testcase covering apt-cdrom also doesn't include such a call…
> Why that is the case, I have no idea, as I would expect at least some
> people to have multiple sources, including cdrom, which would call for
> an update, so that should really work without being scary (= assuming
> warnings from apt are regarded as scary…).
> The irony is that the suspected bad-boy 80174528 actually fixes this
> longstanding problem as the regression was that apt exited nonzero, not
> that it printed warnings (so much for scary).
> The problematic commit is b0f4b486 (and therefore not a regression in
> a security fix – everyone rejoice): While fine by itself, merged with
> the suspected bad-boy we still have no warnings and a successful exit,
> but our helpful list-cleanup kicks in removing files from the lists/
> directory which seem to be orphaned given that it is looking e.g. for
> a Packages.gz file and not for Packages as the part fixing up the
> filename is skipped if a cdrom source is encountered.

You can pretend I don't know anything about d-i vs. apt, except for
running git log in apt.git and looking for cdrom-related changes; you
won't be far from reality.

> The attached patch should merge both in a better working way, at least
> that is what the testcase is promising me – which I have extended a bit
> to cover a bit more ground, too. Nothing near proper testing though, so
> someone giving it a proper testspin would be nice, but if that is too
> hard I guess Michael could just upload it and let the world test it for
> us (now that he doesn't have to fear another security upload).  ;)

I've tweaked bits and pieces locally to use apt at the
appropriate time and I can confirm that the easy/usual one-CD case is
fixed, thanks! It'd be nice to see what happens with several CDs but
that's not going to be me today.

Some notes:
 - apt.git is missing at least one commit and the tag.
 - I think you wanted to close #764442, rather than #76442.

I'm tempted to make apt migrate to testing soon, possibly today, because
bug reports are piling up. From your maintainer point of view, is there
anything speaking against such a move?

Thanks again for the swift fix.


Attachment: signature.asc
Description: Digital signature

Reply to: