ブートローダは既に機能しているかもしれませんが、ブートローダがマスターブートレコードから消えてしまった状況に備えて、ブートローダの設定方法とイントール方法を知っておくのは常に良い考えです。この状況は Windows などの他のオペレーティングシステムをインストールした後に起こる場合があります。以下の情報はブートローダ設定の変更が必要になった際にそれを変更するための助けになるでしょう。
ブートローダを設定するには、必ずさまざまなハードドライブとそのパーティションを識別しなければいけません。Linux はこの目的のために /dev/ ディレクトリ内で「ブロック」スペシャルファイルを使います。Debian Squeeze 以降、ハードドライブの命名規則は Linux カーネルによって統一化されました。現在、すべてのハードドライブ (IDE/PATA、SATA、SCSI、USB、IEEE 1394) は /dev/sd* と表されます。
それぞれのパーティションは自分が存在するディスク上の番号で表されます。たとえば、/dev/sda1 は 1 台目のディスクの最初のパーティションで、/dev/sdb3 は 2 台目のディスクの 3 番目のパーティションです。
PC アーキテクチャ (つまり「i386」およびその年下のいとこである「amd64」) では、長い間「MS-DOS」パーティションテーブルフォーマットを使うよう制限を受けていました。このフォーマットはディスク 1 台当たりに作れる「プライマリ」パーティションの数を 4 つに制限していました。この制限を乗り越えるためには、プライマリパーティションの 1 つを「拡張」パーティションとして作成します。拡張パーティションには追加的な「セカンダリ」パーティションを含めることが可能です。このようなセカンダリパーティションには 5 以上の番号が割り振られます。従って、最初のセカンダリパーティションは /dev/sda5、2 番目は /dev/sda6 などのように割り振られるでしょう。
MS-DOS パーティションテーブルフォーマットのもう一つの制限は、2 TiB を超えるサイズのディスクを取り扱うことができないという点です。近年のディスクではこの制限が現実的な問題になりつつあります。
A new partition table format called GPT (GUID Partition Table) loosens these constraints on the number of partitions (it allows up to 128 partitions when using standard settings) and on the size of the disks (up to 8 ZiB, which is more than 8 billion terabytes). If you intend to create many physical partitions on the same disk, you should therefore ensure that you are creating the partition table in the GPT format when partitioning your disk.
It is not always easy to remember what disk is connected to which SATA controller, or in third position in the SCSI chain, especially since the naming of hotplugged hard drives (which includes among others most SATA disks and external disks) can change from one boot to another. Fortunately, udev creates, in addition to /dev/sd*, symbolic links with a fixed name, which you could then use if you wished to identify a hard drive in a non-ambiguous manner. These symbolic links are stored in /dev/disk/by-id/. On a machine with two physical disks, for example, one could find the following:
mirexpress:/dev/disk/by-id# ls -l
合計 0
lrwxrwxrwx 1 root root 9 7月 23 08:58 ata-STM3500418AS_9VM3L3KP -> ../../sda
lrwxrwxrwx 1 root root 10 7月 23 08:58 ata-STM3500418AS_9VM3L3KP-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 7月 23 08:58 ata-STM3500418AS_9VM3L3KP-part2 -> ../../sda2
[...]
lrwxrwxrwx 1 root root 9 7月 23 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697 -> ../../sdb
lrwxrwxrwx 1 root root 10 7月 23 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 7月 23 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697-part2 -> ../../sdb2
[...]
lrwxrwxrwx 1 root root 9 7月 23 08:58 scsi-SATA_STM3500418AS_9VM3L3KP -> ../../sda
lrwxrwxrwx 1 root root 10 7月 23 08:58 scsi-SATA_STM3500418AS_9VM3L3KP-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 7月 23 08:58 scsi-SATA_STM3500418AS_9VM3L3KP-part2 -> ../../sda2
[...]
lrwxrwxrwx 1 root root 9 7月 23 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697 -> ../../sdb
lrwxrwxrwx 1 root root 10 7月 23 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 7月 23 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697-part2 -> ../../sdb2
[...]
lrwxrwxrwx 1 root root 9 7月 23 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0 -> ../../sdc
lrwxrwxrwx 1 root root 10 7月 23 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 7月 23 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0-part2 -> ../../sdc2
[...]
lrwxrwxrwx 1 root root 9 7月 23 08:58 wwn-0x5000c50015c4842f -> ../../sda
lrwxrwxrwx 1 root root 10 7月 23 08:58 wwn-0x5000c50015c4842f-part1 -> ../../sda1
[...]
mirexpress:/dev/disk/by-id#
Note that some disks are listed several times (because they behave simultaneously as ATA disks and SCSI disks), but the relevant information is mainly in the model and serial numbers of the disks, from which you can find the peripheral file. While the links in /dev/disk/by-id/ are created using the device' serial number and physical path, there are more convenience links in e.g. /dev/disk/by-label/ (based on given labels), /dev/disk/by-uuid/ (based on unique identifiers, which can change when reformatting a device using mkfs.* or mkswap), /dev/disk/by-path/ (based on shortest physical path), and /dev/disk/by-partlabel/ and /dev/disk/by-partuuid/ (only partitions with GPT labels and their unique identifiers). If you use these links, e.g. in /etc/fstab, always prefer unique identifiers over labels. You can also obtain and change this information for each partition or device using the lsblk and blkid commands.
以降の節で挙げる設定ファイルの例はこれと同じディスク構成のマシンに対する設定です。具体的に言えば、1 台の SATA ディスクがあり、最初のパーティションに古い Windows がインストールされており、2 番目のパーティションに Debian GNU/Linux がインストールされている状態です。
GRUB (GRand Unified Bootloader) is more recent. It is not necessary to invoke it after each update of the kernel; GRUB knows how to read the filesystems and find the position of the kernel on the disk by itself. To install it on the MBR of the first disk, simply type grub-install /dev/sda. This will overwrite the MBR, so be careful not to overwrite the wrong location. While it is also possible to install GRUB into a partition boot record, beware that it is usually a mistake and doing grub-install /dev/sda1 has not the same meaning as grub-install /dev/sda.
GRUB 2 configuration is stored in /boot/grub/grub.cfg, but this file (in Debian) is generated from others. Be careful not to modify it by hand, since such local modifications will be lost the next time update-grub is run (which may occur upon update of various packages). The most common modifications of the /boot/grub/grub.cfg file (to add command line parameters to the kernel or change the duration that the menu is displayed, for example) are made through the variables in /etc/default/grub. To add entries to the menu, you can either create a /boot/grub/custom.cfg file or modify the /etc/grub.d/40_custom file. For more complex configurations, you can modify other files in /etc/grub.d, or add to them; these scripts should return configuration snippets, possibly by making use of external programs. These scripts are the ones that will update the list of kernels to boot: 10_linux takes into consideration the installed Linux kernels; 20_linux_xen takes into account Xen virtual systems, and 30_os-prober adds other existing operating systems (Windows, OS X, Hurd), kernel images, and BIOS/EFI access options to the menu.
8.8.3. Using GRUB with EFI and Secure Boot
Using
GRUB to boot either a traditional BIOS system (legacy or UEFI-CSM) or a UEFI system is quite different. Fortunately the user doesn't need to know the differences because Debian provides different packages for each purpose and the installer automatically cares about which one(s) to choose. The
grub-pc package is chosen for legacy systems, where
GRUB is installed into the MBR, while UEFI systems require
grub-efi-arch, where
GRUB is installed into the EFI System Partition (ESP). The latter requires a GTP partition table as well as an EFI partition.
To switch an existing system (supporting UEFI) from legacy to UEFI boot mode not only requires to switch the GRUB packages on the system, but also to adjust the partition table and the to create an EFI partition (probably including resizing existing partitions to create the necessary free space). It is therefore quite an elaborate process and we cannot cover it here. Fortunately, there are some manuals by bloggers describing the necessary procedures.
If you are using a system with “Secure Boot“ enabled and have installed
shim-signed (see sidebar
「CULTURE Secure Boot and the shim bootloader」), you must also install
grub-efi-arch-signed. This package is not pulled in automatically, only if the installation of recommended package has been enabled.
