Slackware and the grub boot loader.
 

Hi: Two questions:
(a) Do you know anybody using slackware with grub? I mean grub loads the Slackware operating system.

(b) Does grub come with the Slackware installation disks?

Yes and yes. Grub isn't used as the bootloader by default. You can install grub manually by chroot into your system.
at the elilo/lilo prompt open another console
chroot /mnt
then run grub-install and grub-mkconfig

Everything that @colorpurple21859 wrote.

I think that I don't have any physical machines left that use lilo/elilo.

In fact, I just installed grub 2.04 on my Slackware64 14.2 machine so I could easily boot into windows 10 on that particular machine. 2 of the other machines don't have to deal with windows, so I don't need to upgrade grub on them. The last machine is running -current, so grub 2.04 is already there.

Thanks. Is there a detailed procedure, assuming I already have the grub boot loader in the MBR, to make the boot loader to load Slackware? I think the procedure is quite simple, only involving at most two steps. Perhaps in the Slackware documentation there are precise instructions to follow?

I have already tried using grub with Slackware in the past but the result has been complete failure and it is already three years that I lack Slackware in my machine.

after installing bootloader to mbr run That will give you a grub menu. Slackware doesn't auto-run that command with kernel updates to update the grub menu for kernel changes.

I use GRUB.

I've been using GRUB since before I started using Slackware, when GRUB was version 0.9x. Back in those days I was multi-booting a lot. I found GRUB more suited to that environment. Just edit menu.lst and not worry about forgetting to run lilo.

I don't think GRUB was included in Slackware until around 10.1 and was in the /extra branch.

I use lilo in throwaway Slackware VMs.

I have debian 10 in another partition. Shall I still be able to boot debian after running that command?

One of the systems needs to be the primary GRUB source. On one system or the other, enable /etc/grub.d/30_os-prober (chmod +x). Then run grub-mkconfig on that system. Debian systems support a grub-mkconfig script wrapper named update-grub.

If you only have one drive, whichever distro was last to run assuming your one drive is sda, will display the boot menu of /boot/grub/grub.cfg of that distro.
Yes you should be able to boot debian after running that command, but there maybe other issues that we aren't aware of at this time.

This is the grub.cfg I got:But there is no line for initrd. Should I add one? And how should it read?

Well, there's https://github.com/Richard-Cranium/SlackwareGrub2

Do you have an initrd.gz?
If you only use the first slackware entry to boot and it works without the initrd.gz line, I wouldn't worrry about it.

Otherwise grub is versatile so there is several ways of doing this.
1. As per Richard Cranium post 11

2. Copy the slackware menu entries that you want to use to /etc/grub.d/40_custom and insert the initrd=/boot/initrd.gz between the vmlinuz line and the } line and run update-grub. Be aware that is file is static and won't change with a kernel version change.

3.Chainload slackware grub.cfg with this entry

I would like to ask how the approach to installing grub2 if you have uefi differs

the above implies bios ?

Previously I had a pc using bios; i booted up in lilo , removed it ,installed grub2 ran command

grub-mkconfig -o /boot/grub/grub.cfg from memory and everything worked. Then if i understand it grub stage 1 was on mbr and that pointed to grub stage2.

For myself and probably many others having a /dev/sda with a gpt label, a 100MB of EFI and presently using elilo ,how would the approach to installing grub2 differ than if you have say a bios pc and lilo?


I see in boot there is a grub folder. Would installing grub2 put files there are creates another directory called grub2 ?

@captain_sensible - you can preview what grub will see and how it will function if you have rEFInd installed for EFI booting. Just load your Slackware install media and select it with rEFInd and the grub bootloader for UEFI media boot will appear and display all the kernels it finds (even some you may have no intention of using excepting recovery) and you can test each and every one.

You can do that from a running Slint typing grub-emu in a terminal. Users will be proposed to run it at end of Slint installation in next Slint installer, which will help blind users to know the layout of the GRUB menu after reboot, otherwise not accessible to them.

I don't have an initrd.gz in the Slackware partition. The initrd is generated by mkinitrd which I can't run because I can't boot Slackware yet. So, let's omit the initrd thing for the moment.

After running grub-mkconfig under debian and with the slackware 14.2 already installed, I booted and got this:Here a new piece of information: this laptop uses eMMC instead of a hard disk. Though I have already successfully installed debian and linux arch on it, I think Slackware simply does not understand it, which is odd because the installer works fine, writing to the eMMC a lot of data.

In view of this, I'll start a separate thread under the title "Slackware and eMMC". Thanks for all the feedback.

If you install the Slackware, there is a initrd.gz by default which comes with the default huge kerneL.

I don't think Slackware will boot without it.

Is that actually accurate? It is my understanding that what makes the Huge kernel huge is almost everything is checked and therefore no initrd is needed. IIRC a sample initrd is included for the Generic kernel only with the expectation that each user will generate his own for his hardware and software specifics. FWIW the only reason I would ever employ initrd is for encrypted file systems. I have never used one in over 20 years.

As pointed out in post #18, the huge kernel does not need a initrd.gz to boot.

This is partially true. On -current and most likely 15.0+ releases, Slackware will include an initrd after installation, but it will be booting the generic kernel with that initrd. The huge kernel is still available (for now) if people want to switch to it. For 14.2 and earlier, it will install both the generic and huge and boot off the huge by default. The admin would be required to set up and initrd and switch to the generic kernel, which is recommended by Pat.

-current boots the huge kernel perfectly without a initrd.gz.
With "modern" hardware there is no perceived benefit to using the generic kernel and a initrd.gz.

I think you will need initrd.gz with eMMC
at the grub menu highlight the slackware menu entry Press e for edit
add a new line after the linux line with this

initrd /boot/initrd.gz

boot and see what happens.
If that doesn't work and/or a initrd.gz doesn't exist, at he grub menu edit the linux line
change the root=/dev/mmcblk0p2 on the linux line to root=UUID=2d63e598-b1b4-4e32-a781-9fe9ceae2c11

I don't know anything about eMMC. But the installer actually is an initrd and it contains lots of modules, see
so if the installer can write to the eMMC but the installed system does not recognize it, it's possible that even the huge kernel may need an initrd for an installed system to boot, with some modules the installer's initrd.img has.

I looked at the /boot directory in the slackware partition and did not find any initrd.gz. What is UUID=2d63e598-b1b4-4e32-a781-9fe9ceae2c11?

While running the installer, what does "lsmod" print out (in another virtual console)?

That is the blkid of the slackware partition, but just remembered that has to have an initrd to work, so scratch that one.

open a terminal in debian as root, this is assuming "/dev/mmcblk0p2" this is the correct /dev for slackware partition.

run the command genererated for mkinitrd

Well, among the lines printed out there is:

So, the huge kernel needs at least those modules in initrd.

All sh did was to print the following:Could it be because I installed 14.2 32-bit and this machine is 64-bit?

Forgot to add the -k for your slackware kernel version.
No that is debians kernel version that is currently running and the script defaults to the running kernel if the -k option isn't supplied

If it still won't boot check-out the last 2 post in this thread https://www.linuxquestions.org/quest...ge-4175587811/

Alright. Assume I already have my initrd.gz. Why can't I just make grub.cfg writable and manually edit it to modify the line? I've already done it adding to the line the kernel parameters edd=off and noapic.

yes you can do that, but the first debian update that runs update-grub will undo your edit. Slackware doesn't update the /boot/grub/grub.cfg when updating the system, but debian does. It should pick up the initrd.gz when update-grub is rerun

Those also will go away when debian updates the kernel. Edit /etc/default/grub and add it to the run update-grub

I would not use mkinitrd_command_generator.sh running on the debian kernel but just try in that chroot.

I assume grub took notice of the 10_custom file, where the initrd line is. I'll see your link in post #32.

I tried with the initrd.gz made as in post #27 and I tried with the one made as in post #35 both cases resulting in Kernel panic (same message).

@colorpurple21859: I read the posts you suggested in post #32. But they assume you recompile the kernel, a work I am not willing to do.

In the eMMC there are two partitions which are not shown by cfdisk. One of them is EFI, I think. When I ran the installer I was surprised it had found an NTFS partition with size 512MB. That is one of the "hidden" partitions. One thing: are we sure the kernel panic message is caused by the eMMC thing? What remains true is that both arch linux and debian had no problem with the eMMC.

EDIT: I have a second machine with 14.2 running on it, in case that is helpful.

When you run lsmod in the installer, maybe it listed some other modules than you wrote in #28 ? If so, try add them in the mkinitrd command in #35.

This probably will never happen, but maybe Slackware could provide a choice? LILO / GRUB , ELILO/GRUB (UEFI) - without having to manually go in and install GRUB instead of LILO/ELILO. Just a thought.

I ran the installer and when it gave me the prompt I logged in as root and ran lsmod. Is it correct?

Volkerdi himself told me lilo can't manage eMMC. I think if elilo can he would have told me.

I'll run the installer and after having run lsmod I'll use gpm (general purpose mouse) to paste the output into a file. Only thing is I don't know where gmp will be in the file system (I installed it).

Yes, run uname -r if the kernel version is the same as the one of the installed system rerun the commands of post 30 minus the update-grub

This is the output of 'uname -r' run while running the installer:Does it match the kernel version?

This is the output of 'lsmod' run while running the installer:

Of course it does: I looked into the slackware /boot directory and the names of the images include '4.4.14-smp'. I did exactly what you said but still the same kernel panic message.

add rootdelay=15 to the linux line of the grub menu

did you try Petri Kaukasoina suggested mkinitrd line:
and/or add this to the mkinitrd command that was generated.

I read this thread and it is very easy to see why Pat does not make grub the default boot manager.
Just a Thought

This link has a section on creating an initrd for an emmc drive that may be of help, ignore the sections about efi. https://ansuz.sooke.bc.ca/entry/340

Ok, I guess we tried to use modules for the wrong (non-smp) kernel. Try this:

In order to paste the output of mkinitrd_command_generator.sh I run the commands of post #27 in a GUI terminal after doing 'su -' and then with the mouse I copy and paste. But I understand 'su -' is not exactly the same as using one of the consoles (dev/ttyN) as root. Is it OK if I use a GUI terminal?