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 _______________________________________________ Help-grub mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-grub
