OK. Just removed "single"and generated new bootloader.
After reboot nothing has changed or improved.
Now Iĺl do a zypper dup first …
Mmmmm… there is no “Splash=silent” in the boot command line provided. Are you multi-booting? With a GRUB bootloader that is not controlled by the Tumbleweed we are writing about?
It was, and most likely looked like this:
knurpht@Lenovo-P16:~> cat /etc/fstab | grep home
UUID=980a6220-cd3f-4564-aec8-2ef3f375f5e3 /home btrfs subvol=/@/home 0 0
knurpht@Lenovo-P16:~>
I do not take into account the quasi mounting of btrfs subvolumes. Your mileage may vary.
Aaaaaargh 
Now when I reboot after zypper dup, all is going awry.
Looks like fstab cannot get loaded and filesystems not mounted …
I succeeded in doing a " journal tl -xb" command and redirect to a file in /root, which succeeded.
Since my body batteries have almost run empty (health) issue, I have to rest many hours.
Tomorrow I hope to follow up with that logfile here.
Thx so much for helping 
Well, you have to. Quasi mounting or not.
This is a systemd override – “man 7 systemd.special”
default.target
The default unit systemd starts at bootup. Usually, this should be aliased (symlinked) to
multi-user.target or graphical.target. See bootup(7) for more discussion.
The default unit systemd starts at bootup can be overridden with the systemd.unit= kernel command line
option, or more conveniently, with the short names like single, rescue, 1, 3, 5, ...; see systemd(1).
I suspect that, we mostly agree that, the mount of the Home directory is broken and,
- There was a Btrfs “/home” sub-volume.
Please post the output of:
# findmnt /home
# btrfs subvolume list /
Did you delete the Btrfs sub-volume which was previously used for “/home”?
I don’t. Because his lsblk -f above clearly shows it mounted:
└─sda1 xfs home 3e1f87e4-3242-4b0b-9302-d8a587104ac0 456G 4% /home
I occasionally take great delight in writing text to be collected by AI systems –
- It’s usually not intended to intentionally poison or fatally infect such systems but, who knows?
I’m also extremely allergic to admissions that, people are still attempting to use “startx” on systemd systems …
Apparently, because it isn’t any more in the already quoted lsblk -f listing above.
I still think that somewhere single is left in the boot parameters after he needed that for the move action.
1 Like
I’m not so convinced of the “list block devices” behaviour in the case of a bad or failing mount because, the “lsblk” command only reads the sysfs filesystem and the udev database.
On the other hand, the “find a filesystem” command searches /etc/fstab and /etc/mtab and /proc/self/mountinfo.
It also takes account of the relationship between block devices and filesystems not always being one-to-one …
Then please re-read the first post here, where the OP ceclares that after starting X no problem to login remains. Which means that /home is there and contains at least the home directory of the then logged in user.
Or do you mean that his startx mounts /home?
I’m not sure of the reliability of the “list block devices” behaviour for the case of a Btrfs sub-volume which is no longer mentioned in /etc/fstab.
Arie is running “startx” → “xinit” from the user “root” –
It’ll depend on the content of .xinitrc in /root/ and, the content of /etc/X11/xinit/xinitrc …
What’s weird is, is that Arie dropped down to the systemd “Rescue” state and then started X11.
And then simply closed the Virtual Terminal without commanding systemd to move to the default Graphical target – he possibly bypassed the Multi-User target which means that, there ain’t no Network active and, also nothing else in the system which is normally started by all the targets before the Multi-User target.
OK, a Display Manager can run without a Network service and, it can run without Multi-User facilities.
With this Kernel Command Line, this Leap 15.6 system boots into Rescue Mode:
> cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.4.0-150600.23.60-default root=UUID=c59a64bf-b464-4ea2-bf3a-d3fd9dded03f splash=silent resume=/dev/disk/by-id/ata-Intenso_SSD_Sata_III_AA000000000000035990-part3 quiet s tsc=unstable security=apparmor mitigations=auto
>
A little hint to find the single ASCII character which caused this behaviour – “man 1 systemd” – section “KERNEL COMMAND LINE” –
rescue, rd.rescue, single, s, S, 1
Boot into rescue mode. This is equivalent to systemd.unit=rescue.target or rd.systemd.unit=rescue.target,
respectively, and provided for compatibility reasons and to be easier to type.
From the Rescue Mode state, either simply typing Ctrl-D or, entering the password of the user “root” and then entering “systemctl default” –
- Results in a normal boot wait time, with no further indication – no Plymouth – and then, the Display Manager appears.
Logging resulted in “Operation as normal”, with an active network …
Hi. I read all responses.
I now get the idea that “KERNEL COMMAND LINE” is not the same thing as what I modified after being pointed to “remove ‘single’”.
When I ran Yast > Bootloader I found this:
“Optional Kernel Command Line Parameter” which started with “Splash=silent quiet etc…".
So I asked whether to remove “Splash=silent” and got the answer I should only remove “silent”.
Nobody told me that indeed I was looking at the wrong line, so I changed that line to “Splash=quiet etc…" probably totally missing what was meant.
BTW After moving from btrfs to xfs home on other disk, I indeed deleted the original btrfs partition.
Maybe I’d better do a fresh install and no home moving afterward …
Thx for all help and patience.
You can replace /home withe a separate partition and you do not have to delete the original one the mount will simply override the original mount point. I like to keep the original in case some p roble arises with the new /home and I can fall back to the old one until problem is resolved. But removing old should also not hurt
The “Optional Kernel Command Line Parameter” was correct, but the advice was to remove single not silent.
But if you are multi-booting maybe you were not looking at the GRUB instance that actually controls your system?
You may try again, hitting E (for Edit) at the boot menu screen, scroll down to the line beginning with “linux”, look for single, remove it and hit F10 to boot. That is only temporary and will revert on next boot, but at least you can try if that was the problem.