Mr Chandy Comments - Answer Overflow

Topics

Mr Chandy

UBUniversal Blue

•Created by Mr.Gravity on 3/6/2025 in #🛟bazzite-help

Xx 9070 xXT support

Ok I think this is definitely something related to the Fish shell and my ignorance on what I'm doing. On testing-42.20250418.2 I installed the Fish shell, and set it to my default. When going through the documentation I saw you could change the hostname of the system, which on the testing release of bazzite is set to "fedora". Which I wanted to change back to "bazzite", like how the stable release is set. I didn't immediately see a problem, Fish seemed to set the hostname to "bazzite" no problem, and likely updated the /etc/hostname file since I didn't experience any issues with distrobox in between changing the hostname and upgrading. When I went to upgrade to testing-42.20250423.4 something about how I changed the hostname didn't work right with the new image. Causing the /etc/hostname file to not be created. Using hostnamectl on the upgraded image to see the hostnames, the static and transient hostnames differed.

hostnamectl status
     Static hostname: (unset)                             
  Transient hostname: bazzite

hostnamectl status
     Static hostname: (unset)                             
  Transient hostname: bazzite

hostnamectl provides a tool to change the hostname, so I gave that a shot.

hostnamectl hostname bazzite --static
  hostnamectl status
     Static hostname: bazzite

hostnamectl hostname bazzite --static
  hostnamectl status
     Static hostname: bazzite

Now the transient hostname is gone, and it created the /etc/hostname file for me. But this file is readable. So likely this isn't a fix. And will likely not be persistent. TLDR: If you are looking for 9070 stuff don't bother reading this. I simply wrote down a problem I experienced that I initially thought could be 9070 or testing release related.

1427 replies

UBUniversal Blue

•Created by Mr.Gravity on 3/6/2025 in #🛟bazzite-help

Xx 9070 xXT support

Enabling login shell def did not fix it. And yeah it's def not 9070 related, but I'll write down what I've found for anyone else that faces the same issue. My testing-42.20250423.4 did not have a /etc/hostname file at all. Which from my googleing is needed to let containers talk with the host system.

Error: unable to start container "": crun: cannot stat `/etc/hostname`: No such file or directory: OCI runtime attempted to invoke a command that was not found

Error: unable to start container "": crun: cannot stat `/etc/hostname`: No such file or directory: OCI runtime attempted to invoke a command that was not found

Went to my testing-42.20250418.2 /etc folder and sure enough /etc/hostname is there. As a test I cp'd the old hostname file to the current /etc dir and bobs your uncle distrobox no longer complains on testing-42.20250423.4. I'll try upgrading to a newer image and see if this is just a one off, or if something with my system is preventing the /etc/hostnames file from being created.

1427 replies

UBUniversal Blue

•Created by Mr.Gravity on 3/6/2025 in #🛟bazzite-help

Xx 9070 xXT support

Thanks, I'll give it a try when I reboot back into that image!

1427 replies

UBUniversal Blue

•Created by Mr.Gravity on 3/6/2025 in #🛟bazzite-help

Xx 9070 xXT support

hmm maybe updating didn't like that my default shell is Fish. Or the new image causes Fish to forget some config.

1427 replies

UBUniversal Blue

•Created by Mr.Gravity on 3/6/2025 in #🛟bazzite-help

Xx 9070 xXT support

Recently upped to testing-42.20250423.4 and had trouble with distrobox spitting out an error relating to /etc/hostname. Anyone on .5 willing to check if its fixed?

1427 replies

UBUniversal Blue

•Created by Mr.Gravity on 3/6/2025 in #🛟bazzite-help

Xx 9070 xXT support

I've given it a try and I've had no luck. And at least according to HansKristian we are kinda stuck for now. I assume until AMD helps out. https://github.com/HansKristian-Work/vkd3d-proton/issues/2398#issuecomment-2796215506 Seems like a couple of people have gotten it running. Just not very well.

1427 replies

UBUniversal Blue

•Created by Mr.Gravity on 3/6/2025 in #🛟bazzite-help

Xx 9070 xXT support

You should be able to see the logs of the last boot using this command.

sudo journalctl --no-hostname -b-1 -r

sudo journalctl --no-hostname -b-1 -r

-r reverses the logs order, so the last reported logs will be at the top.

1427 replies

UBUniversal Blue

•Created by Mr.Gravity on 3/6/2025 in #🛟bazzite-help

Xx 9070 xXT support

I'll take a peek, thanks for the rec.

1427 replies

UBUniversal Blue

•Created by Mr.Gravity on 3/6/2025 in #🛟bazzite-help

Xx 9070 xXT support

guess i gotta learn ffmpeg

1427 replies

UBUniversal Blue

•Created by Mr.Gravity on 3/6/2025 in #🛟bazzite-help

Xx 9070 xXT support

:wah:

1427 replies

UBUniversal Blue

•Created by Mr.Gravity on 3/6/2025 in #🛟bazzite-help

Xx 9070 xXT support

if you

flatpak list | grep "yourapp"
flatpak info --show-runtime org.my.app

flatpak list | grep "yourapp"
flatpak info --show-runtime org.my.app

it should spit out the runtime that runs with your flatpak app.

1427 replies

UBUniversal Blue

•Created by Mr.Gravity on 3/6/2025 in #🛟bazzite-help

Xx 9070 xXT support

I am pretty sure they use their own runtimes, flatpak Handbrake for example uses the Gnome 47 runtime whatever is packaged in that. And it can't see the 9070 xt encoder yet. Also forced it to use the Gnome 48 runtime and that also didn't get it going. So some apps still won't work till other runtimes also update. Hopefully it won't be too long.

1427 replies

UBUniversal Blue

•Created by Mr Chandy on 11/8/2024 in #🛟bazzite-help

Systemd SMB Mount and Automount leading to incorrect sha256sums on some files.

:clown: I have no idea how the discrepancy between the Systemd mount and Nautilus mount happened, but it seems to be fixed. My SMB share is hosted on a Truenas Scale system, and somehow Truenas pushed an update that messed up SMB AIO read buffers (https://ixsystems.atlassian.net/browse/NAS-132365), and it could be that my Systemd mount which used CIFS was affected. I am still confused how the Nautilus mount was NOT affected. I would expect this to also affect the Nautilus mount, but I suppose I don't know enough to explain the behavior. If anyone comes across this same issue and is also using a Truenas Scale system running SMB shares ensure that you update your system to 24.10.2 Thank you for the replies @DevilFish303! Sorry to drag you along on a bug in a different system.

9 replies

UBUniversal Blue

•Created by Mr Chandy on 11/8/2024 in #🛟bazzite-help

Systemd SMB Mount and Automount leading to incorrect sha256sums on some files.

Ran out of allocated words in last message.

rsync sysd mount after file was copied back to share from home dir - 24a8a09321c3a18ac56eee9c10145a41befe3ea54f170e198adefa6235168225 (This is the same exact file that was last sha256sumd, the only difference is how it was accessed. The one above with the 478 (correct) sha256sum was wrtitten to the sysd mount but read through the Nautilus mount. This one was read through the sysd mount. So this means that the sums are consistent when writing to the sysd mount, just not reading from the sysd mount.)

9 replies

UBUniversal Blue

•Created by Mr Chandy on 11/8/2024 in #🛟bazzite-help

Systemd SMB Mount and Automount leading to incorrect sha256sums on some files.

if this is the case, i am suspecting the system hosting the NFS server is performing some sort of compression then

There is LZ4 compression on my datasets, though I really am unsure how this can be the problem. Compression should effect all different ways of mounting the SMB Shares, should it not? If this was the problem I should be getting inconsistent sha256sums when I access the SMB share through the Nautilus SMB mount.

if you rsync the file back, does the original hash get recomputed?

Below I used rsync on the sysd mount to copy the same file as before to my home dir, then again used rsync to copy the file back using the sysd mount path. The file has a wrong but consistent sha256sum, only when I use the sysd mount to access the file does the sha256sum change again.

start sum - 478fe48616edb906ad8ffa6220422cb2e03da38d169596dbfcf2b484ef809954 rsync sysd mount to home dir - 0d70fadfa66c089951920c7eb81ef03e306416efb97b98be3e4410b39868fb8a rsync sysd mount after file was copied back to share from home dir - 2f6294655c433e8ef9c7105941dbcbd5422a3a367ccf8f67f61a9bdf5541f48b rsync Nautilus mount to access file that was copied from home dir to SMB share - 0d70fadfa66c089951920c7eb81ef03e306416efb97b98be3e4410b39868fb8a

I'll do the same as above, but this time I will use the Nautilus SMB mount to rsync -a the above file.

rsync Nautilus mount to home dir - 478fe48616edb906ad8ffa6220422cb2e03da38d169596dbfcf2b484ef809954 cp Nautilus mount after file was copied back to share from home dir - 478fe48616edb906ad8ffa6220422cb2e03da38d169596dbfcf2b484ef809954 (note used cp, rsync doesn't like copying to the Nautilus mount see here: https://bbs.archlinux.org/viewtopic.php?id=287443) rsync sysd mount after file was copied back to share from home dir - 478fe48616edb906ad8ffa6220422cb2e03da38d169596dbfcf2b484ef809954 (copied using rsync to the sysd mount dir, and so long I use the Nautilus mount to sha256sum the sums are consistent)

9 replies

UBUniversal Blue

•Created by Mr Chandy on 11/8/2024 in #🛟bazzite-help

Systemd SMB Mount and Automount leading to incorrect sha256sums on some files.

never had an issue but I also only tend to use rsync -a for all file copy operations.

I attempted to use rsync -a to copy the above file to my home dir from both the sysd mount and the Nautilus Network Locations mount, and getting the same results.

rsync sysd mount - 3dfe5d2dc7cb7e45c6ab0989c57fb254f96fefbef36145bcd05b365996d3d5dc rsync Nautilus mount - 478fe48616edb906ad8ffa6220422cb2e03da38d169596dbfcf2b484ef809954

9 replies

UBUniversal Blue

•Created by Mr Chandy on 11/8/2024 in #🛟bazzite-help

Systemd SMB Mount and Automount leading to incorrect sha256sums on some files.

I have done multiple health checks on the drives. The data on the hard drives is NOT being corrupted. The data on the hard drive itself is as expected. I get consistent sha256sums when using SSH, as well as when I mount the SMB share using the built in network locations in nautilus.

let me ask you this question, for the both systems that are running bazzite, are they both automounting the same NFS network drive?

Yes, both of the Bazzite instances are mounting the same SMB shares.

Do the hashes change when you copy the files Do the hashes change randomly while the files are in storage?

No, the ONLY time I get inconsistent sha256sums is when I use my systemd mounts. And this doesn't seem to effect small files like compressed images, text docs, etc.

ssh - 478fe48616edb906ad8ffa6220422cb2e03da38d169596dbfcf2b484ef809954 ssh - 478fe48616edb906ad8ffa6220422cb2e03da38d169596dbfcf2b484ef809954 sysd - f38b8b8222d3e47d50634295462f32e0483bcbf53f8fb467a736989973f9626d sysd - 6f9fef919a4c0e3328165da6b3e6d760c648d3bd5b1f6f451a466cf4f039c4c9 nautilus network locations - 478fe48616edb906ad8ffa6220422cb2e03da38d169596dbfcf2b484ef809954

These are the sha256sums from one file which I've confirmed to act as expected, as long as I'm not accessing it through the sysd mount. SSH, and Nautilus Network locations mount all have the correct sha256sums. The sysd mount is the only one that is spitting out inconsistent sha256sums. It's a very weird issue, and I've yet to try using a VM to try and replicate this issue on other distros. It would take me some time, as I have yet to delve into using Virtual Machines on Linux. I'm still relatively new to Linux in general only about 11 months so far, but having a blast. :letsgo:

9 replies