FS#24103 - grub2-bios core.img is unusually large - cannot install grub2-bios 1.99~rc2.r3238-1

Attached to Project: Arch Linux
Opened by Aaron Hurt (leprechau) - Wednesday, 04 May 2011, 23:03 GMT
Last edited by Ronald van Haren (pressh) - Sunday, 10 July 2011, 06:42 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Ronald van Haren (pressh)
Architecture x86_64
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No

Details

Description:

When using exta/grub2-bios 1.99~rc2.r3238-1 I get the following:

[root@charlie ~]# grub-install --no-floppy /dev/sda
/sbin/grub-setup: warn: Your core.img is unusually large. It won't fit in the embedding area..
/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..
/sbin/grub-setup: error: will not proceed with blocklists.

This does not happen when using extra/grub2-bios 1.99~rc1-3 .. my setup is as below:

[root@charlie ~]# cat /etc/mdadm.conf
## boot array
ARRAY /dev/md0 level=raid1 num-devices=3 UUID=c76e335f:388e7fff:c4d48bf1:d5b45aa4
## lvm array
ARRAY /dev/md1 level=raid5 num-devices=3 UUID=b3e5db17:39da29a7:b0bbd438:e6d07c86

[root@charlie ~]# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md1 : active raid5 sda2[0] sdc2[2] sdb2[1]
624944384 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

md0 : active raid1 sda1[0] sdc1[2] sdb1[1]
96256 blocks [3/3] [UUU]

unused devices: <none>

[root@charlie ~]# pvs
PV VG Fmt Attr PSize PFree
/dev/md1 group0 lvm2 a- 595.99g 0
[root@charlie ~]# vgs
VG #PV #LV #SN Attr VSize VFree
group0 1 3 0 wz--n- 595.99g 0
[root@charlie ~]# lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
root group0 -wi-ao 120.00g
storage group0 -wi-ao 471.99g
swap group0 -wc-ao 4.00g

[root@charlie ~]# mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=10240k,nr_inodes=498650,mode=755)
/dev/mapper/group0-root on / type ext4 (rw,commit=0)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
devpts on /dev/pts type devpts (rw)
shm on /dev/shm type tmpfs (rw,nosuid,nodev)
/dev/md0p1 on /boot type ext3 (rw,commit=0)
/dev/mapper/group0-storage on /storage type ext4 (rw,commit=0)
none on /proc/bus/usb type usbfs (rw,busgid=108,busmode=0775,devgid=108,devmode=0664)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw,noexec,nosuid,nodev)
none on /proc/fs/vmblock/mountPoint type vmblock (rw)
gvfs-fuse-daemon on /home/ahurt/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=ahurt)
[root@charlie ~]# lvs

All latest updates as of today ... please let me know if you need any more information.
This task depends upon

Closed by  Ronald van Haren (pressh)
Sunday, 10 July 2011, 06:42 GMT
Reason for closing:  Not a bug
Comment by Andrei F (TheBeast) - Thursday, 05 May 2011, 04:39 GMT
Hi,

I can confirm the same problem with grub2-bios-1.99~rc2.r3238-1 & grub2-common-1.99~rc2.r3238-1. Downgrading to grub2-bios-1.99~rc2-1 & grub2-common 1.99~rc2-1 solved the problem in my case. Let me know if you need any extra information.
Comment by Ronald van Haren (pressh) - Thursday, 05 May 2011, 11:58 GMT
Still works for me (edit: no raid setup though).

Can you see if this is a known problem with this bzr revision (3238) and see if they already have a fix? They have an IRC channel which is often helpfull in these cases.
Comment by Aaron Hurt (leprechau) - Sunday, 08 May 2011, 04:51 GMT
I did some research and talked to a few people in #grub on freenode ... the general consensus seems to be that you need to have at least 1M before the first partition when using MBR or have a dedicated 1M+ grub bios partition under GPT when installing newer grub version with softraid and/or lvm. Someone also suggested re-building grub from source with '-Os' cflags ... this didn't resolve the issue for me. I do however have everything working now using the latest grub2 from extra after I redid my disk layout following the above best practices. My three drives (sda, sdb and sdc) now look like the following:


Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 625142448 sectors, 298.1 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 435957EF-580A-470B-8EAD-7D8FF53379EC
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 625142414
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number Start (sector) End (sector) Size Code Name
1 2048 4095 1024.0 KiB EF02 BIOS boot partition
2 4096 208895 100.0 MiB FD00 Linux RAID
3 208896 625142414 298.0 GiB FD00 Linux RAID


My /boot array (md0) is composed of sda2, sdb2, sdc2 and my lvm array is on sda3, sdb3, sdc3 ... so far this is working fine without any errors from grub.
Comment by Anonymous Submitter - Friday, 08 July 2011, 16:41 GMT
I added a note at https://wiki.archlinux.org/index.php/GRUB2#MBR_aka_msdos_partitioning_specific_instructions . The post-MBR gap of (usually) 32 KiB is rather limited to support all the complex modules in core.img needed to get grub2 working in lvm/dmraid/raid etc. setups. I suggest closing this bug since this is neither a packaging specific bug or an upstream bug.

Loading...