In actual fact I haven´t used it until now. The few times the kernel panic happend I just switched the PC off (with the hardware on/off button) and started again. It always worked the second time.
After it happened today I decided to give the rootdelay parameter a try.
I didn´t alter the grub entry though. Just passed the option manually to grub before boot was executed.
So for the next few times I´d like to give it a try first in order to see whether this may be of any help.
Thanks a lot for your kind offer, dear Jorge.
I´ll come back to that if everything else fails.
Although I´m not quite sure how to directly connect an external disk to my motherboard.
I´m not much of a hardware person, I´m afraid.
In the meantime: thanks a lot and many greetings from Rosika
P.S.:
That´s alright, Jorge. Your English is much better than you think it is. No problem there.
Well, not necessarily. And if so, just for nostalgic reasons.
I´d have to save some ISO files first before nuking the internal HDD.
At the moment I´m still trying out the rootdelay=10 parameter.
Until now it´s been working fine. But today was only the 2nd time I booted my system that way. So I can’t say anything definitive about it yet.
I found something interesting on Stack Exchange.
Here they deal with this topic: “What’s the point of rootwait/rootdelay?”.
This might be of interest to me.
I found the comment:
rootwait and rootdelay are used in situations when the filesystem is not immediately available, for example if it’s detected asynchroneously or mounted via usb.
Well, my system actually is mounted via USB.
I also found this explanation:
what rootdelay truly does is to delay the start of the kernel for the specified time in order to let the kernel find the rootfs in slower devices.
Therefore, if you for example set rootdelay=10, your system will wait 10 seconds before trying to start the kernel regardless of whether the rootfs has been found or not.
On the other hand, rootwait simply waits indefinitely for your rootfs to be available and then starts the kernel."
But I don´t quite understand what the user stated here:
All in all, if you had a system that takes 5 seconds to find the rootfs and you have it set up like rootdelay=10 rootwait, it will wait 10 seconds and then start it immediately.
If the system were to take 15 seconds to find the rootfs, then rootdelay=10 will force the first 10 seconds of wait, and then rootwait will take care of the last 5 seconds needed.
Finally, in this last case, if you hadn’t set rootwait, the system will fail to boot after 10 seconds since it wouldn’t be able to find the rootfs.
Well, I understand the reasoning behind the statement but I don´t understand the setting of rootdelay=10 rootwait.
Why use both parameters together
Wouldn´t rootwait alone have done the trick?
And what does “detected asynchroneously” mean?
Many thanks for your opinions and many greetings from Rosika
For a disc, async means writes are buffered, so the computer can go onto other things before the write is completed. The opposite, sync, means no buffering, so everything has to wait for the disk to actually write the data, before proceeding.
Disks are nearly always set to async.
There are sync and async options on the mount statement.
I agree, using both rootwait and rootdelay is illogical
Yes, lets not forget it takes many contributors to make a forum work.
I have a limited range of skills and experience. Some topics are beyond me. I feel I learn more than I put in.
Thank you @Tech_JA and @Rosika for kind words. @easyt50 has it right… we need to appreciate everyonne’s contribution
Oh dear, oh dear.
I didn’t want to offend anyone or even exclude anyone from my praise.
I am really sorry if it came out the wrong way.
I just wanted to express my respect for Neville´s explanation of what async meant in that particular context.jat async meant in that particular context.
I would of course like to agree with this without reservation .
Thanks to all of you from me as well.
