Re: [gentoo-user] HD self test getting stuck at 90% remaining [solved]

2023-06-01 Thread Dale
Grant Edwards wrote:
> I just bought a new 6TB WD Red Plus drive to replace a couple older
> drives (one of which had generated an uncorrectable error email from
> smartd).  I decided that I'd stick it in an external USB-3 SATA drive
> "dock" thingy from Thermaltake and do some testing before installing
> it.
>
> Using smartctl, I ran a "short" self test and a "conveyance" test, and
> both passed.
>
> Then I started a "long" (extended) self test. According to the drive,
> that should take 640 minutes (a bit under 11 hours).  It almost
> immediately reported test running with 90% remaining. A couple
> hours later, it still said 90% remaining.  I stopped the test, ran
> another short test. Messed around with some other smartctl commands,
> and started another "long" test.  Again, it immediately said 90%
> remaining.  After 20 hours, it still said 90% remaining.
>
> Tests getting stuck like that seems to be pretty common.
>
> Some time spent Googling found me two suggestions:
>
>  * The test is stalled because the disk is busy.
>  
>  * The test is stalled because the disk is idle.
>
> Apparently, they're both valid.
>
> The self-test runs in the background when the drive is not busy, so if
> the drive is heavily loaded, self tests can take a lot longer.  But,
> if the drive is _completely_ idle, it might spin-down and go to sleep
> (which pauses the test). This is reportedly more likely to happen when
> the drive is attached via a USB-SATA adapter [I don't know if that's
> true].
>
> Sure enough, if I waited 5-10 minutes and asked for the test status, I
> would hear the drive spin-up when queried.
>
> So I ran a "watch" command to query the drive every 10 seconds:
>
> watch -n10 smartctl -d sat -c /dev/sdc
>
> That seems to keep the drive spinning without doing any actual R/W
> ops, and within an hour the status changed to 80% remaining. About 6
> hours after that, it's now 20% remaining.
>
> So the moral to the story is: when running an extended self test on a
> drive, you don't want it to be busy, but you also don't want it so
> idle that it spins down goes to sleep.
>
> Maybe everybody else already knew that, but it took me an hour or two
> to figure it out...
>
>
>


That's some neat info.  You could likely set 'watch' to a couple minutes
and still be fine but as you say, it doesn't really do anything put poke
the drive to keep it awake.  lol 

I might add, this is why I like eSATA external drives.  They don't
sleep.  They function just like a drive that is installed inside my
system.  If it goes to sleep, I told it to nap. 

Good of you to post this.  This just could help someone one day that
runs into this.

Dale

:-)  :-) 



Re: [gentoo-user] using Wifi in a new machine : progress

2023-06-01 Thread Lee K
On Thu, Jun 01, 2023 at 11:09:50PM -0400, Philip Webb wrote:
> Thanks for all the help so far.
> 
> I've solved the firmware problem.
> The needed files weren't in the latest stable version of  linux-firmware
> nor in the masked version (after much hassle unmasking it),
> but they are in both System Rescue + Mint /lib/firmware/mediatek .
> They are versions  7922  and  7961  with corresponding RAM_CODE files.
> 
> I copied them into the new machine in the same-named dir, 'unxz' them
> & after reboot 'dmesg' announced that it had loaded  7961 
> & 'ip a' showed a 4th interface 'wlp5s0'.  So far, so good.
> 
> What is still not good is that that interface has "NO-CARRIER".
> Also, 'rc-status' after a reboot shows  wpa_supplicant  as STOPPED.
> 
> 'rc-service -v wpa_supplicant start' gets it STARTED,
> but 'ip a' still shows "NO-CARRIER".
> I tried 'ip link set wlp5s0 carrier on',
> but was told "operation not supported".
> 
> w_s seems to be finding its conf file
> at  /etc/wpa_supplicant/wpa_supplicant.conf ,
> but 'wpa_cli' continues to say "can't link to wpa_supplicant".
> 
> I have checked the service name + password are correct in the conf file.
> 
> It's approaching supper time & I've run out of ideas for today anyway.
> 
> Any further advice is most welcome (smile).
> 
> -- 
> ,,
> SUPPORT ___//___,   Philip Webb
> ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
> TRANSIT`-O--O---'   purslowatchassdotutorontodotca
> 
> 

I don't know if you've already done so, but if not, can you post the
contents of wpa_supplicant.conf..?

-- 
Lee



Re: [gentoo-user] using Wifi in a new machine : progress

2023-06-01 Thread Philip Webb
Thanks for all the help so far.

I've solved the firmware problem.
The needed files weren't in the latest stable version of  linux-firmware
nor in the masked version (after much hassle unmasking it),
but they are in both System Rescue + Mint /lib/firmware/mediatek .
They are versions  7922  and  7961  with corresponding RAM_CODE files.

I copied them into the new machine in the same-named dir, 'unxz' them
& after reboot 'dmesg' announced that it had loaded  7961 
& 'ip a' showed a 4th interface 'wlp5s0'.  So far, so good.

What is still not good is that that interface has "NO-CARRIER".
Also, 'rc-status' after a reboot shows  wpa_supplicant  as STOPPED.

'rc-service -v wpa_supplicant start' gets it STARTED,
but 'ip a' still shows "NO-CARRIER".
I tried 'ip link set wlp5s0 carrier on',
but was told "operation not supported".

w_s seems to be finding its conf file
at  /etc/wpa_supplicant/wpa_supplicant.conf ,
but 'wpa_cli' continues to say "can't link to wpa_supplicant".

I have checked the service name + password are correct in the conf file.

It's approaching supper time & I've run out of ideas for today anyway.

Any further advice is most welcome (smile).

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca




[gentoo-user] HD self test getting stuck at 90% remaining [solved]

2023-06-01 Thread Grant Edwards
I just bought a new 6TB WD Red Plus drive to replace a couple older
drives (one of which had generated an uncorrectable error email from
smartd).  I decided that I'd stick it in an external USB-3 SATA drive
"dock" thingy from Thermaltake and do some testing before installing
it.

Using smartctl, I ran a "short" self test and a "conveyance" test, and
both passed.

Then I started a "long" (extended) self test. According to the drive,
that should take 640 minutes (a bit under 11 hours).  It almost
immediately reported test running with 90% remaining. A couple
hours later, it still said 90% remaining.  I stopped the test, ran
another short test. Messed around with some other smartctl commands,
and started another "long" test.  Again, it immediately said 90%
remaining.  After 20 hours, it still said 90% remaining.

Tests getting stuck like that seems to be pretty common.

Some time spent Googling found me two suggestions:

 * The test is stalled because the disk is busy.
 
 * The test is stalled because the disk is idle.

Apparently, they're both valid.

The self-test runs in the background when the drive is not busy, so if
the drive is heavily loaded, self tests can take a lot longer.  But,
if the drive is _completely_ idle, it might spin-down and go to sleep
(which pauses the test). This is reportedly more likely to happen when
the drive is attached via a USB-SATA adapter [I don't know if that's
true].

Sure enough, if I waited 5-10 minutes and asked for the test status, I
would hear the drive spin-up when queried.

So I ran a "watch" command to query the drive every 10 seconds:

watch -n10 smartctl -d sat -c /dev/sdc

That seems to keep the drive spinning without doing any actual R/W
ops, and within an hour the status changed to 80% remaining. About 6
hours after that, it's now 20% remaining.

So the moral to the story is: when running an extended self test on a
drive, you don't want it to be busy, but you also don't want it so
idle that it spins down goes to sleep.

Maybe everybody else already knew that, but it took me an hour or two
to figure it out...




Re: [gentoo-user] using Wifi in a new machine

2023-06-01 Thread Michael
On Thursday, 1 June 2023 19:54:08 BST Philip Webb wrote:
> 230531 Michael wrote:
> > It seems you have the correct module for the mediatek driver installed,
> > since lshw on gentoo shows it being used. What is not shown is the
> > firmware. Now, to bottom out the firmware issue.
> > You need to specify the firmware path in your kernel, as explained here.
> > By default this would be under /lib/firmware/ :
> > https://wiki.gentoo.org/wiki/Linux_firmware
> 
> /lib/firmware/ is the dir with firmware files.
> 
> > Hopefully, the requisite firmware file blobs will be present
> > in the latest stable 'sys-kernel/linux-firmware' package,
> > once you install it.
> 
> It is already installed (230404) , presumably as part of Stage 3.
> That date shouldn't be too old.

The current stable version is:

sys-kernel/linux-firmware-20230515

I suggest you run an update to fetch this version - see below.


> > dmesg will reveal if these are/not being loaded.
> 
> 'dmesg | grep firmware' shows  10  identical lines :
> 
>   Loading firmware : mediatek/WIFI_MT7921_patch_mcu_1_2_hdr.bin :
>failed with error-2 .

Oops!  This is rather ominous and the cause of your problems - see below.


> > you could keyword the trunk version hoping it contains what you need:
> >**     *l^bstd   [compress-xz compress-zstd initramfs
> > 
> > +redistributable savedconfig unknown-license]   ["initramfs? (
> > redistributable ) ?? ( compress-xz compress-zstd )"]
> 
> I don't understand these lines (smile).

This is the bleeding edge version of the package, but you may not need to 
install it (yet).


> > Or, you could compare what firmware files are loaded in Mint/SR ISOs
> > and copy these over to your Gentoo system for now
> 
> SR shows no record of loading via 'dmesg' ;
> Mint ends with a lot of Bluetooth + mt7921e references.
> Mint mentions a firmware " 01 " ( 4 underlines ).

Hmm ... Mint seems to be using an older version, which according to this post 
has since been patched:

https://lore.kernel.org/lkml/3198471.FQF0JACdhR@ripper/


> > or you could fish around the Mediatek website for approp firmware files.
> 
> no sign of firmware files.

OK.

I had a look in the latest stable version sys-kernel/linux-firmware-20230515 
for the file you reported an error on:

$ find /lib/firmware -iname WIFI_MT7961_patch_mcu_1_2_hdr.bin
/lib/firmware/mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
$ ls -la /lib/firmware/mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
-rw-r--r-- 1 root root 92192 May 18 16:16 /lib/firmware/mediatek/
WIFI_MT7961_patch_mcu_1_2_hdr.bin

Do you get the same result?  I'd update to the latest linux-firmware version 
first, just in case.

> > Finally, set up a symlink from '/etc.init.d/net.wlp5s0'
> > to '/etc/init.d/net.lo' or whatever your card is detected, if not wlp5s0.
> 
> i've created that link, but how is it supposed to help ?

This is merely to bring up the interface and establish your wireless network 
service at boot time, if you add it to the default run level:

rc-update add net.wlp5s0 default

but until you get it working, you can use this service to start/stop your 
wireless connection manually.


> > https://wiki.gentoo.org/wiki/Handbook:AMD64/Networking/Introduction
> > 
> > and bring up your wireless network service:
> >  'rc-service -v net.wlp5s0 start'
> 
> it gives "ERROR : fails to start".

Yes, because there is the previous problem with the firmware.


> > Besides wpa_supplicant, other packages required like 'net-misc/netifrc',
> > 'net-misc/dhcpcd' should be installed,
> > if they have not been brought in as dependencies already.
> 
> I've installed 'netifrc' ; 'dhcpcd' was installed long ago.
> 
> > Please post back your dmesg and any terminal output,
> > if you are still having problems bringing up this wireless interface.
> > PS. This page which may or may not be still relevant
> > with the latest stable kernels, but you may want to take a look either
> > way:
> > https://wiki.gentoo.org/wiki/User:Chess/MT7921e
> 
> So no progress today.  I can try copying the firmware files from SR/Mint
> -- everything under  /lib/firmware/  in SR/Mint & see if it helps.

Not yet, let's see if the missing firmware file is available in your /lib/
firmware first.


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Steam.

2023-06-01 Thread Matt Connell
On Thu, 2023-06-01 at 15:18 -0400, Alan Grimes wrote:
> I haven't been able to run steam on my machine for about 2 weeks now. No 
> idea what the cause is, reported to Valve's Github page. Current symptom 
> is that window opens but driving thread stalls out or ??? and UI 
> freezes, needs to be closed from console. First symptoms appeared after 
> a game crash and were not cured by a cold boot.

I'm assuming you're using the package from the steam-meta repository. 
Do you get the same result using the flatpak?  In other words, is the
problem account-specific or package specific?

Alternatively, try moving (renaming) ~/.local/share/Steam and then
starting the client.  That should let it start "fresh".



[gentoo-user] Steam.

2023-06-01 Thread Alan Grimes
I haven't been able to run steam on my machine for about 2 weeks now. No 
idea what the cause is, reported to Valve's Github page. Current symptom 
is that window opens but driving thread stalls out or ??? and UI 
freezes, needs to be closed from console. First symptoms appeared after 
a game crash and were not cured by a cold boot.



--
Beware of Zombies. =O
#EggCrisis  #BlackWinter
White is the new Kulak.
Powers are not rights.




Re: [gentoo-user] using Wifi in a new machine

2023-06-01 Thread Philip Webb
230531 Michael wrote:
> It seems you have the correct module for the mediatek driver installed,
> since lshw on gentoo shows it being used. What is not shown is the firmware.
> Now, to bottom out the firmware issue.
> You need to specify the firmware path in your kernel, as explained here.
> By default this would be under /lib/firmware/ :
> https://wiki.gentoo.org/wiki/Linux_firmware

/lib/firmware/ is the dir with firmware files.

> Hopefully, the requisite firmware file blobs will be present
> in the latest stable 'sys-kernel/linux-firmware' package,
> once you install it.

It is already installed (230404) , presumably as part of Stage 3.
That date shouldn't be too old.

> dmesg will reveal if these are/not being loaded.

'dmesg | grep firmware' shows  10  identical lines :

  Loading firmware : mediatek/WIFI_MT7921_patch_mcu_1_2_hdr.bin :
   failed with error-2 .

> you could keyword the trunk version hoping it contains what you need:
> 
>**     *l^bstd [compress-xz compress-zstd initramfs 
> +redistributable savedconfig unknown-license] ["initramfs? ( redistributable 
> ) 
> ?? ( compress-xz compress-zstd )"]

I don't understand these lines (smile).

> Or, you could compare what firmware files are loaded in Mint/SR ISOs
> and copy these over to your Gentoo system for now

SR shows no record of loading via 'dmesg' ;
Mint ends with a lot of Bluetooth + mt7921e references.
Mint mentions a firmware " 01 " ( 4 underlines ).

> or you could fish around the Mediatek website for approp firmware files.

no sign of firmware files.

> Finally, set up a symlink from '/etc.init.d/net.wlp5s0'
> to '/etc/init.d/net.lo' or whatever your card is detected, if not wlp5s0.

i've created that link, but how is it supposed to help ?

> https://wiki.gentoo.org/wiki/Handbook:AMD64/Networking/Introduction

> and bring up your wireless network service:
>  'rc-service -v net.wlp5s0 start'

it gives "ERROR : fails to start".
 
> Besides wpa_supplicant, other packages required like 'net-misc/netifrc',
> 'net-misc/dhcpcd' should be installed,
> if they have not been brought in as dependencies already.

I've installed 'netifrc' ; 'dhcpcd' was installed long ago.

> Please post back your dmesg and any terminal output,
> if you are still having problems bringing up this wireless interface.
> PS. This page which may or may not be still relevant
> with the latest stable kernels, but you may want to take a look either way:
> https://wiki.gentoo.org/wiki/User:Chess/MT7921e

So no progress today.  I can try copying the firmware files from SR/Mint
-- everything under  /lib/firmware/  in SR/Mint & see if it helps.

Your final note was a link to someone's pains using mt7921e,
which he sad in the end was defective software.

Further advice is still very welcome (smile).

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca