GRUB 2.02 Has Many Features, Might Hit Ubuntu 14.04

[GreatEmerald]

At first, I didn't really get how GRUB2 worked compared to legacy GRUB, but then I learned how to use it properly and have no issues any more. Although I do use UEFI on pretty much every PC I administer, I still use GRUB2 instead of the kernel EFI capabilities, because the fact that you can use its powerful shell when something goes wrong is just that good. If you have something that is bootable, chances are GRUB2 can boot it.

[Grogan]

If you manually need to edit your grub.cfg then you do something completely wrong.

I appreciate you taking the time.

I do understand how it works, I just don't like it. Sure, if all I did was use the distro kernels and let it run the scripts it would mostly work. In some distros I still have to correct what it adds for Windows partitions though... I really don't need it adding stanzas for partitions that don't even have a Windows OS on them. Mint 16's grub autoconfig actually got all that stuff right. It adds too much stupidity to my custom kernel stanzas though, when it just needs to be simple.

I build my own kernels (configured my way), and if I let that stuff run I would have to go and edit the stanzas because it adds lines and parameters I don't want. I could correct all this but I don't believe in manipulating a bunch of scripts just to get something to automatically do what I can in 2 seconds with a text editor.

Even if it does get it right, I would still have to go and check grub.cfg to make sure.

[Grogan]

How is steam on linux? Good experience?

Steam itself is great. They use some pretty kludgy methods... wrapper scripts and a bunch of symlinks to find its various data directories but in a way that makes it somewhat self-repairing. Also, there doesn't seem to be a legit way to change the location of the Steam directory. You can add a new library location, but not all things can go there for example games implemented as Source Engine mods will always go to the main Steam directory. You either have to move the data directories and then let the wrapper script fix it (it will prompt for paths if broken) or just manually move the symlinks in ~/.steam. Other than that and seeming to use a lot of memory (e.g. a few hundred megs... doesn't really matter much to me), the Linux Steam client is good.

What we need are more games ported though, of course. Pretty much anything I want that's available on Linux, I already have. The only game I wanted to buy was Amnesia: A Machine for Pigs. I'm watching though, as soon as I see another game for Linux that I'm even a little bit interested in I'll do it. (I really want this to work out for them)

My best games are Metro Last Light and the Half Life 2 games. Those run very well, at least as good as on Windows. Left 4 Dead 2 and Serious Sam 3 run relatively poorly though, by contrast, at least on AMD Catalyst (fglrx). The best driver for me so far seems to be 3.11 BetaV9.4, the latest BetaV9.95 harms performance for me.

[Pajn]

When the GNOME people take it over and decide that it's too "cluttered" and begin ripping out features.

Would like to see that.
GRUB 3 no support for keyboard (or mouse) because that doesn't work on tablets.
If you don't have a touch screen your out of luck :P

But seriously a feature I would like from GRUB is that it were possible to make it look a bit more modern, think BURG or chameleon.

[Vax456]

I like all the features Grub2 is getting. Not for use on my own machine, but for what you can take advantage of in an IT environment. Netbooting in particular. It would be really nice to have a dhcpd.conf that looks like this:

#For PowerPC Mac's
class "AppleNBI-ppc" {
	match if substring (option vendor-class-identifier, 0, 13) = "AAPLBSDPC/ppc";
	option dhcp-parameter-request-list 1,3,6,12,15,17,43,53,54,60;
	option vendor-class-identifier "AAPLBSDPC";
	if (option dhcp-message-type = 1) {
		option vendor-encapsulated-options 08:04:81:00:00:09;
	} elsif (option dhcp-message-type = 8) {
		option vendor-encapsulated-options 01:01:02:08:04:81:00:00:09;
	} else {
		option vendor-encapsulated-options 00:01:02:03:04:05:06:07;
	}
}

#For Intel Mac's
class "AppleNBI-i386" {
	match if substring (option vendor-class-identifier, 0, 14) = "AAPLBSDPC/i386";
	if (option dhcp-message-type = 1) { option vendor-class-identifier "AAPLBSDPC/i386"; }
	if (option dhcp-message-type = 1) { option vendor-encapsulated-options 08:04:81:00:00:67; }
	option dhcp-parameter-request-list 1,3,17,43,60;
}

subnet 192.168.1.0 netmask 255.255.255.0 {
	pool {
		range 192.168.1.41 192.168.1.60;
		filename "/grub-ppc/grub.0";
		allow members of "AppleNBI-ppc";
	}
	pool {
		range 192.168.1.21 192.168.1.40;
		filename "/grub-efi/grub.0";
		allow members of "AppleNBI-i386";
	}
	pool {
		allow unknown-clients;
		filename "/grub-i386/grub.0";
		range 192.168.1.1 192.168.1.20;
	}
}

This dhcpd.conf is just an example and I have no idea if it'll work.

This way you can supply x86 and PPC Macintosh's the proper bootloader (I know, PPC has long since been obsolete, but the point is...) and supply everything else the i386 bootloader. Say what you want about Grub2's complicated-ness, but this setup ends up making everything much cleaner because you can configure and compile Grub2 to load its configuration from TFTP the same way for all architectures. So you can have a setup like this:

/srv/
	tftp/
		grub-efi/
		grub-pc/
		grub-ppc/
		grub.cfg
		images/
			i386/
				kernel
				initrd.gz
			ppc/
				kernel
				initrd.gz

The various grub directories are just for platform-dependent modules and nothing else, and the grub.cfg will be used for the boot menu for every platform. And then you can do something like this:

grub.cfg

menuentry "Rescue Mode" {
	#grub_platform is a built-in variable that is set when Grub loads.  It represents the architecture.
	if [ "$grub_platform" = "ppc" ]; then
		set bootparameters="root=nfs://path/to/ppc/share"
	else
		set bootparameters="root=nfs://path/to/i386/share"
	fi

	kernel (tftp)/images/$grub_platform/kernel $bootparameters
	initrd (tftp)/images/$grub_platform/initrd.gz
}

I probably screwed something up in these examples, but I have been able to get an old PowerPC G4 to netboot, load grub2, and boot a linux kernel this way, in conjuction with i386 machines. I imagine other architectures can do the same.

I've been searching for ways to exploit Grub2 for all its worth and I would love to build software that uses Grub2 for platform-independent ways of managing clusters of thin clients or offline backups/reimaging.

The point I'm trying to make here is, don't just think of Grub2 as a piece of software for bootstrapping your operating system. It can be used for so much more than just booting your one PC.

[droste]

Correct me if I'm wrong but could it be that the ones hating Grub for being too bloated are the same ones that hate systemd?

Nope. I'm still using grub1 and I'm not going to change this, but like systemd

[Vistaus]

Correct me if I'm wrong but could it be that the ones hating Grub for being too bloated are the same ones that hate systemd?

[johnc]

When will Ubuntu fork GRUB2?Before or after forking the kernel?

When the GNOME people take it over and decide that it's too "cluttered" and begin ripping out features.

[Kano]

@Grogan

If you manually need to edit your grub.cfg then you do something completely wrong. When you come from grub 1 then you would have noticed that it was a custom script in Debian based systems called update-grub that modified the menu.lst file in a post install trigger. This is now STANDARD, the script name is there on Debian but it just calls:

grub-mkconfig -o /boot/grub/grub.cfg

This triggers the execution of all scripts you find in /etc/grub.d, if you want manual entries you have got 2 simple positions, the old way was adding a file in /etc/grub.d (must be +x) or append to /etc/grub.d/40_custom, this required the execution of the command mentioned before. A bit later a file called /etc/grub.d/41_custom was added, that simply souces custom.cfg in the same dir as you find the grub.cfg. As this is dynamically done you can just modifiy the custom.cfg and it will be used. Another project that was first used on Debian is called os-prober, it is used to find other OS installs. Right now grub 2 ships already the os-prober hooks in /etc/grub.d and as soon as you install the tool you see other OSs in the list as well. In the case you dislike that uninstall os-prober or -x the /etc/grub.d/30_os-prober and you are done. If you want that your custom commands are shown first rename the files, 09-xxxx would be in front of default Linux entries. I don't get what your problem is... Btw. if you manually compile kernels on Debian (or RPM) systems there are nice targets to use like:

make INSTALL_MOD_STRIP=1 deb-pkg

[curaga]

hmm the uboot functionality intrigues me, but I'm not entirely sure how that works. Does that mean you need a uEnv to boot to grub, or, are you able to completely place grub over uboot? Because I would love to get rid of uboot - it is so poorly documented and inconsistent.

ARM in general needs a serious overhaul in the booting department. It's an inconvenient mess.

It chainloads grub from u-boot, doesn't replace it. This means you can pretend like u-boot isn't there at the cost of some boot delay, and gain the flexibility of grub.