Here's a post by Pat V
http://www.linuxquestions.org/questi...2/#post4197960

This was in 12-20-2010! If Slackware was as conservative as well, we would not have left the first version of Slackware.
Major distros use grub today, were they wrong?

What we have works fine for most people.

There is a grub package for those that choose to use it and nothing prevents them from doing just that.

Other distros are not Slackware and I don't see how the comparison is even valid.

If the Pro's of those other distros outweigh the cons of said distros then I'd suggest you either Customise Slackware to suit your needs or use another distro.

What's next? Are you going to ask for an option in the Installer for a Graphical Setup?

1 members found this post helpful.

Huh? Lilo IS the default boot loader in Slackware. Makes perfect sense.

I have very little knowledge of Unix / Linux. I like Slackware and I
continue with it, at least for now.

Said is said!

If I were younger, and the longest time, I might have more interest in
contribution, but it makes no sense ...

Very many thanks for keeping Slackware Live (honestly)! :-)

I think that in life, there is no defaults. People who cling to patterns, age earlier ...

0 members found this post helpful.

I switched to GRUB in an earlier Slackware because the need to re-run the lilo command, which sometimes would even fail, because I was moving stuff around a lot. But that was before the GRUB people started being annoying about deprecating grub (legacy, as they call it) even before the documentation for GRUB2 was available. So I ended up "writing off GRUB" altogether because of an annoying core community around it. But I've never liked LILO's hackish ways to find the kernel. I still use GRUB1 (I don't call it legacy) for now.

I'm looking for something better. I don't need all the fancy stuff of GRUB2, although a boot image and basic menu would be nice. A very simple bootloader that loads the kernel raw from a partition (and maybe initrd/initramfs from behind the kernel or from a 2nd partition) would be all I need. The idea of using 1 or 2 partitions just for that seemed to be a waste until GPT came along. Now there are plenty enough to even do a multiboot this way.

So I've been thinking of writing a boot loader like this. Or maybe I'll explore using SYSLINUX or EXTLINUX or hacking it to do GPT.

And I'd like to experiment and see if I can make a small 446 byte bootloader bring the kernel in from a GPT partition, so the bootloader doesn't need to be squatter on other disk sectors.

Isn't that exactly what lilo does? The mapping is entirely done by the kernel at installation time (ioctl calls). The mapping information is cleanly stored in a map file. No side effects. Only burden on you: you need to remember to refresh the map every time you change a boot relevant file.

I myself have used both over the years (lilo used to be the default boot loader for redhat systems) and haven't had problems with either. Personally i would just go with the default for the distribution you are using since they also usually come with the utilities for updating those boot loaders.
Just my 2 cents

1 members found this post helpful.

I think he/she wants the kernel/initrd to be raw written to a partition.

e.g. cat vmlinuz > /dev/sdx1 ; cat initrd.gz > /dev/sdx2

The difference would be that the bootloader I want to make would simply look up the partition table entry, and treat that as a sector range. BTW, one of the reasons I want to do such a bootloader is that it makes it easier to construct hard drive images.

But still, I could hack the lilo configure time program, teach it to generate the sector ranges from partition data, and construct the maps like that. The map would just be a file of sequential numbers. But I would not need to re-run the lilo command if I place a different kernel in the partition where I keep a kernel, since the sectors will still be the same. The only issue to resolve is the oversizing of the partition. It would be spending time loading sectors it does not need to load. The loader I would make would either look for a header in front of the kernel that has the length, or look for a sentinel placed behind the kernel (an sha256 of the name of my bootloader ... what's the chance of that ever being a compilation product of the kernel).

Yes! That! Or variations like:

cat vmlinuz sentinel initrd.gz sentinel sentinel > /dev/sdx2

where "sentinel" is a file containing the name of my bootloader hashed with sha256 (a copy of which would be integrated in the bootloader, too).

FYI, one of the reasons I want to have this is to be an easy way to construct drive image files which would later be dd'd to flash drives.

I see. That would work of course. I'd ask myself if it's worth the effort, though.

Lilo has the advantage that it works in almost every scenario. I have read some posts here that grub couldn't boot on some motherboards (i think it was some asus boards) when the partitions didn't follow dos compatibility. Maybe it is the board's BIOS fault and not grub's but lilo works so it is a nice default choice.

Also lilo is simple/stupid and doesn't need to know the partitioning scheme or filesystem. The disadvantage of this is that we need to run lilo when the kernel is changed but the great advantage is that because of this, lilo works everywhere. I used GPT ever since it was supported in the linux kernel and because GPT has a fake "protective" MBR, i could install lilo there and boot slackware fine. Eventually there was a patch for grub legacy but many people said it was not correct. Anyway, as Martinus2u said, you need to wait for grub to get support for the X thing you might want while lilo works out of the box.