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

Bug#645765: marked as done (please consider allowing to load installer components from a different mirror)

Your message dated Mon, 3 Mar 2014 02:20:41 +0100
with message-id <20140303012041.GA19889@mraw.org>
and subject line Re: Bug#645765: please consider allowing to load installer components from a different mirror
has caused the Debian Bug report #645765,
regarding please consider allowing to load installer components from a different mirror
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
645765: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645765
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: debian-installer
Severity: wishlist
Tags: d-i

Hi,

when entities deploy Debian via network install, point releases can
pose challenges. For example, a site I consult for has a mirror which
is rsynced daily, but the installation server is not updated
automatically with the latest initrd and kernel files.

After the last point release[1], installation was broken since the
kernel from 6.0.2 wasn't willing to load the kernel modules loaded
from the 6.0.3 mirror. Disk not found, game over.

To get around this, I think that it would be desireable to be able to
load installer components from a different source than the repository
that the actual system that is being installed. That way, one would be
able to dump the contents of a (probably older) netinstall CD to a web
server, and point the installer to that web server while still
doing the actual install from ftp.de.d.o.

This could be accomplished, for example, with the following algorithm:

  (1) Run through the normal mirror selection process. Take answer as
      d-i mirror/installer/hostname
  (2) Check whether d-i mirror/installer/hostname is a full mirror or a
      installation image only
      (2a) if full mirror, set d-i mirror/http/hostname to d-i
           mirror/installer/hostname's value
  (3) Expert: Ask "Use the same mirror to for the installation?"
      (3a) if no, ask for d-i mirror/http/hostname
  (4) load installer components from d-i mirror/installer/hostname
  (5) install actual system from d-i mirror/http/hostname

both mirror/installer/hostname and mirror/http/hostname should be
preseedable. Same algorithm for other parameters such as
mirror/*/directory et al.

That way, one could make sure to always have an installer repository
consistent with the kernel/initrd pair offered by the PXE server, and
keep the triple kernel/initrd/repository stable and verified, while
still installing the current point release from the actual mirror.

Please consider adding this functionality to the installer; it would
have saved us (and probably other installations) a lot of grief.
Currently, we have a safety latch active which stops all archive
updates once
/debian/dists/*/main/debian-installer/*/Packages.gz
changes from the file we're familiar with. This is kind of an ugly
workaround, and a nicer solution would be to have the installer load
its components from a dedicated URL that could be forced into sync.

Greetings
Marc



[1] I don't have the slightest idea why this issue has only surfaced
after 6.0.3

--- End Message ---
--- Begin Message --- 
Philipp Kern <pkern@debian.org> (2011-10-18):
> On 2011-10-18, Marc Haber <mh+debian-packages@zugschlus.de> wrote:
> > when entities deploy Debian via network install, point releases can
> > pose challenges. For example, a site I consult for has a mirror which
> > is rsynced daily, but the installation server is not updated
> > automatically with the latest initrd and kernel files.
> 
> There are debian-installer-6.0-netboot-* packages for this in squeeze
> now, FWIW.  It helps in quite a bunch of cases, just maybe not in yours.
> (The install server needs to run on squeeze.)  ;-)
> 
> > [1] I don't have the slightest idea why this issue has only surfaced
> > after 6.0.3
> 
> It certainly happens for new kernel ABIs.  But yeah, point releases
> regularly break d-i netboot images because of the way they work.
> Basically whenever we respin the kernel udebs and then d-i to
> incorporate new security updates / other misc bugfixes.  I wonder what
> was different here if it didn't happen with .1 or .2 (which both had
> non-ABI breaking d-i kernel updates).  Do you have some sort of
> failure message?

I don't think this happens anymore in wheezy, so I'm closing this bug
report. We have another one with a similar goal in mind, with an
attached patch, to review (#736373).

Mraw,
KiBi.

Attachment: signature.asc
Description: Digital signature


--- End Message ---
Reply to: