I found this thread discussing those same attributes for Seagate HDDs saying that compared to other drives their numbers are “high” . . . but that is “normal” for Seagate. I didn’t read on about it . . . .
(https://www.hdsentinel.com/forum/viewtopic.php?f=32&t=735)
I did try to run the smartctl command on my newer nvme drive, but it didn’t show the same stack of results . . . . . I wanted to see if my '20 SSD would show as “old age” but it didn’t show any stats.
Dealing with shaky hardware results in enormous waste of time: Wear and tear of desktop class 4TB HDD model WD40EZRX-22SPEB0
Some fun with SSDs: Another Western Digital Green SSD dead without any pre-fail indication
Spare hardware helps sorting out issues you are experiencing. Testing you machine with a new SSD and a default Tumbleweed install will give some conclusive answers.
Not sure if you have followed the thread, but the TW / is in a new SSD, and the /home is in the HDD . . . which isn’t super old. I have the OEM HDD still running, in that case the Lubuntu install is there, I can run smartctl there and see what shows up . . . .
Only TW is having this issue . . . compared to 6 other linux installs on the various drives, AND as you quoted, I booted the OSX system from the HDD . . . log in went well, apps booted up fine.
As far as I can tell from following this lengthy discussion you consistently fail to present hard facts. Any drive can cause problems at any time. Removing all but the new SSD will help to assess whether Tumbleweed actually has some problem.
yeaaaaah, sure:
Big numbers for 1, 7 & 195 are normal Seagate numbers. Each of mine, older than OP’s in POH, runs 24hrs/day with no issues evident as part of 6 RAID1 filesystems, plus 4 other partitions each:
Model Family: Seagate Constellation ES (SATA 6Gb/s)
Device Model: ST1000NM0011
...
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Size: 512 bytes logical/physical
...
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
...
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 081 063 044 Pre-fail Always - 118971692
...
7 Seek_Error_Rate 0x000f 081 060 030 Pre-fail Always - 144539759
...
195 Hardware_ECC_Recovered 0x001a 117 099 000 Old_age Always - 118971692
...
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 9721 -
# 2 Short offline Completed without error 00% 9697 -
# 3 Short offline Completed without error 00% 9673 -
# 4 Short offline Completed without error 00% 9649 -
# 5 Extended offline Completed without error 00% 9628 -
Model Family: Seagate Barracuda 7200.14 (AF)
Device Model: ST1000DM003-1CH162
...
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
...
ATA Version is: ACS-2, ACS-3 T13/2161-D revision 3b
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
...
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 118 099 006 Pre-fail Always - 192521784
...
7 Seek_Error_Rate 0x000f 087 060 030 Pre-fail Always - 507026342
...
194 Temperature_Celsius 0x0022 032 040 000 Old_age Always - 32 (0 22 0 0 0)
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
...
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 21879 -
# 2 Short offline Completed without error 00% 21855 -
# 3 Short offline Completed without error 00% 21831 -
# 4 Short offline Completed without error 00% 21807 -
# 5 Extended offline Completed without error 00% 21785 -
I’d like to close the “drive” direction . . . today I booted another OS with / in sdb, one that likely shares the same partition with TW in sdb10 . . . . Booted up fine, launching stuff is fine, is it as fast as my SSD?? Obviously not, but faster than the TW situation. If I knew what “facts” to post on it I would.
I previously posted back on a thread with a gent on the factory list-serve who asked, “Is anybody else having log in problems in TW?” And I responded with a link to this thread . . . to wit, no reply back. Today the digest showed another post from him and another gent . . . describing what was happening, and still is?? It’s another couple of folks who seem to be in the same ballpark?? I think I posted that original data in this thread as well?
Subject: Re: sddm stays black after recent TW update
> On Oct 5, 2023, at 9:54 AM, Adrian Glaubitz <adrian.glaubitz@suse.com> wrote:
>
> After rebooting my Tumbleweed machine after one of the recent updates, sddm just shows a black screen with just the mouse pointer showing.
>
> I have not been able to pinpoint the cause of this but maybe someone else has and can help me save some time.
Looking at the logs, it seems that sddm-helper is crashing. I could work around that by switching to lightdm instead of sddm.
However, after that it’s KDE that immediately crashes so I assume the sddm crash is related to some regression in Qt or related code.
Adri
The question is, is he waiting for 3 or 4 minutes to get to the GUI?? There are other posts back on the list-serve . . . .
@non_space from a user on the Packman IRC channel yesterday…
draeath> I just finished debugging a nasty issue and I have no idea where to report it, if reportable at all. Summary: there's version inconsistencies with the Mesa packages in packman-essentials, which caused kwin to crash and sddm to get stuck in a coredump loop. I forced all the Mesa packages back to the standard Tumbleweed repo and the issue went away. (Note: i may be off about the root cause. best i could
<draeath> find was that swrast_dri.so (provided by Mesa-dri) was segfaulting, in turn killing sddm (or kwin when i had tried with xdm). Anyway. It's now far too late and I need to go to bed. Hopefully this text somehow gets noticed by someone who can do something with it. [opensuse tumbleweed, x86_64, VGA compatible controller: Intel Corporation Alder Lake-P Integrated Graphics Controller (rev 0c)]
OK . . . that may relate, I do have Packman going . . . I thought there was some reassignment on the Packman repos in the last few months?? Might have been in Leap where the “vendors” were changed?? This problem occurred well after that change if it happened in TW.
The factory list-serve discussion seemed to indicate a “6.5 kernel” problem and they went back to 6.4 as their solution . . . . I don’t like “going back” especially in TW . . . which always rolls forward . . . but, if it would solve the issue on a temp basis . . . it might be an option . . . .
How would I test out this recent “Mesa-dri” direction??
Are all installed mesa packages from the same repo?
Are there obvious inconsistencies in the versions of the installed Mesa packages?
This is what I have on my newest AMD CPU/GPU PC:
# inxi -S
System:
Host: ara88 Kernel: 6.4.12-1-default arch: x86_64 bits: 64
Console: pty pts/1 Distro: openSUSE Tumbleweed 20231003
# rpm -qa | grep Mesa | sort
libOSMesa8-23.2.0-359.1.x86_64
Mesa-23.2.0-359.1.x86_64
Mesa-demo-egl-9.0.0-2.1.x86_64
Mesa-demo-x-9.0.0-2.1.x86_64
Mesa-dri-23.2.0-359.1.x86_64
Mesa-gallium-23.2.0-359.1.x86_64
Mesa-libd3d-23.2.0-359.1.x86_64
Mesa-libEGL1-23.2.0-359.1.x86_64
Mesa-libGL1-23.2.0-359.1.x86_64
Mesa-libglapi0-23.2.0-359.1.x86_64
Mesa-libOpenCL-23.2.0-359.1.x86_64
Mesa-libva-23.2.0-359.1.x86_64
#
zypper se -si Mesa provides some more verbose information…
There will be another delay . . . this morning both TW and Gecko rolling booted to emergency mode. In the case of TW I couldn’t “systemctl reboot” out of it. “Journalctl -xb” showed a few problems but seemed to hit some “jobs” . . . .
I shut down the machine and let grub do its thing and Leap quickly booted up . . . . Logged in quickly and off to the web races . . . .
Yeah. This is starting to get “irritating” . . . something must have happened to an /etc/fstab . . . or some other news of fresh disaster. Right now Leap, and the Debian, and manjaro systems boot fine, but something in grub2 has changed the system IDs and the partition names, so that the partition will boot, but it won’t be the system that is named . . . .
I ran the grub2-mkconfig in Leap and it got the system names, but moved them to another partition . . . ??? Leap is able to see itself and take care of itself, everybody else be danged . . . ??? Can’t get TW past the ER boot mode . . . so the “slowness” issue is no longer a factor . . . PITA.
Got back into TW with Supergrub2 disk . . . for the most part in checking a few, the other /fstab’s seem to be oK, so now I’m looking at Leap’s grub2 as the source of the confusion . . . seeming to move “sda” to “sdb” . . .and sdb to sdc . . . and sdc to now “sdd” . . . .
But in the Supergrub disk, TW boots . . . back to the slow log in. And, then tried to launch GParted and that crashed out. Firefox boots quickly and works fine.
> inxi -S
System:
Host: no-macpro02.home Kernel: 6.5.4-1-default arch: x86_64 bits: 64
Desktop: MATE v: 1.26.1 Distro: openSUSE Tumbleweed 20231001
butoh-mind@noone-macpro02:~> su -
Password:
noone-macpro02:~ # rpm -qa | grep Mesa | sort
Mesa-23.1.8-358.1.x86_64
Mesa-demo-x-9.0.0-2.1.x86_64
Mesa-dri-23.1.8-358.1.x86_64
Mesa-gallium-23.1.8-358.1.x86_64
Mesa-libEGL1-23.1.8-358.1.x86_64
Mesa-libGL1-23.1.8-358.1.x86_64
Mesa-libglapi0-23.1.8-358.1.x86_64
Mesa-libva-23.1.8-358.1.x86_64
@malcomlewis:
# zypper se -si Mesa
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
--+----------------+---------+--------------+--------+----------------------
i | Mesa | package | 23.1.8-358.1 | x86_64 | Main Repository (OSS)
i | Mesa | package | 23.1.8-358.1 | x86_64 | openSUSE-20220916-0
i | Mesa-demo-x | package | 9.0.0-2.1 | x86_64 | Main Repository (OSS)
i | Mesa-demo-x | package | 9.0.0-2.1 | x86_64 | openSUSE-20220916-0
i | Mesa-dri | package | 23.1.8-358.1 | x86_64 | Main Repository (OSS)
i | Mesa-dri | package | 23.1.8-358.1 | x86_64 | openSUSE-20220916-0
i | Mesa-gallium | package | 23.1.8-358.1 | x86_64 | Main Repository (OSS)
i | Mesa-gallium | package | 23.1.8-358.1 | x86_64 | openSUSE-20220916-0
i | Mesa-libEGL1 | package | 23.1.8-358.1 | x86_64 | Main Repository (OSS)
i | Mesa-libEGL1 | package | 23.1.8-358.1 | x86_64 | openSUSE-20220916-0
i | Mesa-libGL1 | package | 23.1.8-358.1 | x86_64 | Main Repository (OSS)
i | Mesa-libGL1 | package | 23.1.8-358.1 | x86_64 | openSUSE-20220916-0
i | Mesa-libglapi0 | package | 23.1.8-358.1 | x86_64 | Main Repository (OSS)
i | Mesa-libglapi0 | package | 23.1.8-358.1 | x86_64 | openSUSE-20220916-0
i | Mesa-libva | package | 23.1.8-358.1 | x86_64 | Main Repository (OSS)
i | Mesa-libva | package | 23.1.8-358.1 | x86_64 | openSUSE-20220916-0
Might ought to check all. Do any contain sda, sdb, sdc, sdd, sde, sdf, sdg or sdh? If yes, convert them to persistent names.
Thanks for the reply . . . thinking that if the data in Supergrub showed the correct boot location for TW, and that TW booted up–that that would mean TW was “OK” . . . was wrong.
Checking in blkid and etc/fstab AND in GParted it is showing that rather than / in sda and /home in sdb10 . . . they have been “moved” to sdb and sdd. Sdd in Gparted is showing what should be sdc . . . all four drives are showing but they have been switched around for TW.
So, something has tweaked the TW, and possibly the Gecko rolling data . . . but the other systems seem “OK” . . . ???
While I was in TW I ran a zypper . . . and saw a few “Mesa-dri” packages listed . . . . : - ))
@non_space no, it’s been that way for quite some time AFAIK, plug in sda,sdb,sdc and all good, stick in sdd and all would switch around…
Hence the move to UUIDS, (See factory ML) to avoid this issue…
Hmm . . . well, in this case the 4 internal drives were “plugged” in a couple years back. I did plug in the SuperGrub2 disk, the only way to get TW to boot . . . the problem had happened before I plugged in the usb drive . . . . Problems begat more problems???
I was thinking that because of my frustration with the slowness of TW, that moving grub2 over to Leap was potentially a retro move from grub?? Like Leap might be using an older version of grub than TW is, and switching grub over to Leap to get around the slowness problem now put me back to the grub that had “issues” with organizing multi-boot line items? I had this exact problem with UUIDs being changed only a few months back . . . which “we” painfully worked through until I punched out and did what I historically have done to solve grub/UUID problems . . . run a fresh install of something, and then let it handle the bootloading organization.
Seems like there is a gent on the Factory list-serve who hit this same “grub” problem with recent dups and he provided some hints on that issue, which I have to read through again, looking at /etc/default/grub items??? . . . it’s like quagmire stacked on quagmire . . . .