On Tue, 2021-06-22 at 22:54 -0600, Chris Murphy wrote:
> > The uas message is again from device 6:0:0:1 as before, even though
> > the
> > disks have been swapped. IOW the issue definitely comes from the
> > dock,
> > not from the physical drives themselves.
>
> I don't know if it's coming from th
On 24/06/2021 12:20, Patrick O'Callaghan wrote:
On Thu, 2021-06-24 at 11:42 +0100, Christopher Ross wrote:
How can I go about diagnosing and fixing that?
In 2021 i7 machines should not be taking literally minutes to boot.
On my system (also an i7) that takes only 5s. Presumably something is
h
On Thu, 2021-06-24 at 11:42 +0100, Christopher Ross wrote:
>
>
> On 12/06/2021 20:45, Joe Zeff wrote:
> > On 6/12/21 11:54 AM, Patrick O'Callaghan wrote:
> > > Not my case. I don't have systemd-udev-settle.service. This is a
> > > fresh
> > > install of F34.
> >
> > Ok, you can still use systemd
On Thu, 24 Jun 2021 at 07:42, Christopher Ross
wrote:
>
>
> On 12/06/2021 20:45, Joe Zeff wrote:
>
> On 6/12/21 11:54 AM, Patrick O'Callaghan wrote:
>
> Not my case. I don't have systemd-udev-settle.service. This is a fresh
> install of F34.
>
>
> Ok, you can still use systemd-analyze blame to fi
On 24/06/2021 18:42, Christopher Ross wrote:
On 12/06/2021 20:45, Joe Zeff wrote:
On 6/12/21 11:54 AM, Patrick O'Callaghan wrote:
Not my case. I don't have systemd-udev-settle.service. This is a fresh
install of F34.
Ok, you can still use systemd-analyze blame to find out what's causing the
On 12/06/2021 20:45, Joe Zeff wrote:
On 6/12/21 11:54 AM, Patrick O'Callaghan wrote:
Not my case. I don't have systemd-udev-settle.service. This is a fresh
install of F34.
Ok, you can still use systemd-analyze blame to find out what's causing
the delay.
On my F34 boot systemd-udev-settle.
On Tue, 2021-06-22 at 22:54 -0600, Chris Murphy wrote:
> > The uas message is again from device 6:0:0:1 as before, even though
> > the
> > disks have been swapped. IOW the issue definitely comes from the
> > dock,
> > not from the physical drives themselves.
>
> I don't know if it's coming from th
On Tue, 2021-06-22 at 22:45 -0600, Chris Murphy wrote:
> On Mon, Jun 21, 2021 at 4:10 PM Patrick O'Callaghan
> wrote:
>
> > There is a single dock with two slots and no other type of
> > enclosure.
> > The disks are internal SATA units inserted directly into the slots.
> > The
> > dock has a sing
On Tue, Jun 22, 2021 at 4:05 AM Patrick O'Callaghan
wrote:
>
> One other data point and I'll leave it unless anything else turns up: I
> switched the two drives in the dock and got this from dmesg:
>
> [Tue Jun 22 10:52:03 2021] usb 4-3: USB disconnect, device number 2
> [Tue Jun 22 10:52:03 2021]
On Mon, Jun 21, 2021 at 4:10 PM Patrick O'Callaghan
wrote:
> There is a single dock with two slots and no other type of enclosure.
> The disks are internal SATA units inserted directly into the slots. The
> dock has a single dedicated USB-3 connection direct to the system
> motherboard with no in
On Tue, 2021-06-22 at 18:17 +0800, Ed Greshko wrote:
> On 22/06/2021 18:04, Patrick O'Callaghan wrote:
> > Well, I'm grateful to everyone who's chipped in, especially you and
> > Chris, but don't feel in any way obliged.
>
> That's good. As well you shouldn't. I only just thought about that
> in
On 22/06/2021 18:04, Patrick O'Callaghan wrote:
Well, I'm grateful to everyone who's chipped in, especially you and
Chris, but don't feel in any way obliged.
That's good. As well you shouldn't. I only just thought about that in
connection with the
time I spent on my NFS mounts happening at b
On 22/06/2021 18:09, George N. White III wrote:
On Mon, 21 Jun 2021 at 21:45, Ed Greshko mailto:ed.gres...@greshko.com>> wrote:
I do wonder how many brain-seconds have collectively been used in search of
a solution. :-) :-)
A lot more than goes into the design of cheap docks sold on Ama
On Mon, 21 Jun 2021 at 21:45, Ed Greshko wrote:
>
> I do wonder how many brain-seconds have collectively been used in search
> of a solution. :-) :-)
>
A lot more than goes into the design of cheap docks sold on Amazon, but the
search has
educational value.
--
George N. White III
On Tue, 2021-06-22 at 08:42 +0800, Ed Greshko wrote:
> On 22/06/2021 05:41, Patrick O'Callaghan wrote:
> > On Mon, 2021-06-21 at 21:18 +0800, Ed Greshko wrote:
> > > On 21/06/2021 20:31, Patrick O'Callaghan wrote:
> > > > On Mon, 2021-06-21 at 20:02 +0800, Ed Greshko wrote:
> > > >
> > > I thought
On 22/06/2021 05:41, Patrick O'Callaghan wrote:
On Mon, 2021-06-21 at 21:18 +0800, Ed Greshko wrote:
On 21/06/2021 20:31, Patrick O'Callaghan wrote:
On Mon, 2021-06-21 at 20:02 +0800, Ed Greshko wrote:
I thought I mentioned they should have been taken at the same time.
journal starts at
Jun
On Mon, 2021-06-21 at 11:47 -0600, Joe Zeff wrote:
> On 6/21/21 3:14 AM, Patrick O'Callaghan wrote:
> > Yes, that's been established (strictly, I haven't bothered swapping
> > the
> > drives in the dock to see what happens, but it's immaterial). Again,
> > the issue is not that one drive takes time
On Mon, 2021-06-21 at 13:13 -0600, Chris Murphy wrote:
> On Mon, Jun 21, 2021 at 10:58 AM Chris Murphy
>
> wrote:
> >
> > Jun 19 12:47:12 fedora kernel: sd 6:0:0:1: tag#2
> > uas_eh_abort_handler
> > 0 uas-tag 2 inflight: IN
> > Jun 19 12:47:12 fedora kernel: sd 6:0:0:1: tag#2 CDB: Mode Sense(6)
On Mon, 2021-06-21 at 21:18 +0800, Ed Greshko wrote:
> On 21/06/2021 20:31, Patrick O'Callaghan wrote:
> > On Mon, 2021-06-21 at 20:02 +0800, Ed Greshko wrote:
> > > On 21/06/2021 19:48, Patrick O'Callaghan wrote:
> > > > To avoid ambiguity, maybe you should tell me the journal
> > > > options
> >
On Mon, Jun 21, 2021 at 10:58 AM Chris Murphy wrote:
>
> Jun 19 12:47:12 fedora kernel: sd 6:0:0:1: tag#2 uas_eh_abort_handler
> 0 uas-tag 2 inflight: IN
> Jun 19 12:47:12 fedora kernel: sd 6:0:0:1: tag#2 CDB: Mode Sense(6) 1a
> 00 08 00 18 00
Yeah and in the install-boot log it happens again:
On 6/21/21 3:14 AM, Patrick O'Callaghan wrote:
Yes, that's been established (strictly, I haven't bothered swapping the
drives in the dock to see what happens, but it's immaterial). Again,
the issue is not that one drive takes time to spin up, but that the
system start-up waits for it when it does
On Mon, Jun 21, 2021 at 3:20 AM Patrick O'Callaghan
wrote:
>
> The logs are now publicly visible at:
> https://drive.google.com/drive/folders/1nGwVkeTJh5hz4dYRBD7Ikpx6q4MaPki9?usp=sharing
From the live boot (the least complicated one to look at for
starters), there is an anomaly:
Jun 19 08:46:41
On 21/06/2021 20:31, Patrick O'Callaghan wrote:
On Mon, 2021-06-21 at 20:02 +0800, Ed Greshko wrote:
On 21/06/2021 19:48, Patrick O'Callaghan wrote:
To avoid ambiguity, maybe you should tell me the journal options
you´d
like (the timestamps in the uploaded logs don´t show wallclock
time).
The
On Mon, 2021-06-21 at 20:02 +0800, Ed Greshko wrote:
> On 21/06/2021 19:48, Patrick O'Callaghan wrote:
> > To avoid ambiguity, maybe you should tell me the journal options
> > you´d
> > like (the timestamps in the uploaded logs don´t show wallclock
> > time).
>
> The journal times of what you've s
On 21/06/2021 18:17, Patrick O'Callaghan wrote:
I thought the contents of dmesg were already in the journal, but I may
have misunderstood their relationship.
I asked for dmesg since there is a gap in dmesg but not a corresponding gap in
the journal.
[ 30.093669] logitech-hidpp-device 0003:0
On 21/06/2021 19:48, Patrick O'Callaghan wrote:
To avoid ambiguity, maybe you should tell me the journal options you´d
like (the timestamps in the uploaded logs don´t show wallclock time).
The journal times of what you've supplied seem fine. They show
Jun 20 15:44:50 for example
and dmesg -T
On Mon, 2021-06-21 at 18:57 +0800, Ed Greshko wrote:
> On 21/06/2021 18:27, Ed Greshko wrote:
> > On 21/06/2021 18:17, Patrick O'Callaghan wrote:
> > > On Mon, 2021-06-21 at 17:43 +0800, Ed Greshko wrote:
> > > > On 21/06/2021 17:20, Patrick O'Callaghan wrote:
> > > > > The logs are now publicly vi
On 21/06/2021 18:27, Ed Greshko wrote:
On 21/06/2021 18:17, Patrick O'Callaghan wrote:
On Mon, 2021-06-21 at 17:43 +0800, Ed Greshko wrote:
On 21/06/2021 17:20, Patrick O'Callaghan wrote:
The logs are now publicly visible at:
https://drive.google.com/drive/folders/1nGwVkeTJh5hz4dYRBD7Ikpx6q4Ma
On 21/06/2021 18:17, Patrick O'Callaghan wrote:
On Mon, 2021-06-21 at 17:43 +0800, Ed Greshko wrote:
On 21/06/2021 17:20, Patrick O'Callaghan wrote:
The logs are now publicly visible at:
https://drive.google.com/drive/folders/1nGwVkeTJh5hz4dYRBD7Ikpx6q4MaPki9?usp=sharing
I've included my home-
On Mon, 2021-06-21 at 17:43 +0800, Ed Greshko wrote:
> On 21/06/2021 17:20, Patrick O'Callaghan wrote:
> > The logs are now publicly visible at:
> > https://drive.google.com/drive/folders/1nGwVkeTJh5hz4dYRBD7Ikpx6q4MaPki9?usp=sharing
> >
> > I've included my home-grown 'dock' scripts for completen
On 21/06/2021 17:20, Patrick O'Callaghan wrote:
The logs are now publicly visible at:
https://drive.google.com/drive/folders/1nGwVkeTJh5hz4dYRBD7Ikpx6q4MaPki9?usp=sharing
I've included my home-grown 'dock' scripts for completeness, plus logs
of a Fedora Live boot (with no delay) and my current i
On Mon, 2021-06-21 at 06:19 +0800, Ed Greshko wrote:
> On 21/06/2021 06:02, Ed Greshko wrote:
> > On 21/06/2021 05:48, Patrick O'Callaghan wrote:
> > > $ systemd-analyze blame |grep dracut-initqueue.service
> > > 486ms dracut-initqueue.service
> > >
> > > If I power on the dock on after startup
On Sun, 2021-06-20 at 18:00 -0600, Chris Murphy wrote:
> On Sun, Jun 20, 2021 at 3:48 PM Patrick O'Callaghan
> wrote:
> >
> > 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 th
On Sun, 2021-06-20 at 17:40 -0600, Joe Zeff wrote:
> On 6/20/21 3:48 PM, Patrick O'Callaghan wrote:
> > 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 itsel
On Mon, 2021-06-21 at 06:59 +0800, Ed Greshko wrote:
> On 21/06/2021 06:02, Ed Greshko wrote:
> > On 21/06/2021 05:48, Patrick O'Callaghan wrote:
> > > $ systemd-analyze blame |grep dracut-initqueue.service
> > > 486ms dracut-initqueue.service
> > >
> > > If I power on the dock on after startup
On Sun, Jun 20, 2021 at 3:48 PM Patrick O'Callaghan
wrote:
>
> 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)
On 6/20/21 3:48 PM, Patrick O'Callaghan wrote:
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
On 21/06/2021 06:02, Ed Greshko wrote:
On 21/06/2021 05:48, Patrick O'Callaghan wrote:
$ 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
On 21/06/2021 06:02, Ed Greshko wrote:
On 21/06/2021 05:48, Patrick O'Callaghan wrote:
$ 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
On 21/06/2021 05:48, Patrick O'Callaghan wrote:
$ 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 th
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
On Mon, 2021-06-21 at 03:48 +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
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
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
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
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 journa
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)
>
>
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 log
On 20/06/2021 21:51, Patrick O'Callaghan wrote:
So I don't think libvirtd is the culprit in my case.
As long as you're issues allowed me to determine the cause of the issue I was
having, that's all that
matters. :-) :-)
--
Remind me to ignore comments which aren't germane to the thread.
On Sun, 2021-06-20 at 17:53 +0800, Ed Greshko wrote:
> On 20/06/2021 17:32, Patrick O'Callaghan wrote:
> > On Sun, 2021-06-20 at 08:50 +0800, Ed Greshko wrote:
> > > So, I've concluded that my NFS mounting issues are all related to
> > > running virtualization stuff.
> > I do run libvirtd (and virt
On 20/06/2021 17:32, Patrick O'Callaghan wrote:
On Sun, 2021-06-20 at 08:50 +0800, Ed Greshko wrote:
So, I've concluded that my NFS mounting issues are all related to
running virtualization stuff.
I do run libvirtd (and virt-manager), though most of the time I have no
VMs active. I also don't h
On Sun, 2021-06-20 at 08:50 +0800, Ed Greshko wrote:
> So, I've concluded that my NFS mounting issues are all related to
> running virtualization stuff.
I do run libvirtd (and virt-manager), though most of the time I have no
VMs active. I also don't have any NFS mounts (the VM I mostly use is
Wind
On 20/06/2021 06:58, Ed Greshko wrote:
On 19/06/2021 19:22, Patrick O'Callaghan wrote:
On Sat, 2021-06-19 at 11:58 +0800, Ed Greshko wrote:
I removed the WantedBy=multi-user.target from the mount unit. I then
did a daemon-reload.
I noted that there were 2 broken syslinks associated with the mo
On 19/06/2021 19:22, Patrick O'Callaghan wrote:
On Sat, 2021-06-19 at 11:58 +0800, Ed Greshko wrote:
I removed the WantedBy=multi-user.target from the mount unit. I then
did a daemon-reload.
I noted that there were 2 broken syslinks associated with the mounts
in
/etc/systemd/system/multi-user.t
On Fri, 2021-06-18 at 12:15 -0600, Chris Murphy wrote:
> On Fri, Jun 18, 2021, 11:10 AM Patrick O'Callaghan
>
> wrote:
>
> >
> > My problem is that one drive comes up almost instantly and the other
> > takes 30 seconds. In fact I can live with that. My real gripe is that
> > the kernel makes me
On Sat, 2021-06-19 at 11:58 +0800, Ed Greshko wrote:
> I removed the WantedBy=multi-user.target from the mount unit. I then
> did a daemon-reload.
> I noted that there were 2 broken syslinks associated with the mounts
> in
> /etc/systemd/system/multi-user.target.wants so I deleted them. I
> then
On Fri, 2021-06-18 at 19:26 -0600, Chris Murphy wrote:
> I make fstab mount options include:
>
> nofail,noauto,x-systemd.automount
>
> That way it is only mounted on demand, i.e. when the mount point is
> "touched".
>
> It's also possible to use x-systemd.idle-timeout=300 which will
> unmount it
On Fri, 2021-06-18 at 19:36 -0300, George N. White III wrote:
> > The power block says its output is 3A at 12V.
> >
> > The drives are both WD model WD10EZEX, (though the label on one
> > says
> it
> > has a 64MB cache and the other doesn't). Both labels say 5VDC,
> > 0.68A
> > and 12VDC, 0.55A. L
On 19/06/2021 11:58, Ed Greshko wrote:
The mount no longer happens at boot time and the status of the automount unit is
Active: active (waiting). And everything works as expected. Mount upon
accessing the
mount point and unmounting happening after the timeout has expired.
Well, I spoke too
Patrick O'Callaghan:
>> Interesting idea. Mine is this model:
>>
>> https://www.amazon.co.uk/gp/product/B06XYJGDTH/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
>>
>> The power block says its output is 3A at 12V.
>>
>> The drives are both WD model WD10EZEX, (though the label on one
>> says it has
On 19/06/2021 09:26, Chris Murphy wrote:
I make fstab mount options include:
nofail,noauto,x-systemd.automount
That way it is only mounted on demand, i.e. when the mount point is "touched".
It's also possible to use x-systemd.idle-timeout=300 which will
unmount it after 5 minutes idle.
I'll
I make fstab mount options include:
nofail,noauto,x-systemd.automount
That way it is only mounted on demand, i.e. when the mount point is "touched".
It's also possible to use x-systemd.idle-timeout=300 which will
unmount it after 5 minutes idle.
--
Chris Murphy
_
On Fri, 18 Jun 2021 at 14:10, Patrick O'Callaghan
wrote:
> On Fri, 2021-06-18 at 09:02 -0300, George N. White III wrote:
> > On Fri, 18 Jun 2021 at 06:50, Patrick O'Callaghan
> >
> > wrote:
> >
> > > On Fri, 2021-06-18 at 08:58 +1000, Cameron Simpson wrote:
> > > > On 17Jun2021 12:15, Patrick O'
On Fri, Jun 18, 2021, 11:10 AM Patrick O'Callaghan
wrote:
>
> My problem is that one drive comes up almost instantly and the other
> takes 30 seconds. In fact I can live with that. My real gripe is that
> the kernel makes me wait even though the drive is not being accessed.
> If it just wants to
On Fri, 2021-06-18 at 09:02 -0300, George N. White III wrote:
> On Fri, 18 Jun 2021 at 06:50, Patrick O'Callaghan
>
> wrote:
>
> > On Fri, 2021-06-18 at 08:58 +1000, Cameron Simpson wrote:
> > > On 17Jun2021 12:15, Patrick O'Callaghan
> > > wrote:
> > > > On Thu, 2021-06-17 at 07:20 -0300, Georg
On Fri, 18 Jun 2021 at 06:50, Patrick O'Callaghan
wrote:
> On Fri, 2021-06-18 at 08:58 +1000, Cameron Simpson wrote:
> > On 17Jun2021 12:15, Patrick O'Callaghan
> > wrote:
> > > On Thu, 2021-06-17 at 07:20 -0300, George N. White III wrote:
> > > > > The technical specifications of the drives sho
On Fri, 2021-06-18 at 08:58 +1000, Cameron Simpson wrote:
> On 17Jun2021 12:15, Patrick O'Callaghan
> wrote:
> > On Thu, 2021-06-17 at 07:20 -0300, George N. White III wrote:
> > > > The technical specifications of the drives should mention
> > > > startup
> > > power
> > > management. There may
On 17Jun2021 12:15, Patrick O'Callaghan wrote:
>On Thu, 2021-06-17 at 07:20 -0300, George N. White III wrote:
>> > The technical specifications of the drives should mention startup
>> power
>> management. There may also be some power management in the dock.
>> I've noticed that it is becoming mor
On Thu, 2021-06-17 at 07:20 -0300, George N. White III wrote:
> > The technical specifications of the drives should mention startup
> power
> management. There may also be some power management in the dock.
> I've noticed that it is becoming more difficult to find detailed
> documentation
> of add
On Wed, 16 Jun 2021 at 10:47, Patrick O'Callaghan
wrote:
> On Wed, 2021-06-16 at 20:18 +0800, Ed Greshko wrote:
> > On 16/06/2021 19:35, Patrick O'Callaghan wrote:
> > > So two questions:
> > >
> > > 1) Is there an obvious error with the drive itself?
> >
> > If you've not seen errors when you're
On Wed, 2021-06-16 at 17:52 -0700, Samuel Sieb wrote:
> On 2021-06-16 2:27 p.m., Patrick O'Callaghan wrote:
> > On Wed, 2021-06-16 at 11:55 -0700, Samuel Sieb wrote:
> > > On 2021-06-16 4:35 a.m., Patrick O'Callaghan wrote:
> > > > 2) Is there a way to prevent the system boot from freezing while
>
On 2021-06-16 2:27 p.m., Patrick O'Callaghan wrote:
On Wed, 2021-06-16 at 11:55 -0700, Samuel Sieb wrote:
On 2021-06-16 4:35 a.m., Patrick O'Callaghan wrote:
2) Is there a way to prevent the system boot from freezing while it
waits for the drive to come online?
Did you try the dracut initrd m
On 16Jun2021 10:17, Tom Horsley wrote:
>On Wed, 16 Jun 2021 14:46:42 +0100
>Patrick O'Callaghan wrote:
>> I haven't seen any errors, so it's probably a feature rather than a
>> bug
>> with this drive.
>
>I have two USB drives on my system, and one of them takes about
>30 seconds to spin up. It is
On Wed, 2021-06-16 at 13:03 -0600, Joe Zeff wrote:
> On 6/16/21 12:32 PM, Patrick O'Callaghan wrote:
> > I'm not aware of it scanning on the way down. My problem is that it
> > scans a drive that it isn't going to need until something mounts
> > it,
> > and makes everything else wait till it finish
On Wed, 2021-06-16 at 15:57 -0400, Frank McCormick wrote:
> > > I think it was Frank who had the 4 minute delay. I don't think I
> > > said
> > > that mine was 4 minutes, just that there was a delay and I see a
> > > blank
> > > screen with three dots, but apologies if I gave that impression.
>
>
On Thu, 2021-06-17 at 03:11 +0800, Ed Greshko wrote:
> On 17/06/2021 02:27, Patrick O'Callaghan wrote:
> > On Wed, 2021-06-16 at 22:36 +0800, Ed Greshko wrote:
> > > On 16/06/2021 21:46, Patrick O'Callaghan wrote:
> > > > Just to be sure, my next step will be to completely disable
> > > > those
> >
On Wed, 2021-06-16 at 11:55 -0700, Samuel Sieb wrote:
> On 2021-06-16 4:35 a.m., Patrick O'Callaghan wrote:
> > 2) Is there a way to prevent the system boot from freezing while it
> > waits for the drive to come online?
>
> Did you try the dracut initrd modification and possibly also masking
> ud
On 6/16/21 3:11 PM, Ed Greshko wrote:
On 17/06/2021 02:27, Patrick O'Callaghan wrote:
On Wed, 2021-06-16 at 22:36 +0800, Ed Greshko wrote:
On 16/06/2021 21:46, Patrick O'Callaghan wrote:
Just to be sure, my next step will be to completely disable those
units
and reboot again, but I'm 99% sur
On 17/06/2021 02:27, Patrick O'Callaghan wrote:
On Wed, 2021-06-16 at 22:36 +0800, Ed Greshko wrote:
On 16/06/2021 21:46, Patrick O'Callaghan wrote:
Just to be sure, my next step will be to completely disable those
units
and reboot again, but I'm 99% sure that is still going to show the
30-
sec
On 6/16/21 12:32 PM, Patrick O'Callaghan wrote:
I'm not aware of it scanning on the way down. My problem is that it
scans a drive that it isn't going to need until something mounts it,
and makes everything else wait till it finishes. There doesn't appear
to be something analogous to the NFS "soft
On 2021-06-16 4:35 a.m., Patrick O'Callaghan wrote:
2) Is there a way to prevent the system boot from freezing while it
waits for the drive to come online?
Did you try the dracut initrd modification and possibly also masking
udev settle on the system as well?
_
On Wed, 2021-06-16 at 10:17 -0400, Tom Horsley wrote:
> On Wed, 16 Jun 2021 14:46:42 +0100
> Patrick O'Callaghan wrote:
>
> > I haven't seen any errors, so it's probably a feature rather than a
> > bug
> > with this drive.
>
> I have two USB drives on my system, and one of them takes about
> 30 s
On Wed, 2021-06-16 at 22:36 +0800, Ed Greshko wrote:
> On 16/06/2021 21:46, Patrick O'Callaghan wrote:
> > Just to be sure, my next step will be to completely disable those
> > units
> > and reboot again, but I'm 99% sure that is still going to show the
> > 30-
> > second delay.
>
> Well, 30sec is
On 16/06/2021 21:46, Patrick O'Callaghan wrote:
Just to be sure, my next step will be to completely disable those units
and reboot again, but I'm 99% sure that is still going to show the 30-
second delay.
Well, 30sec is annoying. But I thought that it was the 4 min that getting rid
of would
b
On Wed, 16 Jun 2021 14:46:42 +0100
Patrick O'Callaghan wrote:
> I haven't seen any errors, so it's probably a feature rather than a bug
> with this drive.
I have two USB drives on my system, and one of them takes about
30 seconds to spin up. It is very annoying when I'm rebooting the
system but i
On Wed, 2021-06-16 at 20:18 +0800, Ed Greshko wrote:
> On 16/06/2021 19:35, Patrick O'Callaghan wrote:
> > So two questions:
> >
> > 1) Is there an obvious error with the drive itself?
>
> If you've not seen errors when you're using the drive, then probably
> not.
>
I haven't seen any errors, s
On 16/06/2021 19:35, Patrick O'Callaghan wrote:
So two questions:
1) Is there an obvious error with the drive itself?
If you've not seen errors when you're using the drive, then probably not.
2) Is there a way to prevent the system boot from freezing while it
waits for the drive to come onli
On Mon, 2021-06-14 at 11:35 +0100, Patrick O'Callaghan wrote:
> On Mon, 2021-06-14 at 11:10 +0100, Patrick O'Callaghan wrote:
> > On Sun, 2021-06-13 at 14:38 -0600, Chris Murphy wrote:
> > > I actually use a udev rule for idle spin down:
> > >
> > > $ cat /etc/udev/rules.d/69-hdparm.rules
> > > A
On Mon, 2021-06-14 at 11:10 +0100, Patrick O'Callaghan wrote:
> On Sun, 2021-06-13 at 14:38 -0600, Chris Murphy wrote:
> > I actually use a udev rule for idle spin down:
> >
> > $ cat /etc/udev/rules.d/69-hdparm.rules
> > ACTION=="add", SUBSYSTEM=="block", \
> > KERNEL=="sd*[!0-9]", \
> > ENV
On Mon, 2021-06-14 at 18:02 +0800, Ed Greshko wrote:
> On 14/06/2021 17:52, Patrick O'Callaghan wrote:
> > On Mon, 2021-06-14 at 03:42 +0800, Ed Greshko wrote:
> > > On 13/06/2021 23:57, Patrick O'Callaghan wrote:
> > > > I did the same and it has made a big difference, i.e. I no
> > > > longer
> >
On Sun, 2021-06-13 at 14:38 -0600, Chris Murphy wrote:
> I actually use a udev rule for idle spin down:
>
> $ cat /etc/udev/rules.d/69-hdparm.rules
> ACTION=="add", SUBSYSTEM=="block", \
> KERNEL=="sd*[!0-9]", \
> ENV{ID_SERIAL_SHORT}=="WDZ47F0A", \
> RUN+="/usr/sbin/hdparm -B 100 -S 252 /d
On 14/06/2021 17:52, Patrick O'Callaghan wrote:
On Mon, 2021-06-14 at 03:42 +0800, Ed Greshko wrote:
On 13/06/2021 23:57, Patrick O'Callaghan wrote:
I did the same and it has made a big difference, i.e. I no longer
have
the very long delay waiting for usb-settle.
I still don't know why my exte
On Mon, 2021-06-14 at 03:42 +0800, Ed Greshko wrote:
> On 13/06/2021 23:57, Patrick O'Callaghan wrote:
> > I did the same and it has made a big difference, i.e. I no longer
> > have
> > the very long delay waiting for usb-settle.
> >
> > I still don't know why my external dock is being mounted at
On Sun, 2021-06-13 at 19:06 -0400, Go Canes wrote:
> On Sun, Jun 13, 2021 at 5:30 PM Patrick O'Callaghan
> wrote:
> >
> > On Sun, 2021-06-13 at 13:44 -0400, Go Canes wrote:
> > > > I still don't know why my external dock is being mounted at
> > > > boot,
> > > > but I
> > > > can live with it for
On Sun, Jun 13, 2021 at 5:30 PM Patrick O'Callaghan
wrote:
>
> On Sun, 2021-06-13 at 13:44 -0400, Go Canes wrote:
> > > I still don't know why my external dock is being mounted at boot,
> > > but I
> > > can live with it for now.
> > >
> > > poc
> >
> > Maybe pvscan wants to check the drive(s) to
On Sun, 2021-06-13 at 14:38 -0600, Chris Murphy wrote:
> On Sun, Jun 13, 2021 at 5:26 AM Patrick O'Callaghan
> wrote:
> >
> > I'm 99% certain it's being caused by my external USB dock starting
> > up.
> > See my reply to Ed. The dock is not mounted at boot, but has a
> > BTRFS
> > filesystem that
On Sun, 2021-06-13 at 14:21 -0600, Chris Murphy wrote:
> On Sun, Jun 13, 2021 at 3:56 AM Patrick O'Callaghan
> wrote:
> >
> > On Sun, 2021-06-13 at 07:09 +0800, Ed Greshko wrote:
> > > On 13/06/2021 06:57, Ed Greshko wrote:
> > > > But, does your plot show a difference?
> > >
> > > Speaking of y
On Sun, 2021-06-13 at 13:53 -0600, Chris Murphy wrote:
> On Sat, Jun 12, 2021 at 11:20 AM Patrick O'Callaghan
> wrote:
> >
> > On Sat, 2021-06-12 at 07:25 -0600, Chris Murphy wrote:
> > > Both problems need logs. It's quite a bit over kill but these
> > > boot
> > > parameters will help provide e
On Sun, 2021-06-13 at 12:02 -0700, Samuel Sieb wrote:
> > $ ls /etc/systemd/system/systemd-udev-settle.service
> > /etc/systemd/system/systemd-udev-settle.service
>
> I think if you use "ls -l", you'll find that it's a symlink to
> /dev/null. In the other thread we figured out that it's actually
On Sun, 2021-06-13 at 12:54 -0600, Joe Zeff wrote:
> On 6/13/21 11:44 AM, Go Canes wrote:
> > > I still don't know why my external dock is being mounted at boot,
> > > but I
> > > can live with it for now.
> > >
> > > poc
> > Maybe pvscan wants to check the drive(s) to see if it is a LVM
> > volum
1 - 100 of 143 matches
Mail list logo
