Need help fixing PC for a better boot time[SOLVED]

[motoryzen]

@Ron69 Thanks .As far as I can tell it is the kernel time that is long for my case 42.730s (kernel)
I am thinking that the new hard drive is the issue as I didn't have such a slow boot time with the old HD. Could be the sata connection is not good. I have sent a email request for tech support to Seagate with the SMART data included. I do not know how to interpret SMART data and the tests say it passed but some of the Value numbers seem odd

Well I'd try swapping out that sata cable to the new Seagate hdd in the mean time. It won't hurt anything if the cable isn't the problem. They're low cost enough these days.

[OunceofCommonSense]

Yeah, I changed out the sata cable last night no change. I will wait to hear from Seagate about the SMART stats

[motoryzen]

Yeah, I changed out the sata cable last night no change. I will wait to hear from Seagate about the SMART stats

Damn. ( sigh). I've had four different Seagate hdd's across a span of 17 years, and every single one of them didn't last beyond 3 years before having too many messed up sectors of the point of not being able to read nor write data or boot an OS..no matter how much I baby'd them. When I mean baby'd, I mean the total amount of writes done to them. My most recent one I had bought in 2012 died in late 2015 and I NEVER even filled them up with data....not even 70% tops...never dropped, no power outages while the PC was on...etc. The rest I've never even reached 65% capacity within them and that was only ONE fillup.

IDE ( old school from the turn of the millennium), Sata gen 1 1.5Gbps, and Sata gen 2 3.0 Gbps, and the 3TB barracuda in 2012 Sata 6Gbps aka gen III. So given this un-excusable track record, I will never buy another Seagate storage drive again..ever. On the 3TB barracuda..they refused to honor their 3 year warranty on it claiming I didn't have 3 years warranty and that I had 2, when I even ( thank God I had sense enough to screen shot not only the purchase from amazon, but Seagate's OWN website link to that exact drive) emailed them the stupid screenshot of both the amazon purchase and Seagate's official weblink for this exact drive and warranty info. To say the least...choice words were liberally given to them numbskulls. xD

Toshiba, on the other hand has NEVER failed me yet. I still have an old 1TB drive from 12 years ago that is still running like day one brand new and I've filled it up, cleared it, and refilled it up easily more than 5 times. My 5TB toshiba drives ( two of them) are still kicking as well as my 10TB models and so far my 16TB one is running well that I bought around 5 months ago. Sorry to sound like I'm bashing Seagate here, but I've personally seen the proof from the horror stories online I've read about their alleged claim qc versus the real life results. I have a couple of buddies who have encountered similar problems with their Seagate drives and one of them the exact same problem with their warranty department refusing to honor a warranty ( and btw..this WASN'T based upon end user damage......neither of us ever dropped these drives)

How much warranty time is left on that particular Seagate drive?

[OunceofCommonSense]

As I said it is likely a lost cause. I stupidly bought them off Ebay only to find out the seller has a no return policy and the drives are way past their warranty (bought 2). I too had been avoiding Seagate also but found a good review of this particular one on BackBlaze( https://www.backblaze.com/blog/backblaz ... -for-2020/)and decided to get them(Seagate ST6000DX000 6TB,Internal,7200 RPM,3.5" Hard Drive 128MB Cache Desktop).
Now I am not sure what to think. I have been trolling around the internet to find info on the SMART attributes only to find that Seagate drives routinely report the attributes I am worried about with bizzarre results. For example the Command-Timeout(188) reports a value of 4295032833 on mine which would appear very high but the drive passes SMART. Delving into this further that number may be a hexidecimal code that needs to be reinterpreted.
At this point I wish I had listened to my gut and bought a better brand. I may end up shelving both drives and buying something on cyber Monday. I have not yet tested the other drive.
Live and learn!

[motoryzen]

*nods slowly*. Well look..try not to beat yourself up over it regardless of what you end up doing. ..

Toshiba and Samsung are definitely the one's I'd recommend as they have had throughout history much less failure rates and have consistently lasted longer than all other's combined for the past 15 years that I've kept up with.

AS far as hdd's ...I'd go with Toshiba. For ssd's ( as far as sata based) Samsung and Crucial have been rock solid for me as well as other customer builds I've done across the years.

[OunceofCommonSense]

Thanks

[ron69]

I noticed quite a gap in your 'critical-chain' timing:

systemd-time-wait-sync.service @260ms +31.215s
└─systemd-journald.socket @248ms

[OunceofCommonSense]

I noticed quite a gap in your 'critical-chain' timing:

systemd-time-wait-sync.service @260ms +31.215s
└─systemd-journald.socket @248ms

Thanks that looks like the bottleneck. Could be the way I have Geolocation for nftables set up at boot which uses systemd. Probably something beyond my ability to tinker with

[ron69]

Make a Timeshift Backup...
You might try:
systemctl disable systemd-journald.socket
reboot
and see if it helps.
If not, simply enable the service

[OunceofCommonSense]

Tried

Code: Select all

systemctl disable systemd-journald.socket

but little effect. My concern about this is not the extra 20seconds or more it takes to boot but that the computer is operating properly. I think I have spent as much energy on this as I care to. Unless the computer does not boot at all I think I will leave it as is. New computer build on the horizon

[OunceofCommonSense]

Switched out suspect drive for an old drive and the kernel booted in under 8 sec instead of 32 sec

Code: Select all

systemd-analyze
Startup finished in 18.868s (firmware) + 4.891s (loader) + 7.778s (kernel) + 12.895s (userspace) = 44.434s 
graphical.target reached after 12.882s in userspace

Going to shelve the new drive and have ordered another one. As I said I don't mind the extra time it took to boot but I suspect there was something wrong with the drive and I don't want to trust my data to it

[AndyMH]

I had a similar problem with a new msata ssd, could take 8 min to boot from cold. When warm boot time around 30 secs. Did a lot of testing and eventually concluded it was duff and returned it.

[OunceofCommonSense]

Feeling especially foolish right now. The original suggestion regarding SWAP not being configured correctly was right. The drives I replaced did have errors so it was probably best they were replaced. However in my efforts to set up a Swap file not on the SSD(to avoid frequent writes to an older SSD (10 years)) I missed one step.Full directions are found https://www.linuxuprising.com/2018/08/h ... -swap.html, The pertinent part to my situation was as follows:

8. This step is required for Ubuntu and Debian-based Linux distributions (I'm not sure if others need this too). The file mentioned below exists only if you've hibernated your system at least once, so you can skip this step if you don't have it.

You need to edit the /etc/initramfs-tools/conf.d/resume file and comment out (add a # at the beginning of the line) the RESUME=UUID=... line if you don't plan on hibernating your computer (do not confuse it with sleep / suspend). You can find exact instructions for doing this a bit further down below.

If you want to hibernate your computer, you need to edit this line and add the UUID of the partition on which the swap file is located and the resume offset. You can find instructions for doing this by visiting this article (you'll need to follow steps 1, 2, 5 and 6 for this, or just follow the complete article to enable hibernation).

In my case, not doing this resulted in about 15-20 seconds of extra boot time. The systemd-analyze blame command didn't give any info as to why that's happening, so I had to dig quite a bit to find out this is what's causing the boot delay.

Luckily I noticed a "Gave up waiting for suspend/resume device" message being displayed for a very brief moment while booting, which can be caused by not having the correct swap UUID in /etc/initramfs-tools/conf.d/resume.

This file is used when resuming from hibernation, and it caused boot delays because we no longer have a swap partition.

To comment out this line in /etc/initramfs-tools/conf.d/resume, all you have to do is run the command below:

sudo sed -i 's/^RESUME=UUID/#RESUME=UUID/g' /etc/initramfs-tools/conf.d/resume

You'll also need to update initramfs and after that you're done:

sudo update-initramfs -u