Domingo, 29 de agosto de 2010
GNU GRUB2 setup and management seem to be more complex than those of the old (Legacy) GNU GRUB (GRand Unified Bootloader).
The GRUB Legacy to GRUB 2 transition is a part of the lenny (stable) to squeeze (testing) Debian release upgrade. The transition is not automatic, but it is quite easy to carry out: During the release upgrade (apt-get dist-upgrade) I was presented with the following menu
Configuring grub-pc
GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
In order to replace the Legacy version of GRUB in your system, it is recommended that /boot/grub/menu.lst is adjusted to chainload GRUB 2 from your existing GRUB Legacy setup. This step may be automaticaly performed now.
It's recommended that you accept chainloading GRUB 2 from menu.lst, and verify that your new GRUB 2 setup is functional for you, before you install it directly to your MBR (Master Boot Record).
In either case, whenever you want GRUB 2 to be loaded directly from MBR, you can do so by issuing (as root) the following command:
upgrade-from-grub-legacy
Chainload from menu.lst? [YES/no] |
Obviously I answered the default (yes, why not?), and I also answered yes to the other GRUB-related question that I was presented [just keep the Spanish keyboard and the video mode I like for the data terminals (tty)]:
Configuring grub-pc
The following Linux command line was extracted from /etc/default/grub or the `kopt' parameter in GRUB Legacy's menu.lst. Please verify that it is correct, and modify it if necessary.
Linux command line:
lang=es vga=792
[Ok] |
Once the dist-upgrade finished, I rebooted the system and the chainload proved to work correctly, the new GRUB2 menu was completely operational. Then I ran the upgrade-from-grub-legacy command, and the difficult question showed up:
Configuring grub-pc
The grub-pc package is being upgraded. This menu allows you to select which devices you'd like grub-install to be automatically run for, if any.
It is recommended that you do this in most situations, to prevent the installed GRUB from getting out of sync with other components such as grub.cfg or with newer Linux images it will have to load.
If you're unsure which drive is designated as boot drive by your BIOS, it is often a good idea to install GRUB to all of them.
Note: It is possible to install GRUB to partition boot records as well, and some appropriate partitions are offered here. However this forces GRUB to use the blocklist mechanism, which makes it less reliable, and therefore is not recommended.
GRUB install devices:
[ ] /dev/sda (500107 MB, MAXTOR_STM3500320AS)
[ ] - /dev/sda1 (5000 MB, /)
[ ] /dev/sdb (1500301 MB, ST31500341AS)
[Ok]
|
Then it came to my mind that a computer-savvy colleague messed up his MBR’s a couple of months ago. Why the hell I didn’t think about that until then? What was wrong with GRUB Legacy at the moment (I mean, it is still `stable’!)? After those first seconds of panic, I calmed myself down: I knew the answer, in my computer there is a single MBR, and it is at the beginning of the first hard disk, so the right answer is to only select the first option. Ok, done. I reboot, there is no chainloader and everything goes ok, great.
Ok, now let’s do something with the new GRUB. The dist-upgrade installed a new kernel (2.6.32), it seems to be working flawlessly, and the oldest one is no longer compatible with the new nvidia module, so I can safely remove it. First I remove the packages (apt-get --purge remove linux-image-2.24-amd64 and some other related ones), and now I should update the GRUB menu. The old command for this was update-grub, the new one is… the same, great! The remaining kernels are correctly found, so I reboot the system and everything goes ok again. Great.[*]
Before I upgrade the system I usually increase the seconds that the computer stops at the GRUB menu before booting the default option. It takes a few seconds to change this setting, and when I have run into problems with the upgrade it has proven useful. In these situations you may try different kernels, or run in single-user (safety) mode, usually in console mode. You may spend quite a lot of time discovering new technicalities (aka wasting your time) and using different approaches to try to solve some problem. So when you reboot, you cannot type, and I have a tendency to stretch then my legs a little, stretch my arms, don’t look to the screen for some seconds… and oh damn, I forgot to run the non-default GRUB entry that I wanted to test, I’ll have to reboot again! Increasing the time that GRUB pauses in the menu makes it more probable that you notice that you must type something (or if not you’ll have to reboot again). Once I check that everything is ok with the new system, I reduce that time to a couple of seconds, so that the load is fast but I may still have enough time to choose a non-default option in case it is necessary.
In GRUB Legacy this timeout change was implemented by just editing one of the lines of the /boot/grub/menu.lst file
## timeout sec
# Set a timeout, in SEC seconds, before automatically booting the default entry
# (normally the first entry defined).
timeout 5
|
However, this file, which also contains all the GRUB menu entries and options, is invisible to the new GRUB 2, and has only been kept back for safety and as a backup of old settings. There’s a new file in the /boot/grub folder, grub.cfg, but its first lines are very clear:
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
|
The timeout option can be set in the /etc/default/grub file:
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
GRUB_DEFAULT=0
GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX="lang=es vga=792"
|
The file is quite self-explanatory (although the non-technical user still won’t have a clue of what the GRUB_DEFAULT is), and, as it clearly states, now you have to run update-grub after you change any of its settings so that they have any effect in the booting.
This change is to some extent an improvement. The old menu.lst file was a little strange, since it had uncommented lines, commented lines (lines starting with a #) and doubly-commented lines (##). Some options like the timeout were set in an uncommented line, but some others (like the default kernel options kopt) were set in commented lines, and were applied to the menu entries by running update-grub. Other commented lines were just comments, as were all doubly-commented lines (pseudo-titles of file sub-sections as well as explanations and examples of settings to be defined in commented lines).
However, with the new GRUB version you have to run the update-grub command after you change anything. This makes the process longer, and you may forget to run the update, but at least you know that you must always run the update, not only sometimes.
This particular detail is just showing what reportedly is a global change in GRUB (from Legacy to 2): the new system is truly better structured, but it is also much more complex (some may even say cumbersome) than the old one.
[*] You may update-grub before the upgrade-from-grub-legacy, but then you will only be updating the chainloaded GRUB (2) menu, not the chainloader GRUB (Legacy) entries.