GRUB2?

[Tom H]

>> Debian, Fedora, and Ubuntu have implemented grub2 in the same way -
>> which must have come from the upstream devs.

> How annoying. If grub itself can parse the grub.cfg file, I don't
> know why update tools couldn't also parse it and do intelligent
> merges, preserving kernel options, etc. As I recall, one of the
> really big selling points for grub taking over from lilo was that
> you didn't need to run any silly tools to update the boot config,
> now we have "improved" grub back to the point where you
> need the extra silly tools again...

I definitely agree with the "annoying" description, which is why I no
longer use these tools.

However, the new setup has a certain theoretical elegance (even if it
is doubly annoying that there are files in both /etc/default and
/etc/grub.d to edit in order to customize your grub.cfg).

Although in practice it is exactly like lilo (I have been playing with
grub2 since late September/early October and have forgotten more than
once to run update-grub before rebooting), update-grub generates a
"normal" file whereas lilo used to update (to lilo fans with
apologies: I am using the past tense because I have not used lilo in
ages) the MBR or at least the pre-63rd block of the disk (if I
remember correctly).


>> PPS: Fedora uses upstart too!

> Yea, but the fedora upstart script is willing to look
> in /etc/inittab to pick out the run level to decide if
> it should start gdm (the only thing inittab is still
> used for in fedora :-). Come to think of it, this may
> be the single instance of any linux improvement attempting
> to preserve backwards compatibility :-).

The problem is not upstart. It is Ubuntu's choice, for its desktop
edition, to have init levels 2-5 be exactly the same.

I have forgotten whether the previous version of Ubuntu had an inittab
but the current one, 9.10, does not. You can nonetheless modify the
init levels at which init scripts are run (or not) and pass an init
level as a kernel parameter in grub or through "init X".