TW after update to 20200211: My user hard drive partitions do not get mounted at boot any longer

English Install/Boot/Login
#1

Updated TW to 20200211 today, brought Kernel 5.5.2 and Plasma 5.18. Several awful surprises. This is the most important for now:

My user partitions on the internal hard drives (SSDs) are not mounted automatically at boot any longer, i.e. from /etc/fstab. Only / and /home are being mounted at boot now, after this update. The partitions in question are initially shown as disconnected in the Dolphin sidebar. Cicking on them gives me the prompt for the root password, then Dolphin mounts the drives.

My /etc/fstab (in full, with all UUIDs xxx’ed out):

# <file system>                            <mount point>           <type>   <options>                        <dump>  <pass>
UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  swap                    swap     defaults                         0  0
UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  /                       btrfs    noatime                          0  0
UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  /.snapshots             btrfs    subvol=/@/.snapshots             0  0
UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  /var                    btrfs    subvol=/@/var                    0  0
UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  /usr/local              btrfs    subvol=/@/usr/local              0  0
UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  /tmp                    btrfs    subvol=/@/tmp                    0  0
UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  /srv                    btrfs    subvol=/@/srv                    0  0
UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  /root                   btrfs    subvol=/@/root                   0  0
UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  /opt                    btrfs    subvol=/@/opt                    0  0
UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  /home                   ext4     noatime,data=ordered             0  2
UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  /boot/grub2/x86_64-efi  btrfs    subvol=/@/boot/grub2/x86_64-efi  0  0
UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  /boot/grub2/i386-pc     btrfs    subvol=/@/boot/grub2/i386-pc     0  0
UUID=xxxxxxxxx                             /boot/efi               vfat     codepage=437                     0  0
#
UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  /home/me/AVs            ext4     nofail,noatime                   0  2
UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  /home/me/VMs            ext4     noatime                          0  2
UUID=xxxxxxxxxxxxxxxx                      /home/me/XCs            ntfs-3g  noatime,user,users,uid=myself,gid=users,fmask=133,dmask=022,locale=de_DE.UTF-8  0  0
UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  /home/me/ZBs            ext4     noatime                          0  2

The four partitions in question are in the last four lines, the /home/me/XXs. I tried adding the “owner” option to them, but no success.

Please, any help for me? I checked for any rpmnew files on my system, none. I also checked that the groups associated with user “me” are the same as before, i.e. users and vboxusers.

#2

I have seen similar complaints.

https://forums.opensuse.org/showthread.php/538772-No-automount-on-boot-with-kernel-5-4?highlight=mounted+boot

https://forums.opensuse.org/showthread.php/538378-Partition-in-etc-fstab-not-mounted-automatically-at-boot?highlight=mounted+boot

I am not sure it is solved already or not. It seems that those file systems are mounted on boot, but immedialty unmounted again. You must be able to see that behaviour in the logs.

BTW, I am not sure why you replaced the UUIDs in your fstab witth xxxxxxxx. Does not make it realy easy to interprete for your potential helpers. And I do not think it is a security risk to show them.

#3

Thanks for your reply and your pointing to previous complaints. Two remarks: Regarding kernel versions, this issue did occur only today after updating to 5.5.2, with the previous 5.5’s all was fine. Regarding the partitions, Manjaro automounts them fine at boot, kernel 5.5.2. So there must be some problem in TW only…

#4

Hi
Have you updated any configuration changes?


rpmcheckconfig

No issues here with Tumbleweed and 5.5.2 kernel (20200211).

#5

Thank you, will do that on Monday. I figure that rpmcheckconfig will go beyond my search for rpmnew‘s.

#6

FWIW, I should like to mention that my TW 20200211 is on Kernel 5.5.2 and systemd 244 - fails as described, while my Manjaro is on said kernel but systemd 242 - works fine wrt automounting at boot. Remark: Manjaro has quite some history of attempting to upgrade systemd early on, but reverting thereafter until the new systemd version gets ironed out.

#7

OMG, this is getting more troublesome and frightening at every step into systemd mine-field territory.

First, I did an

rpmconfigcheck

on my TW installation. It revealed the same mentions I had looked at after a previous manual search for rpmnew files:

sudo rpmconfigcheck
[sudo] Passwort für root: 
Searching for unresolved configuration files
Please check the following files (see /var/adm/rpmconfigcheck):
    /etc/postfix/main.cf.rpmnew
    /etc/pulse/client.conf.d/50-system.conf.rpmsave

What should I do about postfix? Simply rename the main.cf.rpmnew to main.cf? Didn’t do it yet, since I figured postfix is mail-related, and I don’t use any mail on my TW.
The difference in the pulse files is an autospawn=yes vs. no.
THANK YOU FOR ANSWERING REGARDING WHAT TO DO FOR THE POSTFIX THING:
Remark to malcolmlewis: Thanks for your tip … took me a little while to find out that it is named rpmconfigcheck and not rpmcheckconfig …

Second, I checked that booting into older kernel versions doesn’t help. This might be expected since the issue is thought to be a systemd one.

Third, I took the latest TW 20200214 update, which didn’t help with the mount/unmount at boot issue in systemd - too bad.

I then searched this openSUSE forum and links therein regarding that mount at boot issue. Indeed, it seems to be a severe systemd bug, which was mentioned at least 5 years ago, got tons of “resolved and closed”, then “reopened” etc etc, but it seems to be fundamentally unresolved to this very day. This maybe is the latest instance of reporting it: https://bugzilla.opensuse.org/show_bug.cgi?id=1137373, from there refer to the github link to systemd development.

I am really worried right now because of a couple of consequent issues:

  1. TW doesn’t mount my partitions as specified in /etc/fstab at boot, cf. my original post.
  2. Moreover, the swap defined in /etc/fstab doesn’t get started.
  3. My UEFI boot partition doesn’t get mounted.
  4. And I am not at all sure what is happening to my btrfs root file system.
  5. And what’s happening to SSD trim’s, also maybe other procedures required at shutdown?

Number 3 is especially bad, since the 20200214 update wanted to install a new grub, but it failed.
Number 4 might be the worst of them all. Right after booting I do see (lsblk) that my root btrfs device partition (/dev/sda4) is mounted as /tmp, and my home ext4 partition (/dev/sda5) is mounted as /home. The latter for sure is correct, but I don’t know about the root partition - at least I don’t see anything under /.snapshots. I am not sure whether the /tmp mount is good or not.
PLEASE, AM I SAFE CONTINUING TO RUN TW THIS WAY, OR WILL I END UP WITH A DESTROYED BTRFS ROOT PARTITION AT SOME POINT IN TIME?

Thus, I am now trying to develop a best practice workaround for this sytemd issue.

Solution 1, as found on the openSUSE forum: Do a

mount -a

but that results in mounting my btrfs root device /dev/sda4 under /boot/grub2/i386-pc, which is the last mention of the /dev/sda4 UUID in /etc/fstab - strange and frightening.

Solution 2: Manually mount the desired partitions from Dolphin. Okayish, but I don’t get the EFI boot partition and I don’t get swap that way.

Solution 3: I thought I might create a script that has all the required mount commands and gets invoked by a Plasma Autostart call. Please, I would like a helping hand to check this script - ATTENTION: STILL UNDER DEVELOPMENT:

#!/bin/bash

# mountonboot-workaround.sh
# Work around a systemd bug which at boot
# mounts and unmounts the partitions specified in /etc/fstab.
# Call this script via KDE Autostart with sudo.
# Last edit: LR, 02/17/2020
#
# From fstab for laptop HP 8570w, Tumbleweed version.
# fstab last edit: LR, 05/28/2019
#
## # <file system>                            <mount point>           <type>   <options>                        <dump>  <pass>
## # As created automatically during the original TW install:
## UUID=75015e19-2ca3-4a3f-9797-20b1de4c7153  swap                    swap     defaults                         0  0
## UUID=18e7d6a7-0f65-478b-a2f5-652835ede86c  /                       btrfs    noatime                          0  0
## UUID=18e7d6a7-0f65-478b-a2f5-652835ede86c  /.snapshots             btrfs    subvol=/@/.snapshots             0  0
## UUID=18e7d6a7-0f65-478b-a2f5-652835ede86c  /var                    btrfs    subvol=/@/var                    0  0
## UUID=18e7d6a7-0f65-478b-a2f5-652835ede86c  /usr/local              btrfs    subvol=/@/usr/local              0  0
## UUID=18e7d6a7-0f65-478b-a2f5-652835ede86c  /tmp                    btrfs    subvol=/@/tmp                    0  0
## UUID=18e7d6a7-0f65-478b-a2f5-652835ede86c  /srv                    btrfs    subvol=/@/srv                    0  0
## UUID=18e7d6a7-0f65-478b-a2f5-652835ede86c  /root                   btrfs    subvol=/@/root                   0  0
## UUID=18e7d6a7-0f65-478b-a2f5-652835ede86c  /opt                    btrfs    subvol=/@/opt                    0  0
## UUID=4719be9f-23c5-415b-adfe-55a9b924a771  /home                   ext4     noatime,data=ordered             0  2
## UUID=18e7d6a7-0f65-478b-a2f5-652835ede86c  /boot/grub2/x86_64-efi  btrfs    subvol=/@/boot/grub2/x86_64-efi  0  0
## UUID=18e7d6a7-0f65-478b-a2f5-652835ede86c  /boot/grub2/i386-pc     btrfs    subvol=/@/boot/grub2/i386-pc     0  0
## UUID=D227-C36D                             /boot/efi               vfat     codepage=437                     0  0
## #
## # As added manually for mounting partitions as required:
## UUID=19efc886-dc20-4bbd-bbb7-bdcecd602e51  /home/myself/AVs        ext4     nofail,noatime                   0  2
## UUID=1b652ccd-3c03-41ed-878c-d6f9c7337a61  /home/myself/VMs        ext4     noatime                          0  2
## UUID=237572285A5934D5                      /home/myself/XCs        ntfs-3g  noatime,user,users,uid=myself,gid=users,fmask=133,dmask=022,locale=de_DE.UTF-8  0  0
## UUID=6094e04e-40e0-4233-a9e8-7e27b042b68b  /home/myself/ZBs        ext4     noatime                          0  2
 
swapon -U 75015e19-2ca3-4a3f-9797-20b1de4c7153
mount -t vfat -o codepage=437 -U D227-C36D /boot/efi
mount -t ext4 -o nofail,noatime -U 19efc886-dc20-4bbd-bbb7-bdcecd602e51 /home/myself/AVs
mount -t ext4 -o noatime -U 1b652ccd-3c03-41ed-878c-d6f9c7337a61 /home/myself/VMs
mount -t ntfs-3g -o noatime,user,users,uid=myself,gid=users,fmask=133,dmask=022,locale=de_DE.UTF-8 -U 237572285A5934D5 /home/myself/XCs
mount -t ext4 -o noatime -U 6094e04e-40e0-4233-a9e8-7e27b042b68b /home/myself/ZBs

It would not only be necessary to call this script with root permissions from Plasma Autostart, but I would also have to remove the corresponding items from /etc/fstab to prevent systemd from messing with them in any way. PLEASE, COULD SOMEONE TAKE A LOOK AT THIS SCRIPT? What permissions would I have to give this script in order to run from Plasma Autostart and not ask for root permissions (as mount requires, I think I might have just a mount within the script and not a sudo mount). Finally, as mentioned above, I am not sure whether the root btrfs partition gets mounted in full and correctly.

OMG, this systemd bug leads to quite some consequences, some frightening - losing a file system or partition would be MOST HORRIBLE.

A big “Thank you” to any helpful folks here! I know I am asking for a lot.

#8

Things are really bad. I booted from a - luckily quite recent - Clonezilla replica of my TW system. Comparing this to the borked TW, I find that

  • the btrfs root system is mounted incorrectly at boot, i.e. it is not mounted as / but as /tmp, .snapshots isn‘t mounted (hope it is still present at all), maybe more incorrect mountings,
  • /boot/efi/EFI is not mounted at boot,
  • my user partitions except for the home partition are not mounted.

This is considered a NASTY systemd bug. My functioning Clonezilla replica has systemd 244-1.4 and kernel 5.5.1, while the borked TW Installation has the same systemd with kernel 5.5.2.

What I am reading on the systemd github is - sorry for being outspoken - not very encouraging. Bug reports get opened / closed / reopened / continued elsewhere, it is not obvious whether they have a definitive fix now or not, and - as far as I understand it - including fixes gets postponed by Lennart Poettering himself.

Systemd development is at 245-rc1 now. I am really afraid to touch my TW system now, but will have to upgrade it eventually when 245 arrives. But **** (sorry!), how long would finishing 245 and bringing it into TW take???

Any comments and help are dearly welcome.

In particular: How can I run the borked TW and do a ”zipper dup“ on this system where the btrfs root partition is mounted incorrectly (at least it looks like that)???

#9

Hi
Perhaps the affect on changing from defaults to noatime and missing all the other necessary btrfs mount options? Have you reviewed the btrfs default options before changing?

#10

Sorry, I don‘t quite understand your question. I have two TW systems on two separate SSDs, one is the borked TW after the 20200211 update, one is a Clonezilla replica taken before that date. So both are identical regarding the partitioning and the /etc/fstab. I am just swapping the two disks in my laptop. The Clonezilla replica runs fine, the other one doesn’t regarding all the mounts mentioned and maybe more.

Sorry if I wasn‘t clear enough.

#11

Well, I stopped the TW 20200211 / kernel 5.5.2 / systemd 244-1.4 problem by brute force. Since - ever so luckily - I had taken a Clonezilla replica of my internal hard disk to an external one just two days ago, I now simply restored my TW system to TW 20200209 / kernel 5.5.1 / systemd 244-1.4. All mounting issues were and are not present in this release. Actually, a thank you to Plasma, since it had been Plasma 5.18 arriving in TW 20200211 that had caused me to clone my hard disk before dup‘ing.

That not-mounting-at-boot issue is believed to be a systemd bug; however, for me it shows up with TW kernel 5.5.2, but not 5.5.1. The failed or wrong mountings had been described above. Actually, what happened is: On Feb 14, I started from 20200209, all fine as far as I could tell, my conky showed the mounts. Then I did the standard ”zypper ref“ followed by ”zipper dup“ in terminal to TW 20200211, which ran fine until close to the end when it tried to put a new grub into place, but failed since it couldn’t find the boot partition /boot/efi/EFI. I have no idea who unmounted it! At that point in time, I realized that my user partitions were not mounted either. You know the full story now…

Since (a) I started to not trust my btrfs root partition any longer (cf. the a.m. findings), and (b) no satisfactory solutions came up here, I decided to go for the a.m. brute force solution. Thank you all anyway!

#12

Sorry, I have to bump this thread, since the issue persists.

IF this is solely a systemd issue: Yes, it was observed as early as systemd 242, and it got mentioned thru 244 as of now. On the systemd github, this bug is given many flags that point to it being awful, both from a developer and a user perspective. However, systemd at the time of my last previous post was preparing for the 245 milestone, and thus i was hoping to get systemd 245 in TW within some reasonable time for releasing it and testing it. HOWEVER, the systemd developers have just decided to postpone this bug to the v246 milestone. For me as a user, this is really unacceptable. Remember, not only did some data drives not get mounted due to this bug (which would be tolerable), but my btrfs root partition and my EFI partition didn’t get mounted properly, too - OMG!

OTH, the operating system that gets mentioned in all the systemd bug reports from v242 onwards, is Tumbleweed !!! I am not 100% sure whether TW is the only OS mentioned with it, since the systemd bug reports have been filed, closed, refiled, closed, opened under different bug numbers and so on - just too hard to track.

I am bumping this thread, since I would like to get recommendations from the moderator(s) here:

  • Any sense in adding to the plethora of systemd bug reports? I mean they know about the issue, and they are kicking it around in strange ways. If I were to add to the systemd bug reports, I would point to the failure of mounting the btrfs root partition properly.
  • But then, funny thing is that there seem to be many TW users who don’t experience this bug. So, is it a quirky interaction between systemd and specifics of the Linux kernel in the specific version (5.5.1) I had at that time? Anybody else seeing this currently? Current systemd 244; btrfs root partition, vfat efi partition and ext4 data partitions being affected (= don’t get mounted at boot) on my machine, but NOT the ext4 /home partition which gets mounted fine. Any ideas?
  • Well, it would take me some more encouraging myself before I try to update my TW to a newer kernel and eventually end up in that same desaster again. I could of course recover again via Clonezilla, but I did already spend too much time on this…
#13

openSUSE is the only distro I’m aware of that defaults to using BTRFS. Some don’t support it at all. TW would likely be the only distro using BTRFS and newest systemd.

You can reinstall TW using EXT4 and/or XFS and avoid all BTRFS issues, as some of us forum helpers do. I use exclusively EXT3/4 filesystems for Linux / and /home.

#14
  • There is an impressive list of issues with mounting and unmounting devices: https://github.com/systemd/systemd/issues?utf8=✓&q=unmounting+just+mounted+mounts but there is no obvious correlation to btrfs.
  • Common sense tells me to never use a mount point which is under an other mount point such as /home/me/xxx
    . All my additional mount points are in the root directory. I never experienced any issues with mounting. :wink: 
erlangen:~ # cat /etc/fstab 
UUID=204f7d0f-979a-41e1-a483-a597d0357e0b  /                       btrfs  defaults                      0  0
UUID=204f7d0f-979a-41e1-a483-a597d0357e0b  /.snapshots             btrfs  subvol=/@/.snapshots          0  0
UUID=204f7d0f-979a-41e1-a483-a597d0357e0b  /var                    btrfs  subvol=/@/var                 0  0
UUID=204f7d0f-979a-41e1-a483-a597d0357e0b  /usr/local              btrfs  subvol=/@/usr/local           0  0
UUID=204f7d0f-979a-41e1-a483-a597d0357e0b  /tmp                    btrfs  subvol=/@/tmp                 0  0
UUID=204f7d0f-979a-41e1-a483-a597d0357e0b  /srv                    btrfs  subvol=/@/srv                 0  0
UUID=204f7d0f-979a-41e1-a483-a597d0357e0b  /root                   btrfs  subvol=/@/root                0  0
UUID=204f7d0f-979a-41e1-a483-a597d0357e0b  /opt                    btrfs  subvol=/@/opt                 0  0
UUID=704621ef-9b45-4e96-ba7f-1becd3924f08  /home                   ext4   data=ordered                  0  2
UUID=204f7d0f-979a-41e1-a483-a597d0357e0b  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
UUID=204f7d0f-979a-41e1-a483-a597d0357e0b  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
UUID=4A24-B10D                             /boot/efi               vfat   defaults                      0  0

UUID=f5177cae-4082-44ed-9471-b99030f06866  **/home-HDD**               ext4   defaults                      0  2
UUID=f0060b5e-3c44-4807-9789-f2e0d9d1ba14  **/INTENSO **               btrfs  noauto                        0  0
UUID=ea22d273-1277-42bd-8bcb-8cf71268762c ** /Encrypt**                btrfs  noauto                        0  0
UUID=42f23f3c-9ff6-46f6-a9d9-6894062c37d7  **/test**                   ext4   user,noauto,data=ordered      0  0
erlangen:~ #
#15

Hello all! First post here!

I faced this issue myself on a new TW installation, and from the info I compiled on the subject I think I can shed some light on this issue – there’s quite a lot of misinformation, and, sadly, some FUD.

I must preface saying that even though I have had a TW install for a couple years, it was on a laptop and not my main workstation. So it didn’t get used much. So when I decided to switch from Windows to Linux, I finally did the reinstall on the laptop and installed on the PC as well in the last couple weeks. Since late last year I was reading and learning more about Linux, openSUSE, BTRFS, systemd, etc… yet I still lack real-world experience with Linux. This time, many issues were giving me some unexpected hard time, but that’s for another post. Sounds good? Okay, now let’s cut to the chase!!

The issue seems to be caused by the btrfsmaintenance-refresh.service systemd unit. That’s why this issue is always reported from openSUSE TW installations. Yes, there’s reports of missing mounts for other FS, but there’s always an BTRFS partition in the system, isn’t not?

In my case, the symptoms would include failing to regenerate GRUB (“No valid EFI partition”), no snapshots in YasT, snapper-cleanup failing with “IO ERROR (.snapshots is not a btrfs subvolume)”. Also, the odd “graphical.target was never reached”. All leading to the issue at hand. These were not present on every boot though.

Solution:

# systemctl disable --now btrfsmaintenance-refresh.service

Do this from a terminal, because YaST Services Manager would disable the .path unit as well.

I first found about this workaround here (https://forums.opensuse.org/showthread.php/538011-Btrfs-subvolume-snapshots-not-automounting-correctly-on-one-specific-machine?highlight=btrfsmaintenance), but instead of keeping the service and re-mounting everything later - which is a ugly hack - avoiding the unmounts in the first place is the best way to go.

Someone (here or systemd’s GitHub, I don’t recall) pointed out that the accompaining btrfsmaintenance-refresh.path should be enough to update the timers when the configured period changes through sysconfig, which I agree. Maybe the .service is enabled to handle the first boot? Nevertheless there ought to be a better way of initializing the timers.

To be clear: it’s not btrfs fault, but btrfs maintenance service packaged in openSUSE, which is likely hitting a rece condition in systemd. There’s a few systemd issues that provoke the unmounting too (other conditions).

Given the simplicity of the fix, the time it’s taking for upstream to do so, and my level of expertise, it makes me wonder if I’m wrong in my assessment. So instead of keeping to myself, I’m sharing my thoughts so someone with better information could correct me.

#16

Thank you for all your comments, karlmistelberger, mrmazda and awerlang! These and comments cited therein make a lot of sense.

At this point, I would like to ask the community for three things:

  1. Could you please give me more opinions of yours regarding the karlmistelberger recommendation:

This recommendation seems reasonable, but I would like to ask the community whether it should be regarded “close to mandatory”. I am perfectly willing to give my two Linux installations (TW and Manjaro, both running perfectly for years with my stacked mount points) such an overhaul, but it would be quite some effort due to consequences spreading to app settings on the Linux’s, virtual machines, and even another physical Windows machine linked via Samba.

  1. Ever since installing TW with the default btrfs root file system, I was asking myself at what point in time I would regret this decision:

The final fact that caused me to go for btrfs was that the official TW repos do not offer timeshift. Of course, it wouldn’t be included in the repos just for the reason of defaulting to btrfs. But in fact, this remark may be taken as asking for officially bringing timeshift to TW! (Yeah, malcolmlewis, we talked about timeshift previously, and you pointed me to your repo. But I didn’t go for it, since (1) I adopted btrfs, and (2) such private repo is not the same as an official TW one.)

  1. Now this awerlang post and the HadrienG thread quoted therein in fact are shedding some light:

I had tried myself to put a workaround into place using a script that would mount my missing partitions/directories, either manually or via KDE autostart - but I agree this is an ugly hack.

So I would - as awerlang himself did already - like to ask the community for opinions regarding the workaround mentioned, i.e. disabling the btrfsmaintenance-refresh.service unit in TW. Would that somehow cripple the btrfs snapshotting or other btrfs capabilities? Other side effects? Does it help in performing all mounts correctly at boot?

Thank you all for providing further feedback. The current issue situation involves systemd, btrfs and Tumbleweed. Thus, it is understood to be awful in its consequences, difficult to fix, and - that’s at least my feeling - not handled satisfactorily by systemd bugfixing alone.

#17

Common sense tells me to never use a mount point which is under an other mount point such as /home/me/xxx. All my additional mount points are in the root directory. I never experienced any issues with mounting

Experiences may differ, but mine is that (already for decades) the correct sequence in /etc/fstab is important here and then should work.

And concentrating on openSUSE, I have already (for at least a decade) an (NFS) mount on /home /wij within a mount on /home.

#18

Thank you, hcvv. And also thank you, karlmistelberger! Just checking my /etc/fstab (cf. my first post up in this thread), it has the correct sequence, i.e. /home being listed before all mounts underneath /home/myself. So I feel a bit more comfortable in keeping my TW installation as is - for the time being! - regarding the stacking of mount points.

#19

When the upper mount point is mounted from the same partition as ‘/’ (btrfs), I see no problem. Otherwise unmounting e.g. /home would be inconvenient regarding the nested mount point. Anyway sticking to traditional mount points (/mnt, /media, /run/user) should be more adequate.
If it matters, systemd takes hold of /etc/fstab on init, so a nested mount point always requires the parent mount point (if any) to be mounted already.

My next task (after fixing a few more bugs, or giving up on them) is to configure a backup routine. I’ve read a lot about btrfs and the send/receive feature. It makes it easy to send incremental changes to a separate device through snapshots. Seems the superior choice for real backups. It can track permission changes and renames just fine. Also, snapshots are a live file system, no need to untar/unzip. Also, easy rollbacks when a system update goes wrong. That’s the most compelling single reason I got openSUSE.
I took note about timeshift when I started my studies on linux, but btrfs alone makes it irrelevant IMO.

I checked the routine that btrfsmaintenance-refresh.service runs when it starts. It uninstalls four systemd timers and install/starts the configured jobs (scrub and balance by default). I gave up troubleshooting the routine when it became clear that it should not be there at system boot at all. It only needs to run once, then it will be called on demand, just forget about it. It can be started on demand even disabled. Only the .path counterpart needs to be enabled. The action it performs refers only to some btrfs upkeep, by default it runs once a week (balance: reclaim unused allocated space) or once a month (scrub: detect file system corruption). I’d say unless you’re short on space on disk, they could be skipped for months.

I’ll post a bug on said service starting at boot. That’s the thing I don’t understand. I guess if the setup was changed and the .path and/or .service fails that invocation. Then the next boot fixes it. But nah, still it’s not relevant enough to be at boot. There’s more to lose than to gain.

#20

Are you really sure? To find out whether it matters with your setup you need to run a test by moving the mount point to the root directory. :wink: