Re: GRUB2, GPT and large partition

[Jordan Uggla]

On Sat, Dec 18, 2010 at 4:12 PM, Saku Ytti <address@hidden> wrote:
> Motherboard, flashed to latest firmware today:
> http://www.intel.com/products/desktop/motherboards/DQ57TM/DQ57TM-overview.htm
>
> Raid card (OEM'd LSI2108), flashed to latest firmware today:
> Fujitsu D2616
>
> Following debian packaged grub versions were attempted:
> -rw-rw-r--    1 ftp      ftp       1473076 Feb 11  2009
> grub-pc_1.96+20080724-16_amd64.deb
> -rw-r--r--    1 ftp      ftp       1003658 Dec 01 04:32
> grub-pc_1.98+20100804-10_amd64.deb
> -rw-r--r--    1 ftp      ftp       1165174 Dec 11 20:39
> grub-pc_1.99~20101210-1_amd64.deb
>
>
>
> I have array of 6 x Samsung HD204UI 2TB SATA disks, in raid6 configuration
>
> Partition table: GPT
> Partitions
>   1MB grub_bios (flag set)
>  7.8GB (rest) ext3 flat, inclusive /boot/grub
>
> I'm using debian testing usb stick to install, installation goes
> through without hitch.
>
> When machine is booted I immediately go to grub rescue mode, grub
> complaining that file cannot be found.
>
> - 'help' does not work
> - 'ls' lists expected devices (hd0), (hd0,gpt1), (hd,gpt2)
> - doing ls for gpt1 expectedly complains about unknown filesystem
> - doing ls for gpt2 shows correct files, i see /usr/bin, /home/$USER etc
> - i don't see anything in /boot
> - if I do rescue boot and verify files, /boot is there ok
> - if in rescue I do cp -a /boot/grub /home/$user/foo-a and cp -r
> /boot/grub /home/$user/foo-r, foo-a is empty, foo-r contains files
> - if in rescue I set prefix to /home/$user/foo-r and try to 'insmod
> normal' it complains about ELF headers
> - all files are always seen correctly when rescue booting
> * everything is ok, as long as I make the partition small where grub data is
> * completely reproducable (except I cannot reliably make directory
> from which file list can be read by grub)
>
> Uneducated conclusions
> a) probably cp -a and cp -r are not magical here, probably just luck
> on my part, tried to copy with cp -a previously to many directories in
> root, and none of them workeed
> b) likely some elementary bug in filesystem access code when having
> large partitions? Affects reading directories as well as files
>
> I'm sorry I can't offer any very concrete debug information, maybe if
> I'd try in virtual box and trace calls, but hopefully there is still
> some content here.
>
> Thank you,
> --
>   ++ytti

Not being able to properly handle large drives is a common bug in
firmware (even new ones unfortunately). Usually the message you get
from grub when encountering such a firmware limitation is "error: out
of disk" (because the block that needs to be accessed is past the end
of the disk, according to the incorrect size of the disk as seen by
the firmware). Since a partition can be partly within your firmware's
limitation, and partly past it, it's possible for only some files to
be affected depending on where they're stored on disk. If there are
any BIOS menus that show the size of the drive, confirm that they are
reporting it correctly. You can also test grub on your drive through
qemu by running these commands as root:

losetup -r /dev/loop0 /dev/sda # Make a read only version of /dev/sda
# accessible through /dev/loop0. Don't use qemu with /dev/sda directly!
qemu /dev/loop0

If it's shipped in the debian package you're using you can also use
the userspace utility "grub-fstest" (which you can use with a
debugger, in addition to controlling standard debug output with the
--debug= option).

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)