[New user] Slow booting

pLaYeR45

tomscharbach
No option found in bios to disable the hdd

Lets see if i can manually take out the hdd.

Axios
The problem is if i try to mount and clean the hdd. The laptop starts to make clicking noise and becomes very slow and unresponsive.

Btw thanks for helping me out is there any way i could close this discussion?

tomscharbach

pLaYeR45 The problem is if i try to mount and clean the hdd. The laptop starts to make clicking noise and becomes very slow and unresponsive.

That clicking noise is the hard drive's death rattle.

Axios I dont know your boot sequence either if that disk is first in list might be hanging it.

@pLaYeR45 Consider going back into your BIOS, look for a BIOS entry labeled "Boot Sequence" or similar, and look to see what boot loaders are present.

Solus boot loader is normally called "Linux Boot Manager", Windows boot loader is normally called "Windows Boot Manager", and other Linux builds (the ones that use Grub) are called by different names (for example, on my computer, Ubuntu Budgie's bootloader is called "Ubuntu").

If you can identify the Solus boot loader (simple if it is named "Linux Boot Manager"), try two things: (1) move the Solus boot loader to the top of the boot sequence list, and (2) if your BIOS permits, see if you can disable/remove all the other boot loaders from the list. Either might move the Hitachi hard drive out of the boot path.

pLaYeR45

tomscharbach
My laptop's bios boot sequence consist hard drive names and LAN. Yes the priority is set in
1.Samsung 32gb ssd
2.LAN
3.Hitachi 320gb hdd
I searched on how to totally disable hdd and its says
The commands only run with root. I will try this method after completion of my upcoming exams.btw i was wondering if i can delete drivers for hard drive?

tomscharbach

pLaYeR45 I searched on how to totally disable hdd and its says
The commands only run with root. I will try this method after completion of my upcoming exams.btw i was wondering if i can delete drivers for hard drive?

Don't try this at home ... 😆

Good luck on your exams.

Axios

tomscharbach knew what was on my mind...
Yup click of death...

Axios

I did not comment To deep on UEFI because I only have 2 computers that use it out of all my windows machines
and its something I am reading up on and finally this new machine I got has all the boot loader stuffs I read
about on here (I am slow at change if it works I dont change it..lol) cant wait to mess it all up either...ROFL!

This was good reading the guy works at Redhat..
https://www.happyassassin.net/posts/2014/01/25/uefi-boot-how-does-that-actually-work-then/

tomscharbach

Axios I made the decision to use UEFI and disable CSM on all my computers, and use GPT formatting on all drives in my computers, several years ago. I will not install any OS that is not fully compatible with UEFI, period. If an OS is that far behind the curve, I don't trust it not to be behind the curve in other important respects.

That sounds very dogmatic, I know. However, for the reasons explained in the article you posted, UEFI handles multi-boot, single-OS-per-disk setups more reliably than BIOS, in my opinion, and I have not had an issue with multi-boot on any of my computers since becoming hard-nosed about UEFI-only and following the single-OS-per-disk convention.

WetGeek

tomscharbach That sounds very dogmatic, I know.

To me it sounds like, "Life's too short."

pLaYeR45

tomscharbach

UPDATE: Just installed solus kde and removed solus budgie . The system booted in 45 seconds.

Ran journalctl -b

No red line found

Btw Thank you guys 😊 for helping me out

Axios

Not sure in my mind why installing kde solved your issue or just the way they install something I got to think on awhile.

tomscharbach

Axios Not sure in my mind why installing kde solved your issue or just the way they install something I got to think on awhile.

I wonder, too. It seems to me that the Solus, rather than either DE, controls the boot process, in the sense that whatever happens during the boot process to access the defective Hitachi drive precedes activation of either DE, so there should be no difference.

Specifically, I wonder whether the Budgie issues would have been resolved by a clean -- that is, wipe the entire drive and start over from scratch -- installation of Budgie. I can't think of a reason why Budgie would try to access the defective Hitachi drive during boot and KDE would not.

But speculating is water over the dam because the system is now working until the Hitachi blows up and causes the next problem.

Axios

tomscharbach I agree its always the end result that matters.

sw0leymammoth

I don't mean to bump this thread but I also seem to be running into the same issue as a new user 😅
I'm running Solus KDE on my desktop and using a 2tb Seagate SSD, with Solus being the only OS on it yet it takes about a minute and a half to get from bios to login screen. I've got a newer system with a Ryzen 5600x, where Windows on a different SSD only takes a few seconds to boot. I put Solus Budgie on my laptop as well and it boots in 8 seconds or less while being the only OS on the SSD there. I was able to run those logs the other day and see quite a few red and yellow lines throughout, but I'm not entirely sure what they mean. It doesn't seem like the forums like me uploading the logs as .txt files or .pdfs, so what would be the best way to share those?

ReillyBrogan

If someone could run the following it'd be really helpful for troubleshooting exactly what's taking so long.

sudo journalctl -b0 --no-pager > boot.log
sudo systemd-analyze blame --no-pager > blame.log

And then upload those to hastebin or something. You should skim your boot.log for anything sensitive that you might want to redact before doing this.

sw0leymammoth

ReillyBrogan Thank you for the quick response! Here they are:
https://hastebin.com/apiwucefer.properties
https://hastebin.com/sufumojaku.yaml

ReillyBrogan

Looks like this is the issue:

Dec 01 04:39:55 solus systemd-journald[281]: Journal stopped
Dec 01 11:40:20 sw0leypc systemd-journald[281]: Received SIGTERM from PID 1 (systemd).

There's a 25 second gap there which is interesting. I wonder if it has to do with the time change, usually that kind of clock change is caused because Windows stores the time in the hardware clock in local time while Linux stores it in UTC time. Does this issue happen only when you boot into Solus directly after using Windows? Does it happen if you shutdown from within Solus and then boot back in to Solus on the next boot?

I'd recommend taking a look at the instructions here and following the "Make Windows use UTC" steps.

sw0leymammoth

ReillyBrogan Thanks again! I'd notice the slow startup from shut down within Solus and rebooting within Solus as well. I followed those steps and it definitely seemed to shave off some time, even though I hadn't booted into Windows for a while.
Here are updated logs though in case there are any changes you might notice.
https://hastebin.com/conuyijuna.apache
https://hastebin.com/alucizicaj.sql
Thanks again for your help!

« Previous Page