Slackware on VirtualBox, can't upgrade GRUB
 

I installed Slackware-15 on VirtualBox 7.0.12 and I'm having trouble customizing the GRUB installation:

When I power up the VM, the grub menu shows two huge kernel options, and then a third menu option for all the kernels - and the kernel I want to default is in that menu. I've tried things like adding this to /etc/default/grub

Also, tried to default one of the submenu items with

And then I run grub-mkconfig, and it seems to work - here's an example:

(that's part of grub.cfg, appears like the changes have happened.)

But no matter what I do, I get the same GRUB menu at the beginning. Anyone have any idea what's going on?

If you have a specific entry in the grub menu you want as the default, the simplest way to get it is to see which entry it is in the menu. If the entry you want is the third entry, you would change for testing purposes, the set default="0" line in grub.cfg and change it to the number 2 as Grub counts from zero. Do not run grub-mkconfig. If it boots the entry you want, make the change permanent by editing the /etc/default/grub file, the line entering the number you want instead of 0 and then run grub-mkconfig.

You could just make the change in /etc/default/grub and then run grub-mkconfig if you want.

Yeah I know this, but listen - there are three entries in the startup menu: "huge.s", "something else that's like huge.s", and "Other kernels". What I want is in "other kernels" (it happens to be the first entry). So first, I can't just set "0" or "2" in the grub config script, but I *think* I should be able to do "2>0" to tell Grub to hit the 2 menu entry ("other kernels") and then the first entry in that submenu (which is the generic kernel I want). That's what I tried to do, and grub.cfg changed (see the text above), but there was no change to the behavior at startup - I still just see three entries, two huge, one submenu.

The link below has some relevant information. If you want the generic kernel to boot and the first entry is the huge kernel, why not simply change the linux line to point to the generic kernel in the first entry and add the initrd line?

https://unix.stackexchange.com/quest...-the-second-os

I generally modify the grub.cfg file when testing things as it saves time. Make a change to grub.cfg and reboot to test. I don't run grub-mkconfig so it isn't necessary to put the change in the permanent files. If it works, put the change in the appropriate grub file (/etc/default/grub or /etc/grub.d directory) and run grub-mkconfig. Your choice.

Slackware doesn't auto-run grub-mkconfig with updates, edit the fisrt menu-entry in the grub.cfg linux line to /boot/vmlinuz-generic and be done with it. No need to run grub-mkconfig with kernel updates.

trying to follow the instructions there (I can't copy-paste from VM....is there a trick to that?):
Attachment 42101
/boot/grub/grubenv does exist - didn't SS that, but I can see it there.

the grub.cfg file is complicated (kinda)...it's all about automatically finding kernels, so I don't really know how to write individual entries, a la lilo.

I appreciate the help, but I don't understand how to do this. the grub.cfg file is split into sections:

But I don't see any of those menu entries (see my SS above) - whatever is going on with the "automatically finding kernels" routine is happening before any of the menu entries are being hit, so if I start replacing them, nothing is going to happen. No changes I've made to either /etc/default/grub or /boot/grub/grub.cfg changes anything about the boot process.

/boot/grub/grub.cfg file is the one to edit. If you run grub-mkconfig after editing /boot/grub/grub.cfg the edits will be lost.

If manually editing /boot/grub/grub.cfg and you didn't run grub-mkconfig aftwards does nothing something else is going on. Is there a grub.cfg somewhere on the efi partition that needs to be edited instead of /boot/grub/grub.cfg

I understand - but none of the edits I make are actually propagating down to the menu on restart. Here's the beginning of my grub.cfg file (I got copy paste enabled!).
But it's not defaulting to the second item in the menu (indicated by "1") - it still just sits with the first entry selected and waits for input.

(I even just tried to comment out everything from if [ "$(next_entry)...else and then fi, so that it would just hit the set default command, and no change in behavior.

Can I try to ask something else - is it possible the VirtualBox installation is borked in some strange way? The reason I'm switching from the Slackware huge kernel to the generic one is that when I select the Huge one, it doesn't boot, it just goes and looks for the installation media (the original .iso file), as if the drive is not flagged for booting. If this was a real machine, I would expect some kind of kernel panic if Huge was invalid. Is it possible GRUB is being loaded from some other location, or doing some kind of default script, instead of the one I'm actually editing?

Ok good thought - there is no efi partition in this VM, because I didn't make one.

(on efi machines I think it's mounted in /boot.)

But I shouldn't *need* an efi partition right? GRUB should be able to handle booting being installed to....I dunno, whatever the equivalent of an MBR is for a virtual disk?

EDIT: Don't think this helps, but anyway:

The message in the image in post 6 indicates you are trying to write to a read only filesystem. The "canonical path of cow" part.

As has been pointed out to you twice, given your lack of knowledge on the subject, you are best off modifying the /boot/grub/grub.cfg file as root and leaving the other files alone until you have something that has been tested and works. After modifying the file, do NOT run grub-mkconfig. See line 2 in grub.cfg

Linux installs on GPT drives in Legacy/CSM mode (which you have, MBR install) generally require a 1MB unformatted partition where the core.img file used by grub is placed. You don't have that and you don't have an EFI partition are you booting the installed system or from the iso in the virtual software?


Your Slackware menuentry in grub.cfg should have the 2 lines below at the end of the entry:

The huge kernel will be the same except that huge replaces generic in the linux line and the initrd line is not needed. This seems a lot simpler than what you are trying to do.

Ok, got it, thanks.

Agree that I do not know what I am doing with Virtualization, but I do think I'm addressing this comment (which yes, had been made several times) as best I can - modifying grub.cfg does not impact the boot process -no menu items are any different when I change grub.cfg. And no, I am not running grub-mkconfig at any point in this process.

Very helpful, thanks - although I don't quite understand the question. I certainly am trying to boot into the installed system, and I think I am because I am making changes, installing software, etc. I thought creating a partition table (ie in fdisk during Slackware Install) would have created the MBR and made space for the GRUB files (like core.img). I guess you're saying that didn't happen - can you give me some advice on how to check that?

My concern with that is that /dev/nvmme0n1p6 is my physical disk, not the virtual one. And there are only 4 partitions on that disk, so p6 doesn't exist.

I tried it anyway, but as I've said before, changes to grub.cfg do not have any effect on the GRUB menu, so this change (right or wrong) made no difference.

To install grub to mbr of a gpt drive that doesn't have a 1mb flagged bios-grub/bios-boot partition is similar to this:
from within the booted installed system or chroot into the installed system after bind mount of the appropriate directories.

Trying it....
And it still had no impact on restart. Can I redo this installation and create an MBR partition on the virtual drive? I can see that is an option in fdisk. Is that the "right" thing to do here?