On Thu, Sep 30, 2021 at 4:13 PM Gordon Messmer wrote:
>
> On 9/30/21 12:41, Chris Murphy wrote:
> > Seems likely to me some service is not quitting properly, preventing /
> > from being unmounted
>
>
> If that were the case, there might be information about an exit failure
> in the log. On the ne
On 9/30/21 12:41, Chris Murphy wrote:
Seems likely to me some service is not quitting properly, preventing /
from being unmounted
If that were the case, there might be information about an exit failure
in the log. On the next boot, "journalctl -b -1" might have useful info.
I also wonder i
On Wed, Sep 29, 2021 at 2:18 PM murph nj wrote:
>
> I'm having an issue shutting down. Fedora 34, just updated to 35, same
> problem. (It was around in 33 as well, I've been putting up with it.) I
> know that there is another list for beta versions, but this issue was there
> in the current
Raid0, so there is no redundancy on the data?
And what kind of underlying hard disks? The desktop drives will try
for a long time (ie a minute or more) to read any bad blocks. Those
disks will not report an error unless it gets to the default os
timeout, or it hits the disk firmware timeout.
T
On Thu, 30 Sep 2021 17:50:01 +0100
Terry Barnaby wrote:
> Yes, problems often occur due to you having done something, but I am
> pretty sure nothing has changed apart from Fedora updates.
But hardware is sneaky. It waits for you to install software updates,
the breaks itself to make you think th
On 30/09/2021 11:42, Roger Heflin wrote:
On mine when I first access the NFS volume it takes 5-10 seconds for
the disks to spin up. Mine will spin down later in the day if little
or nothing is going on and I will get another delay.
I have also seen delays if a disk gets bad blocks and correct
On 30/09/2021 11:32, Ed Greshko wrote:
On 30/09/2021 16:35, Terry Barnaby wrote:
This is a very lightly loaded system with just 3 users ATM and very
little going on across the network (just editing code files etc). The
problem occurred again yesterday. For about 10 minutes my KDE desktop
locke
On Wed, 29 Sep 2021 14:17:01 -0400
murph nj wrote:
> I'm having an issue shutting down.
[snip]
> I haven't found anything interesting in /var/log/messages regarding
> it.
>
> Any suggestions to further troubleshooting?
I think this is an artifact of the shutdown process. It is supposition
on
On 30/09/2021 18:27, Bjoern Franke via users wrote:
Hi,
I tried to use the cockpit on fc34, but the login fails:
Sep 30 12:25:11 bfr.foo.bar.tld cockpit-session[170263]:
pam_unix(cockpit:session): session opened for user bfr(uid=1000) by (uid=0)
Sep 30 12:25:11 bfr.foo.bar.tld audit[170263]: U
On mine when I first access the NFS volume it takes 5-10 seconds for the
disks to spin up. Mine will spin down later in the day if little or
nothing is going on and I will get another delay.
I have also seen delays if a disk gets bad blocks and corrects them. About
1/2 of time that does have a m
On 30/09/2021 16:35, Terry Barnaby wrote:
This is a very lightly loaded system with just 3 users ATM and very little going on
across the network (just editing code files etc). The problem occurred again yesterday.
For about 10 minutes my KDE desktop locked up in 20 second bursts and then the pr
Hi,
I tried to use the cockpit on fc34, but the login fails:
Sep 30 12:25:11 bfr.foo.bar.tld cockpit-session[170263]:
pam_unix(cockpit:session): session opened for user bfr(uid=1000) by (uid=0)
Sep 30 12:25:11 bfr.foo.bar.tld audit[170263]: USER_START pid=170263
uid=0 auid=1000 ses=88 subj=sys
Thanks for the feedback everyone.
This is a very lightly loaded system with just 3 users ATM and very
little going on across the network (just editing code files etc). The
problem occurred again yesterday. For about 10 minutes my KDE desktop
locked up in 20 second bursts and then the problem w
13 matches
Mail list logo
