fdisk -l got stuck and umount too. umount -l worked, but I think disks weren’t umounted
I happened day before too. After Midnight. I thought it is random issue, which happened in past and always got fixed by reboot.
I coun’t unmount disks, reboot -f / systemctl reboot -ff commands got stuck.
only reboot command which do something is:
# echo 1 > /proc/sys/kernel/sysrq
# echo b > /proc/sysrq-trigger
But it got stuck too.
Now the server is unaccessible and I know I will have to reboot it with power button, when I return back to place, where the server is.
I cannot provide any other logs now. I will provide at Tuesday.
My questions are:
Is this known bug / should I report it? (the server was reinstalled cleanly about a month ago to fedora 41 and disks are about 10 months old)
What to do with system to not reboot it every day
Is there possibility to make some safety preparation to system to handle this? I would like to have always system stable. (Some force reboot, when system got stuck. Reload a old configuration etc.) Any suggestions?
I will, but I don’t presume it, because I have scheduled this smart check and btrfs check on all disks monthly. And on 1 of april was everything ok. This occurred after upgrade to fedora 42.
Upgrades make storage devices work harder than many normal workloads, so devices nearing failure are more likely to fail when upgrading. If you don’t have backups, try to get an image of the drive. Check for vendor diagnostics. If those are not available, use the S.M.A.R.T tools.
I haven’t describe it enough.
System disk, where was upgrade performed /dev/sda is SSD.
2 Usb HDD disks in RAID 1, which are now not recognized by fedora, are not dependent on upgrade. They are just mounted with data to container services in podman, running on fedora server.
the HDD disks are mounted with
I’m currently for sure backing up the raid disks.
mount seems to be correct and without issues after restart.
However, the usb disks are not recognized by fedora:
# smartctl -H /dev/sdb
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.14.2-300.fc42.x86_64] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org
/dev/sdb: Unknown USB bridge [0x125f:0xa86a (0x9203)]
Please specify device type with the -d option.
Use smartctl -h to get a usage summary
I’m not sure, what can this mean. Is possible that this can cause a new fedora upgrade? not supported driver, etc?
The issue is definitely due to instability in the USB devices [1], especially in a setup with multiple devices, there’s certainly a higher risk.
[1]
If your device is in a USB encloure, try switching to another enclosure or fit it directly on the SATA bus. It is relatively common that USB-SATA bridges used in enclosures do not implement all ATA features, don’t have good error handling or simply lie about the device capabilities. A personal experience of this was a USB enclosure that didn’t implement the USB Attached SCSI (UAS) protocol properly and lost writes during heavy load. Disabling the UAS kernel module helped in that case.
I simply pointed out that a multi-disk USB storage setup is often unstable and might be the cause of what you’re experiencing.
However, I can’t say whether blacklisting the “uas” module will fix the issue or if it’s a good practice. Let’s see what others have to say.
I tried live fedora 41, but it seems to be the same message when smartctl is used.
I tried “btrfs check --force” and it passed without error.
I also tried enter the valid -d type for smartctl
# smartctl --all -d sat /dev/sdc
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.13.10-200.fc41.x86_64] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Seagate Mobile HDD
Device Model: ST2000LM007-1R8174
Serial Number: WY21235Z
LU WWN Device Id: 5 000c50 0f1294b8c
Firmware Version: EB01
User Capacity: 2,000,398,934,016 bytes [2.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5400 rpm
Form Factor: 2.5 inches
Device is: In smartctl database 7.3/5528
ATA Version is: ACS-3 T13/2161-D revision 3b
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Tue Apr 22 21:43:58 2025 CEST
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: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
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: ( 0) seconds.
Offline data collection
capabilities: (0x71) SMART execute Offline immediate.
No Auto Offline data collection support.
Suspend Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
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: ( 327) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x3035) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 080 064 006 Pre-fail Always - 109159324
3 Spin_Up_Time 0x0003 098 098 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 096 096 020 Old_age Always - 4274
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 068 060 045 Pre-fail Always - 6746470
9 Power_On_Hours 0x0032 091 091 000 Old_age Always - 7988 (164 225 0)
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 49
184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
188 Command_Timeout 0x0032 100 094 000 Old_age Always - 7
189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 073 055 040 Old_age Always - 27 (Min/Max 27/27)
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 10
193 Load_Cycle_Count 0x0032 085 085 000 Old_age Always - 30068
194 Temperature_Celsius 0x0022 027 045 000 Old_age Always - 27 (0 17 0 0 0)
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 192 (77 100 0)
241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 4367169305
242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 5507901267
254 Free_Fall_Sensor 0x0032 100 100 000 Old_age Always - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
The above only provides legacy SMART information - try 'smartctl -x' for more
But i still don’t understand what happened. Why it now requires type, when before upgrade it didn’t.
Was it because I used it in btrfs raid? will reformatting do something with it?
I just can’t believe, something would burned out the registers of the HDD on both disks.
This value seems to support the hypothesis of an unstable USB connection. It could also be due to faulty cables, a loose connector, or power issues.
According to online sources, the value refers to:
Command_Timeout (188): RAW_VALUE = 7 → there have been 7 disk commands that took longer than expected to complete.
It’s not critical, but if the number increases, it could indicate:
Faulty or slow SATA cables
Power supply issues
Early signs of disk degradation
The attribute seems to indicate the number of aborted operations or commands due to a timeout occurring, A timeout being defined as when an active command is interrupted, for example by a hard reset or controller reset.
I can’t give you a precise answer, but I don’t think that’s the cause (Raid).
“Command_Timeout” It is related to the internal behavior of the disk’s firmware and its ability to respond within the time expected by the system.
If I were you, I’d back up the data and keep an eye on the drive.
Personally, I avoid and don’t recommend using USB devices for storage, especially when multiple drives or RAID setups are involved.
While the specs on these drives look good on paper, they seem to be very prone to failure (and the earlier versions of this drive are particularly prone to catastrophic failures).