Extremely long boot time

[die.boer]

also this please

journalctl -b -o short-monotonic --no-pager | awk '$1+0 >= 20 && $1+0 <= 110'

That pulls every journal line with a monotonic timestamp between 20s and 110s, across all units — which should make disk contention (or lack of it) visible directly, rather than inferring it from ordering.
Also worth checking

sudo smartctl -a /dev/sda

[Snowhog]

journalctl -b -o short-monotonic --no-pager | awk '$1+0 >= 20 && $1+0 <= 110'
No output. Immediate return to prompt.


sudo smartctl -a /dev/sda
[sudo: authenticate] Password:
smartctl 7.5 2025-04-30 r5714 [x86_64-linux-7.0.0-30-generic] (local build)
Copyright (C) 2002-25, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Hitachi Travelstar 5K500.B
Device Model: Hitachi HTS545050B9A300
Serial Number: 110314PBG4081727SSHV
LU WWN Device Id: 5 000cca 5f6dfb6ca
Firmware Version: PB4OCA1G
User Capacity: 500,107,862,016 bytes [500 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 5400 rpm
Form Factor: 2.5 inches
Device is: In smartctl database 7.5/5706
ATA Version is: ATA8-ACS T13/1699-D revision 6
SATA Version is: SATA 2.6, 3.0 Gb/s
Local Time is: Mon Aug 24 15:56:18 2026 CDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

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: ( 645) 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: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 158) 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 0x002f 100 091 062 Pre-fail Always - 0
2 Throughput_Performance 0x0025 100 100 040 Pre-fail Offline - 0
3 Spin_Up_Time 0x0023 139 100 033 Pre-fail Always - 2
4 Start_Stop_Count 0x0032 096 096 000 Old_age Always - 6736
5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0
7 Seek_Error_Rate 0x002f 100 100 067 Pre-fail Always - 0
8 Seek_Time_Performance 0x0025 100 100 040 Pre-fail Offline - 0
9 Power_On_Hours 0x0032 054 054 000 Old_age Always - 20430
10 Spin_Retry_Count 0x0033 100 100 060 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 098 098 000 Old_age Always - 4553
183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0
184 End-to-End_Error 0x0033 100 100 097 Pre-fail Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 57032871379120
188 Command_Timeout 0x0032 096 013 000 Old_age Always - 7528
190 Airflow_Temperature_Cel 0x0022 075 052 045 Old_age Always - 25 (Min/Max 25/25)
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 23
192 Power-Off_Retract_Count 0x0032 099 099 000 Old_age Always - 13304011
193 Load_Cycle_Count 0x0032 077 077 000 Old_age Always - 230236
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0036 100 100 000 Old_age Always - 0
223 Load_Retry_Count 0x002a 100 100 000 Old_age Always - 0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 1836 -
# 2 Short offline Completed without error 00% 85 -
# 3 Extended offline Aborted by host 90% 85 -

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

[die.boer]

ok...ONE last test ..please lol

sudo time /etc/init.d/grub-common start

[Snowhog]

sudo time /etc/init.d/grub-common start
[sudo: authenticate] Password:
Starting grub-common (via systemctl): grub-common.service.
0.01user 0.02system 0:00.06elapsed 60%CPU (0avgtext+0avgdata 8432maxresident)k
48inputs+0outputs (0major+2529minor)pagefaults 0swaps

[die.boer]

ok from all we saw... the short version:
It's not GRUB, it's not Snap, and it's not a settings problem. Your hard drive is old and wearing out, and that's what's causing the slow boot.
-We proved the GRUB commands themselves are basically instant when run by hand — so GRUB was never actually the problem, just the thing showing the symptom.
-Your SMART data (the drive's own internal health log) shows a Command_Timeout count that's driven that attribute down to 13 out of 100 — a score that low means this drive has racked up thousands of moments where it failed to respond to a request in time and had to retry. That's a real red flag, not a Linux config issue.
-Your drive has also parked its read/write heads over 230,000 times and has 20,000+ hours on it — it's a well-used mechanical drive from roughly 2011, and it's aging out.
-Put together: when your system is doing lots of things at once at boot (Snap mounting things, the daily update check, log cleanup, etc.), the drive gets overloaded and starts timing out and retrying — and that's what turns a normally-instant GRUB step into a 60-95 second wait. When you run things one at a time by hand, there's no overload, so everything looks fast — which is exactly the pattern we saw.

Best fix: back up your data and replace this hard drive with an SSD. This will almost certainly fix the slow boot completely, and your whole system will feel faster in general.
If you can't replace it yet: you can try reducing how often the drive spins down and back up, which puts less wear on it:

sudo hdparm -B 254 /dev/sda

This won't fix the underlying wear, but may reduce how often you hit the worst-case slow boots in the meantime.
Backup your data soon regardless — a drive with this kind of timeout history can fail without much more warning, so treat this as a "get your files off it" priority, not just a performance annoyance.
There's nothing wrong with your Kubuntu install, your GRUB config, or Snap — this is a hardware issue that's been surfacing through software symptoms.

[oshunluvr]

This also seems bad:

187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 57032871379120

Meaning: 187 0xBB Reported Uncorrectable Errors The count of errors that could not be recovered using hardware ECC

My drive with 80,000+ hours is 0 and so is Command_Timeout.

IMO however, that number seems out of whack. I'd check it once in awhile. If it's growing, the drive is dying. If it stays the same, it's likely a red herring.

[Snowhog]

Thank you die.boer for all the effort you put into this to assist me in determining what is going on. oshunluvr: I Googled on the Vendor Specific SMART Attributes with Thresholds and ultimately giving Google's AI this information: Reported_Uncorrect 57032871379120 Toshiba/Hitachi 500GB SATA 2.5-inch HDD when it said: If you have a specific smartctl line or attribute output you are wondering about, share the attribute name, raw value, and brand of your drive and I can help you analyze

This is what it replied with:

A Reported_Uncorrect raw value of 57032871379120 indicates a critical hardware failure on your Toshiba/Hitachi hard drive.

While some manufacturers pack multiple metrics into large SMART raw numbers, any non-zero value for this specific attribute means the drive's internal error correction code (ECC) could not recover corrupted data, and the read request had to be aborted.

What This Value Means for Your Drive

• Severe Data Corruption: Your drive has encountered sectors where data is physically unreadable. The internal software tried multiple times to fix the read error but failed completely.
• Immediate Backup Required: This is a strong predictor of imminent drive failure. The operating system will likely experience sudden freezes, file corruption, or blue screens when trying to access the affected files.
• Physical Media Degradation: Unlike temporary software glitches, uncorrectable errors usually stem from physical degradation of the magnetic platters, a failing read/write head, or severe scratches on the disk.

Next Steps to Safeguard Your Data

• Stop Stressing the Drive: Avoid running heavy disk scans, defragmentation tools, or stress tests. These activities put mechanical strain on an already failing drive and can accelerate complete failure.
• Clone or Copy Crucial Files First: Do not try to back up the whole drive at once if it starts slowing down. Prioritize your absolute most important personal files (documents, photos) first.
• Replace the Drive: This drive is no longer safe for operating systems, backups, or daily use. Once you harvest your data, the hardware should be replaced.

[oshunluvr]

Welp, time for a new SSD!

[oshunluvr]

FYI, Samsung is the way to go with SSDs. A few bucks more, but worth it. I have two old Samsung 840 PROs (2.5 SATA) with 88k and 80k power-on-hours and zero errors and no bad sectors reported.

If that's too rich, I also have a couple Crucial BX500s with only 8K hours, but no issues there either and about half the price of Samsung for the same size.

[Virginio Miranda]

Thank you die.boer for all the effort you put into this to assist me in determining what is going on. oshunluvr: I Googled on the Vendor Specific SMART Attributes with Thresholds and ultimately giving Google's AI this information: Reported_Uncorrect 57032871379120 Toshiba/Hitachi 500GB SATA 2.5-inch HDD when it said: If you have a specific smartctl line or attribute output you are wondering about, share the attribute name, raw value, and brand of your drive and I can help you analyze

This is what it replied with:

A Reported_Uncorrect raw value of 57032871379120 indicates a critical hardware failure on your Toshiba/Hitachi hard drive.

While some manufacturers pack multiple metrics into large SMART raw numbers, any non-zero value for this specific attribute means the drive's internal error correction code (ECC) could not recover corrupted data, and the read request had to be aborted.

What This Value Means for Your Drive

• Severe Data Corruption: Your drive has encountered sectors where data is physically unreadable. The internal software tried multiple times to fix the read error but failed completely.
• Immediate Backup Required: This is a strong predictor of imminent drive failure. The operating system will likely experience sudden freezes, file corruption, or blue screens when trying to access the affected files.
• Physical Media Degradation: Unlike temporary software glitches, uncorrectable errors usually stem from physical degradation of the magnetic platters, a failing read/write head, or severe scratches on the disk.

Next Steps to Safeguard Your Data

• Stop Stressing the Drive: Avoid running heavy disk scans, defragmentation tools, or stress tests. These activities put mechanical strain on an already failing drive and can accelerate complete failure.
• Clone or Copy Crucial Files First: Do not try to back up the whole drive at once if it starts slowing down. Prioritize your absolute most important personal files (documents, photos) first.
• Replace the Drive: This drive is no longer safe for operating systems, backups, or daily use. Once you harvest your data, the hardware should be replaced.

Do not believe on this A Reported_Uncorrect raw value of 57032871379120 .

This is a well documented bug know involving hitachi drives presented with extremely high uncorrect value.

Look at ID 05,196,197 and 198. All of them are raw value = 0 , meaning the drive is still good.

Test the hitachi drive on a different system.

[Snowhog]

I am beginning to think this is a red herring, and that the drive is actually fine. Why? I ran the long-test (#2) and short-test (#1), again, last night:

sudo smartctl -l selftest /dev/sda
[sudo: authenticate] Password:        
smartctl 7.5 2025-04-30 r5714 [x86_64-linux-7.0.0-30-generic] (local build)
Copyright (C) 2002-25, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%     20438         -
# 2  Extended offline    Completed without error       00%     20438         -
# 3  Short offline       Completed without error       00%     20435         -
# 4  Extended offline    Completed without error       00%     20433         -
# 5  Short offline       Completed without error       00%      1836         -
# 6  Short offline       Completed without error       00%        85         -
# 7  Extended offline    Aborted by host               90%        85         -


​

[Snowhog]

What I asked Google AI:

SMART Attributes Data Structure what does RAW_VALUE for Reported_Uncorrect convey

Response:

The RAW_VALUE for S.M.A.R.T. Attribute 187 (Reported_Uncorrect) conveys the total count of read/write operations that could not be corrected using the drive's internal hardware Error Correction Code (ECC).

What the Raw Value Means

• Direct Error Count: For most standard drive manufacturers (such as Western Digital, HGST, and SanDisk), the raw number is a straightforward integer representing how many uncorrectable ECC events have occurred.
• Vendor-Specific Encoding: Some manufacturers (most notably Seagate) encode 48-bit raw values differently. They might combine total operations and error counts into a single hexadecimal string, resulting in an absurdly large decimal number that does not represent a literal single-digit error count unless parsed correctly.
• Hardware Degradation: Unlike minor soft read errors that are fixed on the fly, a non-zero RAW_VALUE here means the drive completely failed to reconstruct the data using standard hardware-level redundancy during an operation.

Health Significance

• Critical Indicator: Most enterprise monitors and storage analytics (like Backblaze) treat any climbing, non-zero raw value on Attribute 187 as a strong statistical precursor to drive failure.
• Action Threshold: If this number is increasing over time, it usually points to physical media decay, head wear, or surface damage, and you should back up your data immediately.

If you share the exact drive manufacturer/model and the current raw number you are seeing, I can help you determine if it represents a critical failure or a vendor-encoded misread.

I then provided the requested data:

Hitachi HTS545050B9A300 57032871379120

Response:

The raw value 57032871379120 on your Hitachi Travelstar 5K500.B (HTS545050B9A300) does not mean you have 57 trillion errors.

Like some Seagate drives, this specific Hitachi firmware line uses multi-field hexadecimal encoding to squeeze multiple independent metrics into a single 48-bit raw value.

The Decoded Breakdown

Converting your decimal number 57032871379120 into hexadecimal yields 0x33DF000A00B0. This string breaks down cleanly into three 16-bit segments:

• 0x33DF (High 16-bits): Converts to 13,279 in decimal. This typically logs the total number of reads/operations processed during the tracking window.
• 0x000A (Middle 16-bits): Converts to 10 in decimal. This is your actual structural error count—representing exactly 10 uncorrectable ECC events.
• 0x00B0 (Low 16-bits): Converts to 176 in decimal. This typically tracks the total number of sector recovery attempts or discrete command timeouts.

What This Means For Your Drive

Your drive has exactly 10 uncorrectable read errors. While 10 errors is a tiny fraction of the drive's total lifetime workload, any number above zero for Attribute 187 is considered a predictive failure alert for data integrity. Because this is an older mechanical notebook drive, these 10 events indicate that the read/write heads have struggled to decipher data on the platters, usually caused by micro-scratches, age, or physical wear.

To see if the drive is safe to keep using as a secondary drive, check your Attribute 05 (Reallocated Sector Count) and Attribute 197 (Current Pending Sector Count). Let me know if either of those values is above zero.

I provided:

Both values are 0

Response:

Having 0 reallocated sectors (Attribute 05) and 0 pending sectors (Attribute 197) alongside your 10 uncorrectable errors means your drive is in a specific, transitional state: the drive knows data was corrupted, but it has not yet marked the physical sectors as dead.

What This Dynamic Tells Us

• Transient Media Errors: The 10 uncorrectable events occurred during a read operation where the drive's ECC engine couldn't reconstruct the data. However, because Attribute 197 is 0, there are currently no unreadable sectors actively waiting to be tested or remapped.
• Successful Overwrites: When a drive encounters a read error, it flags the sector. If your operating system later writes new data to that exact spot, the drive tests the sector. If the sector handles the new write successfully, the drive clears the alert without reallocating it. This leaves you with an historical count of 10 errors (Attribute 187) but 0 current active problems (Attributes 05 and 197).
• Firmware Quirk: Some older Hitachi mobile architectures do not automatically reallocate sectors on read failures alone; they wait for a write failure to permanently swap the sector out.

Risk Assessment & Action Plan

Your drive is not in immediate catastrophic failure, but it is showing its age. Because the underlying hardware structure has dropped data 10 times in the past, trust is compromised.

• Retire from Critical Duty: Do not use this drive for your operating system, active databases, or unbacked-up personal data.
• Safe for Low-Risk Storage: It remains perfectly usable for temporary file transfers, scratch space, or media streaming where data loss would be an inconvenience rather than a disaster.
• Monitor the Delta: The most important metric now is stability. Run your diagnostic software again in two weeks. If the middle hex value (0x000A) stays at 10, the drive is stable. If it climbs to 11 or higher, the physical media is actively degrading, and the drive should be discarded.

[Virginio Miranda]

I am beginning to think this is a red herring, and that the drive is actually fine. Why? I ran the long-test (#2) and short-test (#1), again, last night:

sudo smartctl -l selftest /dev/sda
[sudo: authenticate] Password:
smartctl 7.5 2025-04-30 r5714 [x86_64-linux-7.0.0-30-generic] (local build)
Copyright (C) 2002-25, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 20438 -
# 2 Extended offline Completed without error 00% 20438 -
# 3 Short offline Completed without error 00% 20435 -
# 4 Extended offline Completed without error 00% 20433 -
# 5 Short offline Completed without error 00% 1836 -
# 6 Short offline Completed without error 00% 85 -
# 7 Extended offline Aborted by host 90% 85 -


​

Probably yes. It can be a red herring.

Some have indicate the reported uncorrect high raw value when using Asmedia controller.

I realized that the number extremely high on the reported uncorrect extremely high raw value from smartclt are in decimal way. Hitachi Travelstar drives compress multiple data metrics into a single hexadecimal string for this attribute and in the hexadecimal way the number is 0x33DF000A00B0.

Hitachi typically splits this 48-bit value into three distinct 16-bit fields. 0x33DF converted to decimal number give 13.279, that is the numbers of hours tracked by this specific monitoring component. 000A converted to decimal numbers give a number of 10 that is the real number of uncorrectable raw value error events that occurred during those operations on 0x33DF. And 00B0 is an internal threshold or secondary factory calibration counter.

So, the real number for " Reported Uncorrect Raw Number " is 10.

https://www.backblaze.com/blog/hard-drive-smart-stats/ consider five SMART metrics as impending disk drive failure:

• SMART 5: Reallocated_Sector_Count.
• SMART 187: Reported_Uncorrectable_Errors.
• SMART 188: Command_Timeout.
• SMART 197: Current_Pending_Sector_Count.
• SMART 198: Offline_Uncorrectable

And, anything above 0 on SMART 187 they consider a problem, but a number of 10 is not a guide you to eliminate the disk drive. There are the others 4 SMART ID to take in consideration.

In your smartclt numbers , Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always is equal a 0 and Current_Pending_Sector 0x0032 100 100 000 Old_age Always is equal a 0 too. For the first one this means the drive has not yet run out of spare sectors, and it is not holding any pending sectors waiting to be remapped. For the second one, the firmware of the HDD chose not to quarantine those sectors yet.

So, The best practice is to continue monitoring the HDD with the smartctl tool and check if this number increases. If it starts to rise and other SMART IDs also increase, it will be a strong indicator of potential failure.

There are two other software that i consider to use: GSmartcontrol and QDiskinfo that are a GUI for smartclt tools. The GSmartcontrol has a lot of option in the easy way compared to smartclt line command and QDiskinfo interpret in a different way with hexadecimal calculator directly inside the software.

[Snowhog]

There are two other software that i consider to use: GSmartcontrol and QDiskinfo that are a GUI for smartclt tools. The GSmartcontrol has a lot of option in the easy way compared to smartclt line command and QDiskinfo interpret in a different way with hexadecimal calculator directly inside the software.

Thank you for the info. I installed QDiskinfo; GSmartcontrol isn't in the 'stardard' Ubuntu Repositories (it's third-party ?).

I launched it. Easy to read. Curious though, it reports BB (0x000A) as 100 because the Raw Values is shown as 000000000000. So it appears that QDiskinfo isn't reading the current stored values for the Smart Self-test I last ran.

[oshunluvr]

Yeah I think it's possible and for sure that "uncorrected" value is wrong. At a minimum, I'd check back on those reported values and see if they change week-to-week. If they go up, time to go shopping.

Still though, that leaves the original question unanswered.

Are you using BTRFS or EXT4? I ask because if you're using BTRFS, it's pretty simple to do a new install along side your existing install without damaging anything. Then if the new install boots quickly, at least you'd know it's the OS and not the drive.

Note that I had a bugger of a time getting 26.04 to boot after dist-upgrading from 24.04 vs. a new 26.04 install because the initrd.img file was 3X larger on the upgrade than a fresh install. I just bring it up because if you're running an older install that's been upgraded, maybe something from the past is causing the issue.