The boot_delay parameter is not interpreted by the correct boot module.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
initramfs-tools (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Hello.
Normal computer booting is no longer possible. However, this computer boots up without any difficulty using recovery mode.
A first research shows that the normal boot does not reach the phase of delivery of the trace in the file /var/log/journal.
If he did that, it would be possible to recover the trace with a live USB. (Journalctl -b -D
/mnt/var/
It is possible to see the boot traces on the screen. But it ends with a black screen and the cursor blinking.
The trace lines run so fast that it is impossible to read them.
To solve this problem, I found in a lot of documentations, the "boot-delay" parameter which is described as:
boot_delay = Milliseconds to delay each printk during boot.
So I modified the /boot/grub/grub.cfg file (Ubuntu 20.04.1) to put this setting in a place that I think is good (line 167)
Here is its current content
linux /boot/vmlinuz-
But the boot is absolutely not going the way I wanted!
With the value 0, the start-up delay is 2 seconds.
With the value 60, the start delay is 85 seconds.
With the value 120, the start delay is 185 seconds.
With the value 180, the start delay is 275 seconds.
I had not considered this delay at the start.
When the start is done, the lines continue to scroll at full speed.
My wish was to set the value 9876. But after 4 hours, the start-up still had not taken place.
Thank you for dealing with the problem as best as possible: Software or documentation correction?
Good week.
summary: |
- The boot_delay parameter is not interpreted by the correct boot modude + The boot_delay parameter is not interpreted by the correct boot module. |