cryptsetup creates a 5 seconds delay in the boot
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
The Ubuntu Boot Speed Project |
Fix Released
|
High
|
Unassigned | ||
linux (Ubuntu) |
Fix Released
|
Low
|
Unassigned |
Bug Description
Using Oneiric Beta2 on a dell latitude e6410 bootchart shows that 5 seconds from the boot is spent waiting for plytmouth to do something, that seems buggy
ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: plymouth 0.8.2-2ubuntu26
ProcVersionSign
Uname: Linux 3.0.0-11-generic i686
ApportVersion: 1.23-0ubuntu1
Architecture: i386
Date: Fri Sep 23 16:05:55 2011
DefaultPlymouth: /lib/plymouth/
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
MachineType: Dell Inc. Latitude E6410
PccardctlIdent:
Socket 0:
no product info available
PccardctlStatus:
Socket 0:
no card
ProcCmdLine: BOOT_IMAGE=
ProcEnviron:
LANGUAGE=
PATH=(custom, user)
LANG=fr_FR.UTF-8
SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=
SourcePackage: plymouth
TextPlymouth: /lib/plymouth/
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/28/2010
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A03
dmi.board.name: 04373Y
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.
dmi.product.name: Latitude E6410
dmi.product.
dmi.sys.vendor: Dell Inc.
Changed in linux (Ubuntu): | |
status: | New → Confirmed |
Changed in linux (Ubuntu): | |
status: | New → Confirmed |
summary: |
- creates a 5 seconds delay in the boot + cryptsetup creates a 5 seconds delay in the boot |
Changed in linux (Ubuntu): | |
status: | New → Confirmed |
Changed in linux (Ubuntu): | |
importance: | Undecided → High |
assignee: | nobody → Canonical Kernel Team (canonical-kernel-team) |
status: | Confirmed → Triaged |
Changed in ubuntu-boot-speed: | |
status: | New → Triaged |
importance: | Undecided → High |
plymouth blocks the boot because you have cryptsetup installed, which forces plymouth to be included in the initramfs. Therefore any video initialization delays which are normally ignored because they happen in parallel to the rest of the system startup become critical-path here because we won't leave the initramfs until plymouth is started *and displaying the splash* - even though in your case the splash isn't needed for dm-crypt prompting.
From the attached dmesg:
[ 4.425321] fbcon: inteldrmfb (fb0) is primary device LNXSYSTM: 00/device: 00/PNP0A08: 00/LNXVIDEO: 01/input/ input5
[ 4.425402] Console: switching to colour frame buffer device 180x56
[ 4.425441] fb0: inteldrmfb frame buffer device
[ 4.425443] drm: registered panic notifier
[ 5.460448] acpi device:3d: registered as cooling_device4
[ 5.587831] input: Video Bus as /devices/
[ 5.587905] ACPI: Video Device [VID1] (multi-head: yes rom: no post: no)
[ 5.587949] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
So the video driver loads at 5.5 seconds after boot, which is almost exactly what we see on the bootchart; and then 'plymouth show-splash' executes, and plymouthd waits for 5 seconds for the splash screen to actually render before it returns control to the initramfs init. (Note from the boot chart that this isn't disk I/O or CPU bound - those are mostly flat, and plymouth is waiting on something else from the kernel. That "something else" has to be the video subsystem.)
I think this is a kernel bug. We can and should make cryptsetup smarter about not installing to the initramfs when not needed for the rootfs, but given that there's some subset of users that will always need cryptsetup, it would be best to still sort out the video delay anyway.