Of note . . . haven´t had time to again SSH into the TW system, other pressing matters going on. Today is Gecko rolling MATE day . . . essentially a stack on TW . . . no problems with fast log in and booting apps . . . .
Problem continues in TW after a number of zypper dupś . . . unabated. There was a post on the Factory list-serve from a gent asking, ¨Does anybody else have problems with slow log in after recent update in TW?" I and another gent responded in the affirmative . . . .
Finally had some time and head space to again try to mess with this problem, since the “multi-user” log in is NOT where the problem happens I did not “set-default” to multi-user. I simply “disabled firewalld,” rebooted to log in window, then flipped to a TTY and ran “systemctl start sshd.”
Then I went to the “non-TW” machine and ran #ssh root@192.xxxxxxxxxx and logged in and ran “#journalctl -f”
Then I went BACK to the TW machine and logged into the GUI . . . which again took 3 - 4 minutes to get the GUI populated. The TW wallpaper and mouse cursor were there right away, just no toolbar or anything else . . . ALL as before, now after about 5 zypper dups to see if new packages will fix the problem.
Watching the journalctl data showed many many lines about the “at-spi-bus-launcher” data . . . and a few other items that appeared and then were “gone” as the “bus-launcher” data came back onto the terminal . . . . I tried to scroll back up, but I guess how I have the terminal set is only showing a small amount?? I tried to use File >save contents of the journalctl -f data and it saved a document that has several hundred lines as pasted below . . . but only of what was there after the GUI was populated, so it isn’t showing any of the other potential errors . . . .
I quit the journalctl and ran the requested “systemd-analyze” commands and pasted them below. Again the data showing is highly “optimistic” as far as “boots on the desktop” or “rubber meets the desktop” goes . . . . Still 3 - 4 minutes, and then various apps are slow to boot, like console and “suspend” window. Browser boots up fairly quickly, just a long time to log in, making TW . . . “slow.”
Sep 30 16:44:31 no01.home at-spi-bus-launcher[1983]: Authorization required, but no authorization protocol specified
Sep 30 16:44:31 no01.home at-spi-bus-launcher[1983]: Authorization required, but no authorization protocol specified
Sep 30 16:44:31 no01.home at-spi-bus-launcher[1983]: Authorization required, but no authorization protocol specified
Sep 30 16:44:31 no01.home at-spi-bus-launcher[1983]: Authorization required, but no authorization protocol specified
Sep 30 16:44:31 no01.home at-spi-bus-launcher[1983]: Authorization required, but no authorization protocol specified
Sep 30 16:44:31 no01.home at-spi-bus-launcher[1983]: Authorization required, but no authorization protocol specified
Sep 30 16:44:31 no01.home at-spi-bus-launcher[1983]: Authorization required, but no authorization protocol specified
no01:~ # systemd-analyze
Startup finished in 939ms (kernel) + 4.011s (initrd) + 7.218s (userspace) = 12.169s
graphical.target reached after 7.218s in userspace.
no01:~ # systemd-analyze blame | head -10
5.314s dev-ttyS0.device
5.314s sys-devices-platform-serial8250-tty-ttyS0.device
5.312s sys-devices-platform-serial8250-tty-ttyS10.device
5.312s dev-ttyS10.device
5.311s dev-ttyS11.device
5.310s sys-devices-platform-serial8250-tty-ttyS11.device
5.310s sys-devices-platform-serial8250-tty-ttyS13.device
5.310s dev-ttyS13.device
5.308s dev-ttyS12.device
5.308s sys-devices-platform-serial8250-tty-ttyS12.device
@non_space might have to skip the head part and just look at what is happening later down the chain… Try systemd-analyze critical-chain instead.
Logs on the remote login don’t have much to say about where the CPU cycles are being devoured. That’s why many posts upthread I wrote to use top.
I don’t have a lot of time these days to mess around with systems that self-sabotage every few months, or to run tests that don’t seem to provide diagnostic, let alone therapeutic value . . . I’m care-taking for a friend with health problems–I’m tapped.
The compounding problems with TW now include the 3 to 4 minutes to get to GUI, but again reverting to disordering grub items so that other systems aren’t bootable . . . requiring more time to repair that issue, to get back to repairing the slow log in issue.
I ran out of time on it yesterday, the next test would have been the “top” run . . . but, as mentioned before that didn’t seem to show obvious issues . . . if and when I get back to it, what commands will I run to show “top” data and then how will I “record” that data to be able to post it in this hoary thread??
Perhaps you would prefer a less rolling OS like Leap. When you ride the cutting edge you must be prepared to bleed 
I have Leap, along with a number of other OSs . . . . Lately the Factory list-serve had a guy posting “TW is rock solid, never have a problem with it,” . . . then when I posted, “Lately TW is more ‘Sid-like’ than my Sid install,” he posted back, “When did this problem begin?” And that was the extent of it.
Three or so years back, I never had issues with TW, then it was “rock solid AND cutting edge,” since then . . . problematic would be an under-statement.
AND, this is just using zypper to run upgrades, no time to mess around trying “experiments” . . . zypper chooses to do stuff that messes things up . . . and then doesn’t pick up after itself, etc.
It soon will be relegated to the “Sunday at the picnic” slot in the rotation . . . master of none, etc.
Factory list-serve data from another TW user having issues with “logging in” . . . similar problem, but I don’t recall seeing anything about “udisk” or other issues they posted about. I have SATA drive, they seem to have NVMe drive . . . . But, problems with logging in to TW is the subject line . . . so there must be more than one problem??
Date: Sun, 1 Oct 2023 20:26:29 +0000
Subject: Re: Login issues after recent Tumbleweed update
Hi!
On Thu, 2023-09-28 at 22:17 -0400, xtexc@duck.com wrote:
> I got the same problem.
> I found that the stack canary protector (stack smashing detector) is aborting
> udisksd from time to time.
> And plasmashell could not start udisks2 because of this, so the desktop could
> not start up.
>
> I ran `snapper undochange` to revert the last dist-update, then ran `zypper al
> udisks2` to lock udisks2.
> After another dist-update, I logged into plasma desktop successfully.
> Now the version is `cpe:/o:opensuse:tumbleweed:20230926`.
>
> There are two issues may be useful:
> - <https://github.com/storaged-project/udisks/issues/1152>
> - <https://github.com/storaged-project/udisks/issues/1193>
> It seems that libblockdev-3.0.3 will fix this problem?
Downgrading udisks2 fixed the problem for me! Thanks for the pointer!
Adri
OK. Ran the systemd-analyze command:
# systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @6.559s
└─multi-user.target @6.559s
└─cron.service @6.558s
└─postfix.service @5.630s +888ms
└─time-sync.target @5.594s
└─chronyd.service @5.372s +216ms
└─network.target @5.324s
└─network-pre.target @5.323s
└─wpa_supplicant.service @5.268s +54ms
└─dbus.service @3.502s +90ms
└─basic.target @3.460s
└─sockets.target @3.459s
└─pcscd.socket @3.458s
└─sysinit.target @3.432s
└─systemd-update-utmp.service @3.395s +36ms
└─auditd.service @3.322s +48ms
└─systemd-tmpfiles-setup.service @3.202s +82ms
└─local-fs.target @3.197s
└─home.mount @3.158s +38ms
└─systemd-fsck@dev-disk-by\x2duuid-64c5dba2\x2dbacd\x2d4459\x2d9904\x2d6bda0fbe24e7.service @2.775s +329ms
└─dev-disk-by\x2duuid-64c5dba2\x2dbacd\x2d4459\x2d9904\x2d6bda0fbe24e7.device @584542y 2w 2d 20h 1min 48.143s +4.094s
@mrmazda And, ran the “top” command . . . since I don’t know how to interpret the performance provided by top I don’t know where to go with it. Took a couple of cell snaps.
As posted above from the journalctl data, the item that was “at the top” of the “top” data was the “usr/libexec/at-spi2/at-spi-bus-launcher” ?? systemd journal??? might have been another item. The “spi-bus-launcher” showing a PID # 2134 . . . if that means anything. Once the GUI populated that line dropped down in the mix . . . .
@non_space So this device exisits?
└─systemd-fsck@dev-disk-by\x2duuid-64c5dba2\x2dbacd\x2d4459\x2d9904\x2d6bda0fbe24e7.service @2.775s +329ms
└─dev-disk-by\x2duuid-64c5dba2\x2dbacd\x2d4459\x2d9904\x2d6bda0fbe24e7.device @584542y 2w 2d 20h 1min 48.143s +4.094s
If it’s performing a filesystem check, is it not being unmounted properly…
Lsblk -f shows that more or less number, sans \x2d but that looks like the partition where the /home folder is installed. The / filesystem is in an SSD drive and the /home is in that partition on an HDD . . . where TW had originally been installed, before the time of the SSD drive, etc.
erlangen:~ # systemd-analyze
Startup finished in 13.722s (firmware) + 1.737s (loader) + 623ms (kernel) + 27.879s (initrd) + 9.247s (userspace) = 53.210s
graphical.target reached after 9.247s in userspace.
erlangen:~ #
erlangen:~ # journalctl -b -u init.scope -g Started --no-pager
Oct 02 06:09:35 erlangen systemd[1]: Started Rule-based Manager for Device Events and Files.
Oct 02 06:09:35 erlangen systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
Oct 02 06:10:03 erlangen systemd[1]: Started Rule-based Manager for Device Events and Files.
Oct 02 06:10:04 erlangen systemd[1]: Started Security Auditing Service.
Oct 02 06:10:04 erlangen systemd[1]: Started Watch /etc/sysconfig/btrfsmaintenance.
Oct 02 06:10:04 erlangen systemd[1]: Started Watch for changes in CA certificates.
Oct 02 06:10:04 erlangen systemd[1]: Started CUPS Scheduler.
Oct 02 06:10:04 erlangen systemd[1]: Started Watch for changes in issue snippets.
Oct 02 06:10:04 erlangen systemd[1]: Started Daily Cleanup of Snapper Snapshots.
Oct 02 06:10:04 erlangen systemd[1]: Started Daily Cleanup of Temporary Directories.
Oct 02 06:10:04 erlangen systemd[1]: Started Avahi DNS Configuration Daemon.
Oct 02 06:10:04 erlangen systemd[1]: Started irqbalance daemon.
Oct 02 06:10:04 erlangen systemd[1]: Started D-Bus System Message Bus.
Oct 02 06:10:04 erlangen systemd[1]: Started RPC Bind.
Oct 02 06:10:04 erlangen systemd[1]: Started Machine Check Exception Logging Daemon.
Oct 02 06:10:04 erlangen systemd[1]: Started Avahi mDNS/DNS-SD Stack.
Oct 02 06:10:04 erlangen systemd[1]: Started User Login Management.
Oct 02 06:10:04 erlangen systemd[1]: Started Hostname Service.
Oct 02 06:10:05 erlangen systemd[1]: Started Network Manager.
Oct 02 06:10:05 erlangen systemd[1]: Started MiniDLNA is a DLNA/UPnP-AV server software.
Oct 02 06:10:05 erlangen systemd[1]: Started Start the rsync server daemon.
Oct 02 06:10:05 erlangen systemd[1]: Started VNC manager.
Oct 02 06:10:05 erlangen systemd[1]: Started CUPS Scheduler.
Oct 02 06:10:05 erlangen systemd[1]: Started NTP client/server.
Oct 02 06:10:05 erlangen systemd[1]: Started Backup of RPM database.
Oct 02 06:10:05 erlangen systemd[1]: Started Backup of /etc/sysconfig.
Oct 02 06:10:05 erlangen systemd[1]: Started btrbk backup of /home.
Oct 02 06:10:05 erlangen systemd[1]: Started Balance block groups on a btrfs filesystem.
Oct 02 06:10:05 erlangen systemd[1]: Started Defragment file data and/or directory metadata.
Oct 02 06:10:05 erlangen systemd[1]: Started Scrub btrfs filesystem, verify block checksums.
Oct 02 06:10:05 erlangen systemd[1]: Started Discard unused blocks on a mounted filesystem.
Oct 02 06:10:05 erlangen systemd[1]: Started Check if mainboard battery is Ok.
Oct 02 06:10:05 erlangen systemd[1]: Started zypper dist-upgrade.
Oct 02 06:10:05 erlangen systemd[1]: Started Daily rotation of log files.
Oct 02 06:10:05 erlangen systemd[1]: Started Daily man-db regeneration.
Oct 02 06:10:05 erlangen systemd[1]: Started Daily locate database update.
Oct 02 06:10:05 erlangen systemd[1]: Started Monthly rotation of wtmpdb.
Oct 02 06:10:05 erlangen systemd[1]: Started OpenSSH Daemon.
Oct 02 06:10:05 erlangen systemd[1]: Started The Apache Webserver.
Oct 02 06:10:05 erlangen systemd[1]: Started Getty on tty1.
Oct 02 06:10:05 erlangen systemd[1]: Started User Manager for UID 1000.
Oct 02 06:10:05 erlangen systemd[1]: Started Postfix Mail Transport Agent.
Oct 02 06:10:05 erlangen systemd[1]: Started Command Scheduler.
Oct 02 06:10:05 erlangen systemd[1]: Started X Display Manager.
Oct 02 06:10:06 erlangen systemd[1]: Started User Manager for UID 477.
Oct 02 06:10:06 erlangen systemd[1]: Started Session 2 of User sddm.
Oct 02 06:10:06 erlangen systemd[1]: Started Authorization Manager.
Oct 02 06:10:06 erlangen systemd[1]: Started Disk Manager.
Oct 02 06:10:06 erlangen systemd[1]: Started Daemon for power management.
Oct 02 06:10:11 erlangen systemd[1]: Started Session 4 of User karl.
Oct 02 06:10:11 erlangen systemd[1]: Started A remote-mail retrieval utility.
Oct 02 06:10:11 erlangen systemd[1]: Started RealtimeKit Scheduling Policy Service.
Oct 02 06:10:13 erlangen systemd[1]: Started Time & Date Service.
erlangen:~ #
karl@erlangen:~> journalctl --user -b -u init.scope -g Started
Okt 02 06:10:05 erlangen systemd[1249]: Started Daily Cleanup of User's Temporary Directories.
Okt 02 06:10:05 erlangen systemd[1249]: Started Save jAlbum Project Files.
Okt 02 06:10:11 erlangen systemd[1249]: Started D-Bus User Message Bus.
Okt 02 06:10:11 erlangen systemd[1249]: Started Baloo File Indexer Daemon.
Okt 02 06:10:11 erlangen systemd[1249]: Started sandboxed app permission store.
Okt 02 06:10:11 erlangen systemd[1249]: Started flatpak document portal service.
Okt 02 06:10:11 erlangen systemd[1249]: Started KDE Config Module Initialization.
Okt 02 06:10:12 erlangen systemd[1249]: Started KDE Daemon.
Okt 02 06:10:12 erlangen systemd[1249]: Started KDE Global Shortcuts Server.
Okt 02 06:10:12 erlangen systemd[1249]: Started User preferences database.
Okt 02 06:10:12 erlangen systemd[1249]: Started KDE Window Manager.
Okt 02 06:10:12 erlangen systemd[1249]: Started KDE Session Management Server.
Okt 02 06:10:12 erlangen systemd[1249]: Started KDE Plasma Workspace.
Okt 02 06:10:12 erlangen systemd[1249]: Started Proxies GTK DBus menus to a Plasma readable format.
Okt 02 06:10:12 erlangen systemd[1249]: Started Handle legacy xembed system tray icons.
Okt 02 06:10:12 erlangen systemd[1249]: Started KActivityManager Activity manager Service.
Okt 02 06:10:12 erlangen systemd[1249]: Started Xdg Desktop Portal For KDE.
Okt 02 06:10:12 erlangen systemd[1249]: Started KDE PolicyKit Authentication Agent.
Okt 02 06:10:12 erlangen systemd[1249]: Started PipeWire Multimedia Service.
Okt 02 06:10:12 erlangen systemd[1249]: Started Multimedia Service Session Manager.
Okt 02 06:10:12 erlangen systemd[1249]: Started Portal service.
Okt 02 06:10:12 erlangen systemd[1249]: Started Powerdevil.
Okt 02 06:10:12 erlangen systemd[1249]: Started Geoclue Demo agent.
Okt 02 06:10:12 erlangen systemd[1249]: Started Accessibility.
Okt 02 06:10:12 erlangen systemd[1249]: Started Set KDE_FULL_SESSION=1.
Okt 02 06:10:12 erlangen systemd[1249]: Started Calendar Reminders.
Okt 02 06:10:12 erlangen systemd[1249]: Started /usr/bin/kalendarac.
Okt 02 06:10:12 erlangen systemd[1249]: Started KScreen.
Okt 02 06:10:12 erlangen systemd[1249]: Started Firefox - Web Browser.
Okt 02 06:10:13 erlangen systemd[1249]: Started Virtual filesystem service.
Okt 02 06:10:13 erlangen systemd[1249]: Started Konsole - Terminal.
Okt 02 06:10:13 erlangen systemd[1249]: Started KMail - Mail Client.
Okt 02 06:10:13 erlangen systemd[1249]: Started PipeWire PulseAudio.
karl@erlangen:~>Instead of describing what you think you see, how about showing us:
lsblk -f
At least show the portion that includes 0fbe24e7, but preferably all connected storage in that system. I read that has having been in continuous check mode for 2 weeks, 2 days, 20+ hours, that or something else that’s not expected.
Infamous host erlangen has mount trouble:
erlangen:~ # systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @30.211s
└─multi-user.target @30.211s
└─fetchmail.service @23.502s +6.708s
└─network.target @23.473s
└─NetworkManager.service @22.954s +518ms
└─dbus.service @22.737s +56ms
└─basic.target @22.734s
└─sockets.target @22.734s
└─vsftpd.socket @22.734s
└─sysinit.target @22.677s
└─systemd-update-utmp.service @22.631s +45ms
└─auditd.service @22.590s +40ms
└─systemd-tmpfiles-setup.service @22.445s +102ms
└─local-fs.target @22.380s
!!!!!!!!!!!!!!!!!!!!!!!!
└─run-user-1000.mount @23.148s
!!!!!!!!!!!!!!!!!!!!!!!!
└─local-fs-pre.target @1.147s
└─systemd-tmpfiles-setup-dev.service @1.014s +69ms
└─systemd-tmpfiles-setup-dev-early.service @937ms +43ms
└─kmod-static-nodes.service @611ms +152ms
└─systemd-journald.socket
└─system.slice
└─-.slice
erlangen:~ #
Check journal for mounts:
erlangen:~ # journalctl -b -o short-monotonic -u '*mount' --no-pager
[ 1.379031] erlangen systemd[1]: Mounting /sysroot...
[ 1.438950] erlangen systemd[1]: Mounted /sysroot.
[ 7.620115] erlangen systemd[1]: Mounting FUSE Control File System...
[ 7.620619] erlangen systemd[1]: Mounting Kernel Configuration File System...
[ 7.623760] erlangen systemd[1]: Mounted FUSE Control File System.
[ 7.623806] erlangen systemd[1]: Mounted Kernel Configuration File System.
[ 7.833230] erlangen systemd[1]: Set up automount Backup.automount.
[ 7.833290] erlangen systemd[1]: Set up automount Btrbk.automount.
[ 7.833350] erlangen systemd[1]: Set up automount Crucial.automount.
[ 7.833410] erlangen systemd[1]: Set up automount HDD.automount.
[ 7.857747] erlangen systemd[1]: Mounting /boot/efi...
[ 7.875535] erlangen systemd[1]: Mounting /.snapshots...
[ 7.882664] erlangen systemd[1]: Mounting /boot/grub2/i386-pc...
[ 7.882774] erlangen systemd[1]: Mounting /boot/grub2/x86_64-efi...
[ 7.882868] erlangen systemd[1]: Mounting /home...
[ 7.885693] erlangen systemd[1]: Mounting /opt...
[ 7.887796] erlangen systemd[1]: Mounting /root...
[ 7.889134] erlangen systemd[1]: Mounting /srv...
[ 7.918108] erlangen systemd[1]: Mounting /usr/local...
[ 7.920027] erlangen systemd[1]: Mounting /var...
[ 7.929165] erlangen systemd[1]: Mounted /.snapshots.
[ 7.929236] erlangen systemd[1]: Mounted /boot/grub2/i386-pc.
[ 7.929294] erlangen systemd[1]: Mounted /boot/grub2/x86_64-efi.
[ 7.929356] erlangen systemd[1]: Mounted /home.
[ 7.929452] erlangen systemd[1]: Mounted /opt.
[ 7.993206] erlangen systemd[1]: Mounted /root.
[ 7.994617] erlangen systemd[1]: Mounted /srv.
[ 7.994751] erlangen systemd[1]: Mounted /usr/local.
[ 7.994880] erlangen systemd[1]: Mounted /var.
[ 8.433414] erlangen systemd[1]: Mounting /home-SSD...
[ 8.493425] erlangen systemd[1]: Mounted /home-SSD.
!!!!!!!!!!!!!!!!!!!!!!!!
[ 29.066061] erlangen systemd[1]: Mounted /boot/efi.
!!!!!!!!!!!!!!!!!!!!!!!!
erlangen:~ #
However the root cause is trouble with journal:
erlangen:~ # journalctl -b -o short-monotonic -u systemd-journald.service
[ 0.813859] erlangen systemd-journald[285]: Collecting audit messages is disabled.
[ 0.832409] erlangen systemd-journald[285]: Journal started
[ 0.832420] erlangen systemd-journald[285]: Runtime Journal (/run/log/journal/94f3af277bac4a8eb57da425c9677379) is 8.0M, max 628.7M, 620.7M free.
[ 6.647387] erlangen systemd-journald[285]: Journal stopped
[ 7.412466] erlangen systemd-journald[688]: Collecting audit messages is disabled.
[ 7.413464] erlangen systemd-journald[688]: Journal started
[ 7.413475] erlangen systemd-journald[688]: Runtime Journal (/run/log/journal/94f3af277bac4a8eb57da425c9677379) is 8.0M, max 628.7M, 620.7M free.
[ 7.413565] erlangen systemd[1]: systemd-journald.service: Deactivated successfully.
[ 8.044127] erlangen systemd-journald[688]: Time spent on flushing to /var/log/journal/94f3af277bac4a8eb57da425c9677379 is 51.472ms for 1320 entries.
[ 8.044127] erlangen systemd-journald[688]: System Journal (/var/log/journal/94f3af277bac4a8eb57da425c9677379) is 599.9M, max 4.0G, 3.4G free.
[ 8.044322] erlangen systemd-journald[688]: Received client request to flush runtime journal.
[ 8.070103] erlangen systemd-journald[688]: /var/log/journal/94f3af277bac4a8eb57da425c9677379/system.journal: Journal file uses a different sequence number ID, rotating.
[ 8.070110] erlangen systemd-journald[688]: Rotating system journal.
!!!!!!!!!!!!!!!!!!!!!!!!
[ 30.408751] erlangen systemd-journald[688]: /var/log/journal/94f3af277bac4a8eb57da425c9677379/user-1000.journal: Journal file uses a different sequence number ID, rotating.
!!!!!!!!!!!!!!!!!!!!!!!!
erlangen:~ #
Journal rotation slowed down due to journal file. Target local-fs.target waits for completion of systemd-journald.service.
Performed some vacuuming and checked rotation:
erlangen:~ # journalctl -b -u systemd-journald.service --since 10:00
Oct 02 10:45:22 erlangen systemd-journald[688]: System Journal (/var/log/journal/94f3af277bac4a8eb57da425c9677379) is 368.6M, max 4.0G, 3.6G free.
Oct 02 10:45:22 erlangen systemd-journald[688]: Received client request to rotate journal, rotating.
Oct 02 10:45:22 erlangen systemd-journald[688]: Vacuuming done, freed 0B of archived journals from /var/log/journal/94f3af277bac4a8eb57da425c9677379.
erlangen:~ #
Upon reboot trouble occurs again:
erlangen:~ # journalctl -b -o short-monotonic -u systemd-journald.service
[ 0.715738] erlangen systemd-journald[285]: Collecting audit messages is disabled.
[ 0.737167] erlangen systemd-journald[285]: Journal started
[ 0.737177] erlangen systemd-journald[285]: Runtime Journal (/run/log/journal/94f3af277bac4a8eb57da425c9677379) is 8.0M, max 628.7M, 620.7M free.
[ 28.400657] erlangen systemd-journald[285]: Journal stopped
[ 29.066276] erlangen systemd-journald[770]: Collecting audit messages is disabled.
[ 29.067261] erlangen systemd-journald[770]: Journal started
[ 29.067271] erlangen systemd-journald[770]: Runtime Journal (/run/log/journal/94f3af277bac4a8eb57da425c9677379) is 8.0M, max 628.7M, 620.7M free.
[ 29.067362] erlangen systemd[1]: systemd-journald.service: Deactivated successfully.
[ 29.688159] erlangen systemd-journald[770]: Time spent on flushing to /var/log/journal/94f3af277bac4a8eb57da425c9677379 is 40.635ms for 1355 entries.
[ 29.688159] erlangen systemd-journald[770]: System Journal (/var/log/journal/94f3af277bac4a8eb57da425c9677379) is 380.4M, max 4.0G, 3.6G free.
[ 29.688359] erlangen systemd-journald[770]: Received client request to flush runtime journal.
[ 29.705375] erlangen systemd-journald[770]: /var/log/journal/94f3af277bac4a8eb57da425c9677379/system.journal: Journal file uses a different sequence number ID, rotating.
[ 29.705378] erlangen systemd-journald[770]: Rotating system journal.
[ 31.107969] erlangen systemd-journald[770]: /var/log/journal/94f3af277bac4a8eb57da425c9677379/user-1000.journal: Journal file uses a different sequence number ID, rotating.
erlangen:~ #
There is a big gap in kernel messages:
[ 6.360430] erlangen kernel: [drm] Initialized amdgpu 3.54.0 20150101 for 0000:0b:00.0 on minor 1
[ 6.368319] erlangen kernel: fbcon: amdgpudrmfb (fb0) is primary device
[ 6.368480] erlangen kernel: [drm] DSC precompute is not needed.
[ 6.455874] erlangen kernel: Console: switching to colour frame buffer device 240x67
[ 6.494042] erlangen kernel: amdgpu 0000:0b:00.0: [drm] fb0: amdgpudrmfb frame buffer device
[ 27.006864] erlangen kernel: scsi 12:0:0:0: tag#20 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[ 27.006870] erlangen kernel: scsi 12:0:0:0: tag#20 CDB: Inquiry 12 00 00 00 24 00
[ 27.023532] erlangen kernel: scsi host12: uas_eh_device_reset_handler start
[ 27.154698] erlangen kernel: usb 2-2: reset SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[ 27.183807] erlangen kernel: scsi host12: uas_eh_device_reset_handler success
[ 27.186861] erlangen kernel: scsi 12:0:0:0: tag#20 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
[ 27.186864] erlangen kernel: scsi 12:0:0:0: tag#20 CDB: Test Unit Ready 00 00 00 00 00 00
Each boot has different trouble. However error messages from scsi are persistent:
erlangen:~ # journalctl -b _KERNEL_SUBSYSTEM=scsi
Oct 02 11:39:39 erlangen kernel: scsi host0: ahci
Oct 02 11:39:39 erlangen kernel: scsi host1: ahci
Oct 02 11:39:39 erlangen kernel: scsi host2: ahci
Oct 02 11:39:39 erlangen kernel: scsi host3: ahci
Oct 02 11:39:39 erlangen kernel: scsi host4: ahci
Oct 02 11:39:39 erlangen kernel: scsi host5: ahci
Oct 02 11:39:39 erlangen kernel: scsi host6: ahci
Oct 02 11:39:39 erlangen kernel: scsi host7: ahci
Oct 02 11:39:39 erlangen kernel: scsi host8: ahci
Oct 02 11:39:39 erlangen kernel: scsi host9: ahci
Oct 02 11:39:39 erlangen kernel: scsi host10: ahci
Oct 02 11:39:39 erlangen kernel: scsi host11: ahci
Oct 02 11:39:39 erlangen kernel: scsi 0:0:0:0: Direct-Access ATA CT2000BX500SSD1 030 PQ: 0 ANSI: 5
Oct 02 11:39:39 erlangen kernel: sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
Oct 02 11:39:39 erlangen kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 02 11:39:39 erlangen kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 02 11:39:39 erlangen kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 02 11:39:39 erlangen kernel: sd 0:0:0:0: [sda] Preferred minimum I/O size 512 bytes
Oct 02 11:39:39 erlangen kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Oct 02 11:39:39 erlangen kernel: scsi 1:0:0:0: CD-ROM PIONEER DVD-RW DVR-221 1.00 PQ: 0 ANSI: 5
Oct 02 11:39:39 erlangen kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Oct 02 11:39:39 erlangen kernel: scsi 1:0:0:0: Attached scsi generic sg1 type 5
Oct 02 11:39:39 erlangen kernel: sr 1:0:0:0: [sr0] scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray
Oct 02 11:39:40 erlangen kernel: sr 1:0:0:0: Attached scsi CD-ROM sr0
Oct 02 11:39:41 erlangen kernel: scsi host12: uas
!!!!!!!!!!!!!!!!!!!!!!!!
Oct 02 11:40:03 erlangen kernel: scsi 12:0:0:0: tag#8 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
Oct 02 11:40:03 erlangen kernel: scsi 12:0:0:0: tag#8 CDB: Inquiry 12 00 00 00 24 00
Oct 02 11:40:03 erlangen kernel: scsi host12: uas_eh_device_reset_handler start
Oct 02 11:40:03 erlangen kernel: scsi host12: uas_eh_device_reset_handler success
Oct 02 11:40:03 erlangen kernel: scsi 12:0:0:0: tag#8 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
Oct 02 11:40:03 erlangen kernel: scsi 12:0:0:0: tag#8 CDB: Test Unit Ready 00 00 00 00 00 00
Oct 02 11:40:03 erlangen kernel: scsi host12: uas_eh_device_reset_handler start
Oct 02 11:40:03 erlangen kernel: scsi host12: uas_eh_device_reset_handler success
Oct 02 11:40:03 erlangen kernel: scsi 12:0:0:0: Device offlined - not ready after error recovery
!!!!!!!!!!!!!!!!!!!!!!!!
erlangen:~ #
The trouble is related to an USB-C device attached during boot. It started after duping from 20230922-0 → 20230925-0. Removing the device makes infamous host erlangen great again:
erlangen:~ # systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @8.949s
└─multi-user.target @8.949s
└─fetchmail.service @2.374s +6.574s
└─network.target @2.334s
└─NetworkManager.service @1.972s +361ms
└─dbus.service @1.745s +56ms
└─basic.target @1.742s
└─sockets.target @1.742s
└─vsftpd.socket @1.742s
└─sysinit.target @1.705s
└─systemd-update-utmp.service @1.665s +40ms
└─auditd.service @1.612s +50ms
└─systemd-tmpfiles-setup.service @1.493s +81ms
└─local-fs.target @1.438s
└─run-user-1000.mount @2.091s
└─local-fs-pre.target @1.060s
└─systemd-tmpfiles-setup-dev.service @932ms +72ms
└─systemd-tmpfiles-setup-dev-early.service @795ms +93ms
└─kmod-static-nodes.service @506ms +112ms
└─systemd-journald.socket
└─system.slice
└─-.slice
erlangen:~ #
The data for that partition was provided in the post above . . . today is now Leap 15.6 alpha day, may not have time to reboot to TW and run any commands on it . . . . TW is now “just one of the guys” instead of being the “controller of the teams.”
4 internal drives are in this machine . . . everything was running fine until the approx start of this thread . . . as previously mentioned, long ago.
Indeed, the infamous host stops by . . . was that to show the steps needed to totally analyze the problem . . . or to infamously point out that the host was also having problems booting his system cleanly . . . and then solved it??
Asking for a friend. I haven’t had a usb-c drive plugged into my machine if that relates to anything.
@non_space so the hdd for $HOME, these are separate partitions, or sharing? Can you boot to multi-user target and run a manual fsk on the device, then switch to graphical target, so we can eliminate that as an issue.
The /home directory in that partition is probably shared with a couple other linux installs . . . .
Again, the only system on the machine with these issues is the TW install.
I’ll have to dig through my notes to find how to run an fsck in openSUSE . . . . I’ll post back when that time is available to do it.