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

Uptime was just a couple of hours short of reaching 6 days, which would have been the first time it reached that threshold instead of its usual freezing or rebooting sometime during the 5th day. Alas, once more it did not make it, but this time it did damage. All temperatures were normal, cpu & RAM usage were low, no external power dip occurred, TW [20171125] had been behaving beautifully. Until…

…i needed to go to bed, so i went to Suspend TW. It did not respond. I tried again, thinking my click had not registered. It gave a warning message that a suspend job was already queued [not those exact words], but otherwise ignored me again. Fearing that this was the beginning of another crash, i began closing all my open docs & pgms, preparatory to doing a full shutdown. Each respective window duly closed, but KSysGuard showed their processes still ran & would not be manually killed when i tried therein]. I tried the Shutdown widget, initially which seemed to work, but then a TTY appeared instead of the desktop, & proceeded to fill with continuous error messages, mentioning that the write job was being ignored due to the read-only file system. Oh noooooooo, not that rotten problem *yet again!
*
After 15’ those errors just continued streaming along in TTY, so i did REISUB, to which it did respond. Upon the reboot all looked normal until i reached the passphrase screen to decrypt my /dev/sda3 & mount my /home. It accepted my passphrase, but almost immediately gave simply a blank screen with blinking top lhs cursor. This was repeatable. Groan.

Remembering the last time this [read-only filesystem] occurred, & what solved it, https://forums.opensuse.org/showthread.php/527390-BtrFS-has-gone-ReadOnly-again?p=2840121#post2840121, i attempted the same rescue… booted Tower from my Krypton USB, & tried the btrfs repair. It was not a good outcome this time:

linux@localhost:~> **sudo blkid**
/dev/sdc3: LABEL="hybrid" UUID="f232076a-c63b-424b-af27-a7a23b07a49a" TYPE="ext4" PARTUUID="c0bef442-03"
/dev/sdc2: UUID="2017-07-10-10-52-11-00" LABEL="\"openSUSE Krypton Stable\"" TYPE="iso9660" PARTUUID="c0bef442-02"
/dev/loop0: TYPE="squashfs"
/dev/sdb1: UUID="1be44f1e-8593-460e-91ab-c6132245f640" TYPE="crypto_LUKS" PARTUUID="00060756-01"
/dev/sda1: SEC_TYPE="msdos" UUID="DFF3-1AD7" TYPE="vfat" PARTLABEL="primary" PARTUUID="bde1c356-f603-4a7e-ad42-c399c35f9750"
/dev/sda2: LABEL="root" UUID="f3e11c85-7f1a-4e9e-8585-5b6a61e4ea8c" UUID_SUB="65ee96ef-42d9-4fe4-b96c-c57e868cc214" TYPE="btrfs" PARTLABEL="primary" PARTUUID="b56c2d68-cc5f-48e7-bbd0-2b981a6c602a"
/dev/sda3: UUID="a3869823-41e7-498d-abe7-84438db8f4af" TYPE="crypto_LUKS" PARTLABEL="primary" PARTUUID="d2fc8cea-af0e-446f-8a59-264cc59a1451"
/dev/sdb2: LABEL="SeagateSpare" UUID="f4ae6a8c-a541-4bbd-b086-6358872a3962" TYPE="xfs" PARTUUID="00060756-02"
/dev/sdb3: LABEL="Seagate" UUID="23927deb-03f4-4b7b-9599-9e44c9f86919" TYPE="ext4" PARTUUID="00060756-03"
/dev/sdc1: SEC_TYPE="msdos" LABEL="BOOT" UUID="BA91-72AD" TYPE="vfat" PARTUUID="c0bef442-01"


linux@localhost:~> **sudo btrfs check --repair /dev/sda2**
enabling repair mode
incorrect offsets 12731 12987
Checking filesystem on /dev/sda2
UUID: f3e11c85-7f1a-4e9e-8585-5b6a61e4ea8c
checking extents
incorrect offsets 12731 12987
incorrect offsets 12731 12987
Unable to find block group for 0
extent-tree.c:287: find_search_start: Warning: assertion `1` failed, value 1
btrfs(btrfs_reserve_extent+0x637)[0x55fbb2672527]
btrfs(btrfs_alloc_free_block+0x5f)[0x55fbb2672bbf]
btrfs(__btrfs_cow_block+0x182)[0x55fbb26632a2]
btrfs(btrfs_cow_block+0x10a)[0x55fbb2663aaa]
btrfs(btrfs_search_slot+0x2d3)[0x55fbb2666683]
btrfs(+0x1b000)[0x55fbb265e000]
btrfs(+0x1c275)[0x55fbb265f275]
btrfs(+0x1c8b9)[0x55fbb265f8b9]
btrfs(cmd_check+0xaf3)[0x55fbb26a77b3]
btrfs(main+0x84)[0x55fbb2661e34]
/lib64/libc.so.6(__libc_start_main+0xea)[0x7f39ca2f346a]
btrfs(_start+0x2a)[0x55fbb2661f4a]
Unable to find block group for 0
extent-tree.c:287: find_search_start: Warning: assertion `1` failed, value 1
btrfs(btrfs_reserve_extent+0x637)[0x55fbb2672527]
btrfs(btrfs_alloc_free_block+0x5f)[0x55fbb2672bbf]                                                                                                                                           
btrfs(__btrfs_cow_block+0x182)[0x55fbb26632a2]                                                                                                                                               
btrfs(btrfs_cow_block+0x10a)[0x55fbb2663aaa]                                                                                                                                                 
btrfs(btrfs_search_slot+0x2d3)[0x55fbb2666683]                                                                                                                                               
btrfs(+0x1b000)[0x55fbb265e000]                                                                                                                                                              
btrfs(+0x1c275)[0x55fbb265f275]                                                                                                                                                              
btrfs(+0x1c8b9)[0x55fbb265f8b9]                                                                                                                                                              
btrfs(cmd_check+0xaf3)[0x55fbb26a77b3]                                                                                                                                                       
btrfs(main+0x84)[0x55fbb2661e34]                                                                                                                                                             
/lib64/libc.so.6(__libc_start_main+0xea)[0x7f39ca2f346a]                                                                                                                                     
btrfs(_start+0x2a)[0x55fbb2661f4a]                                                                                                                                                           
Unable to find block group for 0                                                                                                                                                             
extent-tree.c:287: find_search_start: Warning: assertion `1` failed, value 1                                                                                                                 
btrfs(btrfs_reserve_extent+0x637)[0x55fbb2672527]
btrfs(btrfs_alloc_free_block+0x5f)[0x55fbb2672bbf]
btrfs(__btrfs_cow_block+0x182)[0x55fbb26632a2]
btrfs(btrfs_cow_block+0x10a)[0x55fbb2663aaa]
btrfs(btrfs_search_slot+0x2d3)[0x55fbb2666683]
btrfs(+0x1b000)[0x55fbb265e000]
btrfs(+0x1c275)[0x55fbb265f275]
btrfs(+0x1c8b9)[0x55fbb265f8b9]
btrfs(cmd_check+0xaf3)[0x55fbb26a77b3]
btrfs(main+0x84)[0x55fbb2661e34]
/lib64/libc.so.6(__libc_start_main+0xea)[0x7f39ca2f346a]
btrfs(_start+0x2a)[0x55fbb2661f4a]
extent-tree.c:2696: btrfs_reserve_extent: BUG_ON `ret` triggered, value -28
btrfs(+0x2a5f6)[0x55fbb266d5f6]
btrfs(btrfs_reserve_extent+0x94b)[0x55fbb267283b]
btrfs(btrfs_alloc_free_block+0x5f)[0x55fbb2672bbf]
btrfs(__btrfs_cow_block+0x182)[0x55fbb26632a2]
btrfs(btrfs_cow_block+0x10a)[0x55fbb2663aaa]
btrfs(btrfs_search_slot+0x2d3)[0x55fbb2666683]
btrfs(+0x1b000)[0x55fbb265e000]
btrfs(+0x1c275)[0x55fbb265f275]
btrfs(+0x1c8b9)[0x55fbb265f8b9]
btrfs(cmd_check+0xaf3)[0x55fbb26a77b3]
btrfs(main+0x84)[0x55fbb2661e34]
/lib64/libc.so.6(__libc_start_main+0xea)[0x7f39ca2f346a]
btrfs(_start+0x2a)[0x55fbb2661f4a]
Aborted
linux@localhost:~> 

The only bit of good fortune i had this time, was the surprise discovery that Krypton actually gave me access to my encrypted /home. It was literally as simple as navigating to that partition in Dolphin, clicking on it, & entering my passphrase into the resultant popup dialog box. Thank goodness!. So i have therefore been able to copy all my data to “/dev/sdb2: LABEL=“SeagateSpare”” temporarily, & am now [3:10am] going to bed.

Unless something happens in my dreams to change my mind, tomorrow i shall be ending my five month Tumbleweed dalliance. On both my Tower & Laptop there’s just been too many of these stressful serious incidents. TW’s Plasma5 runs superbly for a while, then out of the blue has a meltdown & gives me apoplexy, then the pattern repeats. My laptop stopped being TW two weeks ago after its last catastrophe, which lost all data [https://forums.opensuse.org/showthread.php/528173-Laptop-cpu-suddenly-went-to-99-now-can-boot-but-not-login?p=2845862#post2845862]. Tomorrow i regretfully think TW will be over too, for Tower. It’s sad.

No meltdown or even minor annoyances with several installations since one year when using ext4. Btrfs is complex. With the experience gained in those months starting again with ext4 is easy and straight forward.Tumbleweed is rock stable when sticking to KISS.

(1) ext4
(2) really wondering if your hardware is flaky

Re-install with ext4, and if you are still having problems, you really really need to have a closer look at the hardware. Hardware can be super tricky sometimes, unfortunately. TW is just another distro. You could install any other distro w/btrfs also, and then you’d likely have the same problems. TW is really nice, just admit it, and use ext4 instead.

Hi
I wonder about the hardware as well, Samsung SSD’s have numerous google hits with issues (some are still blacklisted and can have issues with controllers), but also wonder if it’s the encryption?

As other suggest try ext4 and see how it goes?

Thanks to each of you.

Re potential Tower hardware root cause of this cumulative episodic pain, obviously i cannot be certain that it’s not h/w, but i offer these thoughts to potentially counter that proposition:
[ol]
[li]I have had TW meltdowns on both Tower and Lappy. The only reason IMO why more of my threads have been for Tower than Lappy, is that Tower is my primary pc & is in constant use day & many nights, whereas Lappy being my secondary pc has much lighter & less frequent use.[/li][li]In previous threads where opinion had been offered by helpers suspecting my Tower’s h/w, each time i ran tests no faults were found.[/li][li]In my early months of TW i didn’t note when many of the frequent TW freezes or self-reboots occurred [those frequent events usually did not (appear to) cause the serious problems like now; the events like now whilst still too many, have been rarer]. However for the past month i have specifically logged when those irritant events [TW freezes or self-reboots] occurred, & the pattern has been amazing. They occur sometime during the 5th Uptime day… sometimes early, sometimes late [like last night, which very nearly made it to 6 days]. So pls help me understand… what kind of hardware defect can lie dormant [else incrementally accumulate] & then only go boom on the 5th day each time? In my mind such cyclic behaviour is more consistent with a s/w-based defect… indeed it’s almost like there is some “system resource” which gets depleted slowly & attains the critical threshold each 5th Uptime day.[/li][/ol]

Re potential TW BtrFS root cause of this cumulative episodic pain:
[ol]
[li]In several previous threads of mine, & also sometimes as a comment i’ve posted in others’ threads, i have effusively praised BtrFS, because it allows me to have Snapper, which i think is magically wonderful & a major argument in favour of using TW. Though obviously i still do not know the root cause, i now feel sufficiently beaten down by all these hassles that i can no longer defend BtrFS, & i definitely no longer want to use it [though i acknowledge again that this might not be a BtrFS problem].[/li][li]But TW was my first-ever rolling release, & a really major part of my deliberations back in June when i investigated it as a candidate distro for me, was Snapper with its fantastic rollback function. I comforted myself with the logic that if TW’s frequent rolling upgrades ever broke my system, i could rescue myself via Snapper [& indeed i have done so a few times now]. Hence the prospect of potentially staying today with a new-install TW [instead of replacing it with Manjaro KDE like is on my Lappy since its recent TW catastrophe] but without Snapper [ie, ext4 instead of BtrFS], quite alarms me. My TW metaphor has always been that i feel like i’m high up in the air on a tightrope, but i am safe there because openQA is my safety-harness & Snapper is my strong safety-net. No Snapper, no safety-net…[/li][li]I accept & acknowledge that some of you have enjoyed solid reliable TW behaviour over the long-term, using ext4 not BtrFS for root. However others [eg, Malcolm, from memory] have written that BtrFS for them has been solidly reliable. Clearly my experience now since June, in two TW machines, has fallen well short of that.[/li][/ol]

When i awoke this morning i was determined that i was going to replace Tower’s TW with Manjaro KDE [& install Timeshift for a quasi-Snapper capability]. Reading your kind replies has given me pause, albeit i’m probably still 70-30 or maybe 60-40 for leaving still. I will drink more coffee, do more pondering, & make a decision in an hour or two.

Hi
Well I can only go on using btrfs for years now on SSD’s (steered clear of Intel and Samsung) without major hiccups (six machines in daily use), snapper was the beast in the beginning but now is tamed…

I don’t use encryption, so one wonders about that…? No issues with Tumbleweed on the MacBook, but it’s not used all the time, mainly for testing packages I build/maintain.

Thanks Malcolm

I have decided to give TW … One. More. Chance. It’s installing again now, but with these conditions of my decision:
[ol]
[li]Though i feel very conflicted about this, i have changed root from BtrFS to ext4. Root remains unencrypted. It’s still on the Samsung SSD.[/li][li]I’ve continued with [ie, am reusing] my separate LUKS /home, still as xfs, & still on the Samsung SSD.[/li][li]I accepted the Ruby Installer’s nomination of a 2 GB Swap partition at the end of the SSD. I’ve also made it LUKS.[/li][li]I have deleted the previous 4 GB LUKS Swap partition on the Seagate HDD.[/li][li]I’ve retained my existing ext4 “other” data partitions on the Seagate HDD.[/li][li]I’ve mounted tmpfs to /tmp [or vice versa, sigh, i still get muddled on this], & allocated a max of 8 GB of my 32 GB RAM to it [an increase from the previous 2 GB, just in case the historic crashes somehow had anything to do with running out of /tmp space, despite the total absence of any evidence of that].[/li][li]I have made no other changes to fstab, & post-installation i intend to make no changes to any of the parameters i’ve historically customised, eg, trim, access time, cache pressure, swappiness et al [this is so that in the event of another meltdown there can be no possibility that it was some dumb error of mine that caused it].[/li][li]I seriously considered dumping the /home encryption as well as root’s BtrFS, but decided to retain LUKS based on (a) the scientific principle of changing only one variable at a time, during experiments, (b) i expect my distro to fully & reliably support /home encryption, & if it cannot, then i’m going to dump the distro not the encryption.[/li][li]This really is TW’s last chance. After today, if there’s even one dup that breaks my system in a non-trivial way that i cannot easily rectify [given i now have no Snapper Rollback safety-net, & as far as i currently know there is no TW package for Timeshift], or if there’s any ongoing continuation of “5th Day freeze/auto-reboot”, & of course if there’s one more blue-sky meltdown, then TW will be replaced.[/li][/ol]

Fingers crossed.

Hi
Can build timeshift if you want… doesn’t look like any issues…
https://github.com/teejee2008/timeshift

#6: adds complexity without much benefit. KISS applied to partitioning:

erlangen:~ # cat /etc/fstab
UUID=96e71675-528a-4474-87de-3eb705c0c145 swap                 swap       defaults              0 0
UUID=8b190950-c141-4351-9198-7a9592b4fb34 /                    ext4       noatime,acl           1 1
UUID=704621ef-9b45-4e96-ba7f-1becd3924f08 /home                ext4       noatime,acl           1 2
# archive
UUID=f5177cae-4082-44ed-9471-b99030f06866 /home-HDD            ext4       noatime,acl           0 0
# backup system
UUID=dbc33c75-0fbb-4619-add6-d204ecf63a43 /Leap-42.3           ext4       ro,noatime,acl        0 0
erlangen:~ # 
erlangen:~ # df -ht ext4
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2   32G   15G   16G  49% /
/dev/nvme0n1p3  407G  155G  251G  39% /home
/dev/sda3        32G  8.9G   22G  30% /Leap-42.3
/dev/sda4       3.6T  1.6T  2.0T  45% /home-HDD
erlangen:~ # 

If NVMe fails detach its cable and the machine will boot into Leap-42.3, thus allowing for a very comfortable disaster recovery. /home is mirrored to /home-HDD with user data being available in case of meltdown of /home and allowing for emergency operation.

#7: you definitely need trim, verify:

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:~ # 

As displayed in the signature both of my recent machines are running on Samsung SSDs. The 840 showed some degradation in performance and recovered after firmware update. The 850 (10,000h) and 950 (4,000h) are working from the shelf and never exhibited any problems.

erlangen:~ # smartctl -x /dev/nvme0n1
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.14.2-1-default] (SUSE RPM)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 950 PRO 512GB
Serial Number:                      S2GMNX0H609998K
Firmware Version:                   1B0QBXX7
PCI Vendor/Subsystem ID:            0x144d
IEEE OUI Identifier:                0x002538
Controller ID:                      1
Number of Namespaces:               1
Namespace 1 Size/Capacity:          512,110,190,592 [512 GB]
Namespace 1 Utilization:            229,157,601,280 [229 GB]
Namespace 1 Formatted LBA Size:     512
Local Time is:                      Wed Dec  6 06:33:34 2017 CET
Firmware Updates (0x06):            3 Slots
Optional Admin Commands (0x0007):   Security Format Frmw_DL
Optional NVM Commands (0x001f):     Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat
Maximum Data Transfer Size:         32 Pages

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     6.50W       -        -    0  0  0  0        5       5
 1 +     5.80W       -        -    1  1  1  1       30      30
 2 +     3.60W       -        -    2  2  2  2      100     100
 3 -   0.0700W       -        -    3  3  3  3      500    5000
 4 -   0.0050W       -        -    4  4  4  4     2000   22000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         0

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

SMART/Health Information (NVMe Log 0x02, NSID 0x1)
Critical Warning:                   0x00
Temperature:                        34 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    7,335,906 [3.75 TB]
Data Units Written:                 8,043,907 [4.11 TB]
Host Read Commands:                 75,794,937
Host Write Commands:                132,239,677
Controller Busy Time:               855
Power Cycles:                       528
Power On Hours:                     4,356
Unsafe Shutdowns:                   34
Media and Data Integrity Errors:    0
Error Information Log Entries:      254

Errors occur at boot time and are benign.

[Ext4] TW is now reinstalled & running, with all my data still available, but of course none of my pgms… so that takes care of the next few hours for me today. I must say - i was momentarily taken aback at the boot menu screen; something looked “missing” from what it usually has looked like, which of course is true… no Snapper item now… sob, sniff.

Thanks for the GitHub link Malcolm, that’s marvellous.

**Other Linux Distributions
**
Download the .RUN installer from [Releases](https://github.com/teejee2008/Timeshift/releases) page and execute it in a terminal window:
sudo sh ./timeshift*amd64.run # 64-bit
sudo sh ./timeshift*i386.run  # 32-bit
Installer can be used on the following distribution types:



  - RedHat based - Fedora, RedHat, Cent OS, etc (supports dnf and yum)
  - Debian based - Debian, Ubuntu, Linux Mint, Elementary OS, etc (supports apt)
  - Arch based - Arch Linux, Manjaro, etc (supports pacman)



Once i have reinstalled my pgms i shall indeed try my hand at this. It would be lovely if i can have Timeshift in TW, given my loss of Snapper. Not as good, i know, but much better than nothing. Should i be worried that the quote above does not mention SUSE / openSUSE wrt compatibility?

Thanks Karl. Your info as usual is interesting & helpful. OK, i shall add Trim back onto my To Do list… Ha.

So even though i’m now using ext4 like you for root, if i understand correctly i’m different on /home, as yours is not encrypted…? Therefore, your earlier advice to me that your high-reliability TW experience with ext4 is still not an analogue to my system now, given i still have the partial encryption, ie, i suppose theoretically another failure vector. Time will tell…

Oh well. Decided to try it first, not later, but…

gooeygirl@linux-35ka:/run/media/gooeygirl/COMSOL-B> **sudo sh ./timeshift-v17.11-amd64.run**


We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:


    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.


[sudo] password for root: 
Verifying archive integrity... All good.
Uncompressing Timeshift (amd64)  100%  
==============================================================================
Installing files...
==============================================================================
/usr
/usr/bin
/usr/share
/usr/share/polkit-1
/usr/share/polkit-1/actions
/usr/share/locale
/usr/share/locale/fr
/usr/share/locale/fr/LC_MESSAGES
/usr/share/locale/hi
/usr/share/locale/hi/LC_MESSAGES
/usr/share/locale/vi
/usr/share/locale/vi/LC_MESSAGES
/usr/share/locale/uk
/usr/share/locale/uk/LC_MESSAGES
/usr/share/locale/ro
/usr/share/locale/ro/LC_MESSAGES
/usr/share/locale/ko
/usr/share/locale/ko/LC_MESSAGES
/usr/share/locale/cs
/usr/share/locale/cs/LC_MESSAGES
/usr/share/locale/pt_BR
/usr/share/locale/pt_BR/LC_MESSAGES
/usr/share/locale/ia
/usr/share/locale/ia/LC_MESSAGES
/usr/share/locale/ar
/usr/share/locale/ar/LC_MESSAGES                                                                             
/usr/share/locale/tr                                                                                         
/usr/share/locale/tr/LC_MESSAGES                                                                             
/usr/share/locale/da                                                                                         
/usr/share/locale/da/LC_MESSAGES                                                                             
/usr/share/locale/el
/usr/share/locale/el/LC_MESSAGES
/usr/share/locale/hu
/usr/share/locale/hu/LC_MESSAGES
/usr/share/locale/sv
/usr/share/locale/sv/LC_MESSAGES
/usr/share/locale/en_GB
/usr/share/locale/en_GB/LC_MESSAGES
/usr/share/locale/lt
/usr/share/locale/lt/LC_MESSAGES
/usr/share/locale/et
/usr/share/locale/et/LC_MESSAGES
/usr/share/locale/id
/usr/share/locale/id/LC_MESSAGES
/usr/share/locale/am
/usr/share/locale/am/LC_MESSAGES
/usr/share/locale/az
/usr/share/locale/az/LC_MESSAGES
/usr/share/locale/pt
/usr/share/locale/pt/LC_MESSAGES
/usr/share/locale/zh_CN
/usr/share/locale/zh_CN/LC_MESSAGES
/usr/share/locale/ru
/usr/share/locale/ru/LC_MESSAGES
/usr/share/locale/es
/usr/share/locale/es/LC_MESSAGES
/usr/share/locale/is
/usr/share/locale/is/LC_MESSAGES
/usr/share/locale/ca
/usr/share/locale/ca/LC_MESSAGES
/usr/share/locale/it
/usr/share/locale/it/LC_MESSAGES
/usr/share/locale/ne
/usr/share/locale/ne/LC_MESSAGES
/usr/share/locale/nb
/usr/share/locale/nb/LC_MESSAGES
/usr/share/locale/hr
/usr/share/locale/hr/LC_MESSAGES
/usr/share/locale/pl
/usr/share/locale/pl/LC_MESSAGES
/usr/share/locale/eu
/usr/share/locale/eu/LC_MESSAGES
/usr/share/locale/sr
/usr/share/locale/sr/LC_MESSAGES
/usr/share/locale/nl
/usr/share/locale/nl/LC_MESSAGES
/usr/share/locale/sk
/usr/share/locale/sk/LC_MESSAGES
/usr/share/locale/bg
/usr/share/locale/bg/LC_MESSAGES
/usr/share/locale/he
/usr/share/locale/he/LC_MESSAGES
/usr/share/locale/de
/usr/share/locale/de/LC_MESSAGES
/usr/share/applications
/usr/share/doc
/usr/share/doc/timeshift
/usr/share/man
/usr/share/man/man1
/usr/share/timeshift
/usr/share/timeshift/libs
/usr/share/timeshift/images
/usr/share/appdata
/usr/share/icons
/usr/share/icons/hicolor
/usr/share/icons/hicolor/128x128
/usr/share/icons/hicolor/128x128/apps
/usr/share/icons/hicolor/16x16
/usr/share/icons/hicolor/16x16/apps
/usr/share/icons/hicolor/96x96
/usr/share/icons/hicolor/96x96/apps
/usr/share/icons/hicolor/32x32
/usr/share/icons/hicolor/32x32/apps
/usr/share/icons/hicolor/22x22
/usr/share/icons/hicolor/22x22/apps
/usr/share/icons/hicolor/64x64
/usr/share/icons/hicolor/64x64/apps
/usr/share/icons/hicolor/24x24
/usr/share/icons/hicolor/24x24/apps
/usr/share/icons/hicolor/48x48
/usr/share/icons/hicolor/48x48/apps
/etc
/etc/default
/usr/bin/timeshift-launcher
/usr/bin/timeshift-gtk
/usr/bin/timeshift-uninstall
/usr/bin/timeshift
/usr/share/polkit-1/actions/in.teejeetech.pkexec.timeshift.policy
/usr/share/locale/fr/LC_MESSAGES/timeshift.mo
/usr/share/locale/hi/LC_MESSAGES/timeshift.mo
/usr/share/locale/vi/LC_MESSAGES/timeshift.mo
/usr/share/locale/uk/LC_MESSAGES/timeshift.mo
/usr/share/locale/ro/LC_MESSAGES/timeshift.mo
/usr/share/locale/ko/LC_MESSAGES/timeshift.mo
/usr/share/locale/cs/LC_MESSAGES/timeshift.mo
/usr/share/locale/pt_BR/LC_MESSAGES/timeshift.mo
/usr/share/locale/ia/LC_MESSAGES/timeshift.mo
/usr/share/locale/ar/LC_MESSAGES/timeshift.mo
/usr/share/locale/tr/LC_MESSAGES/timeshift.mo
/usr/share/locale/da/LC_MESSAGES/timeshift.mo
/usr/share/locale/el/LC_MESSAGES/timeshift.mo
/usr/share/locale/hu/LC_MESSAGES/timeshift.mo
/usr/share/locale/sv/LC_MESSAGES/timeshift.mo
/usr/share/locale/en_GB/LC_MESSAGES/timeshift.mo
/usr/share/locale/lt/LC_MESSAGES/timeshift.mo
/usr/share/locale/et/LC_MESSAGES/timeshift.mo
/usr/share/locale/id/LC_MESSAGES/timeshift.mo
/usr/share/locale/am/LC_MESSAGES/timeshift.mo
/usr/share/locale/az/LC_MESSAGES/timeshift.mo
/usr/share/locale/pt/LC_MESSAGES/timeshift.mo
/usr/share/locale/zh_CN/LC_MESSAGES/timeshift.mo
/usr/share/locale/ru/LC_MESSAGES/timeshift.mo
/usr/share/locale/es/LC_MESSAGES/timeshift.mo
/usr/share/locale/is/LC_MESSAGES/timeshift.mo
/usr/share/locale/ca/LC_MESSAGES/timeshift.mo
/usr/share/locale/it/LC_MESSAGES/timeshift.mo
/usr/share/locale/ne/LC_MESSAGES/timeshift.mo
/usr/share/locale/nb/LC_MESSAGES/timeshift.mo
/usr/share/locale/hr/LC_MESSAGES/timeshift.mo
/usr/share/locale/pl/LC_MESSAGES/timeshift.mo
/usr/share/locale/eu/LC_MESSAGES/timeshift.mo
/usr/share/locale/sr/LC_MESSAGES/timeshift.mo
/usr/share/locale/nl/LC_MESSAGES/timeshift.mo
/usr/share/locale/sk/LC_MESSAGES/timeshift.mo
/usr/share/locale/bg/LC_MESSAGES/timeshift.mo
/usr/share/locale/he/LC_MESSAGES/timeshift.mo
/usr/share/locale/de/LC_MESSAGES/timeshift.mo
/usr/share/applications/timeshift-gtk.desktop
/usr/share/doc/timeshift/changelog.gz
/usr/share/doc/timeshift/copyright
/usr/share/timeshift/images/include.png
/usr/share/timeshift/images/folder-symbolic.svg
/usr/share/timeshift/images/unlocked.png
/usr/share/timeshift/images/donate.svg
/usr/share/timeshift/images/clock.png
/usr/share/timeshift/images/list-add.png
/usr/share/timeshift/images/media-optical.png
/usr/share/timeshift/images/document-save-symbolic.svg
/usr/share/timeshift/images/item-gray.png
/usr/share/timeshift/images/timeshift-shield-high.svg
/usr/share/timeshift/images/list-remove.png
/usr/share/timeshift/images/item-blue.png
/usr/share/timeshift/images/timeshift-shield-med.svg
/usr/share/timeshift/images/item-green.png
/usr/share/timeshift/images/item-red.png
/usr/share/timeshift/images/disk.png
/usr/share/timeshift/images/locked.png
/usr/share/timeshift/images/emblem-default-symbolic.svg
/usr/share/timeshift/images/open-menu-symbolic.svg
/usr/share/timeshift/images/preferences-system-symbolic.svg
/usr/share/timeshift/images/edit-delete.png
/usr/share/timeshift/images/document-open-recent-symbolic.svg
/usr/share/timeshift/images/exclude.png
/usr/share/timeshift/images/drive-harddisk.svg
/usr/share/timeshift/images/item-yellow.png
/usr/share/timeshift/images/gtk-file.png
/usr/share/timeshift/images/edit-delete-symbolic.svg
/usr/share/timeshift/images/timeshift-shield-low.svg
/usr/share/appdata/timeshift.appdata.xml
/usr/share/icons/hicolor/128x128/apps/timeshift.png
/usr/share/icons/hicolor/16x16/apps/timeshift.png
/usr/share/icons/hicolor/96x96/apps/timeshift.png
/usr/share/icons/hicolor/32x32/apps/timeshift.png
/usr/share/icons/hicolor/22x22/apps/timeshift.png
/usr/share/icons/hicolor/64x64/apps/timeshift.png
/usr/share/icons/hicolor/24x24/apps/timeshift.png
/usr/share/icons/hicolor/48x48/apps/timeshift.png
/etc/default/timeshift.json
==============================================================================
Installing dependency packages...
==============================================================================
Dist Type: Debian / Ubuntu
Package Manager: apt-get
E: Failed to execute child process “dpkg” (No such file or directory)


(process:5836): GLib-CRITICAL **: g_strsplit: assertion 'string != NULL' failed
E: Failed to execute child process “apt-cache” (No such file or directory)


(process:5836): GLib-CRITICAL **: g_strsplit: assertion 'string != NULL' failed
Installed: 0
Available: 0
Nothing to install
E: Failed to execute child process “dpkg” (No such file or directory)


(process:5836): GLib-CRITICAL **: g_strsplit: assertion 'string != NULL' failed
E: Failed to execute child process “apt-cache” (No such file or directory)


(process:5836): GLib-CRITICAL **: g_strsplit: assertion 'string != NULL' failed
Installed: 0
Available: 0
==============================================================================
Installation completed
==============================================================================
Following packages could not be installed. Please install these manually:
 > libgee-0.8-2
 > libvte-2.91-0
 > libjson-glib-1.0-0
 > rsync
------------------------------------------------------------------------------
Start the application using shortcut in Applications Menu
Or execute the command: timeshift-launcher
------------------------------------------------------------------------------
gooeygirl@linux-35ka:/run/media/gooeygirl/COMSOL-B> sudo zypper in rsync libjson-glib-1.0-0 libvte-2.91-0 libgee-0.8-2
Loading repository data...
Reading installed packages...
'rsync' is already installed.
No update candidate for 'rsync-3.1.2-6.1.x86_64'. The highest available version is already installed.
'libgee-0.8-2' not found in package names. Trying capabilities.
No provider of 'libgee-0.8-2' found.
'libjson-glib-1.0-0' not found in package names. Trying capabilities.
No provider of 'libjson-glib-1.0-0' found.
'libvte-2.91-0' not found in package names. Trying capabilities.
No provider of 'libvte-2.91-0' found.
Resolving package dependencies...


Nothing to do.
gooeygirl@linux-35ka:/run/media/gooeygirl/COMSOL-B> 



Later on [another day] i shall try to build it from scratch with the source code at GitHub; that will be an interesting challenge for me.

Karl

The 840 showed some degradation in performance and recovered after firmware update.

This touches on something i have wondered about for over a year [ie, long before i began using TW]. In neither my Lappy or Tower have i ever upgraded any FW… partly because i don’t understand how to do that in Linux [all guides i’d read on the process seem to rely on using Windows], & partly coz of fear of bricking one or both machine/s.

From your comment it’s obvious that you know how to do it successfully. Would you mind pls giving me some ideas how to do it, or links to some good articles on it?

I wonder about this in the context of my problems… can bad FW cause random misbehaviour like several of my threads have described?

  1. Backup your data
  2. Verify the backup
  3. Download iso, burn to rewritable cd and boot from that: Tool & Software Download | Samsung Semiconductor Global presumably ISO EXT0DB6Q
  4. Boot Tumbleweed and check performance: hdparm -tT /dev/sda or whatever your device is

I wonder about this in the context of my problems… can bad FW cause random misbehaviour like several of my threads have described?
To my experience anything can happen. I am learning since 1976: https://www.youtube.com/watch?v=8O0swCd6O20

Hi
Here you go… an openSUSE one :wink:


zypper in https://download.opensuse.org/repositories/home:/malcolmlewis:/TESTING/openSUSE_Tumbleweed/x86_64/timeshift-17.11+git20171129-1.1.x86_64.rpm

Please test, if works as expected, then will push to the Archiving development repo…

Yes, even snapper is not a replacement for backups to separate media.

Haha, the washing machine. I was a cadet engineer back then, & i thought that tech was so awesome that i must have been in a sci-fi movie. Now it’s just hilarious.

Unfortunately i cannot access that Samsung link, with multiple browsers. That’s odd.
https://s18.postimg.org/smbxv8fs9/20171207_002.png

OMZ, you made this just for me? That’s sensational; thanks for your kindness. Later today i shall test it & let you know.

I don’t think i understand the point you’re making. Never have i confused system snapshots & rollbacks, with the entirely different issue of my data backups.

For the record, the reason i valued Snapper so highly, & why i’m now excited at the possibility of Timeshift availability [care of Malcolm’s generosity], is that once TW is [re]installed, it then always takes me several hours to have it fully operational wrt having ALL my many pgms [re]installed [including resolving the ugly & stressful dependency conundrums]. Yesterday it was not til night that i finished that task, & i still have multiple loose ends to tidy up. All that time & effort would be avoided with Snapper / [potentially] Timeshift. Maybe nobody else feels this way, but IMO running a rolling-release distro without a tool for system recovery makes me feel naked & vulnerable.

Try that:

karl@erlangen:~> curl -Iv http://www.samsung.com/semiconductor/minisite/ssd/download/tools.html
*   Trying 23.35.102.192...
* TCP_NODELAY set
* Connected to www.samsung.com (23.35.102.192) port 80 (#0)
> HEAD /semiconductor/minisite/ssd/download/tools.html HTTP/1.1
> Host: www.samsung.com
> User-Agent: curl/7.57.0
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 64099
Content-Length: 64099
< Date: Thu, 07 Dec 2017 05:18:49 GMT
Date: Thu, 07 Dec 2017 05:18:49 GMT
< Connection: keep-alive
Connection: keep-alive
< Set-Cookie: country_codes=de; path=/; domain=.samsung.com
Set-Cookie: country_codes=de; path=/; domain=.samsung.com
< Set-Cookie: device_type=pc; path=/; domain=.samsung.com
Set-Cookie: device_type=pc; path=/; domain=.samsung.com

< 
* Connection #0 to host www.samsung.com left intact
karl@erlangen:~>