[SOLVED] GRUB Error: No suitable video mode found. Booting in blind mode. Dual booting 2 Slackware. Can login, can startx
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Since I'd prefer them in this order:
lilo/elilo just like it's shipped now in 15.0
syslinux
refind
runit
grub-legacy
grub2
Tried, used, but only need 1% of grub features really.
Quote:
Originally Posted by knet
Adding insmod efi_gop to the grub boot entry for my 2nd install seem to work. No error message now.
Mark solved then? I didn't realize only the error was the issue.
Thought it's closely related to (FTIO's) nvidia bug, where all display is blank after the loader completes, which is a nasty bug.
And you did tag this 'nvidia' so excuse the assumption I made, that the display is fully offline up until login/startx.
...
Mark solved then? I didn't realize only the error was the issue.
Thought it's closely related to (FTIO's) nvidia bug, where all display is blank after the loader completes, which is a nasty bug.
And you did tag this 'nvidia' so excuse the assumption I made, that the display is fully offline up until login/startx.
Not yet. The error message persists after reboot despite doing the tweak that's supposed to make it permanent. And you're right there's an nvidia tag because my gpu is nvidia. We're okay elcore, cheers!
The error message persists after reboot despite doing the tweak that's supposed to make it permanent.
I'd just simply add it directly to grub.cfg like marav said, don't overcomplicate things.
There's nothing in Slackware that's overwriting that file without your permission, unless you insist to manually overwrite it with mkconfig or some update-grub script.
Adding insmod efi_gop to the grub boot entry for my 2nd install seem to work. No error message now. How can i make that permanent? Will adding GRUB_PRELOAD_MODULE=efi_gop in the /etc/default/grub file do that?
yes if you run
Code:
grub-mkconfig -o /boot/grub/grub.cfg
after making the edit.
Or as has been suggested by elcore, edit /boot/grub/grub.cfg directly. Unlike other distros Slackware doesn't auto-update the grub.cfg with updates. If you edit the /boot/grub/grub.cfg directly change the /boot/vmlinuz-...-<version nmuber> to either /boot/vmlinuz-huge or /boot/vmlinuz-generic depending on which kernel you use.
Last edited by colorpurple21859; 03-25-2023 at 12:21 PM.
after making the edit.
Or as has been suggested by elcore, edit /boot/grub/grub.cfg directly. Unlike other distros Slackware doesn't auto-update the grub.cfg with updates. If you edit the /boot/grub/grub.cfg directly change the /boot/vmlinuz-...-<version nmuber> to either /boot/vmlinuz-huge or /boot/vmlinuz-generic depending on which kernel you use.
Do you think this error message has nothing to do with not using the nvidia driver?
You mean unless I insist on updating the kernel when available and necessary, right?
See the 1.) upstream kernel 'make install' script, as shipped by kernel.org, and 2.) kernel package doinst.sh script, as shipped by Slackware.
It's certainly not updating grub files. If you do update your grub files along with the kernel, that is your responsibility and not Slackware's.
Furthermore, if you use another distro to update your grub files, I don't see how is that Slackware responsibility either, which is why I asked you to post full grub.cfg in post #2
Furthermore, if you use another distro to update your grub files, I don't see how is that Slackware responsibility either, which is why I asked you to post full grub.cfg in post #2
+1 to that.
Further, the naming scheme of the initramfs in Slackware: "/boot/initrd.gz" is recognized by default neither by grub-mkconfig in grub nor by os-prober. To overcome this grub in Slackware is patched with this:
Code:
diff -Naur grub-2.00.orig/util/grub.d/10_linux.in grub-2.00/util/grub.d/10_linux.in
--- grub-2.00.orig/util/grub.d/10_linux.in 2012-04-18 23:24:38.000000000 +0200
+++ grub-2.00/util/grub.d/10_linux.in 2012-06-30 07:53:03.765625589 +0200
@@ -198,7 +198,8 @@
"initramfs-genkernel-${version}" \
"initramfs-genkernel-${alt_version}" \
"initramfs-genkernel-${GENKERNEL_ARCH}-${version}" \
- "initramfs-genkernel-${GENKERNEL_ARCH}-${alt_version}"; do
+ "initramfs-genkernel-${GENKERNEL_ARCH}-${alt_version}" \
+ "initrd.gz"; do
if test -e "${dirname}/${i}" ; then
initrd="$i"
break
But if grub-mkconfig is run from a distribution not "Slackware initramfs naming scheme aware" grub-mkconfig, not find the initrd, does not write a line for it in grub.cfg so if a generic kernel is used this leads to a kernel panic.
Last edited by Didier Spaier; 03-26-2023 at 03:29 AM.
Furthermore, if you use another distro to update your grub files, I don't see how is that Slackware responsibility either, which is why I asked you to post full grub.cfg in post #2
I for one I believe that in fact it's a very bad idea the delegation of boot loading to another operating system.
That's WHY I use rEFInd as Boot Manager (not abusing it as Boot Loader, then ending with copying kernels around), chainloading the EFI GRUB2 binaries of Slackware, Ubuntu and openSUSE, each one doing its business and only its business.
Maybe this setup looks complicated at first sight, BUT each operating system is fully independent, in the end this simplifying considerably the maintenance.
In the end, it's a practical example of the old saying: don't complicate your life for the sake of simplicity.
Last edited by LuckyCyborg; 03-26-2023 at 03:55 AM.
I for one I believe that in fact it's a very bad idea the delegation of boot loading to another operating system.
100% agree
Quote:
Originally Posted by LuckyCyborg
That's WHY I use rEFInd as Boot Manager...
Next time I dualboot/multiboot I will consider rEFInd first.
Quote:
Originally Posted by LuckyCyborg
Maybe this setup looks complicated at first sight, BUT each operating system is fully independent, in the end this simplifying considerably the maintenance.
This is actually funny. Who is that "you"? It's not me. I am curious though why the assumption.
Is there "someone else" who you think is responsible for executing grub-mkconfig and taking care of your personal boot loader configuration?
I didn't assume a damn thing, you put lmde in your list of distributions and then expect Slackware users to conform with lmde grub2 upgrade policy.
There's no such thing in Slackware yet, if you did read the actual scripts involved you would know, and wouldn't have to ask for confirmation.
Is there "someone else" who you think is responsible for executing grub-mkconfig and taking care of your personal boot loader configuration?
I didn't assume a damn thing, you put lmde in your list of distributions
Well that is a plain stupid assumption. Just because i have listed lmde there doesn't mean I use it to do what is that you're saying? "use another distro to update your grub files". Just stupid.
Quote:
Originally Posted by elcore
and then expect Slackware users to conform with lmde grub2 upgrade policy.
Plain stupid assumption here again. I am not expecting Slackware users to conform with lmde blah blah blah.
Quote:
Originally Posted by elcore
There's no such thing in Slackware yet, if you did read the actual scripts involved you would know, and wouldn't have to ask for confirmation.
I told you I am grub noob and because of that I am humbly inclined to at least be wary of this warning from grub.cfg. That is all.
Code:
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
I am sorry guys and yes I am grateful for the replies. I already marked this thread solved. I only have a full install of Slackware64-15.0 with DAW template. Thanks again.
Just because i have listed lmde there doesn't mean I use it to do what is that you're saying? "use another distro to update your grub files". Just stupid.
No it doesn't, but if you have lmde installed and update its kernel, it'll overwrite the cfg whether you like it or not.
Which is a distribution policy, and not standard for other distros to conform to.
Quote:
Originally Posted by knet
at least be wary of this warning from grub.cfg.
I have no such warning in that file because I'm perfectly capable of writing one myself, tyvm.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
