Re: D-I Etch+1/2 kernel selection (was: Beta1 missing decisions and possible timeline)

2008-02-06 Thread Frans Pop
On Tuesday 05 February 2008, dann frazier wrote:
> On Mon, Feb 04, 2008 at 01:53:43AM +0100, Frans Pop wrote:
> > Finally I created the etch-support udeb which does two things:
> > 1) add an early base-installer hook script that sets the 'altmeta'
> >template
> > 2) add an partman init.d hook script that changes the default
> >inode_size from 256 to 128 (only for i386 and amd64) [2]
>
> Is it known whether or not bootloaders on other archs (the etch
> versions, in particular) are affected by this change? I'm wondering if
> we shouldn't change the etch default to 128, except for archs with
> etch bootloaders that are known to support 256.

As you may have seen on the d-boot list I have changed this in the final 
version after a discussion with Ted Ts'o.
I now include a complete replacement of the mke2fs.conf file that has the 
same defaults as current Etch. Besides the reverted inode_size default this 
also reverts the addition of the "ext_attr" feature.

> > There are still things to decide, and IMO consensus on this should be
> > reached soon!
> > - The naming of the etch+1/2 kernel meta packages is now suddenly
> > essential for the installer and should thus be decided on ASAP.
>
> We talked about this on #debian-kernel last week, and
> linux-image-2.6-$flavor-etchnhalf had no objections.

OK. It's now hardcoded in D-I, so no chance to change your mind anymore :-)


signature.asc
Description: This is a digitally signed message part.


Re: D-I Etch+1/2 kernel selection (was: Beta1 missing decisions and possible timeline)

2008-02-05 Thread dann frazier
On Mon, Feb 04, 2008 at 01:53:43AM +0100, Frans Pop wrote:
> Finally I created the etch-support udeb which does two things:
> 1) add an early base-installer hook script that sets the 'altmeta'
>template
> 2) add an partman init.d hook script that changes the default
>inode_size from 256 to 128 (only for i386 and amd64) [2]

Is it known whether or not bootloaders on other archs (the etch
versions, in particular) are affected by this change? I'm wondering if
we shouldn't change the etch default to 128, except for archs with
etch bootloaders that are known to support 256.

> The result of 1) is IMO exactly what we want:
> - the installer will automagically prefer the Etch+1/2 kernel [4]
>   (preseeding of the exact image as mentioned in [1] is /not/
>   needed)

that's a significant improvement, imo

> - the installer will also install the etch+1/2 kernel meta package, which
>   ensures users will automatically get ABI-changing security updates
> - if for some reason the etchnhalf kernels are not available, the installer
>   will fall back to the 2.6.18 kernels
> - all this only happens if the Lenny installer is used and thus installs
>   using the regular (updated) Etch installer are not changed at all

which is critical..

> There are still things to decide, and IMO consensus on this should be 
> reached soon!
> - The naming of the etch+1/2 kernel meta packages is now suddenly essential
>   for the installer and should thus be decided on ASAP.

We talked about this on #debian-kernel last week, and
linux-image-2.6-$flavor-etchnhalf had no objections.

> - There has as yet been no discussion about exactly which "Etch + Lenny D-I"
>   CD images to create and exactly what should be included on them [3].
>   (Hell, the whole "Etch + Lenny D-I" concept hasn't even really been OKed.)
>   Because of mirror space issues _and_ because of required preparations on
>   the debian-cd side this _really_ needs to be discussed with Sledge
>   urgently.

I'll reply to this on debian-cd only

-- 
dann frazier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: D-I Etch+1/2 kernel selection (was: Beta1 missing decisions and possible timeline)

2008-02-04 Thread Christian Perrier
Quoting Frans Pop ([EMAIL PROTECTED]):

> Sorry for the long explanation below, but I really want people to understand 
> what is happening and why so we are agreed on this implementation and don't 
> have nasty surprises after the point release.


Your mail (which I read carefully) requires ACK from several people.

You maybe want to target these people specifically with specific
questions, in order to be sure to get the quick answers you need.

Apart from that minor suggestion, kudos for that work. I'm pretty much
ignorant with the involved issues and therefore won't care commenting
in the details but, as often, I'm impressed..:-)




signature.asc
Description: Digital signature


D-I Etch+1/2 kernel selection (was: Beta1 missing decisions and possible timeline)

2008-02-03 Thread Frans Pop
On Sunday 03 February 2008, Frans Pop wrote:
> I have been quite disappointed that there was no real follow-up to my
> mails, which now leaves us in the situation that there is basically no
> support yet to select the correct kernel for etch+1/2.

Being the sucker that I am, I did start to look into this after venting
my frustration in the previous mail. I've looked at several options and 
initially the conclusion was that supporting selection for the etch+1/2 
kernel was far from trivial and very likely to be messy.

However, after some false starts that were all way to complex, failure prone 
and ugly, I decided to drag out an old invention: the "etch-support udeb".

Sorry for the long explanation below, but I really want people to understand 
what is happening and why so we are agreed on this implementation and don't 
have nasty surprises after the point release.

The required patches for the installer are attached. I have successfully 
tested them using a custom built netinst CD that had both the 2.6.18 and
2.6.22-686 kernels on it.


Because of changes in the installation procedure since I implemented 
the "sarge-support" udeb, I first needed to ensure installation of the 
etch-support udeb is queued in cdrom-detect and iso-scan. With that, we 
will have the following situation:
- cdrom-detect: queues etch-support for netinst and full CDs
- iso-scan: queues etch-support for hd-media
- choose-mirror: queues etch-support for netboot/floppy-net/businesscard CD

The trick in this is that the udeb will be automatically installed _only_ if 
etch is being installed _and_ the lenny installer is being used.
This is the case if:
- the user is using an Etch netinst or full CD that has the Lenny installer
  on it (this is option 4 from [1])
- the user uses a netboot image or businesscard CD and boots the installer
  with 'suite=etch' or 'suite=stable', or (at medium/low prio) selects
  stable (this is option 3 from [1])

I then added a hack in base-installer which does the following.
If the (new) debconf template "base-installer/kernel/altmeta" has a value 
(e.g. 'etchnhalf'), it will add new potential kernel defaults before the 
the "normal" kernel defaults, with that value postfixed.
I.e, if the normal possible defaults are:
   linux-image-2.6-686
   linux-image-2.6-486
this now becomes:
   linux-image-2.6-686-etchnhalf
   linux-image-2.6-486-etchnhalf
   linux-image-2.6-686
   linux-image-2.6-486

Finally I created the etch-support udeb which does two things:
1) add an early base-installer hook script that sets the 'altmeta'
   template
2) add an partman init.d hook script that changes the default
   inode_size from 256 to 128 (only for i386 and amd64) [2]

The result of 1) is IMO exactly what we want:
- the installer will automagically prefer the Etch+1/2 kernel [4]
  (preseeding of the exact image as mentioned in [1] is /not/ needed)
- the installer will also prefer the correct flavor (which was the main
  issue with my earlier attempts)
- the installer will also install the etch+1/2 kernel meta package, which
  ensures users will automatically get ABI-changing security updates
- if for some reason the etchnhalf kernels are not available, the installer
  will fall back to the 2.6.18 kernels
- all this only happens if the Lenny installer is used and thus installs
  using the regular (updated) Etch installer are not changed at all

There is one issue, which I will detail in a follow-up mail to debian-boot 
only. The short summary is that for arm the etchnhalf kernel meta packages 
are currently not considered "installable", so as things stand now the 
above would not work for arm.


There are still things to decide, and IMO consensus on this should be 
reached soon!
- The naming of the etch+1/2 kernel meta packages is now suddenly essential
  for the installer and should thus be decided on ASAP.
- There has as yet been no discussion about exactly which "Etch + Lenny D-I"
  CD images to create and exactly what should be included on them [3].
  (Hell, the whole "Etch + Lenny D-I" concept hasn't even really been OKed.)
  Because of mirror space issues _and_ because of required preparations on
  the debian-cd side this _really_ needs to be discussed with Sledge
  urgently.
- The changes in the installer need to be implemented and uploaded,
  preferably before the upcoming Beta release, i.e. *very quickly*.


One final remark.
Because of the use of the Lenny installer, the installation procedure will 
be slightly different (improved!) from the Etch installer.
Most relevant changes:
- automatic hardware clock update from NTP server
- by default addition of volatile.d.o besides security.d.o
- slightly changed installation order
- support for installation from multiple CDs from CD/DVD sets
- more targeted prompts for whether or not to use a mirror
- various cleanups and fixes, especially in partman
- some preseeding changes (users should consult the Lenny installation
  guide for preseeding!)

Cheers,
FJP

[1] http://