My laptop is running 12.2 64bits, it has an encrypted LVM. I’m trying to improve the boot up time and used systemd blame which shows lvm.service is taking quite an amount of time to complete whatever it is doing.
See this graph: http://i.imgur.com/RsBuD.png
What could be causing this delay? Where should I start looking for a solution?
Thank you!
Fede
I’m not quite sure what you are looking at.
On one of my computers, I have 12.2 installed in an encrypted LVM. On that same box, using different partitions, I have 12.2 RC2 installed without an LVM, but with encrypted swap (random encryption key for swap).
Booting the encrypted LVM system does take longer, because I have to type in the key. However, apart from that delay in typing the key, I have not noticed any appreciable difference in bootup speed.
As far as I know, the important parts of lvm processing are done in the “initrd” before “systemd” gets into the picture. What remains seems to mostly be waiting for udev to do its thing.
How long does the lvm.service take to start on your computer? My encryption key is not that long and I type pretty fast. I don’t think the delay comes from the typing part. I’ve seen some configurations in which the same service starts really fast.
for example, someone has posted the same service starting in 7842ms here and in Arch
646ms here
My laptop has more or less the same setup as the one mentioned for the Arch system.
739ms lvm.service
Is your root file system part of the lvm?
In my case, it is. And that means that much of the lvm stuff is done in the “initrd” before “systemd” is started. It takes me longer than 739 ms to type in my key.
Part of the point of systemd, is that the parts are run in parallel. So I’m not sure that the times mean a lot. If the root file system is not part of the lvm, the starting the lvm probably includes the time for mounting the file systems that are part of teh lvm. For example, I am seeing
4631ms remount-rootfs.service
It is, the drive is encrypted with LUKS and contains one physical volume with only one volume group which is divided into 3 logical volumes root, home and swap.
Is this more or less the setup you have? The results in your case are much faster than mine, there must be something affecting the process in my case.
Here’s the partitioning for my current desktop (from which I got the timing):
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 401407 199680 83 Linux
/dev/sda2 401408 231094271 115346432 8e Linux LVM
/dev/sda3 231094272 1250263039 509584384 83 Linux
“/sda1” is “/boot”, and “/sda3” is “/shared” which I share over the home network with other computers. The LVM contains root, home, swap.
Most of the LVM and crypto stuff is handled by the “initrd”.
The entire “sda2” is luks encrypted, and opened with LUKS as “/dev/mapper/cr_ata-SAMSUNG_HD642JJ_S1JNJ90QA04749-part2”. It is that “/dev/mapper” virtual disk that is actually the LVM containing root, home, swap.
I’m guessing that the lvm.service time for me is short, because it does not have much to do other than check that everything was already setup in the “initrd”. However, root and home file systems still need to be mounted and/or remounted, which is why I showed that time.
My Setup is similar to yours:
Number Start End Size Type File system Flags
1 1049kB 306MB 305MB primary ext4 boot, type=83
2 306MB 640GB 640GB primary lvm, type=8e
1 is the boot partition
2 is the encrypted volume is which is made of:
--- Physical volume ---
PV Name /dev/mapper/encrypted
VG Name laptop
PV Size 595.88 GiB / not usable 2.10 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 152546
Free PE 0
Allocated PE 152546
--- Volume group ---
VG Name laptop
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 3
Max PV 0
Cur PV 1
Act PV 1
VG Size 595.88 GiB
PE Size 4.00 MiB
Total PE 152546
Alloc PE / Size 152546 / 595.88 GiB
Free PE / Size 0 / 0
--- Logical volume ---
LV Name /dev/laptop/home
VG Name laptop
LV Write Access read/write
LV Status available
# open 1
LV Size 531.88 GiB
Current LE 136162
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:1
--- Logical volume ---
LV Name /dev/laptop/root
VG Name laptop
LV Write Access read/write
LV Status available
# open 1
LV Size 60.00 GiB
Current LE 15360
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:2
--- Logical volume ---
LV Name /dev/laptop/swap
VG Name laptop
LV Write Access read/write
LV Status available
# open 2
LV Size 4.00 GiB
Current LE 1024
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:3
Still in my case is taking much longer than yours to start. Any ideas of where to look for an improvement?
I agree that our two setups are similar. I do not know the reason for the different timings.
Thanks for trying. I’ll see if someone else replies here. I’ll try something in the meantime and will otherwise file a bug for it.