Yet another mount at boot problem - sda1 not mounting at boot

English Install/Boot/Login
1

Hi, I’ve been fighting this one for a bit here and now am looking for advice. This is a recent Tumbleweed install… 2 days old. After initial install and updates, everything worked as expected and my mounts survived multiple restarts during setup. Now today, I had to shutdown and restarted about 45 minutes later… and my second drive is no longer mounting. I haven’t done any updates (ie no zypper dup) between when it last restarted and everything works, and today when it stopped mounting the drive at boot.

My fstab looks like this:

UUID=8410fd11-3ff7-41e8-8eba-d2a8f84a9ecb  /                       btrfs  defaults                      0  0
UUID=8410fd11-3ff7-41e8-8eba-d2a8f84a9ecb  /.snapshots             btrfs  subvol=/@/.snapshots          0  0
/dev/nvme0n1p4                             swap                    swap   defaults                      0  0
UUID=8410fd11-3ff7-41e8-8eba-d2a8f84a9ecb  /var                    btrfs  subvol=/@/var                 0  0
UUID=8410fd11-3ff7-41e8-8eba-d2a8f84a9ecb  /usr/local              btrfs  subvol=/@/usr/local           0  0
UUID=8410fd11-3ff7-41e8-8eba-d2a8f84a9ecb  /tmp                    btrfs  subvol=/@/tmp                 0  0
UUID=8410fd11-3ff7-41e8-8eba-d2a8f84a9ecb  /srv                    btrfs  subvol=/@/srv                 0  0
UUID=8410fd11-3ff7-41e8-8eba-d2a8f84a9ecb  /root                   btrfs  subvol=/@/root                0  0
UUID=8410fd11-3ff7-41e8-8eba-d2a8f84a9ecb  /opt                    btrfs  subvol=/@/opt                 0  0
UUID=0e7b238b-d920-4e49-a31d-72f46d776a25  /home                   xfs    defaults                      0  0
UUID=8410fd11-3ff7-41e8-8eba-d2a8f84a9ecb  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
UUID=8410fd11-3ff7-41e8-8eba-d2a8f84a9ecb  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
UUID=23FC-4283                             /boot/efi               vfat   defaults                      0  0
UUID=f254a220-979c-4147-9413-72d5ff1a8a6c  /home/smaug42/stuff     ext4   data=ordered                  0  0

After booting, the /home/smaug42/stuff mount isn’t mounted (this is /dev/sda1 (the only partition on the drive). If I do a sudo mount -a it mounts normally and I can use it right up until I restart.

[FONT=system]fdisk -l gives me this:

**Disk /dev/nvme0n1: 465.78 GiB, 500107862016 bytes, 976773168 sectors**
Disk model: Samsung SSD 970 EVO 500GB                
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A600BE29-E0D3-4E84-891B-9621BCEEF1DB

**Device****    Start****      End****  Sectors****  Size****Type**
/dev/nvme0n1p1      2048   1026047   1024000   500M EFI System
/dev/nvme0n1p2   1026048 336445439 335419392   160G Linux filesystem
/dev/nvme0n1p3 336445440 944363519 607918080 289.9G Linux filesystem
/dev/nvme0n1p4 944363520 976773134  32409615  15.5G Linux swap


**Disk /dev/sda: 931.53 GiB, 1000204886016 bytes, 1953525168 sectors**
Disk model: TOSHIBA DT01ACA1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 37A517B5-6A55-49DE-A2E6-FC2E9C46457B

**Device****Start****       End****   Sectors****  Size****Type**
/dev/sda1   2048 1953523711 1953521664 931.5G Linux filesystem

[/FONT]
I can’t see anything with dmesg in the boot sequence that hints to the problem… and after running mount -a I see this in dmesg:


   58.909176] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: data=ordered

So… now I’m stuck… not sure how to figure this one out and get the drive to automount on boot.

2

Provide all information:

erlangen:~ # journalctl -k --grep sda
-- Logs begin at Sun 2019-10-06 15:16:15 CEST, end at Sat 2019-10-19 06:00:25 CEST. --
Oct 18 07:22:19 erlangen kernel: sd 0:0:0:0: [sda] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB)
Oct 18 07:22:19 erlangen kernel: sd 0:0:0:0: [sda] 4096-byte physical blocks
Oct 18 07:22:19 erlangen kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 18 07:22:19 erlangen kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 18 07:22:19 erlangen kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 18 07:22:19 erlangen kernel:  sda: sda1 sda2 sda4
Oct 18 07:22:19 erlangen kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Oct 18 07:22:20 erlangen kernel: EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
Oct 18 17:54:06 erlangen kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
Oct 18 17:54:06 erlangen kernel: sd 0:0:0:0: [sda] Stopping disk
Oct 18 17:54:06 erlangen kernel: sd 0:0:0:0: [sda] Starting disk
Oct 19 05:36:02 erlangen kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
Oct 19 05:36:02 erlangen kernel: sd 0:0:0:0: [sda] Stopping disk
Oct 19 05:36:02 erlangen kernel: sd 0:0:0:0: [sda] Starting disk
erlangen:~ #
3

I wasn’t sure what would be useful in all the various logs etc.

**grumpy:/home/smaug42 #** journalctl -k --grep sda
-- Logs begin at Wed 2019-10-16 20:48:24 PDT, end at Fri 2019-10-18 21:50:46 PDT. --
Oct 18 20:15:59 grumpy kernel: **sd 0:0:0:0: ****sda****] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)**
Oct 18 20:15:59 grumpy kernel: **sd 0:0:0:0: ****sda****] 4096-byte physical blocks**
Oct 18 20:15:59 grumpy kernel: **sd 0:0:0:0: ****sda****] Write Protect is off**
Oct 18 20:15:59 grumpy kernel: sd 0:0:0:0: **sda**] Mode Sense: 00 3a 00 00
Oct 18 20:15:59 grumpy kernel: **sd 0:0:0:0: ****sda****] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA**
Oct 18 20:15:59 grumpy kernel:  sda: sda1
Oct 18 20:15:59 grumpy kernel: **sd 0:0:0:0: ****sda****] Attached SCSI disk**
Oct 18 20:16:01 grumpy kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: data=ordered
Oct 18 20:16:55 grumpy kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: data=ordered
**grumpy:/home/smaug42 #**

What are we looking for here?

4

Change the last two columns in “fstab” for that entry, to “0 2” rather than “0 0”

I don’t guarantee that will solve the problem, but it is worth trying. This tells the system to do an “fsck” on the file system. If the file system does not show up as clean, then that might prevent it mounting.

5

Looks like the kernel successfully mounts the disk at 20:16:01, but the mount silently dies and manully mounting succeeds at 20:16:55. Any messages in that intervall?

6

Changing from 0 0 to 0 2 didn’t make any difference on restart.

I’ve just restarted and before doing anything else I checked the mount points… sda1 is not mounted if I check via file manager or CLI. There is a new line in the journal now…

Oct 18 22:02:46 grumpy kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: data=ordered

but nothing is actually mounted for sda1. If I manually mount with a mount -a or mount /home/smaug42/stuff it mounts cleanly and now there’s a second line in the journal…

Oct 18 22:02:46 grumpy kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: data=ordered
Oct 18 22:07:19 grumpy kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: data=ordered

Looks like the kernel successfully mounts the disk at 20:16:01, but the mount silently dies and manully mounting succeeds at 20:16:55. Any messages in that intervall?

Nothing I can see… dmesg only has 2 lines related to the mount point… and no hint around either time stamp:

dmesg |grep sda1
    1.580247]  sda: **sda1**
    4.544159] EXT4-fs (**sda1**): mounted filesystem with ordered data mode. Opts: data=ordered
  278.021129] EXT4-fs (**sda1**): mounted filesystem with ordered data mode. Opts: data=ordered
7

This remembers me of a thread some time ago. It looked at least like this in that from the loggings it looked that the mount was done, immediatly followed by an unmount. Mounting manualy then succeeded and no further problems. If I remember correct, it did not happen at every boot, but very often.

Sorry, but I have to go and not the time to search for that thread.

Also, @smaug42, please always include the first line with the prompt and the command and the last line with the new propmt with your computer output. Much easier for you to copy/paste those two more lines and not to have to type things like “my fstab looks like this”. Not needed, because the “…:~> cat /etc/fstab” is there. Much easier to interprete for us also.

8

Try ‘journalctl -b --grep smaug42’.

9

Hi
Seems a few of these issues show up with samsung devices and ext4 filesystem, see this thread for a fix;
https://forums.opensuse.org/showthread.php/537863-NVMe-Trouble-fstrim-service-Skipping-home-Delayed-Appearence-of-Files-After-Write

10

This is what I get:

**grumpy:/home/smaug42#**journalctl -b --grep smaug42 -- Logs begin at Wed2019-10-16 20:48:24 PDT, end at Sat 2019-10-19 07:31:54 PDT. -- 
Oct19 07:23:41 grumpy systemd[1]: Mounting /home/smaug42/stuff... 
Oct19 07:23:41 grumpy systemd[1]: Mounted /home/smaug42/stuff. 
Oct19 07:23:42 grumpy systemd[1]: Unmounting /home/smaug42/stuff... 
Oct19 07:23:42 grumpy systemd[1]: home-smaug42-stuff.mount: Succeeded.
Oct 19 07:23:42 grumpy systemd[1]: Unmounted/home/smaug42/stuff. 
Oct 19 07:23:46 grumpysystemd-logind[1665]: New session 1 of user smaug42. 
Oct 1907:23:46 grumpy systemd[1675]: pam_unix(systemd-user:session):session opened for user smaug42(uid=1000) by (uid=0) 
Oct 1907:23:46 grumpy systemd[1]: Started Session 1 of user smaug42. 
Oct19 07:23:46 grumpy sddm-helper[1656]:pam_unix(sddm-autologin:session): session opened for usersmaug42(uid=1000) by (uid=0) 
Oct 19 07:23:46 grumpysddm-helper[1684]: Addingcookie to "/home/**smaug42**/.Xauthority"
Oct 19 07:23:46 grumpy kdeinit5[1767]:**kf5.kservice.sycoca:Parse error in "/home/****smaug42****/.config/menus/applications-merged/xdg-desktop-menu-dummy.menu", line  1 , col  1 :  "unexpected end of file"**
Oct 19 07:23:47 grumpy plasma_session[1794]:org.kde.plasma.session: Starting autostart service "/home/smaug42/.config/autostart/insync.desktop"("/usr/bin/insync", "start") 
Oct 1907:23:47 grumpy plasma_session[1794]: org.kde.plasma.session:Starting autostart service "/home/smaug42/.config/autostart/steam.desktop"("/usr/bin/steam") 
Oct 19 07:23:47 grumpy env[1907]:-> checking/home/smaug42/.local/share/Steam/ubuntu12_32/steam-runtime 
Oct19 07:23:47 grumpy rtkit-daemon[1993]: Successfully made thread 1869of process 1869 (/usr/bin/pulseaudio) owned by 'smaug42' highpriority at nice level -11. 
Oct 19 07:23:49 grumpyplasmashell[1805]:**file:///home/****smaug42****/.local/share/plasma/plasmoids/org.kde.thermalMonitor/contents/ui/main.qml:312:TypeError: Type error**
Oct 19 07:23:49 grumpy plasmashell[1805]:**file:///home/****smaug42****/.local/share/plasma/plasmoids/org.kde.thermalMonitor/contents/ui/main.qml:312:TypeError: Type error**
Oct 19 07:23:49 grumpy plasmashell[1805]:**file:///home/****smaug42****/.local/share/plasma/plasmoids/org.kde.thermalMonitor/contents/ui/main.qml:312:TypeError: Type error**
Oct 19 07:23:49 grumpy plasmashell[1805]:**file:///home/****smaug42****/.local/share/plasma/plasmoids/org.kde.thermalMonitor/contents/ui/main.qml:312:TypeError: Type error**
Oct 19 07:23:49 grumpy plasmashell[1805]:**file:///home/****smaug42****/.local/share/plasma/plasmoids/org.kde.thermalMonitor/contents/ui/main.qml:312:TypeError: Type error**
Oct 19 07:23:49 grumpy plasmashell[1805]:**file:///home/****smaug42****/.local/share/plasma/plasmoids/org.kde.thermalMonitor/contents/ui/main.qml:312:TypeError: Type error**
Oct 19 07:23:49 grumpy plasmashell[1805]:**file:///home/****smaug42****/.local/share/plasma/plasmoids/org.kde.thermalMonitor/contents/ui/main.qml:312:TypeError: Type error**
Oct 19 07:23:49 grumpy plasmashell[1805]:**file:///home/****smaug42****/.local/share/plasma/plasmoids/org.kde.thermalMonitor/contents/ui/main.qml:312:TypeError: Type error**
Oct 19 07:23:49 grumpy plasmashell[1805]:**file:///home/****smaug42****/.local/share/plasma/plasmoids/org.kde.thermalMonitor/contents/ui/main.qml:312:TypeError: Type error**
Oct 19 07:23:49 grumpy plasmashell[1805]:**file:///home/****smaug42****/.local/share/plasma/plasmoids/org.kde.thermalMonitor/contents/ui/main.qml:312:TypeError: Type error**
Oct 19 07:23:49 grumpy plasmashell[1805]:**file:///home/****smaug42****/.local/share/plasma/plasmoids/org.kde.thermalMonitor/contents/ui/main.qml:312:TypeError: Type error**
Oct 19 07:23:49 grumpy plasmashell[1805]:**file:///home/****smaug42****/.local/share/plasma/plasmoids/org.kde.thermalMonitor/contents/ui/main.qml:312:TypeError: Type error**
Oct 19 07:23:49 grumpy plasmashell[1805]:**file:///home/****smaug42****/.local/share/plasma/plasmoids/org.kde.thermalMonitor/contents/ui/main.qml:312:TypeError: Type error**
Oct 19 07:23:50 grumpy rtkit-daemon[1993]:Successfully made thread 2357 of process 1869 (/usr/bin/pulseaudio)owned by 'smaug42' RT at priority 5. 
Oct 19 07:23:50 grumpyrtkit-daemon[1993]: Successfully made thread 2410 of process 1869(/usr/bin/pulseaudio) owned by 'smaug42' RT at priority 5. 
Oct19 07:23:50 grumpy plasmashell[1805]:**file:///home/****smaug42****/.local/share/plasma/plasmoids/org.kde.simpleMonitor/contents/ui/main.qml:114:Error: Cannot assign [undefined] to QString**
Oct 19 07:23:52 grumpy baloo_file[1803]: **replacecalled with invalid arguments, docId: 1152922054362727171 url:"/home/****smaug42****/"**
Oct 19 07:24:12 grumpy su[3334]: **(toroot) ****smaug42****onpts/1**
Oct 19 07:24:12 grumpy su[3334]:pam_unix(su:session): session opened for user root(uid=0) bysmaug42(uid=1000) 
Oct 19 07:24:49 grumpy plasmashell[1805]:**file:///home/****smaug42****/.local/share/plasma/plasmoids/com.github.zren.simpleweather/contents/ui/WeatherData.qml:73:TypeError: Property 'value' of object envcan,weather,Vancouver, BC isnot a function**
Oct 19 07:27:14 grumpy plasmashell[1805]:**file:///home/****smaug42****/.local/share/plasma/plasmoids/com.github.zren.simpleweather/contents/ui/lib/ConfigComboBox.qml:69:TypeError: Cannot read property 'value' of undefined**
Oct 19 07:27:22 grumpy plasmashell[1805]:**file:///home/****smaug42****/.local/share/plasma/plasmoids/com.github.zren.simpleweather/contents/ui/config/WeatherStationPicker.qml:80:ReferenceError: weatherStationConfigPage is not defined**
Oct 19 07:27:47 grumpy plasmashell[1805]:**file:///home/****smaug42****/.local/share/plasma/plasmoids/com.github.zren.simpleweather/contents/ui/config/WeatherStationPicker.qml:80:ReferenceError: weatherStationConfigPage is not defined**
Oct 19 07:29:10 grumpy su[4169]: **(toroot) ****smaug42****onpts/1**
Oct 19 07:29:10 grumpy su[4169]:pam_unix(su:session): session opened for user root(uid=0) bysmaug42(uid=1000) 
Oct 19 07:30:10 grumpy baloo_file[1803]:6545298230936323"/home/**smaug42**/Downloads/openSUSE-Tumbleweed-DVD-x86_64-Snapshot20191016-Media.iso"renaming "Unconfirmed 15657.crdownload" to"openSUSE-Tumbleweed-DVD-x86_64-Snapshot20191016-Media.iso"
**grumpy:/home/smaug42#**

I also tried per another suggestion to set ProtectHome to readonly. That happened with /home on a Samsung drive. My /home and root is an NVME Samsung drive… but the sda1 is Toshiba… but was worth a try.

**grumpy:/home/smaug42#**systemctl cat fstrim.service  
**#/usr/lib/systemd/system/fstrim.service**
[Unit] 
Description=Discard unused blocks onfilesystems from /etc/fstab 
Documentation=man:fstrim(8)

[Service] 
Type=oneshot 
ExecStart=/usr/sbin/fstrim--fstab --verbose --quiet 
ProtectSystem=strict
ProtectHome=read-only 
PrivateDevices=no
PrivateNetwork=yes 
PrivateUsers=no
ProtectKernelTunables=yes 
ProtectKernelModules=yes
ProtectControlGroups=yes 
MemoryDenyWriteExecute=yes
SystemCallFilter=@default @file-system @basic-io@system-service

Rebooted and the failed mount point persists.

I’ve had some other weird things happen in the process here… google-chrome-stable suddenly disappeared from /usr/bin Then I noticed at least two other apps I installed after the initial installation were… missing their binaries… all apps are on root which is mounted at boot… and on the Samsun NVME drive. zypper and the RPM database insisted the apps were installed. Force reinstalled the missing apps and everything works again.

This is the first time Tumbleweed has given me any issues at all in years now… but it IS a new PC this time vs old hardware that was happy with Tumbleweed.

At this point… since it’s a fresh install without any history, I’m probably just going to rebuild and re-install again. It was working 100% fine up until yesterday. I want to see if I can recreate the sequence of events that lead up to the problem appearing. Maybe it was something I did? Weird symptom though… silent failing mount. Hmmm

11

Hi
Before you do that, just run a manual fsck on the partition in question first with it unmounted.

12

Tried that:

**grumpy:/home/smaug42#**fsck /dev/sda1 
fsck from util-linux 2.34 
e2fsck1.45.4 (23-Sep-2019) 
stuff: clean, 209686/61054976 files,78648967/244190208 blocks 
**grumpy:/home/smaug42#**fsck -f /dev/sda1 
fsck from util-linux 2.34
e2fsck 1.45.4 (23-Sep-2019) 
Pass 1: Checking inodes,blocks, and sizes 
Inode 48765873 extent tree (at level 1) couldbe narrower.  Optimize<y>? yes 
Inode 49152662 extenttree (at level 2) could be narrower.  Optimize<y>? yes
Inode 49152663 extent tree (at level 1) could be narrower. Optimize<y>? yes 
Inode 49152665 extent tree (atlevel 1) could be narrower.  Optimize<y>? yes 
Inode49545771 extent tree (at level 1) could be narrower.  Optimize<y>?yes 
Inode 49547065 extent tree (at level 1) could be narrower. Optimize<y>? yes 
Inode 49547117 extent tree (atlevel 1) could be narrower.  Optimize<y>? yes 
Inode49547118 extent tree (at level 1) could be narrower.  Optimize<y>?yes 
Inode 49547203 extent tree (at level 1) could be narrower. Optimize<y>? yes 
Inode 49676290 extent tree (atlevel 1) could be narrower.  Optimize ('a' enables 'yes' to all)<y>? yes 
Inode 49676466 extent tree (at level 1) could benarrower.  Optimize ('a' enables 'yes' to all) <y>? yes toall 
Inode 49807576 extent tree (at level 1) could be narrower. Optimize? yes 

Inode 49938705 extent tree (at level1) could be narrower.  Optimize? yes 

Inode 49940620extent tree (at level 1) could be narrower.  Optimize? yes

Inode 49940621 extent tree (at level 1) could benarrower.  Optimize? yes 

Inode 50069680 extent tree(at level 1) could be narrower.  Optimize? yes 

Inode50200973 extent tree (at level 2) could be narrower.  Optimize?yes 

Inode 50200974 extent tree (at level 2) could benarrower.  Optimize? yes 

Inode 50200975 extent tree(at level 2) could be narrower.  Optimize? yes 

Pass1E: Optimizing extent trees 
Pass 2: Checking directorystructure 
Pass 3: Checking directory connectivity 
Pass 4:Checking reference counts 
Pass 5: Checking group summaryinformation 

stuff: ***** FILE SYSTEM WAS MODIFIED *****
stuff: 209686/61054976 files (3.7% non-contiguous),78648917/244190208 blocks 
**grumpy:/home/smaug42#**fsck -f /dev/sda1 
fsck from util-linux 2.34
e2fsck 1.45.4 (23-Sep-2019) 
Pass 1: Checking inodes,blocks, and sizes 
Pass 2: Checking directory structure 
Pass3: Checking directory connectivity 
Pass 4: Checking referencecounts 
Pass 5: Checking group summary information 
stuff:209686/61054976 files (3.7% non-contiguous), 78648917/244190208blocks 
**grumpy:/home/smaug42#**

Rebooted and the same thing…

13

Hi
And if you run (as root user) the command mount -a after booting it mounts ok?

14

Yup, all is good after that.

It mounts during boot, them immediately unmounts… boot completes. I run mount -a as root and it’s back and seems to work just fine. I’m still at a loss as to what’s changed. It was working the way it is supposed to after install. I ran the post install zypper dup and then installed the Nvidia. This was at least 2 restarts and it was fine. Installed apps, installed Steam, installed a few games on sda1. Restarted once or twice in there… all OK, then yesterday I shut down the system to reroute the electrical cables - tuck them up in a cable tray under the desk instead of just straight from the power bar across the floor where they can be stepped on. Plugged all back in… drive won’t mount on boot. No updates were applied between the previous restart and the one where teh prob showed up, and no system changes beyond installing some Steam games to sda1.

15

Hi
Not funky SATA cables or power to the drive in question? Maybe unplug/plug just to be sure?

16

[QUOTE=smaug42;2917456]This is what I get:

**grumpy:/home/smaug42#**[/FONT]journalctl -b --grep smaug42 [FONT=monospace]-- Logs begin at Wed2019-10-16 20:48:24 PDT, end at Sat 2019-10-19 07:31:54 PDT. -- 
Oct19 07:23:41 grumpy systemd[1]: Mounting /home/smaug42/stuff... 
**Oct19 07:23:41 grumpy systemd[1]: Mounted /home/smaug42/stuff.
#provide details between 07:23:41 and 07:23:42
Oct19 07:23:42 grumpy systemd[1]: Unmounting /home/smaug42/stuff... **
Oct19 07:23:42 grumpy systemd[1]: home-smaug42-stuff.mount: Succeeded.
Oct 19 07:23:42 grumpy systemd[1]: Unmounted/home/smaug42/stuff. 
Oct 19 07:23:46 grumpysystemd-logind[1665]: New session 1 of user smaug42. 
Oct 1907:23:46 grumpy systemd[1675]: pam_unix(systemd-user:session):session opened for user smaug42(uid=1000) by (uid=0) 
Oct 1907:23:46 grumpy systemd[1]: Started Session 1 of user smaug42.
...
**grumpy:/home/smaug42#**

systemd[1] properly mounts and unmounts on its own sda1. To find out what triggers unmount detailed information on what is going on is needed. Run ‘journalctl -b’ and post the relevant time span.

17

systemd[1] properly mounts and unmounts on its own sda1. To find out what triggers unmount detailed information on what is going on is needed. Run ‘journalctl -b’ and post the relevant time span.

I’ll have to get back on this one.

Not funky SATA cables or power to the drive in question? Maybe unplug/plug just to be sure?

I started today’s debugging with this in mind. Things I’ve tested on the hardware side:

  • Swapped out the Toshiba 1TB drive for a known good WesternDigital 1TB drive. Reinstalled Tumbleweed from scratch (may as well since it only takes a few minutes and starting fresh might chase out the gremlins) on the NVME drive (so not installing on sda1). Set mounts during install, and drives are formatted as XFS or EXT4 in all of my tinkering. Booted after install, and could access mount points. Rebooted and mount points for sda1 are no longer automounted
  • Replaced the SATA cables and tried again. Same result.
  • Installed a 500GB laptop drive and tried again. Same result.
  • Installed Leap 15.1 and set mounts during install, bot the 500GB and 1TB drives are XFS. This works perfectly and all mount point survive multiple restarts. All software is updated via YaST and Nvidia drivers installed… a couple more restarts… mounts are still working correctly.
  • Just for fun I tried the latest Mint Cinnamon and it also worked 100% with no issues on the drive/partition mounting thing

So from this I assume it is not a hardware issue with either the drives or the cables. I also assume it’s a Tumbleweed specific issue.

Now it’s back to reinstalling Tumbleweed - my first try will be to change repos and zypper dup to see if things work after an upgrade instead of a direct install. If it all fails I’ll dig into the journal as suggested and see if I can extract the relevant log info.

18

Rather than extract bits and possibly miss something useful… the entire output is here: SUSE Paste

I’m back on a clean Tumbleweed install and mounts are not staying mounted through a restart. as before mount -a mounts everything and they stay cleanly mounted until restart. I’ve added another drive in the process, so now I’ve got:

  • an NVME drive which is root plus /home and /swap. This drive automounts all partitions cleanly after a restart… no problems here.
  • a Seagate 500MB platter drive on /dav/sda, partitioned as sda1 and XFS, mounted as /home/smaug42/data. This drive is unmounted after a restart
  • a WD 1TB platter drive on /dev/sdb, partitioned as sdb1 and XFS, mounted as /home/smaug42/games. This drive is unmounted after a restart
19

That is what you should have started with instead of posting randomly selected lines.

All filesystems are unmounted, not only one:


Oct 19 18:39:00 linux-kep4 systemd[1]: Stopped target Local File Systems.
Oct 19 18:39:00 linux-kep4 systemd[1]: Reached target Network (Pre).
Oct 19 18:39:00 linux-kep4 systemd[1]: Stopped target Swap.
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /.snapshots...
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /boot/efi...
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /boot/grub2/i386-pc...
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /boot/grub2/x86_64-efi...
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /home/smaug42/games...
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /home/smaug42/storage...
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /opt...
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /root...
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /srv...
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /usr/local...
Oct 19 18:39:00 linux-kep4 systemd[1]: Stopping Flush Journal to Persistent Storage...
Oct 19 18:39:00 linux-kep4 systemd[1]: Stopping Load/Save Random Seed...
Oct 19 18:39:00 linux-kep4 systemd[1]: cups.path: Succeeded.

This looks like conflicts between some units, so starting one unit stops conflicting ones. Boot with “systemd.log_level=debug printk.devkmsg=on” kernel parameters and post full “journalctl -b” outupt immediately after boot.

20

That’s exactly what I guessed would happen upon reinstalling. Checked the above paste and found some puzzling behavior:

Oct 19 18:39:00 linux-kep4 systemd[1]: issue-generator.service: Succeeded.
Oct 19 18:39:00 linux-kep4 systemd[1]: Started Generate issue file for login session.
Oct 19 18:39:00 linux-kep4 systemd[1]: Started Apply settings from /etc/sysconfig/keyboard.
Oct 19 18:39:00 linux-kep4 systemd[1]: Started firewalld - dynamic firewall daemon.
Oct 19 18:39:00 linux-kep4 systemd[1]: Created slice system-configure\x2dprinter.slice.
Oct 19 18:39:00 linux-kep4 systemd[1]: Stopped target Local File Systems.
Oct 19 18:39:00 linux-kep4 systemd[1]: Reached target Network (Pre).
Oct 19 18:39:00 linux-kep4 systemd[1]: Stopped target Swap.
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /.snapshots...
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /boot/efi...
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /boot/grub2/i386-pc...
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /boot/grub2/x86_64-efi...
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /home/smaug42/games...
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /home/smaug42/storage...
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /opt...
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /root...
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /srv...
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounting /usr/local...
Oct 19 18:39:00 linux-kep4 systemd[1]: Stopping Flush Journal to Persistent Storage...
Oct 19 18:39:00 linux-kep4 systemd[1]: Stopping Load/Save Random Seed...
Oct 19 18:39:00 linux-kep4 systemd[1]: cups.path: Succeeded.
Oct 19 18:39:00 linux-kep4 kernel: XFS (sdb1): Unmounting Filesystem
Oct 19 18:39:00 linux-kep4 kernel: XFS (sda1): Unmounting Filesystem
Oct 19 18:39:00 linux-kep4 systemd[1]: Stopped CUPS Scheduler.
Oct 19 18:39:00 linux-kep4 systemd[1]: Reached target System Time Synchronized.
Oct 19 18:39:00 linux-kep4 systemd[1]: Started Timeline of Snapper Snapshots.
Oct 19 18:39:00 linux-kep4 systemd[1]: Stopping Update UTMP about System Boot/Shutdown...
Oct 19 18:39:00 linux-kep4 systemd[1]: systemd-logind.service: Succeeded.
Oct 19 18:39:00 linux-kep4 systemd[1]: Stopped Login Service.
Oct 19 18:39:00 linux-kep4 systemd[1]: \x2esnapshots.mount: Succeeded.
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounted /.snapshots.
Oct 19 18:39:00 linux-kep4 systemd[1]: boot-efi.mount: Succeeded.
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounted /boot/efi.
Oct 19 18:39:00 linux-kep4 systemd[1]: boot-grub2-i386\x2dpc.mount: Succeeded.
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounted /boot/grub2/i386-pc.
Oct 19 18:39:00 linux-kep4 systemd[1]: boot-grub2-x86_64\x2defi.mount: Succeeded.
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounted /boot/grub2/x86_64-efi.
Oct 19 18:39:00 linux-kep4 systemd[1]: opt.mount: Succeeded.
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounted /opt.
Oct 19 18:39:00 linux-kep4 systemd[1]: root.mount: Succeeded.
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounted /root.
Oct 19 18:39:00 linux-kep4 systemd[1]: srv.mount: Succeeded.
Oct 19 18:39:00 linux-kep4 systemd[1]: Unmounted /srv.