Re: Debian Installer - Etch Beta 3 release
On Thu, Jun 22, 2006 at 10:29:44PM +0200, Frans Pop wrote:
> (Please reply only to d-boot and optionally the relevant port list.)
>
> Hello d-i porters,
>
> Now that 2.6.16-15 kernels have been uploaded to unstable (using a
> linux-2.6.16 source package), we can start thinking about the Etch Beta 3
> release of D-I.
>
> Currently all architectures, except for arm, have built 2.6.16-15 and it
> should be available from the mirrors tomorrow.
>
> Please rebuild and upload your kernel udeb packages against these new
> kernel images as soon as possible. Note that there have been some recent
> changes in kernel-wedge which may affect your builds.
>
> Note also that 2.6.17 has been uploaded to unstable as well (currently in
> NEW). Do _not_ build the kernel udebs against that, but against 2.6.16!
>
> If you have a chance to run some tests using daily images after the new
> kernel udebs have been uploaded, that would be very much appreciated.
>
> I will post a more detailed release plan as soon as it is clear when the
> 2.6.16 kernel packages will migrate to testing. Some information about
> Beta 3 is already available from [1].
>
> If there are any issues for your architecture that we should be aware of,
> please let us know.
yaboot-installer seems to have a minor bug which make it generate yaboot.conf
file, which are not recognized by ybin and/or cause yaboot to die after the
reboot.
These were the magicboot which ybin doesn't like together with a raw install
(that is, inside a PReP boot partition), like is done on IBM CHRP hardware,
and the yaboot.conf had a line containing just :
device=
which yaboot disliked heavily and thus failed to parse the yaboot.conf file,
and discarded it.
Apart from that, d-i seems to work nicely on the JS21 and probably other IBM
64bit power/powerpc machines, not sure about iseries though.
I even noticed that the partman-prep bug is either solved, or only present on
real prep hardware, as it apparently worked well on that box.
And, for serial installs, we could maybe think of creating a screen .udeb, and
then use that to produce the alternative consoles or something.
Friendly,
Sven Luther
Reply to: