Results 1 to 10 of 10

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

  1. #1

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

    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):
    Code:
    # <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. #2
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    25,759

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

    I have seen similar complaints.

    https://forums.opensuse.org/showthre...t=mounted+boot

    https://forums.opensuse.org/showthre...t=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.
    Henk van Velden

  3. #3

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

    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. #4
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    27,817
    Blog Entries
    15

    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
    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...
    Hi
    Have you updated any configuration changes?

    Code:
    rpmcheckconfig
    No issues here with Tumbleweed and 5.5.2 kernel (20200211).
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  5. #5

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

    Quote Originally Posted by malcolmlewis View Post
    Hi
    Have you updated any configuration changes?

    Code:
    rpmcheckconfig
    No issues here with Tumbleweed and 5.5.2 kernel (20200211).
    Thank you, will do that on Monday. I figure that rpmcheckconfig will go beyond my search for rpmnew‘s.

  6. #6

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

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

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

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

    First, I did an
    Code:
    rpmconfigcheck
    on my TW installation. It revealed the same mentions I had looked at after a previous manual search for rpmnew files:
    Code:
    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
    Code:
    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:
    Code:
    #!/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. #8

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

    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. #9
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    27,817
    Blog Entries
    15

    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
    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)???
    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?
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  10. #10

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

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

Posting Permissions

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