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?
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.
On Thu, Nov 19, 2020 at 6:43 PM Ed Greshko ed.greshko@greshko.com 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
On Thu, Nov 19, 2020 at 6:43 PM Ed Greshko ed.greshko@greshko.com 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
On Thu, Nov 19, 2020 at 6:43 PM Ed Greshko ed.greshko@greshko.com 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 ???
On 11/19/20 6:39 AM, Sreyan Chakravarty wrote:
On Thu, Nov 19, 2020 at 6:43 PM Ed Greshko <ed.greshko@greshko.com mailto:ed.greshko@greshko.com> 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.
On Fri, 20 Nov 2020, 1:28 am Samuel Sieb, samuel@sieb.net 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??
On 11/19/20 10:45 PM, Sreyan Chakravarty wrote:
On Fri, 20 Nov 2020, 1:28 am Samuel Sieb, <samuel@sieb.net mailto:samuel@sieb.net> 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.