0

I've been playing around with Debian lately, as it seemed to me like the most logical step after starting my Linux journey with Ubuntu (I really don't like Unity and installing GNOME along side it bothers me, as I can't uninstall Unity completely without messing up much of remaining desktop function.) One thing that has always plagued me during the installation is the option to install GRUB.

It seems to me like it shouldn't be necessary and should just boot straight to the kernel like Ubuntu and Windows do instead of having me select one, and my choice is always the same - the default option.

During the installation, the text explaining the option says something along the lines of, "We need to make Debian bootable" -- Which is the main reason for my hesitance of selecting "no." I certainly do want it to boot! I could take the time and see what happens if I select "no," but I think it'd be wise to ask all of you first.

Is it safe to select "no" for the installation of GRUB? Will Debian still boot if it's not installed? If it is safe to select "no," are there any downsides to this option?

2 Answers 2

1

Ummm... How do I put it. Debian is a linux distro that runs on a computer, but to take it to a state where it can start working one requires a bootloader. The distro basically piggybacks on GRUB or any other bootloader until it is ready to run. You could use syslinux as an alternative to GRUB.

11
  • Interesting. Is it safe to say then that Ubuntu provides its own and thus has no need for GRUB, or is GRUB still there and just hidden somehow?
    – Flummox
    Jan 18, 2014 at 5:04
  • Ubuntu does use GRUB for booting. You may see the grub files in /boot/grub Jan 18, 2014 at 5:07
  • It looks like what you're really asking is how to prevent GRUB from showing the boot menu. GRUB is necessary if you want to be able to boot the kernel. (Or some bootloader. You could install a different one like LILO, but GRUB is probably going to be easiest to work with.)
    – user55325
    Jan 18, 2014 at 5:12
  • Cool. How does Ubuntu go about configuring GRUB to automatically select the kernel you want to load then? Is the same method applicable to Debian? Basically what I'm looking for is a way to not have to select a kernel to load when I start the computer -- I know GRUB automatically loads the default option in 3 seconds, but I'd like to skip the 3 seconds if possible. I should really make this into a new question now, but as long as we're on a roll here, I'll keep it I suppose.
    – Flummox
    Jan 18, 2014 at 5:14
  • @user55325 - You're correct to a point. Is it possible to have GRUB not show the menu, plus select a kernel by default as to avoid the extra time? The latter would be preferred, as I'd assume it'd skip the menu entirely as there'd be no need for one.
    – Flummox
    Jan 18, 2014 at 5:15
0

To expand on the accepted answer…

When an x86 PC starts, its CPU is executing in 16-bit real-mode and it runs the code stored in BIOS. After BIOS performs POST and initial configuration it reads the first 512 bytes from the beginning of the boot disk and transfers the execution there — it's the initial code of a boot loader which is supposed to do the rest.

Now consider what's rest. In the simplest case the boot loader should be able to locate and load the kernel's image and transfer the execution there. Older de-facto standard Linux loader, lilo, kept a contiguous map of all the sectors on which the kernel were stored. But the picture changed quite a bit since then: more filesystems came into use, it became customary to keep the kernel on a RAID device or on an LVM logical disk or on a stack of these all. Computers started to feature more pluggable disks which means arbitrary ordering of their initialization and hence problems with naming. Now consider that these days bringing up a generic system based on Linux requires some early-available user-space tools which are kept on the so-called "initrd" (initial RAM disk) or "initramfs" (initial RAM filesystem), so actually the boot loader loads not only the Linux kernel but also a matching initramfs for it.

So, the boot loader's task is:

  1. Bootstrap itself — those 512 bytes can sensibly only find and load something more complicated.
  2. Discover and initialize all the layers needed to access the boot filesystem (the filesystem containing the kernel and its initramfs).
  3. Load it all and then transfer the control to the kernel.

Now consider that most people find it useful to be able to somehow visualize and control this process, so there's a requirement for the boot loader to be able to present a menu of a sort and an ability to tweak what will be loaded, and how. An ability to load an alternative kernel might also be a bonus (for instance, a new kernel installed from the repository of Debian security updates never removes the existing kernel — rather, that one is kept aside and is available for booting if a regression is found in a new one).

So, as can be seen, unless we deal with some kind of embedded system with very tight memory/storage space requirements, and in which no one controls how the kernel is loaded, it's unreasonable to put this functionality right into the kernel, more so, since the boot loader is an inherently highly hardware platform-dependent piece of software. That's why boot loader exists and why on a generic system the need to use one is mainly inescapable.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .