help-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: grub-install to /dev/vda (MBR!) suddenly fails


From: Jordan Uggla
Subject: Re: grub-install to /dev/vda (MBR!) suddenly fails
Date: Tue, 17 Apr 2012 17:29:51 -0700

On Tue, Apr 17, 2012 at 10:00 AM, Juha Kallio <address@hidden> wrote:
> On 17.4.2012 2:00, Jordan Uggla wrote:
>>
>> On Mon, Apr 16, 2012 at 9:42 AM, Juha Kallio<address@hidden>
>>  wrote:
>>>
>>> Hello!
>>>
>>> I have migrated to grub2 from grub-legacy, and have had a working
>>> installation in a virtual machine for a while. Today I updated the Debian
>>> wheezy installation, and now grub-install to /dev/vda fails with the
>>> following error:
>>>
>>> /usr/sbin/grub-setup: warn: Attempting to install GRUB to a disk with
>>> multiple partition labels or both partition label and filesystem.  This
>>> is
>>> not supported yet..
>>> /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: will not proceed with blocklists.
>>>
>>> This is a virtio disk from KVM, and should only have a basic partition
>>> table
>>> that was created on install. fdisk -l /dev/vda confirms that with the
>>> following information:
>>>
>>> Disk /dev/vda: 6442 MB, 6442450944 bytes
>>> 16 heads, 63 sectors/track, 12483 cylinders, total 12582912 sectors
>>> Units = sectors of 1 * 512 = 512 bytes
>>> Sector size (logical/physical): 512 bytes / 512 bytes
>>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>>> Disk identifier: 0x000d70a5
>>>
>>>   Device Boot      Start         End      Blocks   Id  System
>>> /dev/vda1   *        2048     8386559     4192256   83  Linux
>>>
>>> I haven't tried to boot this virtual machine yet. I also haven't tried
>>> the
>>> --force flag, since I shouldn't be restricted to using blocklists. I can
>>> grub-install to another device, /dev/sda, but for some reason the actual
>>> boot device doesn't work anymore as a target for grub-install.
>>>
>>> I'm sorry if this problem would be more suited to Debian mailing lists.
>>>
>>> Regards,
>>> Juha Kallio
>>>
>>> _______________________________________________
>>> Help-grub mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/help-grub
>>
>> Please post the output of "sudo parted -l"
>>
>
> Sorry for not reporting this earlier, but I solved the problem already.
> After thinking about the error message, I remembered that when installing
> the virtual machine, I first tried to install it without partitioning
> /dev/vda. The disk actually had both a partition label and a filesystem, I
> just thought that I had overwritten the filesystem by creating the partition
> table.
>
> To clarify, what I did when I installed the VM was:
>
> 1) I created an ext4 filesystem on /dev/vda, and tried to install Debian on
> it.
> 2) Naturally I couldn't complete the install, because there was no room for
> GRUB anywhere. Stupid me.
> 3) After realizing my error, I started the install from scratch, and this
> time I created a partition table on /dev/vda. (At this point, I thought the
> filesystem on /dev/vda would be completely overwritten.)
> 4) With the partition table, there was room for GRUB in the beginning of the
> disk, and the install completed without errors.
>
> THE FIX: To get grub-install working again, I overwrote the first MB of
> /dev/vda with zeroes, and restored the partition table. Now grub-install
> completes without errors. What still puzzles me is why didn't I get the same
> complaint from grub-install on my successfull install? And could there
> actually be a _functioning_ ext4 filesystem and a partition table on the
> same location? If it's impossible, why does grub try to detect it?

Yes, it is entirely possible to have a functioning ext4 filesystem and
a partition table in its first sector as ext4 (like most filesystems)
does not use this first sector so that it's available for a boot
record (and so that something that tries to write a boot record
doesn't clobber the FS). Having such a situation is however a very
good way to lose data.

>
>
> Regards,
> Juha Kallio
>
> _______________________________________________
> Help-grub mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/help-grub



reply via email to

[Prev in Thread] Current Thread [Next in Thread]