XFS partition being unmounted during boot....

Hello all,

I just recently moved from Leap to Tumbleweed for AMD graphic card reasons (Vega 56) and now I am seeing an issue with mounting partitions during boot.

I have quite some partitions spread out accross 2 discs and going with the default of the installer most of them are XFS:

UUID=ff56414d-9349-492e-b00d-ef7ee5104bdb  /                       btrfs  defaults                      0  0
UUID=ff56414d-9349-492e-b00d-ef7ee5104bdb  /var                    btrfs  subvol=/@/var                 0  0
UUID=9acf2e86-4004-4c48-8cd7-797f4976731c  /usr                    xfs    defaults                      0  0
UUID=ae405401-3d9d-4f4d-9133-1f2450e939b2  /tmp                    xfs    defaults                      0  0
UUID=ff56414d-9349-492e-b00d-ef7ee5104bdb  /srv                    btrfs  subvol=/@/srv                 0  0
UUID=ff56414d-9349-492e-b00d-ef7ee5104bdb  /root                   btrfs  subvol=/@/root                0  0
UUID=7e897a13-4839-442a-9768-86e5df104df0  /opt                    xfs    defaults                      0  0
UUID=f61c43a9-702a-4e05-b5a0-ec0d80f7e9a2  /mnt/local/data         xfs    defaults                      0  0
UUID=CD9C-F5E5                             /mnt/local/Tausch       vfat   iocharset=utf8                0  0
UUID=cd4c88af-0f8e-40d5-8a9b-2d0284ce0242  /home                   xfs    defaults                      0  0
UUID=ff56414d-9349-492e-b00d-ef7ee5104bdb  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
UUID=ff56414d-9349-492e-b00d-ef7ee5104bdb  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
UUID=CE24-B4AB                             /boot/efi               vfat   defaults                      0  0  /mnt/remote/SoltauSuseServer_Public   nfs  defaults,bg,rw,auto,user,soft    0  0
UUID=8137cdf5-59e1-4bb8-a545-b519d81d31aa   /mnt/local/extern1       ext4      defaults,rw,noauto,user   0 0   /mnt/remote/DMZServer nfs defaults,bg,rw,auto,user,soft   0  0

During boot, I occationally experience one or two partitions not being mounted. This happens to /mnt/local/data the most, to /home rarely and not at all (not yet…) to /mnt/local/Tausch.

When looking into that I found in the boot.log:
OK ] Mounted /mnt/local/data.

And then, a couple lines further down:
OK ] Stopped target Local File Systems.
Unmounting /mnt/local/data…
OK ] Unmounted /mnt/local/data.

I only found one other reference to such behaviour:

I would not have an issue if - on access - the partitions would come up. But while I get the impression that happens for /home (sometimes the KDE login screen does not show my user photo, but when I log in all my desktop settings are there…), it definately does not happen for /mnt/local/data which holds my VirtualBox machines. If I start VirtualBox it complains about the VMs not being accessible.

Did someone else experience such behaviour? Any hints how to track that down and solve?

Thank you and kind regards,

P.S.: Some additions:

  • Mounting and unmounting the partitions on command line works without any errors.
  • All of the affected partitions are on my second disk which is a 4 TB WD black with GPT.
    That disk also has some windows partitions on it (dualboot) for user data and games. These partitions are not accessed from within Linux. But they come up nicely and reliably when booting into WIndows.

Other than studying the journal and dmesg messages, I’m at a loss. It may be worth concentrating on the boot-to-boot differences and anomalies, and comparing them carefully. I usually grep my way through the logs with a search pattern that’s grown over time:

journalctl -b --no-hostname | grep -Ei '\S*( no |warn|\Werr|fail|conflict|igno|repeat|n^a-n p-z]t)\S*\s*\S*'

My result from this morning:

Comparing this output with errors from the last boot could go like this:
Open another terminal window and display the errors from a recent boot there…

journalctl -b **-1** --no-hostname | grep *…see above…]*
journalctl -b **-2** --no-hostname | grep *…see above…]*

The »-1« gives you messages from the last boot, the »-2« from the second-to-last one, and so on. Put those two terminal windows above each other and »alt-Tab« between them to easily notice what’s different. (Of course, you can also do this with terminal tabs, or with redirecting the lines in to text files and »diff« them with the tool of your choice.)

I saw that a week or so ago on my /stuff partition, just unmounted, then ran xfs_repair -n /dev/sdXN to see if anything amiss, then ran xfs_repair -vv /dev/sdXN. All back to normal on next boot.

Good morning to all.

Quick update:
I just ran the cfs_repair command, but from what I can tell it didn’t even find anything. I did not reboot yet.

With regards to analysing the journal, I used the parameters / grep as shown above but there was an overwhelming amount of unrelated stuff (tons of XCB Error 3…

When I added another grep to specifically search for my paths and partitions i found the following:
(Keep in mind: sda is the 4TB disk. partition sda8 is /mnt/local/Tausch, sda9 is /mnt/local/data. Tausch got mounted, data did get unmounted)
Sep 06 07:11:46 systemd[1]: Failed unmounting /mnt/local/Tausch.
Sep 06 07:11:46 systemd[1]: Failed unmounting /mnt/local/Tausch.
Sep 06 07:11:46 systemd[1]: Failed unmounting /mnt/local/Tausch.
Sep 06 07:11:46 systemd[1]: Failed unmounting /mnt/local/Tausch.
Sep 06 07:11:46 systemd[1]: Failed unmounting /mnt/local/Tausch.
Sep 06 07:11:46 systemd[1]: Failed unmounting /mnt/local/Tausch.
Sep 06 07:11:46 systemd[1]: Failed unmounting /mnt/local/Tausch.
Sep 06 07:11:46 systemd[1]: Failed unmounting /mnt/local/Tausch.
Sep 06 07:11:47 systemd[1]: Failed unmounting /mnt/local/Tausch.

So I guess Tausch was just by incident not unmounted because something blocked it from being unmounted. Why the heck is systemd trying to unmount my partitions?


Sorry for replying this late.

Maybe it’s worth checking the messages that come immediately before those unmounting attempts. With »journalctl | less -N« you can scroll/page/search through your machine’s whole log (which can be millions of lines).

Alternatively, redirect it to a file and open that with the text editor of your choice, like so:

journalctl > story-so-far.text
vim story-so-far.text

Do you see any suspicious sda* device activity leading up to those unmount attemts?