Hangs at purple screen

Post by philo
Ubuntu 20.04 with all updates hangs at purple screen when I try to boot up.
If I go to recovery mode and do nothing at all other than hit "resume"
it boots normally.
Checked for broken packages and all OK.
Stumped.
Help appreciated.

Hit ESC at the boot screen and remove 'splash' from the kernel option
line, then you can at lease see where it get stuck.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

philo

2020-08-16 02:27:06 UTC

Hit ESC at the boot screen and remove 'splash' from the kernel option
line, then you can at lease see where it get stuck.

Thank you but in grub, I have kernel parameters set to "quiet splash"

philo

2020-08-16 02:36:46 UTC

Hit ESC at the boot screen and remove 'splash' from the kernel option
line, then you can at lease see where it get stuck.

Thank you but in grub, I have kernel parameters set to "quiet splash"

LOL

I removed the "quiet splash" option and the system boots normally now.

Go figure

Paul

2020-08-16 09:17:22 UTC

Hit ESC at the boot screen and remove 'splash' from the kernel option
line, then you can at lease see where it get stuck.

Thank you but in grub, I have kernel parameters set to "quiet splash"

LOL
I removed the "quiet splash" option and the system boots normally now.
Go figure

The NVidia video card on my machine, Nouveau loses contact with it.
Distros where the Nvidia binary blob driver is fitted, the card
and the driver remain in contact.

I debugged that by using a serial port on the machine, logging in while
the screen wasn't working using the serial port, and having a look
at dmesg. And that showed the Nouveau messages.

And sometimes, editing the boot line, does result in it working.

It's not the same bug as yours, but that's an idea on how to
get in for a look.

The only bad thing about that, is a grub update can decide to
put the boot menu on the temporary serial port console.

console=ttyS0,57600n8 where "quiet splash" would be

Paul

philo

2020-08-16 23:40:21 UTC

Hit ESC at the boot screen and remove 'splash' from the kernel option
line, then you can at lease see where it get stuck.

Thank you but in grub, I have kernel parameters set to "quiet splash"

LOL
I removed the "quiet splash" option and the system boots normally now.
Go figure

The NVidia video card on my machine, Nouveau loses contact with it.
Distros where the Nvidia binary blob driver is fitted, the card
and the driver remain in contact.
I debugged that by using a serial port on the machine, logging in while
the screen wasn't working using the serial port, and having a look
at dmesg. And that showed the Nouveau messages.
And sometimes, editing the boot line, does result in it working.
It's not the same bug as yours, but that's an idea on how to
get in for a look.
The only bad thing about that, is a grub update can decide to
put the boot menu on the temporary serial port console.
console=ttyS0,57600n8 where "quiet splash" would be
Paul

FWIW: My graphics is listed as Mesa Intel

Paul

2020-08-17 00:45:56 UTC

Hit ESC at the boot screen and remove 'splash' from the kernel option
line, then you can at lease see where it get stuck.

Thank you but in grub, I have kernel parameters set to "quiet splash"

LOL
I removed the "quiet splash" option and the system boots normally now.
Go figure

The NVidia video card on my machine, Nouveau loses contact with it.
Distros where the Nvidia binary blob driver is fitted, the card
and the driver remain in contact.
I debugged that by using a serial port on the machine, logging in while
the screen wasn't working using the serial port, and having a look
at dmesg. And that showed the Nouveau messages.
And sometimes, editing the boot line, does result in it working.
It's not the same bug as yours, but that's an idea on how to
get in for a look.
The only bad thing about that, is a grub update can decide to
put the boot menu on the temporary serial port console.
console=ttyS0,57600n8 where "quiet splash" would be
Paul

FWIW: My graphics is listed as Mesa Intel

If a machine refuses to leave the main screen in a usable
state, you'll need to set up a console somewhere, to do your
debugging.

With systemd, and especially with the Ubuntu fantasy world (server
features highjacking a desktop design), there will be times when
the boot log you see on screen, would have a systemd line with
a moving red asterisk. And that's a service that didn't start,
and things are set up to wait forever for it to finish.

These are things you can watch, if you shift the console to
ttyS0 or a similar serial port.

The same thing can happen at shutdown. A shutdown that takes
two minutes, could be systemd holding things hostage.

Some distro designers seem to have a better handle on this
than others. The people with a clue, get on with life and don't
leave systemd burning a hole in the screen with the red asterisk.
For the less clueful ones, they seem to enjoy doing stuff like this.

But I've got mine solved now. I have a permanent cable
run between machines, because you never know when you'll be
needing to debug stuff like this. I also have a copy of Putty
on this machine, that I run all the time. So it's ready too.

Paul

philo

2020-08-17 01:26:33 UTC

Hit ESC at the boot screen and remove 'splash' from the kernel option
line, then you can at lease see where it get stuck.

Thank you but in grub, I have kernel parameters set to "quiet splash"

LOL
I removed the "quiet splash" option and the system boots normally now.
Go figure

The NVidia video card on my machine, Nouveau loses contact with it.
Distros where the Nvidia binary blob driver is fitted, the card
and the driver remain in contact.
I debugged that by using a serial port on the machine, logging in while
the screen wasn't working using the serial port, and having a look
at dmesg. And that showed the Nouveau messages.
And sometimes, editing the boot line, does result in it working.
It's not the same bug as yours, but that's an idea on how to
get in for a look.
The only bad thing about that, is a grub update can decide to
put the boot menu on the temporary serial port console.
console=ttyS0,57600n8 where "quiet splash" would be
Paul

FWIW: My graphics is listed as Mesa Intel

If a machine refuses to leave the main screen in a usable
state, you'll need to set up a console somewhere, to do your
debugging.
With systemd, and especially with the Ubuntu fantasy world (server
features highjacking a desktop design), there will be times when
the boot log you see on screen, would have a systemd line with
a moving red asterisk. And that's a service that didn't start,
and things are set up to wait forever for it to finish.
These are things you can watch, if you shift the console to
ttyS0 or a similar serial port.
The same thing can happen at shutdown. A shutdown that takes
two minutes, could be systemd holding things hostage.
Some distro designers seem to have a better handle on this
than others. The people with a clue, get on with life and don't
leave systemd burning a hole in the screen with the red asterisk.
For the less clueful ones, they seem to enjoy doing stuff like this.
But I've got mine solved now. I have a permanent cable
run between machines, because you never know when you'll be
needing to debug stuff like this. I also have a copy of Putty
on this machine, that I run all the time. So it's ready too.
Paul

When the system hung I could still hit control-alt F4 to get a terminal.

I did try a few things from there

Jonathan N. Little

2020-08-17 12:12:47 UTC

Post by philo
When the system hung I could still hit control-alt F4 to get a terminal.
I did try a few things from there

If that works the *system* is not hung, but the desktop environment in
user space is hung, which is most times the issue with Linux. Very few
*system* crashes that bring down the OS that are not hardware issues.
This is the contrast from Windows where if the GUI decides to go AWOL
the OS is hung. Since all my systems are on a network, even if a system
becomes unresponsive from the keyboard I can often ssh in to fix.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Paul

2020-08-17 15:08:56 UTC

Post by philo
When the system hung I could still hit control-alt F4 to get a terminal.
I did try a few things from there

Not true. Windows is just as multitasking as the rest.

In a lab situation, you hook two computers together,
and use WinDBG on the Technician Machine, to talk to
and inspect the kernel that is still running on the
other machine.

If the second machine responds to a "ping", yet the
screen isn't working, that means it isn't dead. It might
even emit Browse Master election packets, as if nothing
was wrong.

If WinDBG is not able to open the second machine, *then*
it's toast. That means some simpler facilities are not available.

In the old days, this was easy. If a single core processor
(all they had at the time) had a double-bus-fault, the bus fault
handler could not run (couldn't fetch any instructions), so
logically "the processor was toast". And it would be in HLT state
as a result. I don't know how that stuff works today. I know the
IOAPIC can cause the interrupt load to be spread across all
cores, but I don't know the gritty details of what is running
on what core, and when, down there.

Every maintainer of computers, has a level to which they
won't descend. I don't particularly want to be using WinDBG
for a thing like this. My batting average with debuggers isn't
all that good. But the capability is there, and it's there for
a reason. People developing drivers likely do things
that way daily, in the lab.

Paul

Jonathan N. Little

2020-08-17 16:46:05 UTC

Post by philo
When the system hung I could still hit control-alt F4 to get a terminal.
I did try a few things from there

Not true. Windows is just as multitasking as the rest.
In a lab situation, you hook two computers together,
and use WinDBG on the Technician Machine, to talk to
and inspect the kernel that is still running on the
other machine.
If the second machine responds to a "ping", yet the
screen isn't working, that means it isn't dead. It might
even emit Browse Master election packets, as if nothing
was wrong.
If WinDBG is not able to open the second machine, *then*
it's toast. That means some simpler facilities are not available.
In the old days, this was easy. If a single core processor
(all they had at the time) had a double-bus-fault, the bus fault
handler could not run (couldn't fetch any instructions), so
logically "the processor was toast". And it would be in HLT state
as a result. I don't know how that stuff works today. I know the
IOAPIC can cause the interrupt load to be spread across all
cores, but I don't know the gritty details of what is running
on what core, and when, down there.
Every maintainer of computers, has a level to which they
won't descend. I don't particularly want to be using WinDBG
for a thing like this. My batting average with debuggers isn't
all that good. But the capability is there, and it's there for
a reason. People developing drivers likely do things
that way daily, in the lab.
Paul

Okay you are in Windows 10 and your video driver crashes and you
bluescreen what are your options to resolve *without* rebooting?

In Linux you can open a virtual terminal on that very system and kily
the GUI session, restart or even reinstall the video driver without
rebooting. Login to GUI and be on your merry way. Can be done and have
done it.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Paul

2020-08-17 18:04:53 UTC

Post by philo
When the system hung I could still hit control-alt F4 to get a terminal.
I did try a few things from there

Not true. Windows is just as multitasking as the rest.
In a lab situation, you hook two computers together,
and use WinDBG on the Technician Machine, to talk to
and inspect the kernel that is still running on the
other machine.
If the second machine responds to a "ping", yet the
screen isn't working, that means it isn't dead. It might
even emit Browse Master election packets, as if nothing
was wrong.
If WinDBG is not able to open the second machine, *then*
it's toast. That means some simpler facilities are not available.
In the old days, this was easy. If a single core processor
(all they had at the time) had a double-bus-fault, the bus fault
handler could not run (couldn't fetch any instructions), so
logically "the processor was toast". And it would be in HLT state
as a result. I don't know how that stuff works today. I know the
IOAPIC can cause the interrupt load to be spread across all
cores, but I don't know the gritty details of what is running
on what core, and when, down there.
Every maintainer of computers, has a level to which they
won't descend. I don't particularly want to be using WinDBG
for a thing like this. My batting average with debuggers isn't
all that good. But the capability is there, and it's there for
a reason. People developing drivers likely do things
that way daily, in the lab.
Paul

Okay you are in Windows 10 and your video driver crashes and you
bluescreen what are your options to resolve *without* rebooting?
In Linux you can open a virtual terminal on that very system and kily
the GUI session, restart or even reinstall the video driver without
rebooting. Login to GUI and be on your merry way. Can be done and have
done it.

On a Windows 10 system, you'd have to prepare in advance for
this, by reading up on WinDBG and remote debug using serial cable.

*******

The system has VPU recovery, so the driver can be restarted on
the fly. That is automated and based on some sort of timer behavior
and lack of response. The implementation seems to have changed over
the years, because the symptoms set is different now than it used
to be. There was a time, when the screen would flash a certain way,
and that would be your hint of a timeout.

The video card has a reset signal on it, but I don't know if they
bother with separate decodes or wired OR logic, to be able to
reset the card (without resetting the motherboard too) and
start from scratch to recover it. Recovering the card then,
requires that the hardware be able to accept PCIE messages
and deliver responses.

The situation is just as likely to be an Explorer or DWM issue of
some sort, as for the video card to have tipped over in a non-recoverable
way.

Maybe with WinDBG, you can issue a command to do what is needed.

Some Linux distros here, Nouveau loses contact with the NVidia
card during boot. The Linux NVidia driver never loses contact.
The Windows 10 Nvidia driver never loses contact either. In
the Nouveau case, I can still use my Putty terminal and serial
line to do what I want (mainly, dmesg). (But I've set that up in
advance and modified the boot line for support.) And the mere act of
preparing it for debug, frequently removes the symptoms, suggesting
a slight race condition somewhere in software. Fiddle with it
a little bit, it goes away.

Paul

Jonathan N. Little

2020-08-17 18:15:47 UTC

Post by Paul
On a Windows 10 system, you'd have to prepare in advance for
this, by reading up on WinDBG and remote debug using serial cable.

Because we are all clairvoyant enough to know we are going to BSOD? I
don't think this is a fair comparison.

Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Paul

2020-08-17 19:22:56 UTC

Post by Paul
On a Windows 10 system, you'd have to prepare in advance for
this, by reading up on WinDBG and remote debug using serial cable.

Because we are all clairvoyant enough to know we are going to BSOD? I
don't think this is a fair comparison.
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

You made the statement that Windows is some sort of monolithic blob.

It's not.

Just because no one here knows how to burrow into it,
doesn't mean it can't be done.

I have no interest in looking for such a solution. My interests
lay in real things that happen in the room, or in the rare case
where I can reproduce someone elses problem in the room, *then*
I'm interested in tools and techniques. If the frequency that
things happen is not sufficient to justify a setup, I'm not
doing it.

A "ping" tells me what I need to know. If a machine was
frozen, it would not answer a ping. We would suspect a
hardware issue, then use the hardware test tree to decide
what to do next if the conclusion was that the machine froze.

If the machine answers a "ping", then we need to set up
for the next time, to gather more information. If the machine
"pings", then the Event Viewer logging system will be working,
and there should be an event recorded in there. For example,
in the old days, there'd be thousands of bogus ATI messages
in there from the crusty CCC drivers. I could also get a
synopsys from the Reliability Monitor, which would save on
having to check the entire Event Viewer.

I'm not going to go out on a limb, and say TightVNC,
Terminal Services related remote-in, or anything else
is going to work when there is some video issue. They
probably require something to decorate the display,
DWM and Explorer working and so on. I'm not set up
that way either - I don't have a lot of remote-in
applications primed and ready to go. I haven't even
downloaded Teamviewer. There's nothing in my reliability
results here, to lead me to suspect I need any of that
stuff. Not a good usage of time.

Microsoft claimed that 30% of some class of problem, was
caused by NVidia drivers. As long as there is a log entry
generated, that's a start. (A log entry that can be logged,
because the kernel, the task scheduler, and loads of those
rubbish services are still running.)

Paul

John Dow

2020-08-23 15:30:17 UTC

Hit ESC at the boot screen and remove 'splash' from the kernel option
line, then you can at lease see where it get stuck.

Thank you but in grub, I have kernel parameters set to "quiet splash"

LOL
I removed the "quiet splash" option and the system boots normally now.
Go figure

The NVidia video card on my machine, Nouveau loses contact with it.
Distros where the Nvidia binary blob driver is fitted, the card
and the driver remain in contact.
I debugged that by using a serial port on the machine, logging in while
the screen wasn't working using the serial port, and having a look
at dmesg. And that showed the Nouveau messages.
And sometimes, editing the boot line, does result in it working.
It's not the same bug as yours, but that's an idea on how to
get in for a look.
The only bad thing about that, is a grub update can decide to
put the boot menu on the temporary serial port console.

Y'coulda gone with ctl+alt+f2 :)

j>

Paul

2020-08-23 16:31:02 UTC

Hit ESC at the boot screen and remove 'splash' from the kernel option
line, then you can at lease see where it get stuck.

Thank you but in grub, I have kernel parameters set to "quiet splash"

LOL
I removed the "quiet splash" option and the system boots normally now.
Go figure

The NVidia video card on my machine, Nouveau loses contact with it.
Distros where the Nvidia binary blob driver is fitted, the card
and the driver remain in contact.
I debugged that by using a serial port on the machine, logging in while
the screen wasn't working using the serial port, and having a look
at dmesg. And that showed the Nouveau messages.
And sometimes, editing the boot line, does result in it working.
It's not the same bug as yours, but that's an idea on how to
get in for a look.
The only bad thing about that, is a grub update can decide to
put the boot menu on the temporary serial port console.

Y'coulda gone with ctl+alt+f2 :)
j>

Not in this case.

The architecture has changed enough times, that if Nouveau
fails, there's nothing left to drive the screen. All the fallback
codes and behaviors have been removed. Restarting X11 would
not help, because there's no video card path available to
make anything work. Nobody uses VESA any more (except... Puppy).

I have regularly used ctrl+alt+fn in the past.

The solution is simple. Install the NVidia binary blob, and
it stays running. Even if I didn't want the NVidia driver,
it at least doesn't have the Nouveau issue.

Paul

Jonathan N. Little

2020-08-16 15:01:07 UTC

Hit ESC at the boot screen and remove 'splash' from the kernel option
line, then you can at lease see where it get stuck.

Thank you but in grub, I have kernel parameters set to "quiet splash"

LOL
I removed the "quiet splash" option and the system boots normally now.
Go figure

Sometimes, rarely but not never, after an update Ubuntu doesn't load the
desktop and just rebooting again "fixes" it. I have noticed a pattern,
different systems and different hardware. Not sure but I think it
happens more often with Nvidia, but not solely Nvidia. Also I almost
never use the nouveau divers with Nvidia but use the proprietary driver.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

philo

2020-08-16 23:41:19 UTC

Hit ESC at the boot screen and remove 'splash' from the kernel option
line, then you can at lease see where it get stuck.

Thank you but in grub, I have kernel parameters set to "quiet splash"

LOL
I removed the "quiet splash" option and the system boots normally now.
Go figure

Well, all working. I don't know how grub got changed though.

philo

2020-09-03 23:03:18 UTC

Applied the new updates yesterday and when I rebooted my system again
hung at the purple screen.

Again had to remove the line:

GRUB_CMDLINE_LINUX_DEFAULT quiet splash

Why are the updates putting this line back into GRUB and is there a way
to prevent them from doing so?

Seems like a poor idea to change the parameters offering not user
intervention.

Bit Twister

2020-09-04 00:21:49 UTC

Post by philo
Applied the new updates yesterday and when I rebooted my system again
hung at the purple screen.
GRUB_CMDLINE_LINUX_DEFAULT quiet splash
Why are the updates putting this line back into GRUB and is there a way
to prevent them from doing so?

Offhand, my guess is because the lime was removed.
I would recommend something like
GRUB_CMDLINE_LINUX_DEFAULT splash=off
That should get you the same results.

Then again, you might do what we did. Opened a bug report so that
Mageia Linux quit screwing up our changes.

Post by philo
Seems like a poor idea to change the parameters offering not user
intervention.

Yep, and worse not allow the user to override changes.

I use GRUB_CMDLINE_LINUX for my directives, I wrapped the line, to post.

GRUB_CMDLINE_LINUX="ipv6.disable=1 audit=0 splash=off
plymouth.enable=0 noresume mitigations=off vblank_mode=0 glxspheres"

GRUB_CMDLINE_LINUX_DEFAULT=noiswmd

but GRUB_CMDLINE_LINUX_DEFAULT still overrides any duplicate directive
if you were to look through the /etc/grub.d/ scripts. :(

Because I do clean installs, and grub flexibility I went ahead and
created a make file to automagically do whatever is required to
re-introduce my changes. :-D

Jonathan N. Little

2020-09-04 02:12:02 UTC

Offhand, my guess is because the lime was removed.
I would recommend something like
GRUB_CMDLINE_LINUX_DEFAULT splash=off
That should get you the same results.

I think the proper way is empty quotes

GRUB_CMDLINE_LINUX_DEFAULT=""

What I do, I like to see what is going on. Fun speed reading. ;-)

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

philo

2020-09-04 03:50:51 UTC

Offhand, my guess is because the lime was removed.
I would recommend something like
GRUB_CMDLINE_LINUX_DEFAULT splash=off
That should get you the same results.

I think the proper way is empty quotes
GRUB_CMDLINE_LINUX_DEFAULT=""
What I do, I like to see what is going on. Fun speed reading. ;-)

Thank you. I did that but now I have another problem

If I use Grub Customizer or simply use the command sudo grub-mkconfig I
get the following error

I need to make sure I can edit GRUB before I apply any more updates

Sourcing file `/etc/default/grub'
/usr/sbin/grub-mkconfig: 43: /etc/default/grub: =: not found

Bit Twister

2020-09-04 04:02:11 UTC

Post by philo
If I use Grub Customizer

YeaUck. Tried it once to change menu order and glanced at the
resulting grub.cfg. I uninstalled it.

or simply use the command sudo grub-mkconfig I

Post by philo
get the following error
I need to make sure I can edit GRUB before I apply any more updates
Sourcing file `/etc/default/grub'
/usr/sbin/grub-mkconfig: 43: /etc/default/grub: =: not found

Well, you should have posted /etc/default/grub

Did you try GRUB_CMDLINE_LINUX_DEFAULT="splash=off" or what??

philo

2020-09-04 09:36:27 UTC

Post by philo
If I use Grub Customizer

YeaUck. Tried it once to change menu order and glanced at the
resulting grub.cfg. I uninstalled it.
or simply use the command sudo grub-mkconfig I

Well, you should have posted /etc/default/grub
Did you try GRUB_CMDLINE_LINUX_DEFAULT="splash=off" or what??

Here are the contents of "grub"

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'

GRUB_DEFAULT="0"
#GRUB_HIDDEN_TIMEOUT="0"
GRUB_HIDDEN_TIMEOUT_QUIET="true"
GRUB_TIMEOUT="10"
GRUB_DISTRIBUTOR="`lsb_release -i -s 2> /dev/null || echo Debian`"
#GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL="console"

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE="640x480"

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to
Linux
#GRUB_DISABLE_LINUX_UUID="true"

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

#export GRUB_MENU_PICTURE="/etc/default"

#export GRUB_COLOR_NORMAL="light-gray/black"
#export GRUB_COLOR_HIGHLIGHT="magenta/black"
GRUB_CMDLINE_LINUX=""

GRUB_CMDLINE_LINUX_DEFAULT=""
=""

Andrei Z.

2020-09-04 09:54:49 UTC

Post by philo
If I use Grub Customizer

YeaUck. Tried it once to change menu order and glanced at the
resulting grub.cfg. I uninstalled it.
or simply use the command sudo grub-mkconfig I

Well, you should have posted /etc/default/grub
Did you try GRUB_CMDLINE_LINUX_DEFAULT="splash=off" or what??

Here are the contents of "grub"
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT="0"
#GRUB_HIDDEN_TIMEOUT="0"
GRUB_HIDDEN_TIMEOUT_QUIET="true"
GRUB_TIMEOUT="10"
GRUB_DISTRIBUTOR="`lsb_release -i -s 2> /dev/null || echo Debian`"
#GRUB_CMDLINE_LINUX=""
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL="console"
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE="640x480"
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to
Linux
#GRUB_DISABLE_LINUX_UUID="true"
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
#export GRUB_MENU_PICTURE="/etc/default"
#export GRUB_COLOR_NORMAL="light-gray/black"
#export GRUB_COLOR_HIGHLIGHT="magenta/black"
GRUB_CMDLINE_LINUX=""
GRUB_CMDLINE_LINUX_DEFAULT=""
=""

/etc/default/grub here on Mint 20
~~~~~~~~~~~~~~~~~
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to
Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
~~~~~~~~~~~~~~~~~

philo

2020-09-04 09:56:50 UTC

Post by philo
If I use Grub Customizer

YeaUck. Tried it once to change menu order and glanced at the
resulting grub.cfg. I uninstalled it.
or simply use the command sudo grub-mkconfig I

Well, you should have posted /etc/default/grub
Did you try GRUB_CMDLINE_LINUX_DEFAULT="splash=off" or what??

Here are the contents of "grub"
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT="0"
#GRUB_HIDDEN_TIMEOUT="0"
GRUB_HIDDEN_TIMEOUT_QUIET="true"
GRUB_TIMEOUT="10"
GRUB_DISTRIBUTOR="`lsb_release -i -s 2> /dev/null || echo Debian`"
#GRUB_CMDLINE_LINUX=""
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL="console"
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE="640x480"
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter
to Linux
#GRUB_DISABLE_LINUX_UUID="true"
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
#export GRUB_MENU_PICTURE="/etc/default"
#export GRUB_COLOR_NORMAL="light-gray/black"
#export GRUB_COLOR_HIGHLIGHT="magenta/black"
GRUB_CMDLINE_LINUX=""
GRUB_CMDLINE_LINUX_DEFAULT=""
=""

Snip

I now realize that line # 43 was garbage.
I removed it and updated GRUB all ok

Andrei Z.

2020-09-04 12:05:13 UTC

Post by philo
If I use Grub Customizer

YeaUck. Tried it once to change menu order and glanced at the
resulting grub.cfg. I uninstalled it.
or simply use the command sudo grub-mkconfig I

Well, you should have posted /etc/default/grub
Did you try GRUB_CMDLINE_LINUX_DEFAULT="splash=off" or what??

Here are the contents of "grub"
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT="0"
#GRUB_HIDDEN_TIMEOUT="0"
GRUB_HIDDEN_TIMEOUT_QUIET="true"
GRUB_TIMEOUT="10"
GRUB_DISTRIBUTOR="`lsb_release -i -s 2> /dev/null || echo Debian`"
#GRUB_CMDLINE_LINUX=""
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL="console"
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE="640x480"
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter
to Linux
#GRUB_DISABLE_LINUX_UUID="true"
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
#export GRUB_MENU_PICTURE="/etc/default"
#export GRUB_COLOR_NORMAL="light-gray/black"
#export GRUB_COLOR_HIGHLIGHT="magenta/black"
GRUB_CMDLINE_LINUX=""
GRUB_CMDLINE_LINUX_DEFAULT=""
=""

Snip
I now realize that line # 43 was garbage.
I removed it and updated GRUB all ok

Here GRUB_DEFAULT=0 not "0"

/usr/share/grub/default/grub
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

philo

2020-09-05 12:11:49 UTC

Post by Andrei Z.

Post by philo
If I use Grub Customizer

YeaUck. Tried it once to change menu order and glanced at the
resulting grub.cfg. I uninstalled it.
or simply use the command sudo grub-mkconfig I

Well, you should have posted /etc/default/grub
Did you try GRUB_CMDLINE_LINUX_DEFAULT="splash=off" or what??

Here are the contents of "grub"
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT="0"
#GRUB_HIDDEN_TIMEOUT="0"
GRUB_HIDDEN_TIMEOUT_QUIET="true"
GRUB_TIMEOUT="10"
GRUB_DISTRIBUTOR="`lsb_release -i -s 2> /dev/null || echo Debian`"
#GRUB_CMDLINE_LINUX=""
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL="console"
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE="640x480"
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter
to Linux
#GRUB_DISABLE_LINUX_UUID="true"
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
#export GRUB_MENU_PICTURE="/etc/default"
#export GRUB_COLOR_NORMAL="light-gray/black"
#export GRUB_COLOR_HIGHLIGHT="magenta/black"
GRUB_CMDLINE_LINUX=""
GRUB_CMDLINE_LINUX_DEFAULT=""
=""

Snip
I now realize that line # 43 was garbage.
I removed it and updated GRUB all ok

Here GRUB_DEFAULT=0 not "0"
/usr/share/grub/default/grub
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Now that GRUB is fixed I am having a weird H/W problem. I may end up
building a whole new machine.

Looking for an excuse to get a DDR-4 capable mobo

Bobbie Sellers

2020-09-04 04:12:33 UTC

Offhand, my guess is because the lime was removed.
I would recommend something like
GRUB_CMDLINE_LINUX_DEFAULT splash=off
That should get you the same results.

I think the proper way is empty quotes
GRUB_CMDLINE_LINUX_DEFAULT=""
What I do, I like to see what is going on. Fun speed reading. ;-)

Thank you. I did that but now I have another problem
If I use Grub Customizer or simply use the command sudo grub-mkconfig I
get the following error
I need to make sure I can edit GRUB before I apply any more updates
Sourcing file `/etc/default/grub'
/usr/sbin/grub-mkconfig: 43: /etc/default/grub: =: not found

It is time to re-install grub which you should do from the
package manager first removing it then searching on grub, reinstall
every grub package that is compatible. Of course I work on a
different OS with proper root and use Synaptic where I have done
just such a re-installation of Grub. There is a small iso file
called Super Grub2 that lets you boot any viable install of Linux if
you cannot get to the GUI, Otherwise you will have to look up
the proper syntax on your machine to re-install Grub2 from the
recovery mode terminal. You can do that by either going to
the Ubuntu online forum or by searching on "Grub2 install from
terminal". You might have to use tools to get the needed
files so ask the question you need to ask of the Search Engine
{preferably DuckDuckGo in mnsoho}.

bliss

--
bliss dash SF 4 ever at dslextreme dot com

philo

2020-09-04 09:38:35 UTC