Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 22

Thread: Slow GUI file manager on primary drive

  1. #11

    Default Re: Slow GUI file manager on primary drive

    Quote Originally Posted by dcurtisfra View Post
    @rfmhunt:

    It's an SSD.
    • What's the result of (user “root”) “systemctl status fstrim.timer”

    Code:
     > systemctl list-unit-files | grep -i 'trim'
    btrfs-trim.service                                               static         
    fstrim.service                                                   static         
    btrfs-trim.timer                                                 masked         
    fstrim.timer                                                     enabled        
     >
    Assuming that, the systemd fstrim timer service is indicating that, fstrim is occasionally executing, check the systemd Journal around the time that the fstrim last executed.
    Alternatively, (user “root”) start the fstrim service manually: “systemctl start fstrim.service”.
    I ran the command and the result is:

    "fstrim.timer - Discard unused blocks once a week
    Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
    Active: active (waiting) since Wed 2020-01-22 23:01:35 CST; 18h ago
    Trigger: Mon 2020-01-27 00:00:00 CST; 3 days left
    Docs: man:fstrim"

    Knowing next to nothing I would say it seems to be working.


    From eng-int: if I launch Kate from the program menu it starts fine but any attempt to open a file on sba from the "file, open" menu results in the file browser having the spinning cursor (waited over an hour with no change). If I open Kate from CLI ("Kate /etc/fstab") it opens instantly with the file loaded. Using the CLI instance of Kate I can load other files from the same directory (/etc in this case) but any attempt to change directory from the "file, open" menu results in a spinning cursor in the file dialogue pop-up.

    Some further info: I left Gparted running from this morning and it never finished trying to load the drives - just plain hung up with spinning cursor. However, using the partitioner in Yast works near instantaneously.

  2. #12

    Default Re: Slow GUI file manager on primary drive

    Quote Originally Posted by tsu2 View Post
    You should open your VBox application and check which version is installed.
    I suspect you may still be running VBox 5.3, although AFAIK Oracle still supports it you should be making plans to upgrade to 6.1 (Download from Oracle VBox website) or 6.0 (from the openSUSE repositories), both which have substantial improvements over the older versions.

    The DKMS package is likely an indicator of your older VBox version, it's now included in the main VBox install and not as a separate package.

    You haven't said whether you removed the DKMS package from your HostOS or in a Guest, if you removed from the HostOS it wouldn't affect anything in the Guest but if your HostOS was somehow changed then installed versions in your HostOS and Guests might not be in sync anymore which could cause a "missing kernel module" error because kernel modules can be specific to versions.

    Beware that if you don't approach your troubleshooting with a plan, you could be spinning your wheels and maybe make things worse.
    You should ignore anything related to your Guests and maybe even VBox at first.
    Be certain your HostOS is fully updated and fully functioning (everything!) before you look at anything in VBox.
    When you look at VBox, inspect the VBox installation on your HostOS first, everything from verifying the version to the various settings.
    Only after your HostOS and VBox application is working to your satisfaction, you can open your first Guest and address anything that might need to be fixed...And particularly if you made certain changes to VBox running on your HostOS, you might need to also make changes to the Guest such as upgrading to a version that's the same as the main VBox app running on the HostOS, configuration changes, and maybe even re-installing Guest Additions (openSUSE will try to install Guest Additions automatically but if you have versioning problems that won't work).

    HTH,
    TSU
    I googled for problems related to dbus not launching in systemd. After reviewing several links to see if they might have insight to my problem I found a link that mentioned virtualbox update causing a similar problem. It was an older link and they specifically mentioned "virtualbox-guest-dkms". since I didn't have that I searched and found that the file is related to guest extensions in virtualbox. So I deleted guest extensions as I originally wrote. This was all done upgreading from vr 6.0 to 6.1. Doig these step has fixed the booting problem of dbus not launching and booting seems to be working just fine now. I mentioned all this in the original post to give background on what I was doing that preceded the current GUI problem. The machine was up-to-date on everything except Plasma, LIVES, and one other program.

  3. #13

    Default Re: Slow GUI file manager on primary drive

    Quote Originally Posted by dcurtisfra View Post
    You could have booted the Leap 15.1 Installation DVD and then, repaired the system.

    But, the issue seems to be, why did the /etc/ directory suddenly become corrupt?


    1. Is the drive for the “/” partition really OK?
    2. Do you have the “smartmontools” package installed?
    3. Does “smartctl --health /dev/sda” indicate any ageing issues with that drive?
    4. If not, you'll have to inspect deeper with “smartctl --all /dev/sda” …
    5. Are you setting up “fstab” and managing the drive partitions with the YaST module?
    6. Does the “/” partition use Btrfs?

    Here is result of "smarctl -all /dev/sda":

    === START OF INFORMATION SECTION ===
    Model Family: Samsung based SSDs
    Device Model: Samsung SSD 850 EVO 1TB
    Serial Number: S3PJNF0J904692Z
    LU WWN Device Id: 5 002538 d423a3668
    Firmware Version: EMT03B6Q
    User Capacity: 1,000,203,804,160 bytes [1.00 TB]
    Sector Size: 512 bytes logical/physical
    Rotation Rate: Solid State Device
    Form Factor: 2.5 inches
    Device is: In smartctl database [for details use: -P show]
    ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c
    SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
    Local Time is: Thu Jan 23 21:41:11 2020 CST
    SMART support is: Available - device has SMART capability.
    SMART support is: Enabled

    === START OF READ SMART DATA SECTION ===
    SMART overall-health self-assessment test result: PASSED

    General SMART Values:
    Offline data collection status: (0x00) Offline data collection activity
    was never started.
    Auto Offline Data Collection: Disabled.
    Self-test execution status: ( 0) The previous self-test routine completed
    without error or no self-test has ever
    been run.
    Total time to complete Offline
    data collection: ( 0) seconds.
    Offline data collection
    capabilities: (0x53) SMART execute Offline immediate.
    Auto Offline data collection on/off support.
    Suspend Offline collection upon new
    command.
    No Offline surface scan supported.
    Self-test supported.
    No Conveyance Self-test supported.
    Selective Self-test supported.
    SMART capabilities: (0x0003) Saves SMART data before entering
    power-saving mode.
    Supports SMART auto save timer.
    Error logging capability: (0x01) Error logging supported.
    General Purpose Logging supported.
    Short self-test routine
    recommended polling time: ( 2) minutes.
    Extended self-test routine
    recommended polling time: ( 512) minutes.
    SCT capabilities: (0x003d) SCT Status supported.
    SCT Error Recovery Control supported.
    SCT Feature Control supported.
    SCT Data Table supported.

    SMART Attributes Data Structure revision number: 1
    Vendor Specific SMART Attributes with Thresholds:
    ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
    5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
    9 Power_On_Hours 0x0032 097 097 000 Old_age Always - 10358
    12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 609
    177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always - 6
    179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0
    181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0
    182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0
    183 Runtime_Bad_Block 0x0013 100 099 010 Pre-fail Always - 0
    187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always - 0
    190 Airflow_Temperature_Cel 0x0032 070 059 000 Old_age Always - 30
    195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always - 0
    199 CRC_Error_Count 0x003e 099 099 000 Old_age Always - 12
    235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 124
    241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 14934862779

    SMART Error Log Version: 1
    No Errors Logged

    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% 10339 -
    # 2 Short offline Completed without error 00% 10328 -
    # 3 Short offline Completed without error 00% 10320 -
    # 4 Short offline Completed without error 00% 10307 -
    # 5 Short offline Completed without error 00% 10291 -
    # 6 Short offline Completed without error 00% 10276 -
    # 7 Short offline Completed without error 00% 10259 -
    # 8 Short offline Completed without error 00% 10256 -
    # 9 Short offline Completed without error 00% 10238 -
    #10 Short offline Completed without error 00% 10228 -
    #11 Short offline Completed without error 00% 10222 -
    #12 Short offline Completed without error 00% 10213 -
    #13 Short offline Completed without error 00% 10194 -
    #14 Short offline Completed without error 00% 10192 -
    #15 Short offline Completed without error 00% 10187 -
    #16 Short offline Completed without error 00% 10180 -
    #17 Short offline Completed without error 00% 10172 -
    #18 Extended offline Completed without error 00% 10167 -
    #19 Short offline Completed without error 00% 10144 -
    #20 Short offline Completed without error 00% 10128 -
    #21 Short offline Completed without error 00% 10112 -

    SMART Selective self-test log data structure revision number 1
    SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
    1 0 0 Not_testing
    2 0 0 Not_testing
    3 0 0 Not_testing
    4 0 0 Not_testing
    5 0 0 Not_testing
    255 0 65535 Read_scanning was never started
    Selective self-test flags (0x0):
    After scanning selected spans, do NOT read-scan remainder of disk.
    If Selective self-test is pending on power-up, resume after 0 minute delay.


  4. #14

    Default Re: Slow GUI file manager on primary drive

    I have one last input. The problem persists for both normal user and root logins. It is the same across four different desktop environments (Plasma, LXDE, XCFE,? - can't remember). In all cases the CLI access to sda is perfectly fine but a GUI access causes a program to freeze or just take a long time (>20min) to load. If I start in a directory then the graphical interface works just fine for anything in that top level directory or its subs - trying to change to another top level directory causes the freeze problem. For instance if I start Kate at CLI with a file in /lib/lsb/ then everything under /lib/ is eaily accessible. If I then try to access a file in /var or /usr Kate will freeze. This is consistant across all DEs and for all users. Gparted will start but not proceed past the intial disk scan (which never finishes), however parted from CLI works perfectly fine.

    I have tried reinstalling KIO as suggested and it didn't help. I tried reinstalling different DEs and it didn't help. Something is preventing GUI from accessing sda but it doesn't prevent CLI access. Only exception is Yast which works just fine.

  5. #15
    Join Date
    Oct 2008
    Location
    Glasgow, Scotland
    Posts
    1,230

    Default Re: Slow GUI file manager on primary drive

    Quote Originally Posted by rfmhunt View Post
    The problem persists ...
    Most likely something went wrong during an update. Sometimes it is just too difficult to determine the exact cause of a problem and just try to fix it.

    What has generally worked for me is
    Code:
    sudo zypper dup
    but first it is important to ensure that you do not have any inappropriate repositories enabled with
    Code:
     zypper lr -Eu
    --
    slàinte mhath,
    rayH

    ~ knowing the right answer is easier than knowing the right question.

  6. #16
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    2,749

    Question Re: Slow GUI file manager on primary drive

    @rfmhunt:

    The SMART data looks pretty much OK – the only things to watch are:
    Code:
    5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
    181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0
    182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0
    183 Runtime_Bad_Block 0x0013 100 099 010 Pre-fail Always - 0
    187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always - 0
    190 Airflow_Temperature_Cel 0x0032 070 059 000 Old_age Always - 30
    195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always - 0
    199 CRC_Error_Count 0x003e 099 099 000 Old_age Always - 12
    235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 124
    • No reallocated sectors – good.
    • Program and Erase fail count both 0 – good.
    • No Runtime bad blocks – good.
    • No uncorrectable errors – good.
    • Airflow temperature: 30 °C – OK.
    • ECC error rate = 0 – good.
    • CRC error count = 12 – keep an eye on this counter – if it begins increasing, monitor for other “end of life” indications …
    • POR (Power) recovery count: A count of the number of sudden power off cases.

    If there is a sudden power off, the firmware must recover all of the mapping and user data during the next power on.

    Having pointed all that out, I can't see anything which could have caused file corruption in the /etc/ directory – “fstab” for example.
    • Are you absolutely certain that, you didn't accidentally edit “/etc/fstab”?

  7. #17

    Default Re: Slow GUI file manager on primary drive

    Quote Originally Posted by dcurtisfra View Post
    @rfmhunt:

    The SMART data looks pretty much OK – the only things to watch are:
    Code:
    5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
    181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0
    182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0
    183 Runtime_Bad_Block 0x0013 100 099 010 Pre-fail Always - 0
    187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always - 0
    190 Airflow_Temperature_Cel 0x0032 070 059 000 Old_age Always - 30
    195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always - 0
    199 CRC_Error_Count 0x003e 099 099 000 Old_age Always - 12
    235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 124
    • No reallocated sectors – good.
    • Program and Erase fail count both 0 – good.
    • No Runtime bad blocks – good.
    • No uncorrectable errors – good.
    • Airflow temperature: 30 °C – OK.
    • ECC error rate = 0 – good.
    • CRC error count = 12 – keep an eye on this counter – if it begins increasing, monitor for other “end of life” indications …
    • POR (Power) recovery count: A count of the number of sudden power off cases.

    If there is a sudden power off, the firmware must recover all of the mapping and user data during the next power on.

    Having pointed all that out, I can't see anything which could have caused file corruption in the /etc/ directory – “fstab” for example.
    • Are you absolutely certain that, you didn't accidentally edit “/etc/fstab”?
    I don't think it has anything to do with fstab. As far as I can tell there is no corruption in /etc/ - only one entry in fstab was originally deleted and I fixed that. That was causing a problem related to the machine not booting correctly and it boots every time just fine now. I'm pretty sure that is theere is a persistant fstab problem it would also manifest itself from the CLI and I have no problems with file access from the CLI. The problem is the difference between CLI and GUI access for the one drive (/dev/sda).

  8. #18

    Default Re: Slow GUI file manager on primary drive

    Quote Originally Posted by eng-int View Post
    Most likely something went wrong during an update. Sometimes it is just too difficult to determine the exact cause of a problem and just try to fix it.

    What has generally worked for me is
    Code:
    sudo zypper dup
    but first it is important to ensure that you do not have any inappropriate repositories enabled with
    Code:
     zypper lr -Eu

    I will think about trying this but not sure I want to go to 15.2 unless I have to as I am content with 15.1. Last night when trying to reinstall various files (kio, etc) the return was always that they were up to date. I had to use "-f" to get zypper to do anything so I'm pretty sure 15.1 is at latest configuration.

  9. #19
    Join Date
    Oct 2008
    Location
    Glasgow, Scotland
    Posts
    1,230

    Default Re: Slow GUI file manager on primary drive

    Quote Originally Posted by rfmhunt View Post
    I will think about trying this but not sure I want to go to 15.2 unless I have to as I am content with 15.1. Last night when trying to reinstall various files (kio, etc) the return was always that they were up to date. I had to use "-f" to get zypper to do anything so I'm pretty sure 15.1 is at latest configuration.
    No! I meant “zypper dup” to 15.1 as a system repair mechanism. If you are running Leap-15.1 you should not have any repositories enabled for another distribution. Hence e the “zypper lr -Eu” to double check. It is best if you only have the openSUSE Leap-15.1 Main and Update repositories enabled to effect a repair.
    --
    slàinte mhath,
    rayH

    ~ knowing the right answer is easier than knowing the right question.

  10. #20

    Default Re: Slow GUI file manager on primary drive

    Quote Originally Posted by eng-int View Post
    No! I meant “zypper dup” to 15.1 as a system repair mechanism. If you are running Leap-15.1 you should not have any repositories enabled for another distribution. Hence e the “zypper lr -Eu” to double check. It is best if you only have the openSUSE Leap-15.1 Main and Update repositories enabled to effect a repair.

    Okay, now I understand. I will try that.

Page 2 of 3 FirstFirst 123 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •