Unusually long boot times with LVM Snapshots

[Sreyan Chakravarty]

Hi,

I use LVM with full disk encryption. I also use LVM snapshots, which have
prevented me from completely bricking my entire system many times.

Now the only problem is that the boot times when LVM snapshots are present
are extremely long.

I boot my machine, enter my encryption passphrase and then wait for about 3
minutes. It is only after that long wait does my machine boot.

This only happens if snapshots are present, if no snapshots are present,
boot is almost instantaneous after I enter my passphrase.

Is there any way this can be solved ?

I am not even sure which component to blame for this.

Is this a GRUB2 or systemd or kernel issue?

[Ed Greshko]

On 19/11/2020 18:54, Sreyan Chakravarty wrote:
> I use LVM with full disk encryption. I also use LVM snapshots, which have prevented me from completely bricking my entire system many times.
>
> Now the only problem is that the boot times when LVM snapshots are present are extremely long.
>
> I boot my machine, enter my encryption passphrase and then wait for about 3 minutes. It is only after that long wait does my machine boot.
>
> This only happens if snapshots are present, if no snapshots are present, boot is almost instantaneous after I enter my passphrase.
>
> Is there any way this can be solved ?
>
> I am not even sure which component to blame for this.
>
> Is this a GRUB2 or systemd or kernel issue?

If you run "systemd-analyze blame" it should tell you what process is taking the most time.

---
The key to getting good answers is to ask good questions.

[Sreyan Chakravarty]

On Thu, Nov 19, 2020 at 6:43 PM Ed Greshko  wrote:
> The key to getting good answers is to ask good questions.

Would you be having any idea as to where to put the --skip-mappings option
in LVM ?

Taken from here:
https://www.redhat.com/archives/linux-lvm/2016-January/msg00010.html

[Sreyan Chakravarty]

On Thu, Nov 19, 2020 at 6:43 PM Ed Greshko  wrote:
> If you run "systemd-analyze blame" it should tell you what process is
> taking the most time.

It seems the bug has existed since 2010:

https://bugzilla.redhat.com/show_bug.cgi?id=604767

[Sreyan Chakravarty]

On Thu, Nov 19, 2020 at 6:43 PM Ed Greshko  wrote:
> If you run "systemd-analyze blame" it should tell you what process is
> taking the most time.

These are the top 10 entries from "systemd-analyze blame":

1 3min 26.155s dracut-initqueue.service

2      38.577s udisks2.service

3      29.180s accounts-daemon.service

4      25.936s systemd-journal-flush.service

5      21.845s ModemManager.service

6      18.583s abrtd.service

7      18.575s avahi-daemon.service

8      18.570s bluetooth.service

9      18.147s firewalld.service

10      18.037s rtkit-daemon.service

What on earth is dracut-initqueue.service ???

[Samuel Sieb]

On 11/19/20 6:39 AM, Sreyan Chakravarty wrote:
> On Thu, Nov 19, 2020 at 6:43 PM Ed Greshko <[e-mail] 
> > wrote:
> If you run "systemd-analyze blame" it should tell you what process
> is taking the most time.
>
> These are the top 10 entries from "systemd-analyze blame":
>
> 1 3min 26.155s dracut-initqueue.service
>    2      38.577s udisks2.service
>    3      29.180s accounts-daemon.service
>    4      25.936s systemd-journal-flush.service
>
> What on earth is dracut-initqueue.service ???

That's the process in the initrd that tries to find and mount the root 
filesystem, so that makes sense.  The problem is somewhere in there.

[Sreyan Chakravarty]

On Fri, 20 Nov 2020, 1:28 am Samuel Sieb,  wrote:
> That's the process in the initrd that tries to find and mount the root
> filesystem, so that makes sense.  The problem is somewhere in there.
> _______________________________________________
>
> What else can I do to debug this problem??

[Samuel Sieb]

On 11/19/20 10:45 PM, Sreyan Chakravarty wrote:
> On Fri, 20 Nov 2020, 1:28 am Samuel Sieb, <[e-mail] 
> > wrote:
> That's the process in the initrd that tries to find and mount the root
> filesystem, so that makes sense.  The problem is somewhere in there.
> _______________________________________________
>
> What else can I do to debug this problem??

Edit /etc/lvm/lvm.conf, find the line in the "log {" section that has 
"verbose = 0" and change it to "verbose = 1".  Then run "dracut -f". 
Reboot and at the grub menu, edit the boot entry, remove the "quiet 
rhgb" parameters from the linux command line, then boot it.  See what 
it's doing doing that time.  After it's booted, you can also check 
"dmesg" and possible the "journalct -b" for information.