cryptsetup creates a 5 seconds delay in the boot

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
[ 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/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input5
[ 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.

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

Thank you for your help, we really do appreciate it.

that's still an issue

could be similar to bug #854986

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

Thank you for your help, we really do appreciate it.

yes it's still an issue (the interaction with users on kernel bugs is ridiculous, you could maybe ask one by stable serie and not do this automatic robot ping pong for every kernel upload)

I had that problem as well, back then /etc/initramfs-tools/conf.d/resume had a wrong UUID for my swap partition. I guess somewhere in between installing cryptsetup, or ubiquity configuring an encrypted swap partition through ecryptfs-utils (I selected "encrypt my home dir" on install) it either wrote a wrong "resume" file right from the start, or something later on changed it. I didn't really notice before as I never use hibernate.

There is a ubiquity bug report regarding swap partitions at bug 709363 which might be related to comment 10.

This bug seems to have been reassigned to initramfs-tools in error. I don't know if this is still an issue, but the issue is the time it takes to initialize the video driver, which is a kernel issue.

Sebastian Bacher, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc1

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

the issue seems resolved on trusty, close the bug report