Yesterday we installed Debian 6 on an old rig with an Areca hardware raid controller and 4 2Tb disks in RAID 1+0. Since the volume is so big, we would need to use a GPT partition table, and Debian correctly set it up for us, but after the installation, the machine didn’t boot at all. Booting on the rescue system and chrooting into the installed system to reinstall grub, we obtained this error:
root@debian:~# grub-install /dev/sda /usr/sbin/grub-setup: warn: This GPT partition label has no BIOS Boot Partition; embedding won't be possible!. /usr/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. /usr/sbin/grub-setup: error: if you really want blocklists, use --force.
Turns out, Debian didn’t create a BIOS boot partition for Grub, so we had to create one
root@debian:~# parted /dev/sda
(parted) unit MB
(parted) p free
Model: Areca ARC-1210-VOL#00 (scsi)
Disk /dev/sda: 4000000MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 0.02MB 4000MB 4000MB linux-swap(v1)
2 4000MB 4300MB 300MB ext3 boot
3 4300MB 104300MB 100000MB ext3
104300MB 4000000MB 3895700MB Free Space
(parted) mkpart primary 104300 104400
(parted) p
Model: Areca ARC-1210-VOL#00 (scsi)
Disk /dev/sda: 4000000MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 0.02MB 4000MB 4000MB linux-swap(v1)
2 4000MB 4300MB 300MB ext3 boot
3 4300MB 104300MB 100000MB ext3
4 104301MB 104400MB 99.6MB primary
(parted) set 4 bios_grub on
(parted) q
Information: You may need to update /etc/fstab.
root@debian:~# partprobe /dev/sda
root@debian:~# ls -l /dev/sda*
brw-rw-rw- 1 root root 8, 0 Jul 12 19:02 /dev/sda
brw-rw-rw- 1 root root 8, 1 Jul 12 19:02 /dev/sda1
brw-rw-rw- 1 root root 8, 2 Jul 12 19:02 /dev/sda2
brw-rw-rw- 1 root root 8, 3 Jul 12 18:51 /dev/sda3
brw-rw-rw- 1 root root 8, 4 Jul 12 19:02 /dev/sda4
The magic sits in the command set 4 bios_grub on, which enables the partition as a BIOS Boot partition. Next, we tried again to install grub, successfully:
root@debian:~# grub-install /dev/sda Installation finished. No error reported.
Edit: info was obtained mostly (but not only) from the wonderful Arch Wiki
thanks a lot)
you’re welcome :)
Ok, but you didn’t mention whether the system successfully booted after that. I found the identical result as you did, but the system still hung at “Loading Grub,” with a blinking cursor and no grub > prompt or anything else. The system is unresponsive to keystrokes, other than CTRL+ALT+DEL.
I have a system with the first GPT partition loaded as /boot. You would think that would be plenty of space. There’s 150 MB free. I think it was a mistake to label (hd0,gpt1) as type ‘ee’, using parted > set 1 bios_grub on, in my particular case.
However, after I ran fsck on /dev/sda1, to correct corrupted groups, the partition mounted, and the “grub-install” script did complete without error. And I received no, “Unknown file system” error from update-grub.
But the system will not boot to the grub prompt or the grub menu. I also must comment that if the partition chosen for “bios boot partition” is formatted, it may be corrupted by the GNU Parted command above. Ext3 apparently can be recovered, but I can’t say for sure whether other format types would respond the same way.
I also tried, GTP fdisk (gdisk -h) to insert CHS sector values that PC-bios boot systems seem to like, though CHS values generally have no correlation to reality, correcting them to form a hybrid GPT/MBR partition table can solve problems.
Caveat, the above method may have worked if I had made an empty partition and then marked it with “parted > set 1 bios_grub on”, it might have booted. The mystery is how the system booted for about a year, but after a system rescue (bad script removed all linux-image (kernel) packages from /boot), it seems impossible to get it to boot again.
Although, the tools seem safe. I haven’t lost any partitions in the process of repair.
thank you for the informative comment!
in that particular case, the machine did in fact boot up, but I’ve seen other systems fail… one thing you can try is set the gpt partition as bootable with fdisk (current versions of fdisk will only see a GPT partition in a GPT partitioned disk)
Perfect! Many thanks!
Hint: If in trouble, super grub disk does boot such “lost drives”.
thanks for the hint :)