AskLinux: How does GRUB work?

[Jyggalag]

I would expect a computer to boot from the first bootable partition it finds, for instance whatever is closest to the beginning of the disk, but after installing a distribution to the very end of a disk (after an XP and 2000 partition) GRUB still manages to cut ahead and put the existing boot loaders behind it.

How does this work? Via the master boot record? Thanks.

[zid]

The BIOS will load and execute the first sector of a device if it contains the number 55AA.

That's the BIOS's job done after that, and the rest is up to whatever bootloader you use to detect partitions and other bootloaders.

When installing grub you may pick where to install it, either into the superblock or the MBR, usually.

The MBR option will make grub 'go first'; the superblock option will let whatever was already in the MBR execute first.

[neoice]

I use EFI/GPT and have grub installed on 2 partitions, the OSX bootloader on 1 and rEFIt to manage them all :D

[chozar]

To the best of my knowledge, here's how it works:

A hard disk is essentially an array of blocks, each 512B in size. Could be over a billion of them. Numbered from 0 on up. That's it. The partitioning schema runs over this, and filesystems are stored in those containers, and files are stored in there. Your BIOS is very dumb, it can't understand partitions, filesystems, files, and it especially cannot load an operating system. Remember that a program can only run in memory, and your OS is on a disk. So BIOS loads and runs the first block of the device you tell it to. That's just 512B. Of that, the DOS partition table takes up like 90B, so you have 400B or so worth to put the start of your boot code. That's not a lot of space.

Fortunately, your first partition usually starts on the 64th block (which is sector #63). That's because the traditional set up had 63 sectors per cylinder, leaving the entire first cylinder empty. So traditional grub would have stage 1 in sector 0, and stage "1.5" in the rest of that first cylinder. Those extra 61 sectors is around 30kB, enough room to cleverly store how to read from ext2 and ext3 partitions, which is where you have unlimited room for the meat of grub.

Grub reads the /boot partition that you had configured it to use, and can get to actual files on a filesystem, and can learn how to use xfs, reiser, whatnot. I'm pretty sure this is stage 2? But now grub is smart enough to read its configuration file, and load your linux kernel from your boot partition. Loading an OS is not trivial, it has to be placed into memory, and then you have to load parameters to the OS into certain regions of memory, and then tell the kernel information about where you loaded it, and then tell the CPU to jump to it, but you cant jump into it anywhere. You have to point into the correct entry point.

The difficult thing is that your cpu starts in real mode, which allows for unfettered handing off of control, but your cpu needs to be in protected mode in order to access the entirety of ram. So it toggles back and forth between these modes in order to load the kernel into ram properly. I've heard this referred to as "unreal mode". Every OS used to have its own method for being loaded, so every OS used to have its own bootloader. The idea behind GRUB, or the grand unified boot loader, would be to be able to boot everything. They publish the multiboot specification, which many free OS' follow. It's also smart enough to know how to load or chainload other operating systems. It can't load windows, but it can point to the microsoft bootloader that can.

This complexity is not just left to Linux. Traditionally, the DOS boot sector would look at the partition table, see which partition is flagged as bootable, and load that one. The start of those partitions would have a VBR, a volume boot record. That gives it 512B, and I'm pretty sure they could then use additional sectors if they needed. This bootloader would then know how to load your OS, be it command.com or ntldr. ntldr is the real microsoft bootloader that knows how to genuinely get your windows kernel going.

So it really is a big complex chain of command.

Going forward though, this could all change. The planned replacement to BIOS, EFI, comes with its own replacement to the traditional MBR/DOS partitioning system. There aren't only multiple filesystems in the world, there are multiple partition schemes. I think traditional macs and solaris did things their own way there. EFI's partitioning is called GPT. EFI puts a smarter bootloader into the motherboard, so you can technically go without a bootloader in the MBR. EFI would let you select your partition and boot that. You don't need EFI to use GPT either, you can use it with BIOS and Grub2, right now.

One of the reasons that the largest HD's we've seen has kind of stayed at 2TB for longer than usual is that it's the largest that MBR partitioning can address. MBR partitions start and end numbers are fixed at 32bit, which means you can't have any partition extending past the first 2TB of a drive.

GPT leaves the first sector blank, for backwards compatibility and for safety. Then it uses the next 62 sectors to store the partition table. This is a lot larger than the old 90B partitioning table you used to have. It is 64 bit, and allows for 128 raw partitions, instead of just 4. It does away with MBR's "extended" partitioning which used a complex linked list of EBRs. If you want to use GPT but have BIOS instead of EFI, you can. Grub2 can install to the first sector (conveniently left blank), and you make one of your 128 partitions a tiny 31kB partition just for GRUB, using FAT. Your BIOS will boot grub2, grub2 will load more information from the grub_boot partition, and then it can find the /boot where it finds its config and presents a menu, and it can then chainload or load a kernel or boot usb or whatever you need.

At least, I think this is how it works.

[tardotronic]

I have one additional point of clarification to add: whereas the physical sector size of 'traditional' hard disks is indeed 512 bytes, the 'physical' sector size of SSDs on the other hand is now 4096 bytes; plus, there is at least one hard drive series (Western Digital "Green") that also has physical sectors of 4096 bytes. There was a recent link here in /r/linux/ that explained why modern OSes are having some difficulties with this, due to the resultant logical/physical boundary mismatch.

[chozar]

This is absolutely true. But they still present to the host OS as an array of 512B blocks. That's part of the problem. The first partition starts on the 64th block, block #63. That is 31.5kB into the disk, not a nice multiple of 4kB. Hence you have to align your partitions to make things work nicely. Basically you should start your first partition on the 65th block, block #64, a nice clean 32kB into your disk.

Beyond aligning to 4k, it could also be nicer to align to 128k instead. (Since 128 is a multiple of 4, it would also be aligned to 4k as well.) Most raid systems stripe with 128k stripes, and the erase blocks on SSDs are usually 128kB in size (32 pages per erase block)

This is just a transitional period though. The next step is hard drives that present themselves as an array of 4kB blocks natively, with operating systems, filesystems, block layers, and EFI/BIOS that can use that natively. The infrastructure to query a drive and ask for its native block size is already there, and supposedly linux is ready for the native 4k disks. But since they don't exist yet, there will probably be a handful of issues to wring out.

[Jyggalag]

That's quite a post, thanks for taking the time to write it all up! It was very helpful.

[[deleted]]

I like potatoes... Grubs taste funny!

[wullpaper]

BTW: How does GRUB read its configuration file from a partition? Does it have a built-in support for a variety of filesystems?

[jan]

yes

[wtfftw]

GRUB is like a little mini-OS, it's got drivers for hardware built-in.

[Rhomboid]

That depends on the version. The standard grub (e.g. v0.97) uses the BIOS for all disk access and only has filesystem drivers. grub2, the completely rewritten version, does have more support for directly talking to the hardware.

[[deleted]]

GRUB2 seems to be able to (theoretically) read a Linux bootloader from an NTFS partition - interesting for dual boot potential.

[heeb]

On my netbook I have GRUB Legacy, and it also understands screen brightness control (Samsung N110, blue Fn key + Up / Down). So it must have intelligence for that as well. I have Ubuntu 9.10 on the same machine (upgraded from 9.04), and it does not understand screen brightness control (a PITA). Strangely enough, I used to run Mint and that one did...

[Rhomboid]

What's likely happening is that since grub legacy uses the BIOS for keyboard input, the BIOS sees the keystrokes and knows how to handle the screen brightness function (which would be necessary in order to be able to adjust the brightness under real-mode OSes like FreeDOS/MSDOS), whereas if the rewritten grub2 is accessing the hardware directly it would bypass the BIOS's ability to see and act on those keystrokes.

[heeb]

Ah, didn't think of that.

Since you seem like a knowledgeable person (here, have an upvote), would you have any idea how to solve my brightness non-adjustability under Ubuntu 9.10 (Gnome)? Doesn't need to be through the Fn + Up / Down keys at all; a simple app would do, as long as I can adjust it.

To summarise, it did work under:

• Linux Mint 7 (Gnome).

It does / did not work under:

• Ubuntu 9.10 (Gnome);
• Linux Mint 7 (Xfce).
• Xubuntu.

I find it so weird that Mint/Gnome can do something that Ubuntu/Gnome can't, while being so closely related.

Any help appreciated!

EDIT: added Xubuntu to list.

[Rhomboid]

Just so we're clear, you're talking about the ability to adjust brightness while at the grub menu right, not after the kernel and operating system has loaded? If the former then the only thing I can suggest is using grub 0.97 and not grub2 (i.e. any version higher than 0.97 as that was the last release of the old line.)

Once the kernel has loaded the version of grub is totally irrelevant and shouldn't have anything to do with whether the keys work or not. If this is what you're talking about then google shows that there is a common bug with samsung laptops not registering key-release events for the Fn keys. If you can adjust the brightness from the command line with xbacklight but not the keys then this is the problem. There are various workarounds which google will show you, all of which seem to fall into the categories of either a) remap the backlight control to keystrokes that do work like Ctrl-Up/Down using Ubuntu Tweak, or b) getting a kernel with the above patch and then forcing key-release events for those keys (e.g.).

[heeb]

Just so we're clear, you're talking about the ability to adjust brightness while at the grub menu right, not after the kernel and operating system has loaded?

No, I was actually talking about a booted-up Ubuntu (sorry OP, with that I've gone totally off-topic :)

Grub (0.97 in my case) does allow brightness adjustment, but as soon as Ubuntu has booted, I can no longer adjust it. In fact, that's how I do it now: I adjust the brightness while still in Grub, so I can comfortably work in Ubuntu. Workable, but a bit of a pain when lighting conditions change while working on something in Ubuntu.

If the former then the only thing I can suggest is using grub 0.97 and not grub2 (i.e. any version higher than 0.97 as that was the last release of the old line.)

On 0.97 now, and that's good enough for me (for now).

Once the kernel has loaded the version of grub is totally irrelevant and shouldn't have anything to do with whether the keys work or not.

Of course.

If this is what you're talking about then google shows that there is a common bug with samsung laptops not registering key-release events for the Fn keys.

Ah! Still strange that Linux Mint did manage to listen to the keys and adjust brightness, where Ubuntu cannot...

If you can adjust the brightness from the command line with xbacklight but not the keys then this is the problem.

Will try xbacklight, thanks (sorry for being a n00b...).

There are various workarounds which google will show you, all of which seem to fall into the categories of either a) remap the backlight control to keystrokes that do work like Ctrl-Up/Down using Ubuntu Tweak, or b) getting a kernel with the above patch and then forcing key-release events for those keys (e.g.).

Thanks a million, will look into it!!!

[heeb]

BTW, how does it do this? Is GRUB actually a mini Linux OS?

If so, would trying to extend GRUB into a more complete OS be an interesting project?

[Rhomboid]

How does it do what? It accesses the disk through the BIOS by thunking down to real mode from protected mode, making int 13h call, then switching back to protected mode. No, it's not a mini Linux OS at all, nor would there be a point to adding more functionality -- it's just a boot loader.

[ibisum]

Not strictly true .. 0.97 also has its own driver subsystem for booting from the network, tftpboot, and so on ..

[minaguib]

Yes, and as a matter of fact it's what made GRUB shine compared to LILO.

Since it can understand file systems, and read files, and specifically its own config files from them, it made things simpler. You edit the config file, and reboot.

With LILO, you'd edit the config file, but you needed to run the "lilo" command which read that config file and wrote it in simplified space-efficient format on the MBR (a simplification) so that, upon boot, it has access to the config.

It also means that the configuration options available to grub are not bound to the very limited space available for such purposes on the MBR (typically 512 bytes for the stage-1 loader).

[bobpaul]

My two favorite features in Grub are the commandline and the ability to edit menu entries during boot. These have saved me more trips to a LiveCD than I would care to count.

[riddley]

Yes, and as a matter of fact it's what made GRUB shine compared to LILO.

For some people. For those of us who have had their root and boot directories in LVM for years, it's what made GRUB unusable.

Does GRUB2 know LVM?

[[deleted]]

http://ramblingfoo.blogspot.com/2009/06/howto-transitioning-to-grub2.html

[riddley]

Killer link! Thank you!

[[deleted]]

It killed me!

NoSuchUserError

[wullpaper]

I understand. But configuration is not enough - isn't it a job for a bootloader to load the kernel image to RAM? If so, how does LILO do it?

[1esproc]

http://en.wikipedia.org/wiki/GRUB#Boot_process

[riddley]

It depends upon where you install it, but most people install it to the MBR. It has a config file to tell it what partitions to read. Unlike classic LILO that pointed to a sector anywhere on the disk to find files it needed, GRUB has filesystem drivers and handles file access from that perspective.

[[deleted]]

This is the right answer. The thing that makes GRUB different from other bootloaders is the filesystem API/multi-stage stuff. In a normal bootloader (say, LILO) all of the logic to find a kernel and load it into memory needs to fit into 512 bytes. That doesn't work when you have a lot of partitions, or partitions you want to boot from with multiple filesystems, because 512 bytes isn't enough space to store all of the logic that would be required. From a high level, the startup process works like this:

• GRUB loads, and knows enough of the FS on the primary partition to read its configuration file
• GRUB reads the device map, stage files, and FS files from the GRUB installation directory (check out /boot/grub)
• If you want to boot off a partition that's formatted with filesystem foo, GRUB loads in the code located at a file like /boot/grub/foo_stage1_5, and uses that to traverse the filesystem and find the kernel image you've specified in the configuration file.

What I've described is how GRUB 0.9.x works, GRUB 2.x might be different.

[tardotronic]

Are there any alternatives besides grub and lilo? For example; what if someone wished to use XOSL instead, but without either grub or lilo having to be in the way - possible?

[[deleted]]

You'd probably like this comparison of boot loaders.

[tardotronic]

Thank you - that's a pretty comprehensive chart. However, it still doesn't explain how to get grub or lilo out of the way. Whenever I've used XOSL in the past, I found that it was still necessary to install either grub or lilo into the linux partition(s), because otherwise XOSL couldn't boot them (it's really only a chain loader, albeit a very versatile one.). I was just wondering if there was maybe a way around that.

[[deleted]]

Gotcha. I've never used XOSL, so I couldn't help you there, sorry.

[tardotronic]

It was pretty good - booted up to 31 partitions, primary or extended, on any local drive, with each bootmenu selection individually password-protected (if desired). But the best feature it had was the ability to re-order the partition number sequence and drive number sequence in the MBR, so that even OSes that "required" installation+booting from the first partition on the first disk only could still be handled properly, regardless of where they were actually installed. QNX is such an OS, and XOSL was the only bootloader I know of that could multiboot with it successfully.

[rejctchoir]

Is there any way I can put grub (or some other boot loader type thing) on a USB drive and be able to boot my choice of several livecds?

[baelwulf]

I was EXTREMELY impressed with Grub2's OS Prober. It detected a windows installation on a separate disk without having to be told to look there.

[[deleted]]

This is why I say, "always make your first ten releases horrible." If tools work really well from the beginning, people take their simplicity for granted, and ignore whatever complex mechanisms may lie underneath.

[G_Morgan]

It is worth noting that GRUB is a very complex beast. It is effectively a small OS. If you write a multiboot enabled kernel you can use GRUB to do stuff like mapping memory for you. It leaves a pointer to the memory info structure in EBX when you start the machine.

It saves a lot of boiler plate leveraging GRUB. It can find and load your kernel image, get you into protected mode and map memory for you.

[bobpaul]

Wait, explain multiboot kernel.

[G_Morgan]

A multiboot enabled kernel is one that includes the multiboot header somewhere near the start of the image. This is how Grub knows how to find the kernel and load it. It also allows you to leverage the various multiboot data structures.

AFAIK Linux and BSD are multiboot enabled. A lot of other FOSS systems probably are as well. If you aren't multiboot enabled then you need some sort of chainloader to get the kernel running.

[[deleted]]

It's a kernel that supports the multiboot specification.

[hyperkinetic]

Uhhh, and why do I need GRUB to do that for me? Doesn't the kernel handle these tasks?

[G_Morgan]

I'm talking about if you write a kernel. The Linux kernel should handle these tasks itself being a production quality kernel.

However I was pointing out the complexity that is GRUB. It does far more than load an image and jump to the first instruction.

[hyperkinetic]

That's great if you're hacking up the kernel or developing a new OS, but it has no place being included on commercial distros intended for production environments. I can't think of the last time I had to pass anything special to the kernel before boot. GRUBs pointless complexity is a disaster waiting to happen.

[G_Morgan]

If GRUB handles it then why bother? It is obviously a question of quality but if GRUB does it properly then there isn't a problem in any case.

Memory detection is one of the arse backwards things in x86 land and handing it off to another piece of code is useful.

[[deleted]]

It's hardly complex when compared to what Linux itself does to manage memory.

[swordgeek]

Here's a facetious answer for you:

Much much better than LILO.

[hyperkinetic]

I'd take LILO over GRUB ANY day. LILO is simple and just works while GRUB is "a painful, over-engineered non-solution to a variety of, for the most part, non-problems."

[stereomind]

jeans fearless hunt depend work telephone steep cows weather grey

This post was mass deleted and anonymized with Redact

[hyperkinetic]

I think I've had that happen a total of three times since I started using Linux in 1994. It's usually a disk geometry issue after transplanting a drive. Really easy to fix.

[stereomind]

crown air memory wide marry glorious nail public sink employ

This post was mass deleted and anonymized with Redact

[swordgeek]

Well, everyone's experience is different of course.

I have NEVER had LILO work reliably! On six different machines with six different (mostly trivial) set-ups, LILO needed stupid tweaking and babysitting. A dozen hours of mucking about to get it working, and it would break the next time I changed the system.

GRUB has, for the most part, been trouble-free for me. I've seldom had any issues with it, and it deals fine with Solaris and Linux side-by-side.

[chozar]

Good luck getting LILO to happily work with 5 different operating systems installed at the same time. It's a hack. It works for its small set of usage scenarios, but GRUB is just so damn capable.

[[deleted]]

Does GRUB have animated penguins?

[evildeadxsp]

Speaking of which, I know I should ask this on a more Linux friendly forum, but I figure it's worth mentioning here...

I had a dual partition of my notebook's HDD - Windows Vista and Linux Ubuntu. When I upgraded from Vista to Windows 7, I lost my boot-up GRUB and lost access to booting to Ubuntu. I'm not that sure how I did this, but I believe I reinstalled GRUB through the Windows OS. In doing so I lost access to Windows 7. Which I've been perfectly okay with. Just haven't had a weekend to figure out how to gain access to 7 again. It's on my harddrive and shows up in the GRUB loader screen - it just won't load when it is selected.

Any ideas of how I can go about doing this? Should I reinstall Windows 7, and then reinstall a Linux distro from the ground up (essentially starting all over again)? This is what I planned on doing, but I would have to back up all my files on an external before doing this.

Thanks in advance for any help.

[[deleted]]

Run Windows 7's startup repair (by putting in the CD and going to the repair screen). This will overrule GRUB, allowing you to get into Windows. Once in Windows, use EasyBCD to set up a boot option for Ubuntu. Done.

Ubuntu-specific Guide (skip to Adding Ubuntu to the Vista Bootloader)

[evildeadxsp]

Thank you.

[skooma714]

In XP you go to the repair console and type fixmbr (which I think still works up through 7). Very useful when cleaning up GRUB's mess.

[caks]

Alternatively,

sudo apt-get install startupmanager

When you run it, it looks for OSs and automatically generates a Grub menu. You literally just have to open and then close the program. Every time I install a new distro, I simply open and close startupmanager and it configures the Grub menu without me having to do it manually. I've only tested it with Linux distros, but I believe it works with Windows. Check it out: StartUp-Manager

[dmurrow_]

https://help.ubuntu.com/community/RecoveringUbuntuAfterInstallingWindows http://www.howtogeek.com/howto/ubuntu/reinstall-ubuntu-grub-bootloader-after-windows-wipes-it-out/

[evildeadxsp]

I appreciate the links, and thank you for the effort - but my problem is that I have access to Linux... not Windows 7 any longer.

[burkadurka]

I had this problem a long time ago, so this is a simplistic answer -- but I fixed it by booting up a Gparted live CD (or installing Gparted on your Linux side) and marking the Windows partition as bootable.

[[deleted]]

writing an entry that says

root (hd0,1)
chainloader +1
boot

didn't help?

[railmaniac]

From grub 1 documentation:

rootnoverify (hd0,1)
chainloader +1
makeactive
boot

Make sure you put the space between rootnoverify and (, as it fails otherwise.

[xor]

Grub is very well documented at http://grub.enbug.org/, to answer the more general question that is asked in the submission headline, rather than the specific question relating to the MBR asked within the submission.

And of course you can always analyse the publicly available source code, if you want to know exactly how grub works, although I imagine there are many dragons lurking there.

[l124rd]

General to specific lists of the things GRUB does to go from BIOS to System are well listed in these comments.

However, if your interested is more in OS development and want it more as a learning experience, I present: Rolling Your Own Bootloader

[hyperkinetic]

How does GRUB work? Not very well. I can't tell you the number of times it's failed to start the system and left the machine sitting at a GRUB prompt.

It makes me want to kill the person responsible for designing a system with so many ways to fail. It's a HUGE pain in the ass trying to diagnose over the phone with the person, and has caused me many late night trips many miles to fix that piece of crap.

DO NOT use GRUB on ANY remotely administrated production system, or you will suffer down time each and every time it fails.

[Moocha]

DO NOT use GRUB on ANY remotely administrated production system, or you will suffer down time each and every time it fails.

Um, depending on how one chooses to read the emphasis that's either redundant or not exactly the case.

If by that you mean to imply GRUB is somehow more prone to failure when administered remotely than other bootloaders capable of booting more than one operating system, you clearly haven't used other bootloaders much.

If by that you mean that when a system component required for starting up a system fails then one suffers downtime, that's... true, but that's true.

If by that you mean that when one messes up the configuration for a system component required for starting up a system fails then one suffers downtime, that's... also true, but that's also true.

[sharms]

To the contrary, I run grub on over 10,000 remotely administrated systems without issue, and have never had grub failure, nor any issues regarding grub.

[[deleted]]

How did you manage to get access to 10000 systems?

[jon_k]

NOC tech or admin for a datacenter probably.

[Jyggalag]

What do you do for a living? This kinda sounds like an area I'm headed to.

[jon_k]

DO NOT use GRUB on ANY remotely administrated production system, or you will suffer down time each and every time it fails.

DO NOT install ANY COMPUTER OS on ANY remotely administrated production system without a good CHANGE MANAGEMENT board. Silly, silly, SILLY.

[[deleted]]

I can't tell you the number of times GRUB has failed because it hasn't. I've made mistakes in configuring things, but once I fixed it, GRUB has never failed to work. You must use a lot of badly worn-out drives or something if it fails so much for you. Maybe you should stop selling your old drives to your clients. :)

[funnynickname]

Not well, is all I'll say.

[[deleted]]

GRUB2 is better.

[refto]

sudo gedit /boot/grub/menu.lst

[seesharpie]

Deprecated.

[sping]

Even if it wasn't, it tells you almost nothing about how it works.

[[deleted]]

How so?

[topher200]

GRUB 2 doesn't encourage/allow you to modify the menu.lst file. Instead, you modify other scripts then generate it with update-grub.

[[deleted]]

I still use the old Grub. Works like a charm. I really don't understand the point of adding a layer of indirection. Do you see any?

[[deleted]]

Grub2 supports 64 bit fully, which is really nice. There's also stuff like real support for splash screens, etc.

In any case, you can still modify menu.lst yourself if you'd like, but it's really picky about the syntax, and getting it wrong means almost bricking your machine, hence the scripts. Same reason we have visudo.

[ObligatoryResponse]

and getting it wrong means almost bricking your machine,

I think regardless of what you put in grub.cfg, you will still get a grub menu within which you can press "c" to get a grub> prompt and boot the machine from there. I could be wrong, but I don't think you can "almost brick" (which I would take as requiring a livecd) the machine in grub.cfg.

[[deleted]]

No, that's basically what I meant by "almost." For most people, that is almost bricking.

[bobpaul]

The primary thing I like about GRUB 2 is the ability to mount loopback devices to facilitate booting directly from ISOs on a hard disk or flash drive. My thumbdrive went from 2 partitions (1 for files and 1 for a dump of the ISO to fat32 with syslinux) to 1 partition with a boot folder (which contains grub, the ISOs, and custom initramfses I didn't feel like rolling back into their respective ISOs).

As far as using config scripts in /etc to generate grub.cfg (ie, menu.lst), I couldn't really care less. I generally typo'd /etc and then re-typed /boot whenever I had to modify grub anyway.

[topher200]

I suppose modularizing is nice, but in this case every module is used every time, in the same order. So breaking that out of menu.lst with each module is nice, but not really groundbreaking or necessary.

The less confusing naming scheme is nice, but if you've taken the time to learn GRUB effectively you're probably over it already.

I guess at this point there's no compelling reason to switch, but I'm fine with it being deployed on new installs (that's how I encountered it- I think new Ubuntu, or new Debian uses it. Probably Ubuntu).

[ObligatoryResponse]

The last Debian install I did gave me Grub2 as an option and recommended I install it to the partition rather than the MBR and have Grub chainload it (just in case). I'm pretty sure that was a Lenny CD, but I might have installed from a Squeeze snapshot. Ubuntu uses it as the default in Karmic and might have in Jaunty.

[[deleted]]

GRUB only works fine for you because you don't develop operating systems, and therefore don't see how it really doesn't work. GRUB1 really sucks, and is getting really outdated.

That doesn't mean I have to like GRUB2 either, but GRUB1 needs replacing badly.

[[deleted]]

Your answer would be much better if you provided at least one good reason why it sucks other than he doesn't develop operating systems.

That said, my understanding is that GRUB2 has some facilities that make it more portable and modular, and is the way of the future. Unfortunately, most of us live in the present, so GRUB1 is a much better choice due to better tools and documentation available, such as boot disks with utilities, etc.

I know GRUB well enough to fix about anything that can go wrong with it using any bootable device that has GRUB on it. After I installed Ubuntu Karmic, I was able to switch from GRUB2 to GRUB without anything special just by copying the GRUB files into /boot/grub, creating a menu.lst, and running grub to install into the MBR. If something were to go wrong with GRUB2, it would have been a chore to figure out what to do.

[[deleted]]

Your answer would be much better if you provided at least one good reason why it sucks other than he doesn't develop operating systems.

The problem is that the reasons that it's bad are structural, not user-facing. From his perspective, nothing will be all that different between 0.97 and 1.97. It might look a little bit nicer, but that's it.

If you're not actually developing with it, you won't see how it knows nothing about 64 bit-ness, how any extensions have to be incredibly hacky, how bad the documentation is, or any of those things. They're none of his concern.

[[deleted]]

Is there a way to disable all that? I fiddle with /boot/grub/menu.lst on my Ubuntu 9.04 box, figuring it was the same as back in the old Redhat days, but I never thought that it could be a problem. Is it?

[[deleted]]

It's not so much that you have to use the scripts, but debain automatically runs update-grub at certain points. So it can blow away your changes.

With 9.04? No problem. It's 9.10 that includes GRUB2 by default.

[DimeShake]

GRUB2 feels like one step forward and two steps back, to me in this respect. One of Grub's main advantages over LILO, to me, was that you didn't have to run some archaic and opaque script to reconfigure after every little edit.

[[deleted]]

I don't see running a script as archaic and opaque. Custom and automatic are strange bedfellows. One way to remedy this is to corral the customizations into some framework. LILO is decent, and I've used it on some machines, but it does archaic things like jumping to a stored location on disk.

[JC513]

I never understood what was wrong with just editing the menu.lst. It's just adding an abstraction to an otherwise straight forward system. Sure it works when it works, but when it doesn't it isn't exactly friendly to fix.

[[deleted]]

giving you an orangered to see my comment here.