Follow-up Comment #1, bug #27069 (project grub): I ran into a similar problem recently. I think I know what's going on.
I installed (Ubuntu) Linux onto the end of a 500GB USB external hard drive, connected to a laptop. When I rebooted after the install, I got the "unknown filesystem" error. But if I then connected the same hard drive to a desktop machine I had, the Linux system booted correctly. The problem, I believe, is just a plain old BIOS barrier limitation---it can't boot off the drive if the necessary /boot files are farther than a certain amount (137GB?) from the first sector. BIOS barriers may seem like a historical concern (137GB was an issue way back in 2001), but this came up on a fairly recent-model laptop, new enough to have a Core 2 Duo processor. It's plausible that BIOS code to boot off USB drives sometimes doesn't receive the same amount of attention as code to boot off standard IDE/SATA drives. Of course, the reason why I wanted to install Linux at the tail end of the drive in the first place was so that the first partition would be a ~440GB FAT32 filesystem. And the reason for _that_ is because, when the USB drive is plugged into a Windows system, Windows will only take notice of the first partition---and I wanted the drive to be useful as a data vehicle on non-Linux systems. (I'm not sure how MacOS X handles things, but I wouldn't be surprised if it did the same thing.) The solution I eventually found online pointed out that Windows only cares about the first partition---i.e. partition number 1 in the drive's partition table (*)---but that partition does not also have to be the first one in the drive's actual physical layout. That is to say, I created a partition table (using fdisk(8)) that has the partitions out of order. The big FAT32 partition goes right up to the end of the disk, yet the system lists it as /dev/sdx1. Windows picks it up exactly as desired, and Linux boots happily, BIOS barrier or no. (*) Alternately, this could be read as "the lowest-numbered partition in the partition table," but that is not something I took the time to confirm. With all that said, I think this can be categorized not as a bug in GRUB2, but nonetheless as an operating hazard that the program could probably deal with in a better way---even if it's just printing a warning at an appropriate point in time. _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?27069> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ _______________________________________________ Bug-grub mailing list Bug-grub@gnu.org http://lists.gnu.org/mailman/listinfo/bug-grub