On Mon, 2021-06-21 at 03:55 +0800, Ed Greshko wrote:
On 21/06/2021 02:50, Patrick O'Callaghan wrote:
> On Mon, 2021-06-21 at 02:41 +0800, Ed Greshko wrote:
> > On 21/06/2021 00:16, Patrick O'Callaghan wrote:
> > > On Sun, 2021-06-20 at 23:08 +0800, Ed Greshko wrote:
> > > > On 19/06/2021 20:09, Patrick O'Callaghan wrote:
> > > > > There are three files:
> > > > >
> > > > > live-blame (output of systemd-analyze blame)
> > > > > live-boot.svg (output of systemd-analyze plot)
> > > > > live-journal (output of journal after logging into KDE)
> > > > Could you also upload the complete journal from start of boot
> > > > until the
> > > > login screen
> > > > is shown for a boot with the delay, for comparison.
> > >
https://drive.google.com/drive/folders/1H4XNTtZRaEgPUlGif2w-CR4Fof5OIqE0?...
> > Access denied.
> Try it now.
Before doing more "pillow" research, the first thing I wonder about
is....
30.578s dracut-initqueue.service
On my system it is...
21ms dracut-initqueue.service
If you were to boot your installed system with the dock disconnected
what would you see?
$ systemd-analyze blame |grep dracut-initqueue.service
486ms dracut-initqueue.service
If I power on the dock on after startup is complete, one drive appears
immediately and the other takes 30 seconds or so, so the delay is not
being caused by the boot process itself. It must be the hardware (the
drive or the dock) taking that long for whatever reason, possibly power
management as George suggested. As I've said, my goal is to convince
the kernel that it doesn't need to wait for this so as to continue with
the startup.
poc