Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 41

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

  1. #11

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

    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!

  2. #12

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

    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...

  3. #13
    Join Date
    Dec 2008
    Location
    FL, USA
    Posts
    2,382

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

    Quote Originally Posted by 111MilesToGo View Post
    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
    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.
    Reg. Linux User #211409 *** multibooting since 1992
    Primary: 15.1,TW,15.2 & 13.1 on Haswell w/ RAID
    Secondary: eComStation (OS/2)&15.1 on 965P/Radeon
    Tertiary: TW,15.2,15.1,Fedora,Debian,more on Kaby Lake,Q45,Q43,G41,G3X,965G,Cedar,Caicos,Oland,GT218&&&

  4. #14
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    1,909
    Blog Entries
    1

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

    Quote Originally Posted by 111MilesToGo View Post
    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...
    • There is an impressive list of issues with mounting and unmounting devices: https://github.com/systemd/systemd/i...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.


    Code:
    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:~ #
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), openSUSE Tumbleweed, KDE Plasma 5

  5. #15
    Join Date
    Mar 2020
    Location
    São Leopoldo, RS, Brazil
    Posts
    241

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

    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:

    Code:
    # 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/showthre...rfsmaintenance), 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.

  6. #16

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

    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:
    Quote Originally Posted by karlmistelberger View Post
    • 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.

    Code:
    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:~ #
    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.


    2. 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:
    Quote Originally Posted by mrmazda View Post
    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.
    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.)


    3. Now this awerlang post and the HadrienG thread quoted therein in fact are shedding some light:
    Quote Originally Posted by awerlang View Post
    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.

    ...

    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:

    Code:
    # 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/showthre...rfsmaintenance), 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.
    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.

  7. #17
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    27,125

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

    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.
    Last edited by hcvv; 03-Mar-2020 at 07:31.
    Henk van Velden

  8. #18

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

    Quote Originally Posted by hcvv View Post
    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.
    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.

  9. #19
    Join Date
    Mar 2020
    Location
    São Leopoldo, RS, Brazil
    Posts
    241

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

    Quote Originally Posted by 111MilesToGo View Post
    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.
    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.



    Quote Originally Posted by 111MilesToGo View Post
    2. 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.)
    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.



    Quote Originally Posted by 111MilesToGo View Post
    3. 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.
    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.

  10. #20
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    1,909
    Blog Entries
    1

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

    Quote Originally Posted by 111MilesToGo View Post
    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.
    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.
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), openSUSE Tumbleweed, KDE Plasma 5

Page 2 of 5 FirstFirst 1234 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •