Boot Performance Updates

[Scott James Remnant (Canonical)]

Here is the feature freeze exception request for the boot performance updates for karmic. I will attach tasks to this bug for each package that needs updating, with a rationale for that package if appropriate.

These updates will have been tested first through the ubuntu-boot PPA and on the wide range of hardware and install setups I have here for testing purposes.

They are part of the general work towards karmic+1 for 10s Upstart Native boot.

debhelper: this contains an Upstart-aware dh_installinit used by the other packages
upstart: updated to include the udev bridge and mountall tools
others: updated to switch from init scripts to upstart jobs
sysvinit: updated to not ship most of the contents of initscripts anymore

initramfs-tools: updated to allow for optional scripts/hooks, and to make the framebuffer driver optional on USPLASH=y
usplash: updated to be optional in the initramfs, and converted to upstart (mmm, "stop on starting gdm" goodness)

[Steve Langasek (vorlon)]

What does it mean for usplash to be optional in the initramfs? How is initramfs-tools supposed to know at initramfs generation time whether usplash is needed - aren't we still supposed to be using usplash for opportunistic prompts in the initramfs (such as for fsck)?

[Steve Langasek (vorlon)]

actually, doesn't sound like the initramfs-tools change itself should be a problem, so confirming that one.

[Robbie Williamson (robbiew)]

@Steve By "optional" we mean that it does not show by default, only for specific cases where xsplash cannot be started, i.e. file system check required, encrypted filesystem requiring passwords, etc.

[Steve Langasek (vorlon)]

Before approving the bulk of these, I have a few questions:

- If approved, how soon can these be uploaded? (I think we want the bulk of this to land before alpha-6; if you're ready to go on these, feel free to grab me on IRC so that we can get this on its way.)
- Do we have a rollback plan in the event the upstart job conversions don't work as intended, and under what conditions would we decide to roll back? (E.g., what kind of bugs at beta time would be a sign that something is Wrong?)
- There are a number of packages not on this list which have init scripts whose lsb headers reference packages that are being converted, e.g.:
  /etc/init.d/libvirt-bin:# Should-Start: hal avahi
  /etc/init.d/saned:# Should-Start: dbus avahi
  /etc/init.d/bluetooth:# Required-Start: $local_fs $syslog $remote_fs dbus
  /etc/init.d/landscape-client:# Required-Start: $local_fs $remote_fs hal dbus
  /etc/init.d/dns-clean:# Required-Start: $local_fs gdm
  /etc/init.d/pppd-dns:# Required-Start: $local_fs gdm
  /etc/init.d/pulseaudio:# Should-Start: udev NetworkManager
 + countless instances of 'syslog'

how are these handled? Are all the native upstart jobs guaranteed to be processed first before running rc?

[Steve Langasek (vorlon)]

Robbie, in that case why are changes to initramfs-tools required to implement this? The initramfs hook itself should figure out whether to run - initramfs-tools can't know, when building the initramfs, whether a filesystem check will be required since that's decided at boot.

The encrypted fs use case can be detected at initramfs build time, but that's not the only use case.

[Scott James Remnant (Canonical) (canonical-scott)]

On Fri, 2009-09-11 at 19:10 +0000, Steve Langasek wrote:

> Before approving the bulk of these, I have a few questions:
>
> - If approved, how soon can these be uploaded? (I think we want the
> bulk of this to land before alpha-6; if you're ready to go on these,
> feel free to grab me on IRC so that we can get this on its way.)
>
I'm ready to upload them today, so they'll be before alpha 6. The tasks
are a single set though, so they have to go in together or not at all.

> - Do we have a rollback plan in the event the upstart job conversions
> don't work as intended, and under what conditions would we decide to
> roll back? (E.g., what kind of bugs at beta time would be a sign that
> something is Wrong?)
>
To be honest, I'm pretty confident that we can work out the bugs. I'm
already getting reports that situations that didn't work with the old
init scripts work now (USB disks mentioned in fstab now being mounted,
etc.)

I fully expect there to be a few bugs, of course.

Rollback plan is obviously going to have to be to revert all the
changes, and delete the Upstart jobs restoring the init scripts.

> - There are a number of packages not on this list which have init scripts whose lsb headers reference packages that are being converted, e.g.:
> /etc/init.d/libvirt-bin:# Should-Start: hal avahi
> /etc/init.d/saned:# Should-Start: dbus avahi
> /etc/init.d/bluetooth:# Required-Start: $local_fs $syslog $remote_fs dbus
> /etc/init.d/landscape-client:# Required-Start: $local_fs $remote_fs hal dbus
> /etc/init.d/dns-clean:# Required-Start: $local_fs gdm
> /etc/init.d/pppd-dns:# Required-Start: $local_fs gdm
> /etc/init.d/pulseaudio:# Should-Start: udev NetworkManager
> + countless instances of 'syslog'
>
> how are these handled? Are all the native upstart jobs guaranteed to be
> processed first before running rc?
>
We don't use the LSB headers, so they don't matter.

But I do plan to convert them - just not in time for Alpha 6 and I think
it's important that we get the root code (filesystem mounting, etc.) as
widely tested as possible.

Scott
--
Scott James Remnant
<email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

On Fri, 2009-09-11 at 17:56 +0000, Steve Langasek wrote:

> What does it mean for usplash to be optional in the initramfs? How is
> initramfs-tools supposed to know at initramfs generation time whether
> usplash is needed - aren't we still supposed to be using usplash for
> opportunistic prompts in the initramfs (such as for fsck)?
>
A file placed in /etc/initramfs-tools/conf.d with USPLASH=y tells
initramfs-tools that it is needed.

We don't do fsck, etc. in the initramfs - the only prompt we do there is
asking for a cryptroot password - and that's something that can be
handled by cryptsetup.

(Right now, not handling it is fine too, it'll just prompt on the
console)

Scott
--
Scott James Remnant
<email address hidden>

[Steve Langasek (vorlon)]

Oh, fair point - so we can start usplash from the root filesystem if needed for fsck prompting? Does this work already today, and if not, is this converging on schedule for release?

In some cases, cryptsetup will be installed on systems that aren't using crypted root; so having cryptsetup ship a file under /etc/initramfs-tools/conf.d turning on usplash will cause usplash to be used in some initramfses where it's not needed (and possibly even some systems where no prompting is required). Is that acceptable, or do you have some other plan for how usplash will be selected?

[Steve Langasek (vorlon)]

On Mon, Sep 14, 2009 at 03:02:23PM -0000, Scott James Remnant wrote:
> I'm ready to upload them today, so they'll be before alpha 6. The tasks
> are a single set though, so they have to go in together or not at all.

Ok, please go ahead.

> > - There are a number of packages not on this list which have init scripts whose lsb headers reference packages that are being converted, e.g.:
> > /etc/init.d/libvirt-bin:# Should-Start: hal avahi
> > /etc/init.d/saned:# Should-Start: dbus avahi
> > /etc/init.d/bluetooth:# Required-Start: $local_fs $syslog $remote_fs dbus
> > /etc/init.d/landscape-client:# Required-Start: $local_fs $remote_fs hal dbus
> > /etc/init.d/dns-clean:# Required-Start: $local_fs gdm
> > /etc/init.d/pppd-dns:# Required-Start: $local_fs gdm
> > /etc/init.d/pulseaudio:# Should-Start: udev NetworkManager
> > + countless instances of 'syslog'

> > how are these handled? Are all the native upstart jobs guaranteed to be
> > processed first before running rc?

> We don't use the LSB headers, so they don't matter.

If the LSB headers are accurate declarations of these services'
dependencies, and we fail to reliably honor those dependencies, then it
matters.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

On Mon, 2009-09-14 at 17:49 +0000, Steve Langasek wrote:

> Oh, fair point - so we can start usplash from the root filesystem if
> needed for fsck prompting? Does this work already today, and if not, is
> this converging on schedule for release?
>
It's on schedule for release.

> In some cases, cryptsetup will be installed on systems that aren't using
> crypted root; so having cryptsetup ship a file under /etc/initramfs-
> tools/conf.d turning on usplash will cause usplash to be used in some
> initramfses where it's not needed (and possibly even some systems where
> no prompting is required). Is that acceptable, or do you have some
> other plan for how usplash will be selected?
>
I don't think it's a bad thing. If you have cryptsetup installed, one
file system or another is bound to be encrypted so you're getting
usplash anyway.

If you have it installed but no encrypted fs, it's a simple fix to get
rid of usplash.

Scott
--
Scott James Remnant
<email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

On Mon, 2009-09-14 at 17:57 +0000, Steve Langasek wrote:

> > > - There are a number of packages not on this list which have init scripts whose lsb headers reference packages that are being converted, e.g.:
> > > /etc/init.d/libvirt-bin:# Should-Start: hal avahi
> > > /etc/init.d/saned:# Should-Start: dbus avahi
> > > /etc/init.d/bluetooth:# Required-Start: $local_fs $syslog $remote_fs dbus
> > > /etc/init.d/landscape-client:# Required-Start: $local_fs $remote_fs hal dbus
> > > /etc/init.d/dns-clean:# Required-Start: $local_fs gdm
> > > /etc/init.d/pppd-dns:# Required-Start: $local_fs gdm
> > > /etc/init.d/pulseaudio:# Should-Start: udev NetworkManager
> > > + countless instances of 'syslog'
>
> > > how are these handled? Are all the native upstart jobs guaranteed to be
> > > processed first before running rc?
>
> > We don't use the LSB headers, so they don't matter.
>
> If the LSB headers are accurate declarations of these services'
> dependencies, and we fail to reliably honor those dependencies, then it
> matters.
>
Why? Nothing uses them.

In fact, nothing *can* use them because there isn't one in acpi-support
<g>

Scott
--
Scott James Remnant
<email address hidden>

[Steve Langasek (vorlon)]

On Mon, Sep 14, 2009 at 07:51:11PM -0000, Scott James Remnant wrote:
> I don't think it's a bad thing. If you have cryptsetup installed, one
> file system or another is bound to be encrypted so you're getting
> usplash anyway.

Crypted filesystems can be decrypted using an on-disk key instead of a
passphrase; it's debatable whether that's ever sensible, but it does mean
there are use cases where cryptsetup is used but doesn't prompt on boot.

Anyway, I agree that it's reasonable to have usplash come up in this
particular case - just want to make sure we know what we're in for in
karmic.

Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Launchpad Janitor (janitor)]

This bug was fixed in the package upstart - 0.6.3-2

---------------
upstart (0.6.3-2) karmic; urgency=low

  FFE LP: #427356.

  * debian/upstart-job:
    - Remove trailing "s" from file
    - Support direct invocation better.
  * udev/upstart-udev-bridge.c:
    - New tool to capture events from the udev netlink socket and
      convert into upstart events.
  * conf/rc-sysinit.conf:
    - Run once all filesystems are mounted, rather than on startup
  * debian/control:
    - Add dependency on mountall for the filesystem event.

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:19:09 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package acpid - 1.0.6-9ubuntu6

---------------
acpid (1.0.6-9ubuntu6) karmic; urgency=low

  FFE LP: #427356.

  * Replace init script with Upstart job.
    - This does not load modules, unlike the init script, since these are
      all loaded by ACPI:* modaliases now (and thus by udev)
  * debian/control:
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:34:49 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package anacron - 2.3-13.1ubuntu9

---------------
anacron (2.3-13.1ubuntu9) karmic; urgency=low

  FFE LP: #427356.

  * Replace init script with Upstart job.
    - Do not start the job on installation, since anacron is run from
      cron or on boot to catch up.
  * debian/control:
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:34:29 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package apport - 1.9-0ubuntu4

---------------
apport (1.9-0ubuntu4) karmic; urgency=low

  FFE LP: #427356.

  * Replace init script with Upstart job.
  * debian/control:
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:33:57 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package at - 3.1.11-1ubuntu4

---------------
at (3.1.11-1ubuntu4) karmic; urgency=low

  FFE LP: #427356.

  * Replace init script with Upstart job.
  * debian/control:
    - Add missing ${misc:Depends}
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:33:39 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package avahi - 0.6.25-1ubuntu3

---------------
avahi (0.6.25-1ubuntu3) karmic; urgency=low

  FFE LP: #427356.

  * Replace init scripts with Upstart jobs.
  * debian/control:
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:33:13 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package cron - 3.0pl1-106ubuntu3

---------------
cron (3.0pl1-106ubuntu3) karmic; urgency=low

  FFE LP: #427356.

  * Replace init script with Upstart job.
  * debian/control:
    - Add missing ${misc:Depends}
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:32:59 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package dbus - 1.2.16-0ubuntu3

---------------
dbus (1.2.16-0ubuntu3) karmic; urgency=low

  FFE LP: #427356.

  * Replace init script with Upstart job.
  * debian/control:
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:32:44 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package debhelper - 7.3.15ubuntu2

---------------
debhelper (7.3.15ubuntu2) karmic; urgency=low

  FFE LP: #427356.

  * dh_installinit: handle upstart job files in preference over init
    scripts, supplying appropriate maintainer scripts to stop, start or
    restart the jobs over upgrades.
    - currently unlike init scripts, these accept failures because Upstart
      considers "start when already running" failure.
  * dh_installinit: --upstart-only will not include maintainer script code
    to replace an init script with an upstart job, otherwise a compatibilty
    symlink to /lib/init/upstart-job is left in its place

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:32:13 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package gdm - 2.27.90-0ubuntu5

---------------
gdm (2.27.90-0ubuntu5) karmic; urgency=low

  FFE LP: #427356.

  * Replace init script with Upstart job.
  * debian/control:
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit
  * debian/patches/20_upstart.patch:
    - Emit Upstart events when starting the login session and desktop
      session, just after starting xsplash. These can be used as
      synchronisation points.

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:31:21 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package hal - 0.5.13-1ubuntu3

---------------
hal (0.5.13-1ubuntu3) karmic; urgency=low

  FFE LP: #427356.

  * Replace init script with Upstart job.
  * debian/control:
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:31:00 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package hostname - 2.95ubuntu1

---------------
hostname (2.95ubuntu1) karmic; urgency=low

  FFE LP: #427356.

  * Add -b option that allows the file specified by -F to be non-existant
    or empty, in which case the default hostname of "localhost" will be set
    if none is set currently.
  * Install Upstart job to set hostname on startup, but do not run it in
    postinst.
  * debian/control:
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:37:22 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package ifupdown - 0.6.8ubuntu20

---------------
ifupdown (0.6.8ubuntu20) karmic; urgency=low

  FFE LP: #427356.

  * Replace the udev rule with a per-interface Upstart job.
  * Add a "networking" job that partially replaces the networking init
    script from netbase.
  * debian/control:
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit
    - Add missing ${misc:Depends}

  * Add if-up and if-down scripts to emit Upstart events when interfaces
    come up and go down.

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:30:29 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package initramfs-tools - 0.92bubuntu46

---------------
initramfs-tools (0.92bubuntu46) karmic; urgency=low

  FFE LP: #427356.

  * mkinitramfs: Allow scripts to specify OPTION=VAR, and unless VAR is
    set to something other than "n", the script will not be included.
  * scripts/functions: Likewise when running scripts (for hooks)

  * Make usplash-related components optional, you need to set USPLASH=y
    for these to be included:
    - hooks/kernelextras: which includes the KMS driver
    - scripts/init-top/framebuffer: which loads it

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:30:12 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package module-init-tools - 3.10-3

---------------
module-init-tools (3.10-3) karmic; urgency=low

  FFE LP: #427356.

  * Replace init script with Upstart job.
    - This drops support for the long deprecated (and never documented)
      /etc/modules-2.6 and /etc/modules-2.6.24 forms
  * debian/control:
    - Add missing ${misc:Depends}
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:29:39 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package netbase - 4.35ubuntu2

---------------
netbase (4.35ubuntu2) karmic; urgency=low

  FFE LP: #427356.

  * debian/netbase.init:
    - Replace the "start" command with a call to upstart-job
  * debian/control:
    - Depend on upstart-job
  * debian/netbase.postinst:
    - Remove old start symlinks on upgrade
    - Only install symlinks for runlevel 0 and 6

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:27:40 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package procps - 1:3.2.8-1ubuntu3

---------------
procps (1:3.2.8-1ubuntu3) karmic; urgency=low

  FFE LP: #427356.

  * Replace init script with Upstart job.
    - Do not start after upgrade.
  * debian/control:
    - Add missing ${misc:Depends}
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit
  * Use contents of /etc/sysctl.conf after contents of files in /etc/sysctl.d
    LP: #292470.

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:26:56 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package rsyslog - 4.2.0-2ubuntu3

---------------
rsyslog (4.2.0-2ubuntu3) karmic; urgency=low

  FFE LP: #427356.

  * Replace init script with multiple Upstart jobs.
  * debian/control:
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:26:43 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package sreadahead - 1.0-3

---------------
sreadahead (1.0-3) karmic; urgency=low

  FFE LP: #427356.

  * debian/rules, debian/sreadahead.install:
    - Install Upstart job using dh_installinit
  * debian/control:
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit
  * debian/sreadahead.upstart:
    - Start before mounting filesystems.

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:26:20 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package sysvinit - 2.87dsf-4ubuntu3

---------------
sysvinit (2.87dsf-4ubuntu3) karmic; urgency=low

  FFE LP: #427356.

  * Various initscripts have been replaced by Upstart jobs shipped in
    other packages, the following have been removed:
    - hostname.sh
    - mountkernfs.sh
    - mountdevsubfs.sh
    - checkroot.sh
    - mtab.sh
    - checkfs.sh
    - mountall.sh
    - mountall-bootclean.sh
    - mountoverflowtmp
    - mountnfs.sh
    - mountnfs-bootclean.sh
    - bootmisc.sh
    - bootlogs
    - rmnlogin

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 02:45:59 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package udev - 147~-1

---------------
udev (147~-1) karmic; urgency=low

  FFE LP: #427356.

  * Update to GIT HEAD (pre 147 release):
    - worker signal mask corrected. LP: #407428.
    - database format change to avoid path length issues. LP: #377121.
    - multiple devices may not claim the same /dev names, except with
      symlinks
    - NAME="%k" produces a warning
    - symlinks to udevadm no longer resolve to the original command
    - rules updates. LP: #281335, LP: #407940, #420015, #426647.

  * Build-depend on gawk, since build fails with mawk.

  * Replace init scripts with Upstart jobs.
  * debian/control:
    - Add missing ${misc:Depends}
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:22:11 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package network-manager - 0.8~a~git.20090911t130220.4c77fa0-0ubuntu3

---------------
network-manager (0.8~a~git.20090911t130220.4c77fa0-0ubuntu3) karmic; urgency=low

  FFE LP: #427356.

  * Replace init script with Upstart job.
  * debian/control:
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 13:40:43 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package usplash - 0.5.37

---------------
usplash (0.5.37) karmic; urgency=low

  FFE LP: #427356.

  * Make usplash optional in the initramfs, you need to set USPLASH=y
    otherwise it will not be included:
    - initramfs/scripts/init-top/usplash: script optional
    - initramfs/hooks/usplash: as is hook

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 15:13:16 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package util-linux - 2.16-1ubuntu2

---------------
util-linux (2.16-1ubuntu2) karmic; urgency=low

  FFE LP: #427356.

  * Replace hwclock udev rule with an Upstart job. This has never needed
    to be a udev rule after all since it doesn't access the hardware!
  * Replace init script with an Upstart job run on shutdown.
  * debian/control:
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit
    - Add missing ${misc:Depends}

  * Fix build with newer glibc due to versionsort() prototype change.

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 15:14:58 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package cryptsetup - 2:1.0.6+20090405.svn49-1ubuntu2

---------------
cryptsetup (2:1.0.6+20090405.svn49-1ubuntu2) karmic; urgency=low

  * debian/initramfs/cryptroot-conf: declare that we want usplash included
    in the initramfs whenever this package is installed. LP: #427356.

 -- Steve Langasek <email address hidden> Tue, 15 Sep 2009 08:43:15 -0700

[Martin-Éric Racine (q-funk)]

This series of uploads seriously broke things on this system! I'm sorry, but I'm gonna have to ask for the above changes to be reverted immediately and for the Free Exception to be withdrawn. I'll also ask for these changes to be postponed to karmic+1.

[Steve Langasek (vorlon)]

The packages in question must all be upgraded as a group, and owing to these very uploads, the packages are not yet all built (having broken the buildd chroots for a time). When the dust settles we should look at making the upgrade path more robust, but until then it's too early to declare it broken (and the release team, at least, will not entertain requests for a revert).

[Kamilion (kamilion)]

The only issue I'm currently having with this series is requesting an upgrade to 'initscripts' is asking for hostname, rsyslog, and ubuntu-minimal to be removed at the moment. This scared me enough to cancel synaptic/update-manager and look at the list of packages a bit closer. Found the link here, deselected the packages listed above and installed everything else.

Still waiting on a few more packages to make the switch, but I'm definitely looking forward to it.

Thanks for the hard work, Robbie, Scott, and Steve!
Let us know when it's safe to proceed, if you would be so kind.

[Ryan (ubuntu-draziw)]

Well, I'm now able to boot again - but this was a pain. I have a couple questions...

1. With all the functional package dependency issues, were they not all set in the debs? eg - How is it that some packages being available and some not allowed it to mangle so many systems in the field? Shouldn't it have held off trying to install any until all were in? Were the dependencies set incorrectly?

2. With such a large change (touching so many areas) with such risk ('average' testers unable to boot/recover without a lot launchpad visits after rescue usb/cd)... Was this tested as set via a PPA etc first and somehow everyone running via the PPA just had zero issues? - Or was it direct to test on all the 'normal' alpha uses using the normal repos?

Ouch and glad to be able to boot all the way into X again - thanks for the recovery. :)

[Robbie Williamson (robbiew)]

On 09/15/2009 07:55 PM, Ryan wrote:
[snip]>
> 2. With such a large change (touching so many areas) with such risk
> ('average' testers unable to boot/recover without a lot launchpad visits
> after rescue usb/cd)... Was this tested as set via a PPA etc first and
> somehow everyone running via the PPA just had zero issues? - Or was it
> direct to test on all the 'normal' alpha uses using the normal repos?
>

The packages were released via the ubuntu-boot team PPAs and tested without
major issues. The problem was not the packages, the problem was the buildds not
being happy in the middle of moving the packages into the archive. With that
said, a discussion has started on how we can modify update-manager, so that in
the future we can basically stop users from upgrading packages when we know the
archive is foobar'd.

[Luka Renko (lure)]

Dust have settled, but new mountall still causes regression for LVM+dm_crypt configuration - seems that cryptsetup was not taken into account with this updates. See bug 430496

[Kamilion (kamilion)]

Just some notes...

The new networking scripts failed to find my br0 defined in /etc/network/interfaces.
(Fortunately this motherboard has IPMI2 KVM-over-dedicated-IP, otherwise I would have been up a creek)

couldn't find out how to disable upstart services, so I ended up moving /etc/init/gdm.conf to /etc/init-disabled/gdm.conf,
Any better ways?

sysvconfig has gone away, but sysv-rc-conf works fine for poking at the remaining rc?.d sysv links.

Some simple upstart jobs I'd like to see quickly:
opensshd, postfix, bootlogd, kvm/libvirt

[Steve Langasek (vorlon)]

On Wed, Sep 16, 2009 at 06:59:43AM -0000, Kamilion wrote:

> The new networking scripts failed to find my br0 defined in
> /etc/network/interfaces.

Please open a separate bug report for this against the ifupdown package, and
provide the contents of your /etc/network/interfaces.

> couldn't find out how to disable upstart services, so I ended up moving
> /etc/init/gdm.conf to /etc/init-disabled/gdm.conf, Any better ways?

For the moment, I'm not aware of one.

> Some simple upstart jobs I'd like to see quickly:
> opensshd, postfix, bootlogd, kvm/libvirt

These are not a priority for the karmic release cycle, and at the moment we
have our hands full resolving the bugs that have been identified with those
services already converted. You could file wishlist bugs against these
packages, but I don't think there'd be much point.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

On Wed, 2009-09-16 at 00:55 +0000, Ryan wrote:

> 1. With all the functional package dependency issues, were they not all
> set in the debs? eg - How is it that some packages being available and
> some not allowed it to mangle so many systems in the field? Shouldn't it
> have held off trying to install any until all were in? Were the
> dependencies set incorrectly?
>
The core set of packages had a circular set of dependencies, involving
Essential/required packages. Unfortunately this meant if APT couldn't
see all of them at once, it did the wrong thing when using dist-upgrade.

The reason you couldn't see all of them at once is that the exact same
thing happened to the buildds, and they ended up being unable to
continue building the very packages they needed to unstick themselves.

> 2. With such a large change (touching so many areas) with such risk
> ('average' testers unable to boot/recover without a lot launchpad visits
> after rescue usb/cd)... Was this tested as set via a PPA etc first and
> somehow everyone running via the PPA just had zero issues? - Or was it
> direct to test on all the 'normal' alpha uses using the normal repos?
>
All of the updates were first tested in the ubuntu-boot PPA. No issues
were reported.

Even so, it's quite normal to directly test using the
development/unstable release - that's exactly what it's for. If you're
running the development/unstable release, you should expect regular
problems.

(Though compared to other distros, we seem to do a better job of holding
it all together)

Scott
--
Scott James Remnant
<email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

On Wed, 2009-09-16 at 06:59 +0000, Kamilion wrote:

> The new networking scripts failed to find my br0 defined in /etc/network/interfaces.
> (Fortunately this motherboard has IPMI2 KVM-over-dedicated-IP, otherwise I would have been up a creek)
>
You should file a separate bug for this.

> couldn't find out how to disable upstart services, so I ended up moving /etc/init/gdm.conf to /etc/init-disabled/gdm.conf,
> Any better ways?
>
Rename them to .conf-disabled is another.

I tend to just comment out the "start on" line.

Better methods are planned in future Upstart releases which will find
their way into future Ubuntu releases.

> Some simple upstart jobs I'd like to see quickly:
> opensshd, postfix, bootlogd, kvm/libvirt
>
I think we'll largely stick with the current set for karmic; though
don't be surprised if karmic+1 work appears in the ubuntu-boot PPA
sooner rather than later.

Scott
--
Scott James Remnant
<email address hidden>

[Kamilion (kamilion)]

On Wed, Sep 16, 2009 at 12:05 PM, Scott James Remnant wrote:
> On Wed, 2009-09-16 at 06:59 +0000, Kamilion wrote:
>
>> The new networking scripts failed to find my br0 defined in /etc/network/interfaces.
>> (Fortunately this motherboard has IPMI2 KVM-over-dedicated-IP, otherwise I would have been up a creek)
>>
> You should file a separate bug for this.

Never mind, it was my fault. Missed a package. Haven't had the problem since the initial reboot.
After a package update this morning and a reboot, it works fine.

>> couldn't find out how to disable upstart services, so I ended up moving /etc/init/gdm.conf to /etc/init-disabled/gdm.conf,
>> Any better ways?
> Rename them to .conf-disabled is another.
So it's looking in any directory under /etc/init for ".conf" files, correct?

What's the best trigger to get upstart to log all events as early as possible?
I'd like to figure out the path the new setup follows.

> I tend to just comment out the "start on" line.
yeah, I ended up doing the same, to keep 'start gdm' working,

> Better methods are planned in future Upstart releases which will find
> their way into future Ubuntu releases.

Where's the discussion for this type of stuff currently centered?

>> Some simple upstart jobs I'd like to see quickly:
>> opensshd, postfix, bootlogd, kvm/libvirt

> I think we'll largely stick with the current set for karmic; though
> don't be surprised if karmic+1 work appears in the ubuntu-boot PPA
> sooner rather than later.

I've got some time to kill, and I'd like to see at least opensshd make the jump before karmic+1, mainly because it's one of the single most important dependencies on a remote system to have properly tied to network events being emitted. Better to debug this now and have it solid and reliable before ubuntu-server goes out.
How can I help? (Just send me an email)

[Scott James Remnant (Canonical) (canonical-scott)]

On Thu, 2009-09-17 at 01:46 +0000, Kamilion wrote:

> > Better methods are planned in future Upstart releases which will find
> > their way into future Ubuntu releases.
>
> Where's the discussion for this type of stuff currently centered?
>
On the upstream Upstart development list.

Scott
--
Scott James Remnant
<email address hidden>

[Jamie Strandboge (jdstrand)]

This change affected ufw, as seen in bug #431804. Fix is forthcoming.

[Frans van Berckel (fberckel)]

Is bug #427356 about a hard freeze after 2 lines of boot in Karmic on PowerPC related?

[Steve Langasek (vorlon)]

I don't know what other bug you meant to refer to, but the bug number you've given is the one for /this/ bug report...

[Frans van Berckel (fberckel)]

Sorry I was talking about bug # 432155

[Steve Langasek (vorlon)]

Yes, that bug looks like it's probably a regression introduced by this change.

[Frans van Berckel (fberckel)]

And bug #433494 about Karmic system fails to boot got to be related as well!

[Martin-Éric Racine (q-funk)]

Also affects console-setup and pulseaudio, both of which are partially broken since this migration has started.

[Martin-Éric Racine (q-funk)]

See bug #433897 for console-setup issues and bug #433884 for pulseaudio issues.

[Jasmine Hassan (jasmine-aura)]

Well, everyone keeps saying usplash was disabled, I figured I must be missing something obvious. But it didn't seem as though, because I was mislead...

On September 2nd, 2008, Scott Remnant wrote, on:
http://www.netsplit.com/2009/09/02/making-a-splash/

>You could also argue that we could load the KMS drivers earlier, in the initramfs for example. While possible, this adds a significant time to the boot time for the extra loading and probing required. If we load the KMS driver in the initramfs, it takes about 8-10s to load the X server; if we load the KMS driver in the full system, it only takes about 6-8s to load the X server. Easy win.

>But what if we have to check the filesystem, or enter a decryption passphrase to mount it? That’s why we still have usplash. In those cases we will start usplash to display the progress or request the key. The usplash theme will be themed such that when it finishes, and X starts up, it looks ok frozen for the short time until xsplash replaces it with an identical theme.

So I was under the impression that usplash was here to stay, with the addition of xsplash..

However, on a minimal / "command-line" installed system, xsplash may be too much for the system to handle, in terms of resources, and in terms of graphical support, if a minimal X environment was later installed. For instance, on my test-bed system, a neomagic 256ZX with 4mb video ram is not capable of supporting 24-bit color depth, as its max supported resolution is 1024x768 @ 16-bit depth.

Are there any plans to account for that in other ubuntu branches, like say, Lubuntu?

To make matters worse, the new "feature" added by the stream of fixes described in bug #427356 "Boot performance updates" - i.e the newly added option "USPLASH=y" to initramsfs-tools - was nowhere to be mentioned.. Not in the default /etc/initramfs-tools/initramfs.conf file, nor in `man initramfs.conf`, nor in any of the usplash package files :(

I guess we need this new option documented in `man initramfs.conf` or to at least include "USPLASH=n" in the default initramfs.conf ?

Thanks

[Jasmine Hassan (jasmine-aura)]

On a side note:
Having both usplash and xsplash, usplash kicks in for most of the boot time than xsplash does on my test-bed slow (minimal install) system - P3 500mhz, 192mb PC100 RAM.. That is, usplash for about 16 seconds, no *splash for about a 7-8 second gap, then xsplash for 4-5 seconds :(

[d2kx (d2kxweb)]

I've got a high-end system and for me usplash also takes up the most time it seems. Two splashes is a bad thing.

[Steve Langasek (vorlon)]

usplash is currently *only* used if you have the cryptsetup package installed, which needs it for prompting for passphrases in the initramfs. If you aren't using encrypted disks, you should remove the cryptsetup package from your system. If you don't have cryptsetup installed but you are seeing usplash, make sure you upgrade to the latest versions of all packages in karmic and check whether that doesn't fix this. If it doesn't, please file a new bug report.

If you are using cryptsetup, booting will be unavoidably slower.

[Matteo Settenvini (tchernobog)]

I use cryptsetup only for removable media which isn't connected at startup, and for filesystems mounted manually as loopback devices. Thus, can't we avoid using usplash if /etc/crypttab is empty/non-existant/contains only comments? That'll help a lot.

[Jasmine Hassan (jasmine-aura)]

@Comment #61 by Steve Langasek:

How about file-system checks? no usplash while fsck analyzes the file-systems?

I would've thought usplash is still needed in such case. i.e. only started from initramfs when a file-system check is about to begin.