My server has 800+ days uptime, but ever since a couple weeks the **MySQL server** keeps hitting **100% CPU** and I have to restart the mysqld service. Where do I start to find out where this issue is coming from? As all the sites on my server keep freezing until I restart. I don't want to keep restarting the service every time. Sometimes it is after a couple minutes, sometimes a couple hours, sometimes a couple days. Nothing changed really. I only once updated the my.cnf file for the default character set and restarted recently, but I don't believe this is linked in any way. **--- Server details ---**
Debian 10 Buster
MySQL Version: 14.14
Average users: 150 - 200 per day
vCPU's: 4
RAM: 4GB
**my.cnf** No slow queries shown so far. [mysqld] collation_server = utf8mb4_unicode_ci character_set_server = utf8mb4 sql-mode="NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION" slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow_queries.log log_queries_not_using_indexes = 'OFF' long_query_time = 5

I have been investigating to fix what appears to be a problem with systemd watchdog but with no success. I have a bunch of services that are of Type=notify. If the system time is set backwards, every service is killed by systemd because it thinks the watchdog timeout was hit. Here is the debug log from systemd systemd: xxx:service: Unit entered failed state. systemd: xxx:service: Failed with result 'watchdog'. Is there a way to tell Systemd not to restart services when the system time is changed manually? Shouldn't the watchdog depend on the CLOCK_MONOTONIC? Is this a known issue in Systemd?

Looking at last reboot | head -3, I get the following result:

reboot   system boot  5.7.10-201.fc32. Fri Jul 31 11:29   still running
reboot   system boot  5.7.10-201.fc32. Fri Jul 31 11:22 - 09:29  (-1:53)
reboot   system boot  5.7.10-201.fc32. Tue Jul 28 23:14 - 09:21 (2+10:07)

I thought at first that the times and dates were showed as "boot - shutdown", but this doesn't make sense considering the second line that shows a negative time difference. procinfo returns the correct boot time:

$ procinfo | grep Bootup
Bootup: Fri Jul 31 09:29:39 2020    Load average: 0.01 0.06 0.06 1/1071 28719

The hardware clock shows the correct time:

$ date; sudo hwclock --show
Fri 31 Jul 2020 11:55:17 AM CEST
2020-07-31 11:55:17.436472+02:00

The problem seems to lie with last reboot and who -b:

$ date; uptime; who -b
Fri 31 Jul 2020 11:55:43 AM CEST
 11:55:43 up  2:26,  2 users,  load average: 0.00, 0.04, 0.05
         system boot  2020-07-31 11:29

/var/run/utmp, read by default by who -b, doesn't exist on my system and /var/log/wtmp, read by last reboot, has the following permissions:

$ ll /var/log/wtmp
-rw-rw-r--. 1 root utmp 39K Jul 31 11:23 /var/log/wtmp

What could be the reason of these discrepancies? **EDIT** The correct shutdown time is 09:29 UTC+2. The 11:29 and 11:22 times from last reboot should be 09:29 and 09:22, respectively. As observed by @telcoM, one could think that early boot might be using UTC timezone, but then the 11:29 should be 07:29... Another detail: I'm running a simple Fedora 32 physical machine.

I can't figure out how to ask systemd to not start specific service after reboot. I tried to disable service but I can't start it after disabling because my service's unit file is not located in /etc/systemd/system. I also tried to clear WantedBy. My configuration file:

[Service]
Type=simple
Restart=no
WorkingDirectory=/home/sentinel/arbitrage
ExecStart=/home/sentinel/arbitrage/venv/bin/python -m src.settings_bot.main
User=sentinel
Group=sentinel
Environment=PYTHONUNBUFFERED=1
Environment=DEV=
StandardOutput=append:/home/sentinel/arbitrage/settings-bot-log.txt
StandardError=append:/home/sentinel/arbitrage/settings-bot-log.txt

[Install]
WantedBy=

My server is experiencing random reboots, and I haven't been able to locate any logs explaining the cause. Below are the system details. OS: Debian 12.8 (bookworm) Hardware: SMC (SYS-111E-FWTR) kernel: Linux Dev-test 6.1.0-28-rt-amd64 #1 SMP PREEMPT_RT Debian 6.1.119-1 (2024-11-22) x86_64 GNU/Linux Drivers: ice (v1.15.5) iavf(v4.12.6) mlx5_core(24.10-1.1.4) ipmitool mc watchdog get Watchdog Timer Use: SMS/OS (0x44) Watchdog Timer Is: Started/Running Watchdog Timer Logging: On Watchdog Timer Action: No action (0x00) Pre-timeout interrupt: None Pre-timeout interval: 0 seconds Timer Expiration Flags: (0x10) * SMS/OS Initial Countdown: 300.0 sec Present Countdown: 249.5 sec last reboot reboot system boot 6.1.0-28-rt-amd6 Wed Feb 26 08:46 still running reboot system boot 6.1.0-28-rt-amd6 Wed Feb 26 07:18 - 08:43 (01:25) reboot system boot 6.1.0-28-rt-amd6 Tue Feb 25 20:42 - 08:43 (12:01) ~# uptime 10:15:03 up 1:28, 7 users, load average: 7.28, 7.76, 7.75 :~# date Wed Feb 26 10:15:05 AM EAT 2025 ~# HISTTIMEFORMAT='%Y-%m-%d %H:%M:%S ' history | grep reboot 186 2025-02-26 08:47:45 reboot 203 2025-02-26 08:47:45 reboot 250 2025-02-26 08:47:45 reboot 267 2025-02-26 08:47:45 reboot' I tried disabling watchdog action by suspecting wdt causing reboot. Verified dmesg and journal logs but no clue.

I want to obtain, for every one of my system's users (or at least, every one with a home directory under /home), the amount of disk space their files use. I have root access, but - there are many users with lots and lots of files, and the directory is an nfs-mount. So, counting is kind of slow; and my machine may be rebooted in the process, so I need to be able to resume counting after the machine is up again. What would be a decent way of achieving this? I don't very much mind the output format. Notes: * I can't set quotas. I mean, I have root access, but I don't get to do what I want.

I have a RasPi 4 connected to a 12TB EXT4 hard drive in a Sabrent cage hub which I use for an OpenMediaVault NAS. The drive worked fine for about a month until its file system started to go missing in OMV, either completely or visible and unmounted with the status "missing." I've tried automatically rebooting every 12 hours or manual restarts (the Pi and cage have separate power buttons) and cannot tell which method is more reliable. I've noticed the block device sometimes changes between sda(1) and sdb(1) and other times no partitions are listed in fdisk or df. Sometimes the drive is SMART compatible (and passes), other times it says it isn't. I've had error messages after the following commands:

**(1) [2024-11-02] sudo smartctl -a /dev/sda | less**

SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART Status not supported: Incomplete response, ATA output registers missing
SMART overall-health self-assessment test result: PASSED
Warning: This result is based on an Attribute check.

General SMART Values:
Offline data collection status:  (0x80) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                (   87) seconds.
Offline data collection
capabilities:                    (0x5b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        No Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   1) minutes.
Extended self-test routine
recommended polling time:        (   1) minutes.
SCT capabilities:              (0x003d) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   132   132   054    Pre-fail  Offline      -       96
  3 Spin_Up_Time            0x0007   155   155   024    Pre-fail  Always       -       425 (Average 425)

**(2) [2024-11-02] dmesg**

[ 1197.499680] critical target error, dev sda, sector 23437770624 op 0x0:(READ)                                                                                                                                                                                                                                              flags 0x0 phys_seg 1 prio class 2

[ 1197.499692] Buffer I/O error on dev sda, logical block 2929721328, async page                                                                                                                                                                                                                                              read

[Note: no errors in dmesg as of 2024-12-02]

**(3) [2024-12-01] sudo fdisk -l /dev/sda**

fdisk: cannot open /dev/sda: Input/output error

**(4) [2024-12-01] sudo fsck /dev/sda**

fsck.ext2: Input/output error while trying to open /dev/sda

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193  [Note: this option timed out]
 or
    e2fsck -b 32768  [Note: this option timed out]

**(5) [2024-12-01] sudo smartctl -i /dev/sda**

Read Device Identity failed: scsi error medium or hardware error (serious)

**(6) [2024-12-01] sudo smartctl --all /dev/sda1 --test=short -T permissive**

SMART support is:     Unavailable - device lacks SMART capability

Error Counter logging not supported

No Self-tests have been logged

It appears most likely to unmount after I'm away from home and don't perform updates for awhile (I have not set up a reverse proxy for the RasPi in general, only for a Plex server). I can't tell if the hard drive is about to fail or if this is all just an issue with booting.

I have a raspberry pi. I have a crontab running and telling it to reboot at mid-day every day (sudo reboot now). Here is the result of last reboot -F:

myuser@mypiname:~ $ last -F reboot
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970   still running
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970   still running
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970   still running
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Tue Oct 27 12:00:33 2020 (18562+11:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Tue Oct 27 12:00:03 2020 (18562+11:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Mon Oct 26 12:01:00 2020 (18561+11:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Mon Oct 26 12:00:31 2020 (18561+11:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Mon Oct 26 12:00:03 2020 (18561+11:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Mon Oct 26 12:00:03 2020 (18561+11:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Mon Oct 26 12:00:03 2020 (18561+11:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Sun Oct 25 12:00:33 2020 (18560+11:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Sun Oct 25 12:00:03 2020 (18560+11:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Sat Oct 24 12:00:33 2020 (18559+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Sat Oct 24 12:00:04 2020 (18559+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Fri Oct 23 12:00:03 2020 (18558+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Thu Oct 22 12:00:44 2020 (18557+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Thu Oct 22 12:00:11 2020 (18557+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Wed Oct 21 12:00:06 2020 (18556+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Tue Oct 20 12:00:33 2020 (18555+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Tue Oct 20 12:00:04 2020 (18555+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Mon Oct 19 12:00:33 2020 (18554+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Mon Oct 19 12:00:03 2020 (18554+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Sun Oct 18 12:00:04 2020 (18553+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Sat Oct 17 12:00:04 2020 (18552+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Fri Oct 16 12:00:33 2020 (18551+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Fri Oct 16 12:00:03 2020 (18551+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Fri Oct 16 12:00:03 2020 (18551+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Thu Oct 15 12:00:34 2020 (18550+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Thu Oct 15 12:00:04 2020 (18550+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Wed Oct 14 12:00:04 2020 (18549+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Wed Oct 14 12:00:04 2020 (18549+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Wed Oct 14 12:00:04 2020 (18549+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Tue Oct 13 12:00:33 2020 (18548+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Tue Oct 13 12:00:03 2020 (18548+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Mon Oct 12 12:00:36 2020 (18547+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Mon Oct 12 12:00:04 2020 (18547+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Sun Oct 11 12:00:34 2020 (18546+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Sun Oct 11 12:00:04 2020 (18546+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Sat Oct 10 12:00:33 2020 (18545+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Sat Oct 10 12:00:04 2020 (18545+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Fri Oct  9 12:02:03 2020 (18544+10:02)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Fri Oct  9 12:00:04 2020 (18544+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Thu Oct  8 12:00:34 2020 (18543+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Thu Oct  8 12:00:04 2020 (18543+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Wed Oct  7 12:00:33 2020 (18542+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Wed Oct  7 12:00:04 2020 (18542+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Tue Oct  6 12:00:04 2020 (18541+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Mon Oct  5 17:38:18 2020 (18540+15:38)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Mon Oct  5 12:00:04 2020 (18540+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Sun Oct  4 12:00:33 2020 (18539+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Sun Oct  4 12:00:03 2020 (18539+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Sat Oct  3 12:00:04 2020 (18538+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Fri Oct  2 12:00:03 2020 (18537+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Fri Oct  2 12:00:03 2020 (18537+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Thu Oct  1 18:07:11 2020 (18536+16:07)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Thu Oct  1 18:07:11 2020 (18536+16:07)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Thu Oct  1 18:07:11 2020 (18536+16:07)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Thu Oct  1 18:07:11 2020 (18536+16:07)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Thu Oct  1 18:07:11 2020 (18536+16:07)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Thu Oct  1 12:01:00 2020 (18536+10:00)
reboot   system boot  4.19.66-v7+      Thu Jan  1 01:00:01 1970 - Thu Oct  1 12:00:31 2020 (18536+10:00)

wtmp begins Thu Oct  1 10:28:43 2020

I unplugged my Raspberry Pi around 2PM today (27/10/2020 13:55:XX) but it does not show here that it had been unplugged (maybe because it is not a reboot). How do I get last boot times instead of last reboot times? Also, I would like to have "all" the boot times, not only the last. I tried last boot -F but it does not show anything.

I have rebooted my ubuntu manually, but it is failing to start again. It stays on the ubuntu logo: I tried the recovery mod and ran file disk check. Then choose resume to continue normal startup. But I ended up here: And it didn't continue to anywhere. So, I have to power off the laptop with power button. Now, this is the screen:

I'm trying to reboot a Teltonika RTU950 using ssh. I can log in as root via ssh and then reboot the router fine. However if i try to send the reboot command over ssh it does not work. ssh root@routerip 'reboot' This returns the error: ash: reboot: not found I've tried using shutdown -r instead. Also tried using absolute path. Always gives me the same error. To be noted that the error says: ash: and not bash:. The router runs on a linux os. uname gives: Linux Teltonika-RUT950.com 3.18.44 #1 Any idea what could be causing this?

I am seeing some strange/frustrating behavior with iptables in Pop!_OS, which I am struggling to understand. Firstly, I have a server, on which I want to enable incoming ssh connections. The following set of iptables rules does not seem to work (I can't connect with ssh from a remote machine): Chain INPUT (policy DROP 434 packets, 243K bytes) pkts bytes target prot opt in out source destination 854 85718 ACCEPT all -- lo any anywhere anywhere 0 0 ACCEPT icmp -- any any anywhere anywhere icmp echo-reply 5 420 ACCEPT icmp -- any any anywhere anywhere icmp echo-request 183 27170 ACCEPT udp -- any any anywhere anywhere udp spt:domain 75 9853 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh 706 528K ACCEPT tcp -- any any anywhere anywhere tcp spt:https 183K 472M ACCEPT tcp -- any any anywhere anywhere tcp spt:http 0 0 ACCEPT tcp -- any any anywhere anywhere tcp spt:ssh state ESTABLISHED Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 129K packets, 7005K bytes) pkts bytes target prot opt in out source destination However, if I run the following line, the ssh connection from the remote machine does work: $ sudo iptables -A INPUT -i lo -j ACCEPT Chain INPUT (policy DROP 434 packets, 243K bytes) pkts bytes target prot opt in out source destination 854 85718 ACCEPT all -- lo any anywhere anywhere 0 0 ACCEPT icmp -- any any anywhere anywhere icmp echo-reply 5 420 ACCEPT icmp -- any any anywhere anywhere icmp echo-request 183 27170 ACCEPT udp -- any any anywhere anywhere udp spt:domain 75 9853 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh 706 528K ACCEPT tcp -- any any anywhere anywhere tcp spt:https 183K 472M ACCEPT tcp -- any any anywhere anywhere tcp spt:http 0 0 ACCEPT tcp -- any any anywhere anywhere tcp spt:ssh state ESTABLISHED 0 0 ACCEPT all -- lo any anywhere anywhere Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 129K packets, 7005K bytes) pkts bytes target prot opt in out source destination This seems particularly puzzling, given that I seemingly had the exact same filter line enabling loopback connections beforehand. Does the ordering of the rules matter in this case? Secondly, I have the systemd netfilter-persistent service enabled, but it doesn't seem to be saving/reloading the iptables settings correctly on boot. When I reboot, the rules revert to the first example. Is anyone able to help shed some light on these issues. I need to have incoming ssh connections enabled on the server, and for the firewall settings to persist on reboot.

I’ve been experiencing significant system instability on my Ubuntu 24.04 machine after a recent BIOS update. The system randomly resets itself, and the logs show various errors. I’m hoping to get some guidance on how to troubleshoot and resolve these issues. **System Information:** ----------------------- - **OS**: Ubuntu 24.04 (Previously Ubuntu 22.04 with the same issue) - **Kernel**: 6.8.0-40-generic - **Motherboard**: Gigabyte Z790 GAMING X AX DDR5 LGA1700 (Rev 1.1) - **CPU**: Intel i7-13700k - **BIOS Version**: Updated to F11d (latest) from Gigabyte’s website due to issues with microcode for 13th and 14th generation Intel processors. The problem started after updating to F11c, and F11d did not resolve it. - **Dual Boot**: Windows and Ubuntu (Issue does not appear on Windows, at least not yet) **Issue Description:** ---------------------- Since updating the BIOS, my system has been crashing randomly, and the logs are filled with various errors. I’ve tried resetting the BIOS to its default settings, but the issue persists. The crashes occur at random moments, even when the system is idle, with no applications running. Here’s a snapshot of the errors occurring shortly after boot:

$journalctl --since "2024-08-14 12:15:00" --until "2024-08-14 12:34:00" -p 0..3                                     

sie 14 12:16:17 BMO kernel: i2c i2c-1: Invalid 7-bit I2C address 0xffff
sie 14 12:16:18 BMO kernel: iwlwifi 0000:00:14.3: WRT: Invalid buffer destination
sie 14 12:16:18 BMO kernel: 
sie 14 12:16:19 BMO kernel: Bluetooth: hci0: Malformed MSFT vendor event: 0x02
sie 14 12:16:19 BMO bluetoothd: profiles/sap/server.c:sap_server_register() Sap driver initialization failed.
sie 14 12:16:19 BMO bluetoothd: sap-server: Operation not permitted (1)
sie 14 12:16:29 BMO gdm-password]: gkr-pam: unable to locate daemon control file
sie 14 12:16:32 BMO systemd: Failed to start app-gnome-gnome\x2dkeyring\x2dpkcs11-2688.scope - Application launched by gnome-session-binary.
sie 14 12:16:32 BMO systemd: Failed to start app-gnome-gnome\x2dkeyring\x2dsecrets-2685.scope - Application launched by gnome-session-binary.
sie 14 12:16:32 BMO systemd: Failed to start app-gnome-gnome\x2dkeyring\x2dssh-2682.scope - Application launched by gnome-session-binary.
sie 14 12:16:32 BMO systemd: Failed to start app-gnome-snap\x2duserd\x2dautostart-2942.scope - Application launched by gnome-session-binary.
sie 14 12:16:32 BMO systemd: Failed to start app-gnome-user\x2ddirs\x2dupdate\x2dgtk-2950.scope - Application launched by gnome-session-binary.
sie 14 12:16:33 BMO kernel: [drm:nv_drm_master_set [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to grab modeset ownership
sie 14 12:16:33 BMO kernel: [drm:nv_drm_master_set [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to grab modeset ownership
sie 14 12:16:33 BMO kernel: [drm:nv_drm_master_set [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to grab modeset ownership
sie 14 12:16:33 BMO kernel: [drm:nv_drm_master_set [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to grab modeset ownership
sie 14 12:16:33 BMO kernel: [drm:nv_drm_master_set [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to grab modeset ownership
sie 14 12:16:33 BMO kernel: [drm:nv_drm_master_set [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to grab modeset ownership
sie 14 12:16:33 BMO kernel: [drm:nv_drm_master_set [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to grab modeset ownership
sie 14 12:16:33 BMO kernel: [drm:nv_drm_master_set [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to grab modeset ownership
sie 14 12:16:33 BMO kernel: [drm:nv_drm_master_set [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to grab modeset ownership

Troubleshooting Steps Taken So Far: ----------------------------------- - **I2C**: Running i2cdetect -y -r 1 shows a device at address 0x48, but the Invalid 7-bit I2C address 0xffff error persists.

sudo i2cdetect -y -r 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

- **WiFi**: The Intel WiFi card (iwlwifi 0000:00:14.3: WRT: Invalid buffer destination) continues to show errors even with updated drivers. - **Bluetooth**: Reinstalling bluez did not resolve the Bluetooth errors related to malformed MSFT vendor events. - **GNOME Keyring**: Multiple GNOME Keyring components fail to start, affecting other system processes. - **NVIDIA DRM**: The DRM module for NVIDIA (nv_drm_master_set) fails to grab modeset ownership, potentially causing graphical instability. - **Memtest86+**: Passed without errors, so RAM issues are unlikely. - **Temperatures**: I’ve been monitoring component temperatures closely, and none of them appear to be overheating. Additional Information: ----------------------------------- - **Dual Boot**: I have a dual-boot setup with Windows, and this issue does not occur on Windows (at least, not yet). - **BIOS Reset**: I’ve reset the BIOS to its default settings, but the issue persists. - **Random Ubuntu reboots**: The system reboot itself randomly, even when idle with no applications running. - **Previous Ubuntu Version**: The problem started on Ubuntu 22.04 after the BIOS update, so I reinstall to Ubuntu 24.04, but the issue remains. Request for Help: ----------------------------------- I’m looking for: - Guidance on identifying which of these errors might be causing the system resets. - Could the BIOS update have introduced hardware or firmware incompatibilities with the current Ubuntu kernel? - What steps can I take to isolate whether this is a hardware or software issue? Has anyone encountered similar issues post-BIOS update, and if so, how were they resolved? Any insights or suggestions would be greatly appreciated! Thank you in advance!

I come accross some unexpected auto reboot and no vmcore left. So I want to catch whenever a kernel reboot happened and who call this. As I thought before, when I input a reboot command, then the SYSCALL_DEFINE4(reboot) will be invoked and then kernel goes into the function kernel_restart. But the fact was, when I used kprobe to trace kernel_restart and entered reboot，nothing was caught ---- I've already tested on some other kernel function such as do_sys_open and ksys_umount and they all worked fine so at least my use of kprobe is not wrong. Now I wonder that is there any other way in kernel to call a reboot?

On RHEL based systems network is supposed to be managed by NetworkManager. I would like to build a persistent configuration of a VLAN-aware bridge that survives reboots. Building on top of the excellent answer by A.B. , I have created a network configuration for a virtual machine running Alma Linux 9.4 that receives VLAN 1 tagged traffic and is reachable from management VLAN. But how to make this persistent? Can it be done using standard network management tool, NetworkManager? # cat mkbr2.sh ip link add name bridge0 type bridge vlan_filtering 1 vlan_default_pvid 0 ip link set dev ens192 master bridge0 ip link set bridge0 up bridge vlan add vid 1 dev bridge0 pvid untagged self bridge vlan add vid 2-4094 dev ens192 bridge vlan add vid 1 dev ens192 pvid ip addr add 10.200.200.106/24 dev bridge0 ip route add default via 10.200.200.10 # ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens192: mtu 1500 qdisc mq master bridge0 state UP group default qlen 1000 link/ether 00:0c:29:44:89:b3 brd ff:ff:ff:ff:ff:ff altname enp11s0 6: bridge0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:0c:29:44:89:b3 brd ff:ff:ff:ff:ff:ff inet 10.200.200.106/24 scope global bridge0 valid_lft forever preferred_lft forever inet6 fe80::20c:29ff:fe44:89b3/64 scope link valid_lft forever preferred_lft forever # bridge -compressvlans vlan show port vlan-id ens192 1 PVID 2-4094 bridge0 1 PVID Egress Untagged

I am stucked on how to execute a shell script only once after the machine reboots, the file that I have has the following content where I am writing a test to get only the first element from the file:

#!/bin/bash

echo "A" >> /home/vtr/Documents/test.txt
echo "B" >> /home/vtr/Documents/test.txt 
echo "C" >> /home/vtr/Documents/test.txt

sleep 10  #this sleep I put only to the lines below be executed when the machine came back to the desktop
test=$(sort /home/vtr/Documents/test.txt | uniq | head -n 1)
echo $test >> /home/vtr/Documents/finaltest.txt

I already went through cron and by systemd but on both of them instead have only

as output I am getting a file which was ran several times:

A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A

And this is my

/etc/systemd/system/testing.service

file:

[Unit]
Description=One test script
After=network.target

[Service]
Type=oneshot
ExecStart=/home/vtr/Documents/testing.sh

[Install]
WantedBy=multi-user.target

I also tried to perform a test only writing "A","B" and "C" without the sleep, test and echo lines above

"C" >> /home/vtr/Documents/test.txt

but I am having the same thing where the output file should be:

A
B
C

But in fact it's printing and running several times also:

A
B
C
A
B
C
A
B
C
A
B
C
A
B
C
A
B
C
A
B
C
A
B
C
A
B
C

Is there anyway to run a script after reboot once?

I have a hypervisor with Ubuntu Server 18.04, on which several virtual machines are installed, running on VirtualBox. At 23:45, the physical server automatically restarted. I tried to look in syslog and kern.log, but I did not find anything about the system restart Part of syslog at the moment of restart

Aug 29 23:38:27 hypervisor dhcpd: DHCPREQUEST for 12.34.56.78 from 08:00:27:75:09:8d via vboxnet0
Aug 29 23:38:27 hypervisor dhcpd: DHCPACK on 12.34.56.78 to 08:00:27:75:09:8d via vboxnet0
Aug 29 23:38:39 hypervisor named: resolver priming query complete
Aug 29 23:39:01 hypervisor CRON: (root) CMD (  [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi)
Aug 29 23:39:07 hypervisor dhcpd: DHCPREQUEST for 123.234.123.12 from 08:00:27:c3:0c:28 via vboxnet2
Aug 29 23:39:07 hypervisor dhcpd: DHCPACK on 123.234.123.12 to 08:00:27:c3:0c:28 via vboxnet2
Aug 29 23:39:17 hypervisor systemd: Starting Clean php session files...
Aug 29 23:39:18 hypervisor systemd: Started Clean php session files.
Aug 29 23:39:33 hypervisor named: resolver priming query complete
Aug 29 23:40:57 hypervisor dhcpd: DHCPREQUEST for 12.34.56.78 from 08:00:27:75:09:8d via vboxnet0
Aug 29 23:40:57 hypervisor dhcpd: DHCPACK on 12.34.56.78 to 08:00:27:75:09:8d via vboxnet0
Aug 29 23:41:37 hypervisor dhcpd: DHCPREQUEST for 123.234.123.12 from 08:00:27:c3:0c:28 via vboxnet2
Aug 29 23:41:37 hypervisor dhcpd: DHCPACK on 123.234.123.12 to 08:00:27:c3:0c:28 via vboxnet2
Aug 29 23:41:37 hypervisor named: resolver priming query complete
Aug 29 23:43:19 hypervisor named: message repeated 3 times: [ resolver priming query complete]
Aug 29 23:43:27 hypervisor dhcpd: DHCPREQUEST for 12.34.56.78 from 08:00:27:75:09:8d via vboxnet0
Aug 29 23:43:27 hypervisor dhcpd: DHCPACK on 12.34.56.78 to 08:00:27:75:09:8d via vboxnet0
Aug 29 23:43:33 hypervisor named: resolver priming query complete
Aug 29 23:44:07 hypervisor dhcpd: DHCPREQUEST for 123.234.123.12 from 08:00:27:c3:0c:28 via vboxnet2
Aug 29 23:44:07 hypervisor dhcpd: DHCPACK on 123.234.123.12 to 08:00:27:c3:0c:28 via vboxnet2
Aug 29 23:46:03 hypervisor systemd-modules-load: Inserted module 'coretemp'
Aug 29 23:46:03 hypervisor kernel: [    0.000000] microcode: microcode updated early to revision 0xf4, date = 2022-07-31
Aug 29 23:46:03 hypervisor kernel: [    0.000000] Linux version 4.15.0-213-generic (buildd@lcy02-amd64-079) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023 (Ubuntu 4.15.0-213.224-generic 4.15.18)
Aug 29 23:46:03 hypervisor kernel: [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-213-generic root=UUID=60a0068c-dde5-4583-8574-98c0a03bb007 ro net.ifnames=0
Aug 29 23:46:03 hypervisor systemd: Started Uncomplicated firewall.
Aug 29 23:46:03 hypervisor kernel: [    0.000000] KERNEL supported cpus:
Aug 29 23:46:03 hypervisor systemd: Starting Flush Journal to Persistent Storage...
Aug 29 23:46:03 hypervisor kernel: [    0.000000]   Intel GenuineIntel
Aug 29 23:46:03 hypervisor kernel: [    0.000000]   AMD AuthenticAMD
Aug 29 23:46:03 hypervisor kernel: [    0.000000]   Centaur CentaurHauls
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Aug 29 23:46:03 hypervisor systemd: Started Set the console keyboard layout.
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x200: 'Protection Keys User registers'
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: xstate_offset:  576, xstate_sizes:  256
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: xstate_offset:  832, xstate_sizes:   64
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: xstate_offset:  896, xstate_sizes:   64
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: xstate_offset:  960, xstate_sizes:    8
Aug 29 23:46:03 hypervisor systemd: Started Load/Save Random Seed.
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: Enabled xstate features 0x21f, context size is 968 bytes, using 'compacted' format.

kern.log

Aug 26 17:24:07 hypervisor kernel: [4048716.348358] device vboxnet0 left promiscuous mode
Aug 26 17:24:07 hypervisor kernel: [4048716.348379] device vboxnet3 left promiscuous mode
Aug 26 17:24:07 hypervisor kernel: [4048716.418638] vboxnetflt: 8265681 out of 8655381 packets were not sent (directed to host)
Aug 26 17:24:07 hypervisor kernel: [4048716.470636] vboxnetflt: 388 out of 534983 packets were not sent (directed to host)
Aug 26 22:36:39 hypervisor kernel: [4067468.933959] VBoxNetFlt: attached to 'vboxnet0' / 0a:00:27:00:00:00
Aug 26 22:36:39 hypervisor kernel: [4067468.934478] VBoxNetFlt: attached to 'vboxnet3' / 0a:00:27:00:00:03
Aug 26 22:36:39 hypervisor kernel: [4067468.935191] VMMR0InitVM: eflags=246 fKernelFeatures=0x0 (SUPKERNELFEATURES_SMAP=0)
Aug 26 22:36:39 hypervisor kernel: [4067468.936917] device vboxnet0 entered promiscuous mode
Aug 26 22:36:39 hypervisor kernel: [4067468.936929] device vboxnet3 entered promiscuous mode
Aug 26 22:37:11 hypervisor kernel: [4067500.476672] VMMR0InitVM: eflags=246 fKernelFeatures=0x0 (SUPKERNELFEATURES_SMAP=0)
Aug 26 22:39:59 hypervisor kernel: [4067668.448094] device vboxnet0 left promiscuous mode
Aug 26 22:39:59 hypervisor kernel: [4067668.487732] vboxnetflt: 3543 out of 3649 packets were not sent (directed to host)
Aug 26 22:40:25 hypervisor kernel: [4067694.334590] VBoxNetFlt: attached to 'vboxnet0' / 0a:00:27:00:00:00
Aug 26 22:40:25 hypervisor kernel: [4067694.335071] device vboxnet0 entered promiscuous mode
Aug 26 22:42:31 hypervisor kernel: [4067820.931694] device vboxnet3 left promiscuous mode
Aug 26 22:42:31 hypervisor kernel: [4067821.036953] vboxnetflt: 0 out of 529 packets were not sent (directed to host)
Aug 29 23:46:03 hypervisor kernel: [    0.000000] microcode: microcode updated early to revision 0xf4, date = 2022-07-31
Aug 29 23:46:03 hypervisor kernel: [    0.000000] Linux version 4.15.0-213-generic (buildd@lcy02-amd64-079) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023 (Ubuntu 4.15.0-213.224-generic 4.15.18)
Aug 29 23:46:03 hypervisor kernel: [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-213-generic root=UUID=60a0068c-dde5-4583-8574-98c0a03bb007 ro net.ifnames=0
Aug 29 23:46:03 hypervisor kernel: [    0.000000] KERNEL supported cpus:
Aug 29 23:46:03 hypervisor kernel: [    0.000000]   Intel GenuineIntel
Aug 29 23:46:03 hypervisor kernel: [    0.000000]   AMD AuthenticAMD
Aug 29 23:46:03 hypervisor kernel: [    0.000000]   Centaur CentaurHauls
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x200: 'Protection Keys User registers'
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: xstate_offset:  576, xstate_sizes:  256
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: xstate_offset:  832, xstate_sizes:   64
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: xstate_offset:  896, xstate_sizes:   64
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: xstate_offset:  960, xstate_sizes:    8
Aug 29 23:46:03 hypervisor kernel: [    0.000000] x86/fpu: Enabled xstate features 0x21f, context size is 968 bytes, using 'compacted' format.
Aug 29 23:46:03 hypervisor kernel: [    0.000000] e820: BIOS-provided physical RAM map:
Aug 29 23:46:03 hypervisor kernel: [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable
Aug 29 23:46:03 hypervisor kernel: [    0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009efff] reserved
Aug 29 23:46:03 hypervisor kernel: [    0.000000] BIOS-e820: [mem 0x000000000009f000-0x000000000009ffff] usable

last reboot says (after an unscheduled restart, I rebooted myself once):

reboot   system boot  4.15.0-213-gener Fri Aug 30 00:03   still running
reboot   system boot  4.15.0-213-gener Thu Aug 29 23:45 - 00:03  (00:17)

wtmp begins Thu Aug  1 13:43:08 2024

cat /proc/sys/kernel/panic is 0 The physical server has been running for about 40 days without rebooting. How can I find out the reason for the reboot and prevent this from happening in the future?

I ran this command on /dev/sda1 when I meant to do something similar to /dev/sda2. /dev/sda1 was mounted at this time.

sudo parted -a opt /dev/sda mkpart primary ext4 0% 100%
Warning: You requested a partition from 0.00B to 1000GB (sectors 0..1953525167).
The closest location we can manage is 17.4kB to 1048kB (sectors 34..2047).
Is this still acceptable to you?
Yes/No? yes                                                               
Warning: The resulting partition is not properly aligned for best performance: 34s % 2048s != 0s
Ignore/Cancel? Ignore
Information: You may need to update /etc/fstab.

The output of print is:

(parted) print                                                            
Model: ATA ST1000LM035-1RK1 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name     Flags
 6      17.4kB  1049kB  1031kB                  primary
 1      1049kB  300MB   299MB   fat32                    boot, esp
 2      300MB   4347MB  4048MB  linux-swap(v1)           swap
 4      4347MB  124GB   120GB   ext4
 3      124GB   724GB   600GB   ext4
 5      724GB   1000GB  276GB   ext4

The output of fdisk -l /dev/sda is:

/dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: ST1000LM035-1RK1
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: 86AB55F1-52A1-4F8C-ACE9-1A7B4C4E9082

Device          Start        End    Sectors   Size Type
/dev/sda1        2048     585727     583680   285M EFI System
/dev/sda2      585728    8491007    7905280   3.8G Linux swap
/dev/sda3   242864128 1414739967 1171875840 558.8G Linux filesystem
/dev/sda4     8491008  242864127  234373120 111.8G Linux filesystem
/dev/sda5  1414739968 1953523711  538783744 256.9G Linux filesystem
/dev/sda6          34       2047       2014  1007K Linux filesystem

Partition 6 does not start on physical sector boundary.
Partition table entries are not in disk order.

This is the drive that contains my OS and everything. What do I do so that my reboot doesn't fail. Too afraid to turn off the machine right now.

I am not an expert of computer and now facing an ssh issue. I hope someone can provide me some idea to solve the problem. Previously, everything goes normal that I can ssh to Fedora39 ("Working computer") from my computer ("Home computer"). Recently, I update the kernel to 6.9.9-100.fc39.x86_64 by the following command: $ dnf update kernel Then, I reboot my computer and load into the newest module. Everything seems to be fine, but I find that I cannot ssh to the "Working computer" from my "Home computer". It gives me an error: **Connect to address ... port 22: Resource temporarily unavailable** I try to use my "Working computer" to ssh to "itself", it successes without any error. I also try to check the status in sshd: $systemctl status sshd The status gives me active and load enabled. Anyone have the idea about it? Thank you. **Update** Just want to add more information: I go to https://www.infobyip.com/sshservertest.php and try to connect with the IP with port 22. It is found that the IP cannot be connected.

I have accidently made a wrong symlink So currently rebooting does not work(giving error as image 1) I am trying to solve this with a live usb mounted and creating a new symlink But I cannot chroot because of the broken symlink. Is there a solution? Can i just do the below command directly without chroot? sudo ln -sf /mnt/lib/x86_64-linux-gnu/ld-2.35.so /mnt/lib64/ld-linux-x86-64.so.2

After deleting Windows 11, I installed Nobara Linux, but my laptop reboots itself after 5 seconds in login screen. And it doesn't matter if I managed to enter password or move to tty, cause it reboots anyway. Same with Ubuntu, Fedora and Garuda. Only distro which works without this bug is Manjaro Bungie Edition and Garuda in recovery mode, which is basically tty. Maybe worth mentioning that there is still Windows boot manager in BIOS. My laptop is HP VICTUS 16(Ryzen 5 5600 and Nvidia RTX 3050) PS: Sorry for bad English, and I am thankful for any solution or advice.