I have a strange issue. I had some apps that I had loaded without a package manager and put them in the /opt folder. I did this on 2 machines. I created .desktop files and everything worked good. I used all day long and shut down pc. Next day I power it up and all my apps I loaded this way were not in my app list (Im using GNOME on Opensuse Tumbleweed). I could not figure out what was going on, the desktop files were still there but no icons.
I went to my /opt folder and there are no files at all. the /opt folder is there though, just empty.
If I restart my PC everything will work again. I basically have been working around this by booting my pc twice for apps to work.
I would like to find out why this is happening so I can fix it on both machines before I load too many more applications. I have reloaded both machines from scratch in attempt to fix and it happened again - so it must be some kind of update that is breaking it - I need some help troubleshooting this one.
I did see this in debugfs (this error is here even when my /opt folder does show files so may not be related):
debugfs: Bad magic number in super-block while trying to open /dev/sda1
/dev/sda1 contains a btrfs file system
What you said was interesting - I dont know how I could have copied / created my app folders in /opt if not mounted - but I did something as a “test”.
I got my pc up where I could see my files in /opt and everything was working. I then copied the entire subdirectory structures to a temp location and rebooted.
On the reboot I was back to where I could see /opt, but had NO subdirectories again and things were broke.
I copied the structure from my temp location back to this and everything started working again so I thought I would reboot.
I rebooted and it is still working. I have tried it a few times and things seem to be working now - although I still dont know why / how this could have happened??? Or how it works one time and not another.
I guess I really havent fixed anything - I’m just testing - because now I probably have 2 copies of the same apps and when I boot one time I am running off one and reboot again and running off another.
This indicates that nrickert was right. And also, that you know have the data/apps in two physical places: One set in the folder /opt on the / fs, where the /opt subvolume was not mounted, one in the mounted subvolume which has that folder as it’s mount point. To verify this, you need to mount/unmount the subvolume and inspect it’s contents in both cases. But that raises the question why this subvolume was not mounted everytime. Info should be in the journal.
I am going to mess with the .service file to see if I can figure out why it is messing up. Im thinking it has something to do with the local-fs.target becasue in the journal i see them mount / unmount really quickly - maybe this is interfering with the mounting. In the meantime I can manually balance , defrag, scrub, and trim from here:
hris@T440:/usr/share/btrfsmaintenance> ls -ltotal 24
-rwxr-xr-x 1 root root 1903 Jun 24 2019 btrfs-balance.sh
-rwxr-xr-x 1 root root 927 Jun 24 2019 btrfs-defrag.sh
-rw-r--r-- 1 root root 2080 Jun 24 2019 btrfsmaintenance-functions
-rwxr-xr-x 1 root root 2776 Jun 24 2019 btrfsmaintenance-refresh-cron.sh
-rwxr-xr-x 1 root root 1227 Jun 24 2019 btrfs-scrub.sh
-rwxr-xr-x 1 root root 941 Jun 24 2019 btrfs-trim.sh
I have only run them here once and they seem to work just fine but have not dug into this too deep yet. Is there any reason I shouldnt run them manually from here that you know of?
the thread is 2 months old, but I have exactly the same issue and the symptoms appear as you told, which is knew for me and so a light of hope seems to shine again : my app in /opt is visible only when it’s unmounted (in terminal). I had posted last year for a similar case : https://forums.opensuse.org/showthread.php/537083-srv-empty-after-booting-recovering-folders-after-reboot
I can’t decide what I should do from this thread, because I haven’t understood clearly if it is OK to use one of the solutions given with btrfs-maintenance(…). Could I change the mount point of /opt, so that it takes my app into account ?
Anyway I guess I’d better get rid of btrfs and move to ext4.
Thanks for letting me know what you think about it.
I don’t figure out clearly the mechanism implied in btrfs subvolums. The fact that the same point of a fs can be either a subdirectory of root fs, or an independent file system when mounted, is something I just discovered and of which of course I don’t see all the implications. So this issue seems to me like a three-card trick!
I’ll apply your suggestions tonight at shut down.
Thanks for your help.
erlangen:~ # btrfs subvolume list /
ID 256 gen 209719 top level 5 path @
ID 258 gen 235369 top level 256 path @/var
ID 259 gen 235103 top level 256 path @/usr/local
ID 260 gen 235357 top level 256 path @/tmp
ID 261 gen 234521 top level 256 path @/srv
ID 262 gen 235320 top level 256 path @/root
ID 263 gen 228953 top level 256 path @/opt
ID 264 gen 234079 top level 256 path @/boot/grub2/x86_64-efi
ID 265 gen 209735 top level 256 path @/boot/grub2/i386-pc
ID 266 gen 235338 top level 256 path @/.snapshots
ID 853 gen 235369 top level 266 path @/.snapshots/494/snapshot
ID 907 gen 232395 top level 266 path @/.snapshots/544/snapshot
ID 908 gen 232399 top level 266 path @/.snapshots/545/snapshot
ID 915 gen 232914 top level 266 path @/.snapshots/552/snapshot
ID 916 gen 232915 top level 266 path @/.snapshots/553/snapshot
ID 919 gen 235042 top level 266 path @/.snapshots/556/snapshot
ID 920 gen 235293 top level 266 path @/.snapshots/557/snapshot
Mount the top subvolume for comfortably inspecting all subvolumes:
erlangen:~ # mount -o subvolid=5 /dev/sdb8 /mnt/
erlangen:~ # ls /mnt/@/.snapshots/5/snapshot/
.snapshots bin boot dev etc home lib lib64 mnt opt proc root run sbin selinux srv sys tmp usr var