I hate grub

[Don B. Cilly]

Let's have a hate topic. Snarl, growl.
No, really. I hate grub. To start with, it sound like "crap" with a head-cold. And it pretty much behaves as such. Let alone what it literally means.
And then... do I really have to elaborate? Or are you familiar enough with the beast to guess?

But the thing is, if it weren't so important, I wouldn't really care.
But the thing is, it's not important. It's fundamental,
That and the partition manager (KDE's in particular), are enough to put anybody off Linux as soon as they attempt to install it.

Now, I can understand. We like our "security through obscurity". If everybody actually used Linux, we'd be a target.
So, the partition manager and the impossible installation whinings probably have some sense in the global ecosystem of OSs.

But grub mainly comes into play after we've actually managed to install, and are actually trying to use, the OS.
It annoys. It misbehaves. It does everything in its power to make it difficult to understand it, let alone use it.
It doesn't even look at fstab, let alone modify it it as needed. And a hundred other things.

So, well, I really wish someone out there would make a bootloader that was actually usable, and get it to be Linux's default.

[SpecialEd]

>>>>

Now, I can understand. We like our "security through obscurity". If everybody actually used Linux, we'd be a target.>>>

Personal pet peeve: Security through obscurity does not apply to Linux. Security through obscurity relies on the secrecy of the system, the opposite of Linux.

[Don B. Cilly]

Well, it depends on whether you take it literally or figuratively.
Figuratively speaking (I put it in quotes and this is the Water Cooler) it does apply.
You know what I'm talking about, don't you?

What it doesn't apply to, is grub. Even though it is unbearably obscure, it's not secure in any meaningful way... well, except in helping people stay away from Linux so nobody thinks it's worth running exploits on it

[P.S.] Please don't take this seriously. It's the Water Cooler and I'm just basically bullshipping*

*Bullshipping: the well-known Spanish practice of shipping bulls from one end of the country to the other - and back - , for no apparent reason... except to get agricultural subsidies ;·)

[oshunluvr]

There are other boot loaders available, but I don't find grub a problem at all. Nor is it "obscure" by any meaning of that word I'm aware of. Now EFI - that's another subject. But progress must be made in all things or they die - and that includes boot loaders.

[Don B. Cilly]

Boohoo. My hate thread isn't finding any fellow haters... ;·)
So, 21 posts in this thread and 12 in this other because clonezilla does't find it simple enough to know that if you clone a partition you also clone the UUID and that causes grub to go bonkers. and boot-repair is too much of a cobbler to realise, well, anything to do with grub - i mean, it deals in footwear, not food, where the answer was: just edit fstab, you twit, it takes three seconds or so... makes it not obscure enough?

[EDIT] Of course, EFI, it's another matter. Because grub doesn't rely on that at all...

[oshunluvr]

Well, I remember OLD grub (now called "grub legacy") and LILO before that. Talk about tedious. The GRUB we have now is a god send!

As far as clonezilla and grub not getting along - well, that's not an unknown thing to most of us who have used either/both extensively. Frankly, I don't think that using clonezilla to duplicate a drive within the same host system is the intended purpose of the tool so I doubt the devs were to concerned about that use-case and that certainly wouldn't be the fault of the grub devs either. I'm not trying to pick on you, just saying that understanding that grub (and fstab) are using UUIDs by default and also understanding that clonezilla means clone in every sense of the word and you wouldn't have found yourself in such a pickle. Next time you'll know to change the UUID before running update-grub and so you've learned something - a good day by any definition.

There are other cases where UUIDs must be managed. At the moment, I have 7 or 8 bootable installs all residing on the same file system (btrfs using subvolumes), so every install has the same UUID and all the fstabs and grub.cfgs are identical in practical terms. When I make a backup of a subvolume onto a different drive (technically - different file system) I also edit the UUIDs in the grub.cfg and fstab of each backup after I send it to the backup file system. This makes the backup bootable in place (from the backup volume) in case of a drive failure. A simple sed one-liner in the backup script makes the change flawlessly.

[claydoh]

I agree with oshunluvr. The real issue that seems to mess people up is EFI (which has zero to do with Grub), and the fact that the way this works on modern systems is completely and exactly unlike how the MBR works.

having used Linux as my desktop since 2002, I have literally had zero boot issues on any of my systems since using uefi over bios/mbr. LiLo, lol those were the fun days. U-boot was interesting, but in an extreme,manually manual setup way, that was done manually over a manual serial port connection on an arm device.

With the old grub you could only have 4 partitions, period. Then you could do extended partitions, which of course could crap out with multiboot. Then, when you installed another OS, that one's grub takes over, unless you are a bit crafty, and reinstalling Windows wipes out grub completely.

efi, imo is both simpler in general, and more complicated (perhaps), but it allows for better multiboot, at the very least.


What happened in your case would have happened no matter what boot loader you used, in my expertly non-expert opinion. We have all done things, screwed up, and learned. Some of us still do ( but I'll never tell ya'll when I do )

[jlittle]

IMO some of the trouble lots of us have with grub is due to the debian implementation of grub, and its focus on making it friendly for those not familiar with the command line and scripting. Supporting that usage is a design goal with grub, so fair enough, but the debian scripts (f.ex. update-grub, what they ship in /etc) hide too much and don't cope well with systems with more than one OS that has grub, or with systems where installs come and go. IMO, and I'm banging my drum on this again, sorry, if you're one to have more than one Linux install, or uninstall ever, a manually maintained, simplified, grub.cfg is the way to go.

UEFI should be able to boot OSs directly, it should be the boot loader, no grub required. But Windows' malign influence means that we need the grub project to sort out booting. I think it would be better if each distro installed a grub that just starts the Linux image for that install. But where would you do the fancy theming, with shiny colours? Horrors, those new to Linux might see some details, and recoil.

[oshunluvr]

I think it would be better if Microsith died and went to h-e-double-toothpicks...

[Don B. Cilly]

OK, so grub is wonderful. Top-of-the-line in ease of configuration, user-friendliness and efficiency.
Not to mention the grub-customizer, which is pure genius, and boot-repair, which seems to do anything but repair... well, anything, but is sleek and cute.

Stilll... clonezilla... it's used to clone disks/partitions.
Well, I have this weird notion that if someone clones a disk/partition, he might possibly, in some particular cases, then actually want to use it.
I mean, I may be totally insane, but a tinge of doubt crosses my mind that for some of us less advanced users, it may just be a possibility.
Now, it goes and clones the UUID. I guess it's too much to ask a programmer to put up a warning that says something like "Mind you, cloning a disk/partition will also clone the UUID. You may want to change it." Or, "Would you like me to assign it a random one?" but I guess that would be asking... one has to go searching and parsing until he finds out that, the sudo command line being a bit dangerous, he can do it with gparted, but not with kde's partitioner.*

Oh well. It then gives it over to our lovely grub/EFI system, which proceeds to make a total hash of it.
It prints dire warnings, and then - instead of "would you like to fix them"? - says "No error reported".
If you manage, after quite a few forum posts, to get someone to fix it for you, it still complains warns, and behaves erratically. Does pretty much anything, in fact, except attempting to fix the problem.
Until someone says,"Did you check the fstab"? And you think, me, checking the fstab? Shouldn't that be the first thing grub does when it starts spewing out warnings?
So you go and check it, and of course it's wrong, even though you didn't make it.

And this is the first thing a new Linux user has to contend with when he starts to use it. Great.
I've been using Linux (with no X, just text) since 1995, and grub still gets me. Not that LiLo was any better, mind you...

*The wonderful partitioner that, when the installation whines and whinges about your boot partition not having an esp flag (honestly, esp?) and sends you back (to your room without supper) does not have that particular flag anywhere so you have to exit completely and get yourself gparted which does have it, partition with that, and re-do the installation.
I still think KDE is by far the best interface for Linux, but the partitioner is not one of its strong points, no :·)

[oshunluvr]

OK, so grub is wonderful. Top-of-the-line in ease of configuration, user-friendliness and efficiency.

OK, now that's just crazy talk

Not to mention the grub-customizer, which is pure genius, and boot-repair, which seems to do anything but repair... well, anything, but is sleek and cute.

No comment as I've never used it or needed it. Do we really need that? I mean, fancy grub screens are cool and everything but if that 7 seconds of my life are boring I can handle it. GRUB is a utility not eye candy and I've never needed boot repair tools because GRUB has the ability to install itself, so what's the boot repair supposed to do anyway?

Stilll... clonezilla... it's used to clone disks/partitions.
Well, I have this weird notion that if someone clones a disk/partition, he might possibly, in some particular cases, then actually want to use it.

Here's the funny thing, we use clonezilla at work like 50 times a week or more for the last 18 months (a production roll out of 800-900 Dell PCs for very specific uses), but never once cloned a drive within a system and left it in there and tried to boot to it - not even once. I honestly can't think of why you would do that. But like I said, if we needed to, we would also change the UUID. I've duplicated file systems withing a computer in my office most to move some data from one drive to another, but then afterward I wiped the source because the reason to move the file system was to reuse the space for something else. But hey, you have your reasons but I still don't see how the GRUB or Clonezilla folks are responsible to predict everything that a user might try.

I too have been using Linux since the 90's and OS/2, Unix, DOS, along with Windows crap when I had to, and I've broken a LOT of installs. I can confidently say that almost every time I was totally to blame (excluding Windows of course ), usually because I forgot a detail or leapt into something without enough pre-study of what I was about to do.

I totally agree there are parts of Kubuntu that need work and the partition manager is very high on the list along with the installer - both those items are what I call "first day stuff" - but you're mixing your complaints IMO. Boot flags required for EFI are not a thing invented for Linux and neither is GRUB technically.

As far a GRUB, hate it if you want but it's really not that difficult to manage and better than any alternative I'm aware of https://en.wikipedia.org/wiki/Compar...f_boot_loaders. One thing I totally agree with is ease of initial installation for new Linux users needs to be the highest priority, but I don't see that being the fault of GRUB. EFI is not a Linux or GRUB invention - it was Intel's idea and heavily influenced by Microsith.

[Don B. Cilly]

Well, one possible reason for wanting to use a clonezilled disk could be:
- One of your disks shows signs of fatigue/failure.
- You repair what you can, get yourself a new disk, and before it gets any worse you clone your system onto the new one. You would probably want to check if it works before removing the old disk - or relegating it to sporadic use for plain storage.

I only used clonezilla twice, and both times it was for that reason.
Last time I don't remember any problems... I probably disconnected the old disk at the first signs of them... I don't remember, it was years ago. There are always some problems.
Or maybe your mum gives you a new ultrafast SSD for Christmas... I'm sure those instances aren't that rare.

Still, of course it's silly talk. I just made a little Hate Thread in the Water Cooler to... cool me head off from the overheating of the grubbing

[oshunluvr]

Yeah, just conversation. My mum never bought me an SSD...

[Flavio R. Cavalcanti]

Your "water cooler" is wellcome, as an opportunity to exchange ideas and experiences. I have read your 2 other (specific) topics, too.

I can understand some (or almost all) of your problems, I guess ─ and I am avoiding some of them, just by keeping my very very old hardware (10 years) for some months more.

In one word, I am trying to understand all I can, in order to never use UEFI, after to get next new hardware.

From this very old hardware point of view, ─ with old BIOS hardware and with MBR partitioning, ─ Grub has been reasonably useful, even if it sometimes has got mad.

By the way, I don't use Clonezilla, ─ just GParted running from a Live session, ─ to clone (move) installed distros from a HDD to another.

GParted is more simple, so I can deal with less variables.

(Yes, I prefer GParted, ─ instead of KDE Partition Manager, ─ although I always use KDE desktop).

If I want to test the clone before to remove the original distro, I need to change the UUID, ─ of both "/" and "/home" clones, ─ then run Grub again in order to recognize them (and distinguish them from the original ones).

But, before to run Grub, I have to replace old UUIDs with new ones, in a few system files, within the clone:

/etc/fstab
/etc/default/grub ---- in the case of openSUSE, Mageia, PCLinuxOS, Manjaro
/etc/initramfs-tools/conf.d/resume ---- in the case of Devuan
… (may be there other cases)

Yes, Kubuntu needs less manual work than other distros.

If the clone work fine and I want to keep it, I still need to reinstall the last Kernel, so it will incorporate the new "/" UUID.

Another way is just to unplug device with the original ones, for a while, ─ so you may test the clone without so much manual work.

If it is all right, just run a new Live session, ─ with original device plugged again, ─ and format the original partitions.

Then, run Grub again, and be happy.

In my very old hardware I have 4 devices (3 HDD + 1 SSD) and I "dualboot" 12 installed distros.

It was fine with just Kubuntu and Mint, as they are very similar, and their Grub "understand" one each other. ─ Adding Debian didn't create any big problem.

Adding a former KDE Neon did create a little problem. Nothing really serious.

When I started to try non-buntu distros, there were some problems. ─ Kubuntu-Mint-Debian's Grub didn't work to run Manjaro or Arch, for example. ─ So, I had to set Manjaro-Arch's Grub to manage my Boot Menu.

Then, I could'nt allow other distro's Grub to overwrite Manjaro-Arch's Grub at sda Master Boot Record (MBR), every time there is a Kernel update.

It is relatively easy to tell Kubuntu-Mint-Debian's Grub not to write to MBR:

[#]sudo dpkg-reconfigure grub[/#]

or

[#]sudo dpkg-reconfigure grub-pc[/#]

and select sdb, sdc, or none.

Installing openSUSE in a BtrFS partition, ─ without a separate /boot partition, ─ brought a new problem, as some distro's Grub didn't read BtrFS partitions.

tl;tr ─ Summary: ─ Now I have a Grub by Mageia at sda; and a Grub by openSUSE at sdb, and both can run any other distro. ─ If I need, just press DEL at Boot and run BIOS Setup to boot from sdb.

12 distros' Grub detecting 12 distros may drive Grub crazy. ─ There is a lot of sed and paste activity, and you may end up with some enormous grub.cfg files.

So, I have set 10 distro's Grub not to detect the other distros ─ by editing /etc/default/grub file:

[#]GRUB_DISABLE_OS_PROBER=true[/#]

Each distro's Grub will detect just itself ─ in order to Mageia's and openSUSE's Grub read them.

(Slackware didn't install its own Grub, and it was a problem to Mageia's and openSUSE's Grub to correctly detect it ─ until I manually installed Slackware's Grub).

So, you can see how Grub is simple, itself. It has been a lot of fun.

Now, I cannot figure how could it be with UEFI and a Fat32 ESP partition. ─ Many people says it is very simple! No problem! ─ But I have seen tons of people crying everywhere. I am really afraid.

By the way, all my distros are installed within MBR primary partitions, ─ 3 for each device.

Some years ago, I had also a distro installed in a logical partition, ─ but back then, there were just 2 distros (Mint and Kubuntu).

[Don B. Cilly]

Well, I did try with gparted, but it seemed incredibly slow.
Clonezilla only copies used sectors, so if I have a 400 GB partition with only 30 GB of stuff on it, gparted will copy the whole 400 while clonezilla only 30.
Of course, you can leave it running, go do something else and come back to it when it's done, but... you know...

EFI, I wouldn't have touched it, except first Kubuntu 18 and then Neon absolutely demanded it. Couldn't find a way to install them without it.
I already mentioned the silly little caper with the esp partition flag and gparted.
I wonder how most people manage to install the latest Kubuntu/Neons without pre-partitioning with gparted... they probably ignore the dire warnings and hope for the best.

Anyway, I've leaned a lot from the clonezilla/UUID mess.
Which, BTW, whether you use one or the other to copy the partition, would produce the same errors, wouldn't they? I mean, they both copy the UUID.

So, if I ever have to do it again, I'll change the UUID before doing anything else and... hope for the best