[Solved] grub-install fails

[Aris Veresie]

Code: Select all

Aris@Aris2:~$ sudo grub-install /dev/sda1 --force
/usr/sbin/grub-setup: warn: Attempting to install GRUB to a partition instead of the MBR.  This is a BAD idea..
/usr/sbin/grub-setup: error: embedding is not possible, but this is required for cross-disk install.

My disk,

Code: Select all

Aris@Aris2:~$ df -h
/dev/sda1             2.0G   35M  1.8G   2% /mnt/MaxBoot
/dev/sda2              49G  394M   46G   1% /mnt/Squeeze
/dev/sda4              49G  451M   46G   1% /mnt/Wheezy
/dev/sda6              49G  460M   46G   1% /mnt/Sid

[makh]

use instead:
sudo grub-install /dev/sda

[Aris Veresie]

I think it showed the same error messages when I tried before. Right now I have grub problems on my second disk and I cannot check.

[makh]

a quick solution shall be to use SGD.

OR

Ref:
https://wiki.archlinux.org/index.php/GRUB

Alternate method (grub-install)
Tip: This procedure is known to be less reliable, the recommended method is to use the GRUB shell.
Use the grub-install command followed by the location to install the bootloader. For example to install the GRUB bootloader to the MBR of the first drive:
# grub-install /dev/sda
GRUB will indicate whether it successfully installs. If it does not, you will have to use the GRUB shell method.

[Aris Veresie]

Thank you makh.
As the arch link you gave me (and the error message) say, Grub cannot be installed on a GPT disk. Quite strange since it did that some time ago, and now refuses that. It is my spare (and testing) computer and I want to start it when I clean up this one, just maintenance. I am not much in a hurry to do that, but I will keep you posted.
The strange thing here is that "grub-install /dev/sda" made a problem on my second disk as the one described here. (I have also used "grub-install /dev/sda1" and both with the --force option.)
viewtopic.php?f=10&t=79170

SGD? Sun systems global desktop?

[dzz]

What is

/dev/sda1 2.0G 35M 1.8G 2% /mnt/MaxBoot

?

I ask because, I recently did an install on a 3TB disk, meaning gpt is required. I discovered that a small, dedicated "grub-boot" partition, correctly formatted, is then needed (gparted can make one)

Normally the --force option is only used when you want grub installed to partition, so it can be chained from another bootloader. I don't know how or if that works with gpt, or if a "grub-boot" partition is still needed

SGD must be "super-grub-disk" (rescue cd)

[makh]

SGD?

super grub disk

[dzz]

SGD (a 3rd party app) *might* get your system booted in an emergency but a definitive Debian solution is needed here.to help the OP and others with gpt/grub issues.

[kiyop]

What is

/dev/sda1 2.0G 35M 1.8G 2% /mnt/MaxBoot

?

+1

I ask because, I recently did an install on a 3TB disk, meaning gpt is required. I discovered that a small, dedicated "grub-boot" partition, correctly formatted, is then needed (gparted can make one)

If UEFI is not used, "bios boot" partition is required for installing grub2 correctly on (apparently) MBR of HDD with GPT.
As for "bios boot" partition,
http://en.wikipedia.org/wiki/BIOS_Boot_partition
It need not be formatted as some filesystem.
Only it should have "bios_grub" flag.

Although, debian squeeze uses grub(2) version 1.98,
there is grub2 version 1.99 manual.
http://www.gnu.org/software/grub/manual ... stallation

[Aris Veresie]

I was working from my second disk (Squeeze) and /mnt/MaxBoot was the mounted location of /dev/sda1, the first partition (ext4) of the first disk (250GB) with the boot flag set to on. The disk has a GPT partitioin table, and according to the Grub-1.99 manual there is no problem installing it on a /boot partition. It's the partition I have to install a multiboot loader, and Grub is the best answer. The Debian version is 1.98, maybe there is a problem?
I have managed to install Grub on the second disk, but it must have overwritten the kernel and vmlinuz files. Somehow I could not connect to the internet but I could ping the local net. I have tried to copy the files to a usb flash disk but they did not want to be written(!). Does the 6.0.4-DVD.iso has those files?
According to the manual "Installing a boot loader on a running OS may be extremely dangerous.", maybe that is why I get these problems. Still, I was trying to install from my second disk to the first disk and got this mess.

[kiyop]

Grub may be able to be installed on /boot partition in a GPT hard disk which does not contain a "bios boot" partition. I am not sure. But even if it can be installed, I think the installed grub2 cannot be booted correctly from MBR.

"grub-install" to (apparently) MBR of a GPT hard disk which contains a bios boot partition succeeded without any problem.
If you can make grub2 installed on (apparently) MBR of a GPT hard disk which does not contain any bios boot partition can boot correctly some linux, please let me know. I am curious.

I know uefi version of grub can be installed and work correctly without a bios boot partition. But I guess that uefi function on the machine is needed.

I have managed to install Grub on the second disk, but it must have overwritten the kernel and vmlinuz files.

What do you mean?

I have tried to copy the files to a usb flash disk but they did not want to be written(!).

How did you try to copy the files? Are you sure that the partition of the usb flash is correctly mounted with proper option? Are you sure that you tried to copy files with proper privilege?

Does the 6.0.4-DVD.iso has those files?

What are "those files"?

According to the manual "Installing a boot loader on a running OS may be extremely dangerous.", maybe that is why I get these problems. Still, I was trying to install from my second disk to the first disk and got this mess.

Maybe you did wrong things.

[Aris Veresie]

@kiyop
By "those files", I mean vmlinuz and kernel. I thought I was going to be able to start by copying them.

Anyway, I will mark this as solved, although in reality I re-installed on both disks. On the second scsi disk Gnome stable for system backup, then I removed it so Grub does not give me problems, and installed on the first disk the base system, on which I will install both Gnome and Xfce to see how the upgrades to testing work.

[flabdablet]

GRUB consists of several parts: there's a very small primary boot loader that fits wholly inside disk sector 0 (the MBR), a larger secondary loader (anywhere from 30KiB to around 50KiB depending on which modules are included) that understands filesystems and LVM and mdraid and other complicated stuff, and then the various bits and pieces in /boot/grub in the boot filesystem.

Because the primary loader has to fit inside a single 512-byte disk sector that also includes a partition table, there simply isn't room for code that does anything as complex as navigating filesystems. All the primary loader can do is read a sequential range of disk blocks into RAM and jump to the code contained in those. So the secondary loader needs to reside in some such range.

The usual place for the secondary loader on an MBR-partitioned disk is in disk sectors 1..62, usually left otherwise unused by traditional MBR-style partitioning; GRUB calls this "embedding". If the GRUB secondary loader ends up bigger than 31KiB (which is more likely to happen with GRUB2 due to its extra capabilities and modular design), it won't fit in this space and GRUB installation will fail. The best fix is to start the first partition further along the disk than its traditional starting place on sector 63. You can install GRUB to a partition and avoid embedding, but this relies on /boot/core.img occupying an unchanging range of sequential disk sectors inside the /boot filesystem which is usually pretty hard to guarantee and is, as grub-setup says, a BAD idea.

GPT partitioning uses more space for the partition table than MBR partitioning does. There is still a "protective" MBR on disk sector 0, which has room for GRUB's primary stage as well as a dummy MBR partition table, but the partition table proper occupies disk sectors 1..33 and -33..-1 (where -1 is the last sector on the disk). GRUB's secondary loader can't be embedded starting on sector 1 on a GPT-partitioned disk because doing so would destroy the partition table.

However, GPT also defines a special partition type specifically intended for use by boot loaders. So rather than continue the undisciplined MBR tradition of stuffing the secondary loader into some ill-defined region of unpartitioned space, the GRUB2 installer requires one of those special partitions to be defined when installing to a GPT disk. Note that this is not the same thing as a /boot partition - you can have one of those as well if you want, or /boot can simply be a directory inside the root filesystem; in any case you still need a chunk of non-filesystem space to hold the GRUB stage responsible for finding /boot in the first place.

Fortunately this is a pretty easy thing to add in most cases, because GPT partitions tend to be built on 1MiB boundaries by default rather than the (fake) track and cylinder boundaries traditional for MBR partitioning, so there's usually some unused space between disk blocks 34 and 2047. You can use parted to check for that and make a little partition in there:

Code: Select all

sudo parted /dev/sda #substitute your own boot disk's device name here
unit s
print free


This will show you if your existing partition table has the required chunk of free space starting on sector 34. If it does, continue with the parted session:

Code: Select all

mkpart grub 128s 2047s #might as well align it somewhat


You will probably see parted complain about non-optimal alignment here. It does that any time you create a partition that doesn't start on a 2048 sector (1MiB) boundary. The warning is safe to ignore. I like to start the partition at sector 128 instead of sector 34 because aligning on a 64KiB boundary is nicer for 4KiB-sectored ("Advanced Format") disks and RAID controllers, but you can use 34s instead of 128s if you prefer.

Code: Select all

print


will now show you the state of the partition table, and you need to note the partition number that's been assigned to your new partition. I'll assume here that it was partition 7:

Code: Select all

set 7 bios_grub on #mark this as a bootloader partition
print
quit


You should now be able to run sudo grub-install /dev/sda and have it succeed.

Incidentally, if you use one of the automatic or guided partitioning options in the Debian installer and pick GPT partitioning, the installer will automatically create the required bios_grub partition. You might need to work around a bug to make the subsequent GRUB installation step succeed, but it does build the partition table properly.

[hilbilly]

Yeah this is really a pain and has been for quite awhile now.

I'd like to know just why is putting Grub somewhere other than the MBR is a "BAD idea". I happen to think its a good idea, as that keeps it from being stomped on by any other OS. I just like the segregation of having each OS in it's own partition along with it's own boot loader.

Having a "master" boot loader is of course required to get to the loaders on each partition, and Micro$oft loves to assume it's the only OS on the disk and overwrite the MBR, but I don't think Grub's tactics are much less controlling.

It doesn't matter if the --force parameter is provided or not, or if the (hda2) or /dev/sda2 format is used. I've never had much luck (but some, after much time & effort I can't seem to easily repeat) putting grub anywhere other than the MBR.

My preference on an MFT partition scheme is to have a relatively small partition o type FAT32 as the first boot partition, and use the other partitions for each OS I want to install. FAT32 is used to allow Micr$oft & DOS boot files. However none of the *nix variants I use will allow a FAT32 partition to be used for /boot.

GPT is a far superior partitioning scheme but still not widely used for some reason. Then you have the variants of GPT such as Apples to contend with. I used to be sooo happy with LILO, but those simple days are gone it seems

If someone wants to explain the rationale for that BAD message, the world is listening