Page 5 of 6 FirstFirst ... 3456 LastLast
Results 41 to 50 of 55

Thread: Tower's BtrFS has gone ReadOnly... again... yet again.

  1. #41
    Join Date
    Jun 2017
    Location
    Australia
    Posts
    582

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    Quote Originally Posted by karlmistelberger View Post
    #7: you definitely need trim, verify:

    Code:
    erlangen:~ # systemctl list-timers
    NEXT                         LEFT        LAST                         PASSED        UNIT                         ACTIVATES
    Thu 2017-12-07 00:00:00 CET  17h left    Wed 2017-12-06 05:06:56 CET  1h 10min ago  logrotate.timer              logrotate.service
    Thu 2017-12-07 02:06:00 CET  19h left    Tue 2017-12-05 18:52:55 CET  11h ago       systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
    Mon 2017-12-11 00:00:00 CET  4 days left Mon 2017-12-04 06:51:20 CET  1 day 23h ago fstrim.timer                 fstrim.service
    
    3 timers listed.
    Pass --all to see loaded but inactive timers, too.
    erlangen:~ # 
    erlangen:~ # journalctl -u fstrim.service 
    -- Logs begin at Tue 2017-01-31 14:09:48 CET, end at Wed 2017-12-06 06:15:22 CET. --
    Dec 04 06:51:20 erlangen systemd[1]: Starting Discard unused blocks...
    Dec 04 06:53:31 erlangen fstrim[5205]: /home: 250.8 GiB (269247569920 bytes) trimmed
    Dec 04 06:53:31 erlangen fstrim[5205]: /: 16.6 GiB (17836232704 bytes) trimmed
    Dec 04 06:53:31 erlangen systemd[1]: Started Discard unused blocks.
    erlangen:~ #
    Mine looks slightly different to yours.
    Code:
    gooeygirl@linux-Tower:~> systemctl list-timers
    NEXT                          LEFT        LAST                          PASSED     UNIT                         ACTIVATES
    Sat 2017-12-09 00:00:00 AEDT  6h left     Fri 2017-12-08 00:00:53 AEDT  17h ago    logrotate.timer              logrotate.service
    Sat 2017-12-09 10:59:23 AEDT  17h left    Fri 2017-12-08 10:59:23 AEDT  6h ago     systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
    Mon 2017-12-11 00:00:00 AEDT  2 days left Wed 2017-12-06 16:15:33 AEDT  2 days ago fstrim.timer                 fstrim.service
    
    3 timers listed.
    Pass --all to see loaded but inactive timers, too.
    gooeygirl@linux-Tower:~> 
    
    
    gooeygirl@linux-Tower:~> journalctl -u fstrim.service
    Hint: You are currently not seeing messages from other users and the system.
          Users in the 'systemd-journal' group can see all messages. Pass -q to
          turn off this notice.
    -- Logs begin at Wed 2017-12-06 19:20:29 AEDT, end at Fri 2017-12-08 12:53:44 AEDT. --
    -- No entries --
    gooeygirl@linux-Tower:~> sudo journalctl -u fstrim.service
    [sudo] password for root: 
    -- Logs begin at Wed 2017-12-06 16:14:56 AEDT, end at Fri 2017-12-08 17:55:11 AEDT. --
    -- No entries --
    gooeygirl@linux-Tower:~>
    Your two outputs were consistent & in agreement with each other, whereas mine are not. I wondered if maybe i need to enable the service, but apparently not:
    Code:
    gooeygirl@linux-Tower:~> sudo systemctl enable fstrim.service
    The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
    settings in the [Install] section, and DefaultInstance for template units).
    This means they are not meant to be enabled using systemctl.
    Possible reasons for having this kind of units are:
    1) A unit may be statically enabled by being symlinked from another unit's
       .wants/ or .requires/ directory.
    2) A unit's purpose may be to act as a helper for some other unit which has
       a requirement dependency on it.
    3) A unit may be started when needed via activation (socket, path, timer,
       D-Bus, udev, scripted systemctl call, ...).
    4) In case of template units, the unit is meant to be enabled with some
       instance name specified.
    
    
    gooeygirl@linux-Tower:~> sudo systemctl enable fstrim
    The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
    settings in the [Install] section, and DefaultInstance for template units).
    This means they are not meant to be enabled using systemctl.
    Possible reasons for having this kind of units are:
    1) A unit may be statically enabled by being symlinked from another unit's
       .wants/ or .requires/ directory.
    2) A unit's purpose may be to act as a helper for some other unit which has
       a requirement dependency on it.
    3) A unit may be started when needed via activation (socket, path, timer,
       D-Bus, udev, scripted systemctl call, ...).
    4) In case of template units, the unit is meant to be enabled with some
       instance name specified.
    gooeygirl@linux-Tower:~>
    Whereas my SSD's / is now ext4, my [reused] /home is xfs... does trim still work for that? In any event, it clearly should work on ext4 ie my /.

  2. #42
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    26,289
    Blog Entries
    15

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    Quote Originally Posted by GooeyGirl View Post
    I do have a second account setup already [specifically for testing], & therein, TS GUI successfully launches directly from the App Menu.

    I do not use Wayland.

    Could you pls elaborate on what i need to do wrt "Display driver/setup on your system?"?
    Hi
    So it's at your user level... hard to say some configuration tweak maybe related to gtk?
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  3. #43
    Join Date
    Jun 2017
    Location
    Australia
    Posts
    582

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    Hmmm, sorry, the penny is still not dropping for me. Any suggestions on where i should look . for what i should be looking?

    some configuration tweak maybe related to gtk
    --> are you meaning something that i did? Golly - i haven't a clue what that might be.

  4. #44
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    26,289
    Blog Entries
    15

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    On Fri 08 Dec 2017 11:06:01 PM CST, GooeyGirl wrote:

    Hmmm, sorry, the penny is still not dropping for me. Any suggestions on
    -where- i should look . for -what- i should be looking?

    > some configuration tweak maybe related to gtk --> are you meaning
    > something that *i* did? Golly - i haven't a clue

    what that might be.
    Hi
    Alas have no idea, no KDE/Plasma in play for me, maybe file
    ownership/permissions in your home directory in one of the configuration
    directories perhaps since it works for your test user.

    --
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    openSUSE Leap 42.2|GNOME 3.20.2|4.4.92-18.36-default
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!


  5. #45
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    815

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    Quote Originally Posted by GooeyGirl View Post
    Mine looks slightly different to yours.
    Code:
    gooeygirl@linux-Tower:~> systemctl list-timers
    NEXT                          LEFT        LAST                          PASSED     UNIT                         ACTIVATES
    Sat 2017-12-09 00:00:00 AEDT  6h left     Fri 2017-12-08 00:00:53 AEDT  17h ago    logrotate.timer              logrotate.service
    Sat 2017-12-09 10:59:23 AEDT  17h left    Fri 2017-12-08 10:59:23 AEDT  6h ago     systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
    Mon 2017-12-11 00:00:00 AEDT  2 days left Wed 2017-12-06 16:15:33 AEDT  2 days ago fstrim.timer                 fstrim.service
    
    3 timers listed.
    Pass --all to see loaded but inactive timers, too.
    gooeygirl@linux-Tower:~> 
    
    
    gooeygirl@linux-Tower:~> journalctl -u fstrim.service
    Hint: You are currently not seeing messages from other users and the system.
          Users in the 'systemd-journal' group can see all messages. Pass -q to
          turn off this notice.
    -- Logs begin at Wed 2017-12-06 19:20:29 AEDT, end at Fri 2017-12-08 12:53:44 AEDT. --
    -- No entries --
    gooeygirl@linux-Tower:~> sudo journalctl -u fstrim.service
    [sudo] password for root: 
    -- Logs begin at Wed 2017-12-06 16:14:56 AEDT, end at Fri 2017-12-08 17:55:11 AEDT. --
    -- No entries --
    gooeygirl@linux-Tower:~>
    Your two outputs were consistent & in agreement with each other, whereas mine are not. I wondered if maybe i need to enable the service, but apparently not:
    Code:
    gooeygirl@linux-Tower:~> sudo systemctl enable fstrim.service
    The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
    settings in the [Install] section, and DefaultInstance for template units).
    This means they are not meant to be enabled using systemctl.
    Possible reasons for having this kind of units are:
    1) A unit may be statically enabled by being symlinked from another unit's
       .wants/ or .requires/ directory.
    2) A unit's purpose may be to act as a helper for some other unit which has
       a requirement dependency on it.
    3) A unit may be started when needed via activation (socket, path, timer,
       D-Bus, udev, scripted systemctl call, ...).
    4) In case of template units, the unit is meant to be enabled with some
       instance name specified.
    
    
    gooeygirl@linux-Tower:~> sudo systemctl enable fstrim
    The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
    settings in the [Install] section, and DefaultInstance for template units).
    This means they are not meant to be enabled using systemctl.
    Possible reasons for having this kind of units are:
    1) A unit may be statically enabled by being symlinked from another unit's
       .wants/ or .requires/ directory.
    2) A unit's purpose may be to act as a helper for some other unit which has
       a requirement dependency on it.
    3) A unit may be started when needed via activation (socket, path, timer,
       D-Bus, udev, scripted systemctl call, ...).
    4) In case of template units, the unit is meant to be enabled with some
       instance name specified.
    gooeygirl@linux-Tower:~>
    Whereas my SSD's / is now ext4, my [reused] /home is xfs... does trim still work for that? In any event, it clearly should work on ext4 ie my /.
    There are two fstrim units:

    Code:
    erlangen:~ # systemctl status fstrim.service
    ● fstrim.service - Discard unused blocks
       Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled)
       Active: inactive (dead)
    erlangen:~ # systemctl status fstrim.timer
    ● fstrim.timer - Discard unused blocks once a week
       Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
       Active: active (waiting) since Sat 2017-12-09 07:35:25 CET; 11min ago
      Trigger: Mon 2017-12-11 00:00:00 CET; 1 day 16h left
         Docs: man:fstrim
    
    Dec 09 07:35:25 erlangen systemd[1]: Started Discard unused blocks once a week.
    erlangen:~ #
    Don't enable fstrim.service. As it is invoked by fstrim.timer It should be disabled.

    Code:
    erlangen:~ # cat /usr/lib/systemd/system/fstrim.timer
    [Unit]
    Description=Discard unused blocks once a week
    Documentation=man:fstrim
    
    [Timer]                                                                                                                                                                                                                                      
    OnCalendar=weekly                                                                                                                                                                                                                            
    AccuracySec=1h                                                                                                                                                                                                                               
    Persistent=true                                                                                                                                                                                                                              
                                                                                                                                                                                                                                                 
    [Install]                                                                                                                                                                                                                                    
    WantedBy=timers.target                                                                                                                                                                                                                       
    erlangen:~ # cat /usr/lib/systemd/system/fstrim.service 
    [Unit]                                                                                                                                                                                                                                       
    Description=Discard unused blocks                                                                                                                                                                                                            
                                                                                                                                                                                                                                                 
    [Service]                                                                                                                                                                                                                                    
    Type=oneshot                                                                                                                                                                                                                                 
    ExecStart=/usr/sbin/fstrim -av                                                                                                                                                                                                               
    erlangen:~ #
    fstrim.timer invokes fstrim.service: OnCalendar=weekly result of this invocation is displayed in the journal:

    Code:
    erlangen:~ # journalctl -u fstrim.service
    -- Logs begin at Tue 2017-01-31 14:09:48 CET, end at Sat 2017-12-09 07:49:55 CET. --                                                                                                                                                         
    Dec 04 06:51:20 erlangen systemd[1]: Starting Discard unused blocks...                                                                                                                                                                       
    Dec 04 06:53:31 erlangen fstrim[5205]: /home: 250.8 GiB (269247569920 bytes) trimmed                                                                                                                                                         
    Dec 04 06:53:31 erlangen fstrim[5205]: /: 16.6 GiB (17836232704 bytes) trimmed                                                                                                                                                               
    Dec 04 06:53:31 erlangen systemd[1]: Started Discard unused blocks.                                                                                                                                                                          
    erlangen:~ #
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), openSUSE Tumbleweed, KDE Plasma 5

  6. #46
    Join Date
    Sep 2012
    Posts
    4,941

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    Quote Originally Posted by karlmistelberger View Post
    Don't enable fstrim.service.
    You can't do it anyway (using "systemctl enable" or equivalent) - there is nothing to enable in this unit definition.

  7. #47

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    On 12/07/2017 10:06 PM, GooeyGirl wrote:
    >
    > I shan't reply individually to your overnight [for me] replies, but will
    > make this omnibus post. Firstly i wish to express my gratitude again for
    > this ongoing wonderful & generous support.
    >
    > Next, a quick tangent, which might annoy some of you, but if so i hope
    > not to also offend. I detected a bit of a sneering / disdainful tone in
    > some of your remarks about Timeshift. Yes it is "just" a front-end for
    > rsync [so why don't i just use rsync?]. Yes i could [theoretically,
    > maybe] just perform the equivalent function 100% manually via CLI prior
    > to every TW dup [or some other fairly frequent schedule i might wish],
    > so why don't i? Well... you -vastly- over-estimate my competence, skill
    > & knowledge. With some of those things i either literally am too
    > incompetent to do them, or otherwise even if i blundered through
    > successfully it would be undesirably stressful & uncomfortable for me.
    > My screen-name here is "GooeyGirl". Whilst i presume that you understand
    > the 2nd-part of that, i suspect that the meaning of the 1st-part gets
    > lost in translation. When i first created my openSUSE account back in
    > June, i actually tried to register as "GUI-Girl" [to strongly imply to
    > anyone seeing me in the forums that *i like using GUIs* (ie, not CLI)
    > wherever possible]. I got part-way through the registration procedure &
    > my rotten browser crashed on me. Once i'd relaunched it & returned to
    > that registration page, i was annoyed to discover that the system now
    > regarded "GUI-Girl" [which was previously available for me] as then
    > being unavailable coz it was "already in use" [grrrrr]. I could not fix
    > that [& the Administrator could not help], so i created "Gooey"... in
    > English dialects it sounds identical to "GUI". Anyway the salient point
    > here for this present topic is this: for Linux numpties like me
    > [simultaneously enthusiastic but untalented], FOSS like Timeshift are
    > simply invaluable, even if they seem superfluous or poorly-coded to
    > experts. For dopes like me such pgms either allow me to do stuff that i
    > otherwise cannot do at all, or else helps me do it more easily &
    > comfortably. I respect everyone's opinion, but on that issue i
    > respectively disagree with the tone i perceived here.
    >


    Sorry but I have to disagree with you here, you are NOT untalented at
    all just not educated enough in all aspects of linux. How can you expect
    yourself to be fluent in any operating system with just a few number of
    years usage.
    I started using *nix over 30 years ago and there is much I never learned.
    I believe you are doing a fantastic job so I for one give you a hearty
    pat on the back and say keep up the fantastic work. :-)

    --
    Ken
    linux since 1984
    S.u.S.E./openSUSE since 1996

  8. #48

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    On 12/08/2017 06:12 PM, malcolmlewis wrote:
    >
    > On Fri 08 Dec 2017 11:06:01 PM CST, GooeyGirl wrote:
    >
    > Hmmm, sorry, the penny is still not dropping for me. Any suggestions on
    > -where- i should look . for -what- i should be looking?
    >
    >> some configuration tweak maybe related to gtk --> are you meaning
    >> something that *i* did? Golly - i haven't a clue

    > what that might be.
    >
    > Hi
    > Alas have no idea, no KDE/Plasma in play for me, maybe file
    > ownership/permissions in your home directory in one of the configuration
    > directories perhaps since it works for your test user.
    >
    >


    Try this command from your ~ dir:

    Code:
    *****

    ll -R | grep root

    *****

    to see if any files in your home dir gained root ownership.

    --
    Ken
    linux since 1984
    S.u.S.E./openSUSE since 1996

  9. #49
    Join Date
    Jun 2017
    Location
    Australia
    Posts
    582

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    Quote Originally Posted by malcolmlewis View Post
    Hi
    Alas have no idea, no KDE/Plasma in play for me, maybe file
    ownership/permissions in your home directory in one of the configuration
    directories perhaps since it works for your test user.

    --
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    openSUSE Leap 42.2|GNOME 3.20.2|4.4.92-18.36-default
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!
    Thanks, sorry for lagged reply [lots happened here to distract me, but it did not help that i got locked out of the forum & have only wangled my way back in just now].

    I compared all the groups & permissions of all the potentially relevant files & directories i could think of in my account vs my test account, & did not uncover any obvious difference. However, i have actually managed to solve it [ie, the GUI finally would launch properly without needing su, in my account], but i do not really understand why what i found, was the problem.

    Before i solved it [all the following are in a normal not super-user Konsole]:
    Code:
    gooeygirl@linux-Tower:~> timeshift-launcher
    No protocol specified
    Unable to init server: Could not connect: Connection refused
    
    (timeshift-gtk:17818): Gtk-WARNING **: cannot open display: :0   ### ie, no GUI  :-( 
    gooeygirl@linux-Tower:~>
    My other account:
    Code:
    rachel@linux-Tower:~> timeshift-launcher
    App config loaded: /etc/timeshift.json
    
    ### At this point the GUI opened. Once i'd finished with it & closed it, this happened:
    
    App config saved: /etc/timeshift.json
    rachel@linux-Tower:~>
    My normal account after i solved it:
    Code:
    gooeygirl@linux-Tower:~> timeshift-launcher
    App config loaded: /etc/timeshift.json
    
    ### At this point the GUI opened. Once i'd finished with it & closed it, this happened:
    
    App config saved: /etc/timeshift.json
    gooeygirl@linux-Tower:~>
    Drumroll... this was the culprit:


    Isn't that strange? Simply changing to another GTK3 widget Theme from the indicated one, fixed it.

  10. #50
    Join Date
    Jun 2017
    Location
    Australia
    Posts
    582

    Default Re: Tower's BtrFS has gone ReadOnly... again... yet again.

    Quote Originally Posted by kensch View Post
    Sorry but I have to disagree with you here, you are NOT untalented at
    all just not educated enough in all aspects of linux. How can you expect
    yourself to be fluent in any operating system with just a few number of
    years usage.
    I started using *nix over 30 years ago and there is much I never learned.
    I believe you are doing a fantastic job so I for one give you a hearty
    pat on the back and say keep up the fantastic work. :-)

    --
    Ken
    linux since 1984
    S.u.S.E./openSUSE since 1996
    That's extremely kind & generous of you Ken, thanks very much for being so nice. My boundaries will never reach the dimensions i might wish for them, but i do want to keep earnestly trying to extend them as much as i can anyway. Learning is good, & Linux is fun as well as productive [sigh, if only i'd discovered it a couple of decades ago...]. I'm lucky that there's many people who are kind enough to help.

Page 5 of 6 FirstFirst ... 3456 LastLast

Posting Permissions

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