OMG, this is getting more troublesome and frightening at every step into systemd mine-field territory.
First, I did an
on my TW installation. It revealed the same mentions I had looked at after a previous manual search for rpmnew files:
[sudo] Passwort für root:
Searching for unresolved configuration files
Please check the following files (see /var/adm/rpmconfigcheck):
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:
- TW doesn’t mount my partitions as specified in /etc/fstab at boot, cf. my original post.
- Moreover, the swap defined in /etc/fstab doesn’t get started.
- My UEFI boot partition doesn’t get mounted.
- And I am not at all sure what is happening to my btrfs root file system.
- 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
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:
# 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.