Work Station, I get used to just shortening things, even though it can be maddening for me when others do it and I don’t know what they mean. Sorry.
haha no need to apologize. Thanks for your help!
hi @jakfrost
I have now run sudo flatpak repair --reinstall-all and in the Terminal output I got the following error which could be what you have suspected? What does this mean?
error: Failed to execute child process “dbus-launch” (No such file or directory)
That is a bug I think and likely you should report it or add your comments to the existing one Issues · fedora-silverblue/issue-tracker · GitHub. I’ll do some more digging in the meantime.
[Edit] try repair without any options. I cannot find Nautilus listed as a flatpak when I list apps and grep gnome. That likely means it is not a flatpak. Try running nautilus from a command line, then it might show some error(s) we can diagnose.
[Second edit] Nautilus is definitely not a flatpak. I launched it as just nautilus from the command line, then as nautilus dbus-launch which gave a number of errors, but ran. This makes me still think it is a Gnome issue, possibly dbus related, especially since Gedit (a flatpak) was also a problem for you.
I have tried opening Files from Terminal today using nautilus. Files starts up ok but once I close it it takes about 15 seconds for the cursor to return to the command prompt.
If I use nautilus dbus-launch it does open and I get dialogue popup:
Similarly there is a delay in return to command prompt on closing.
Not sure if this is useful info?
also posted an issue report as you suggested.
and noticed now my “software” app doesn’t open. Perhaps I did something to it yesterday? 
Good that you filed the bug. It sucks that SW now is not working. As for starting nautilus from the CLI I got basically the same message, both with and without using dbus-launch the difference I had was dbus-launch caused multiple pop-up error messages of the same type and without it I got only the one. Another thing I noticed when I did it was that in either case the terminal didn’t come back to the command prompt I had to ctrl C to get back to the prompt, but that could have been my impatience.
I also was impatient at first and tried Firefox as I haven’t had an issue with it and found it went back to the command prompt quickly. So I tried Nautilus again and it was just a matter of waiting longer for me.
Yeah, another thing about the dbus-launch method was it sure caused verbose messages in the terminal. Also, I am not certain it is normally a user level option, meaning usually I think apps request it during launch in Gnome, if they require dbus which they normally do. This may turn out to be a Gnome bug.
I didn’t get any verbose output with d-bus launch. By the way, I assume you meant SB - (silverblue) here?
Do you use Silverblue as your main machine or as a secondary machine? I’m just trying to get some work done in Writer and its going a bit funny which is frustrating so I hope they can sort this out.
SW=SoftWare, again with my habit of shortening things. I use Silverblue as my only Linux machine. I had early issues with it, which invariably were caused by me, but were sometimes legitimate bugs too. The biggest problem was the paradigm shift of how to setup my particular workflow. Gnome software is part of the base image, so if that is flaky, I think it is something Gnome related. I don’t know how much data you have already made, but my suggestion for progressing this from your end is to contemplate backing up your data and doing a fresh install. I know that is likely not the answer you were hoping for, but it may be your fastest route to happiness. There are times when I have had installs run through and something silently fail, you still can use the system but things get weird sometimes, could be an installer bug or could be my hardware (likely). It all detracts from the user experience if you cannot get to the root cause.
I have backups of the /etc and /var directories as I understand these are the only writable directories. Do you think the error would be in one of these directories (therefore i whole new install) or the base image?
No, I don’t really. But I would note some things about a Silverblue install. Aside from the fact /etc is mutable, it is also diffed by rpm-ostree to extract the differences between what is stored in /usr/etc and what you have in /etc during upgrades. The flatpaks you have installed, and if they were installed in the default method are system-wide, also store some info in the user home dir for persistence reasons. When you do an upgrade with rpm-ostree this is basically creating a local image from the base image fedora provides with your particular layering. So by using recent backups (of /etc and /var/home/user) you can copy those back onto a fresh install overwriting what is there. That’s all fine and dandy, you could also just do a re-install of the base image, leaving home intact, then copy your backed up /etc over. The drawback I see with that method is it involves custom partitioning during the installation process, something many are reluctant to do for obvious reasons.
I would say it is likely going to be a good point to focus on the image itself and try to repair your install without getting into re-install mode. In other words, I don’t think you are there yet, you can still boot your system and it mostly functions, with the exception of some flatpaks and Gnome apps. So let’s look at the rpm-ostree side of things and see if there is something you can do there to help yourself to reaching the happy to use Silverblue state.
So start with rpm-ostree cleanup -m to clear cached data and transactions that are pending or incomplete.
Then do rpm-ostree refresh-md to refresh you repo info.
Then do and rpm-ostree update to make sure you are up to date.
Then after that try sudo flatpak repair to see if your flatpak install get repaired.
I’ve completed those commands, restarted and have Software backup and running. No errors were obvious so fingers crossed it’s back up and running.
BTW, I found out the Writer issue (in this instance) was user error. Looks like I had accidentally put on track changes and right to left formatting somehow. Still not really used to LibreOffice!
LibreOffice is pretty good if you are more familiar with Word and other MS products. If you find it okay (your system) after a couple of days use,maybe close your issue with an explanation of what you found.
Glad to hear you’re up and running like you should be.
Just for curiosity, have you tried MarkText yet?
I’ve just downloaded Marktext. It seems to only open .txt files. My Bash scripts don’t have extensions so I can’t open them.
This sounds vaguely familiar. It might be a wayland/mutter issue, not a Silverblue issue. I’ve got a fairly consistent reproducer: move a portion of gedit off screen (less than half?) and start typing in the window. It’s somewhat transient, I haven’t figured out the exact pattern, but eventually I can trigger a hang where by nothing I type shows up until I try to reposition the window - and have first the repositioning also is unresponsive but once it responds, document contents are refreshed and everything I was typing, appears.
This never happens when the app is full screen. This is a bit tricky to track down, and likely requires some coordination with developers to get a proper gdb backtrace while the problem happens. It’s understandable if you can’t or don’t want to do that. But if you can come up with a pattern to reproduce the problem, it should be possible for someone to reproduce and capture the backtrace.
I’m actually getting setup to to that now with gedit.
That’s an interesting theory. I often have the windows not in the full screen state so the freezing happens enough that I could reproduce it.
You can open a folder with it. It understands languages such as bash. If you open your home dir, for example, it should show you everything in your home dir but not hidden files. If you use the search function you will be able to find them and open them.
And I always have my windows maxed and switch between workspaces, likely why I don’t come across this problem.