Snapshot restore issue

I edit my text , use

sudo timeshift-launcher

please.

❯ sudo timeshift-launcher

** (timeshift-gtk:3735): WARNING **: 19:02:52.247: Unable to connect to dbus: Error spawning command line “dbus-launch --autolaunch=12f3c70021084db7bef0fd5b9cb4ea58 --binary-syntax --close-stderr”: Child process exited with code 1
App config loaded: /etc/timeshift.json
Mounted '/dev/nvme0n1p2' at '/run/timeshift/backup'

(timeshift-gtk:3735): GLib-GIO-CRITICAL **: 19:02:52.479: g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
 
(timeshift-gtk:3735): GLib-GIO-CRITICAL **: 19:02:52.480: g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

(timeshift-gtk:3735): GLib-GIO-CRITICAL **: 19:02:52.480: g_dbus_connection_get_unique_name: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
App config saved: /etc/timeshift.json

Seems the </> dos not not work for you too.
Use three ~ in first and last line please. greetings SGS :slight_smile:

dbus error, IDK :frowning:

Maybe @librewish or @petsam know more.

Sorry.

Thanks for your efforts anyway @SGS

1 Like

Unfortunately, this rarely helps, but have you tried reinstalling timeshift.

I have searched your error and have seen several posts that suggested this may somehow be linked to fctix. Try uninstalling fctix, reboot and see what happens when starting timeshift again. Fctix is not critical and has been eliminated from the new ISO's I believe (so it can safely be uninstalled).

Hi and thanks for your help.
I have reinstalled timeshift and the error remains as you more or less predicted :slightly_smiling_face:
Also removing package fcitx presents a problem, maybe?
I.e. I presume you are referring to fcitx and not fctix?
I'm just not sure if I can uninstall fcitx with all these dependencies?

❯ sudo pacman -Rns fcitx
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing fcitx breaks dependency 'fcitx>=4.2.7' required by fcitx-configtool
:: removing fcitx breaks dependency 'fcitx' required by fcitx-m17n
:: removing fcitx breaks dependency 'fcitx' required by fcitx-qt5

❯ pactree -d 1 fcitx
fcitx
├─pango
├─libxinerama
├─gtk-update-icon-cache
├─shared-mime-info
├─hicolor-icon-theme
├─desktop-file-utils
├─libxkbfile
├─libxfixes
├─dbus
├─icu
└─libxkbcommon

More over, maybe I am dependent on fcitx seeing this post?
I had to use fcitx-config-gtk3 to set my Norwegian keyboard after everything else failed.
See here.

Can you confirm @librewish that I can safely remove the fcitx package with all it's dependencies to try to prevent the timeshift error?

You can remove fcitx
Via

sudo pacman -Rnsc fcitx

If it doesn't help you can always reinstall

sudo pacman -S garuda-fcitx

So now I have removed fcitx and the error message is still coming up after a restore.
Please advise further.

Or should I maybe just ignore this error message? The system is back to were I wanted it to go with the last restore anyway. So maybe the error message is not a problem.
I just whish I knew who,what when is displaying this error message.

Also, now I have two 'Before restoring...' snapshots with identical description.
Numbers 14 and 15.
This seems wrong.

❯ sudo timeshift --list
Mounted '/dev/nvme0n1p2' at '/run/timeshift/backup'
Device : /dev/nvme0n1p2
UUID   : 8344326d-e1fe-46c6-bf83-b03108b13786
Path   : /run/timeshift/backup
Mode   : BTRFS
Status : OK
16 snapshots, 212.0 GB free

Num     Name                 Tags  Description                                    
------------------------------------------------------------------------------
0    >  2020-10-15_23-00-01  D                                                    
1    >  2020-10-16_23-00-02  D                                                    
2    >  2020-10-17_23-00-01  D                                                    
3    >  2020-10-18_06-23-05  O     Before restoring '2020-10-16 23:12:47'         
4    >  2020-10-20_10-00-01  D                                                    
5    >  2020-10-21_13-00-01  D                                                    
6    >  2020-10-21_19-49-59  O     {timeshift-autosnap} {created before upgrade}  
7    >  2020-10-22_15-00-01  D                                                    
8    >  2020-10-22_16-11-41  O     {timeshift-autosnap} {created before upgrade}  
9    >  2020-10-23_10-33-41  O     {timeshift-autosnap} {created before upgrade}  
10   >  2020-10-23_15-00-01  D                                                    
11   >  2020-10-23_17-26-26  O     {timeshift-autosnap} {created before upgrade}  
12   >  2020-10-23_17-58-42  O     Before restoring '2020-10-23 17:26:26'         
13   >  2020-10-24_11-06-37  O     {timeshift-autosnap} {created before upgrade}  
14   >  2020-10-24_11-10-42  O     Before restoring '2020-10-24 11:06:37'         
15   >  2020-10-24_13-25-12  O     Before restoring '2020-10-24 11:06:37'

Well those are the snapshots of the system before you restored the snapshot.

As for error message can you give a screenshot of it ?

Its from timeshift

But i have never seen this

So dont know

1 Like

And you have followed the same steps as descibed in the Garuda Wiki?
I will try and see what happens if I do

sudo timeshift --restore --snapshot xxx.

Hmm, this gives error after logging in to the restored system.

Now I have made a change in the sudoers file:

sudo EDITOR=nano visudo 
## Uncomment to allow members of group wheel to execute any command
%wheel ALL=(ALL) ALL

And now the error message does not appear anymore after logging in to a restored snapshot.
Do you all have made this change in the sudoers file as well?

No, I use micro :slight_smile:

And only YOU have this problem so ...

"I never wanted to say this in this forum :wink: install from scratch or new as dualboot :slight_smile: and check the diffence then :slight_smile: ."

I don't mean if you all use nano in stead of micro,.
What I mean if you have made the relevant change in sudoers file.
So enabling wheel group users to execute any command by uncommenting the respective line in the sudoers file.

Do you really think that every user change this file first, after an installation?

sudo cat /etc/sudoers
## sudoers file.
##
## This file MUST be edited with the 'visudo' command as root.
## Failure to use 'visudo' may result in syntax or file permission errors
## that prevent sudo from running.
##
## See the sudoers man page for the details on how to write a sudoers file.
##

##
## Host alias specification
##
## Groups of machines. These may include host names (optionally with wildcards),
## IP addresses, network numbers or netgroups.
# Host_Alias	WEBSERVERS = www1, www2, www3

##
## User alias specification
##
## Groups of users.  These may consist of user names, uids, Unix groups,
## or netgroups.
# User_Alias	ADMINS = millert, dowdy, mikef

##
## Cmnd alias specification
##
## Groups of commands.  Often used to group related commands together.
# Cmnd_Alias	PROCESSES = /usr/bin/nice, /bin/kill, /usr/bin/renice, \
# 			    /usr/bin/pkill, /usr/bin/top
# Cmnd_Alias	REBOOT = /sbin/halt, /sbin/reboot, /sbin/poweroff

##
## Defaults specification
##
## You may wish to keep some of the following environment variables
## when running commands via sudo.
##
## Locale settings
# Defaults env_keep += "LANG LANGUAGE LINGUAS LC_* _XKB_CHARSET"
##
## Run X applications through sudo; HOME is used to find the
## .Xauthority file.  Note that other programs use HOME to find   
## configuration files and this may lead to privilege escalation!
# Defaults env_keep += "HOME"
##
## X11 resource path settings
# Defaults env_keep += "XAPPLRESDIR XFILESEARCHPATH XUSERFILESEARCHPATH"
##
## Desktop path settings
# Defaults env_keep += "QTDIR KDEDIR"
##
## Allow sudo-run commands to inherit the callers' ConsoleKit session
# Defaults env_keep += "XDG_SESSION_COOKIE"
##
## Uncomment to enable special input methods.  Care should be taken as
## this may allow users to subvert the command being run via sudo.
# Defaults env_keep += "XMODIFIERS GTK_IM_MODULE QT_IM_MODULE QT_IM_SWITCHER"
##
## Uncomment to use a hard-coded PATH instead of the user's to find commands
# Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
##
## Uncomment to send mail if the user does not enter the correct password.
# Defaults mail_badpass
##
## Uncomment to enable logging of a command's output, except for
## sudoreplay and reboot.  Use sudoreplay to play back logged sessions.
# Defaults log_output
# Defaults!/usr/bin/sudoreplay !log_output
# Defaults!/usr/local/bin/sudoreplay !log_output
# Defaults!REBOOT !log_output

##
## Runas alias specification
##

##
## User privilege specification
##
root ALL=(ALL) ALL

## Uncomment to allow members of group wheel to execute any command
# %wheel ALL=(ALL) ALL

## Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL

## Uncomment to allow members of group sudo to execute any command
# %sudo	ALL=(ALL) ALL

## Uncomment to allow any user to run sudo if they know the password
## of the user they are running the command as (root by default).
# Defaults targetpw  # Ask for the password of the target user
# ALL ALL=(ALL) ALL  # WARNING: only use this together with 'Defaults targetpw'

## Read drop-in files from /etc/sudoers.d
@includedir /etc/sudoers.d

No of course not :slight_smile:
I just wonder why I had this error message and now it's gone after I changed sudoers file.
So then I wondered if you developers have changed this file as well.
But I see in your file that you haven't.
Perhaps no other user has used timeshift restore or seen this error message.
I'm just wondering...

Me too :slight_smile:
I change nothing. Everything work.
I just wonder what you did or what you changed in advance? :wink:

So, your question "what you did or what you changed in advance" triggered me thinking of a modification in /etc/pam.d/sudo where I added a line as the 1st line to allow wheel group to use sudo without password

auth           sufficient      pam_wheel.so trust use_uid

Now I have deleted this line and also reverted sudoers file to original.
And hey, what do you think: no more error message after timeshift snapshot restore!

So now I'm "stuck" with having to enter the root password again with sudo at the command prompt.
Do you you have an alternative for this maybe?

1 Like

No.

Unfortunately I can't explain it well, in short ,
it makes sense to allow certain things only by previous (security) password request.
Even if almost everything is stored in the snapshot you can easily destroy the system, I can think of an example :wink: ?