From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1NWgpR-0001TZ-GD for mharc-grub-devel@gnu.org; Sun, 17 Jan 2010 20:54:53 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NWgpQ-0001Se-4B for grub-devel@gnu.org; Sun, 17 Jan 2010 20:54:52 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NWgpL-0001Pq-G4 for grub-devel@gnu.org; Sun, 17 Jan 2010 20:54:51 -0500 Received: from [199.232.76.173] (port=35996 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWgpL-0001Pk-CN for grub-devel@gnu.org; Sun, 17 Jan 2010 20:54:47 -0500 Received: from mercav16.na.sas.com ([149.173.6.153]:3066) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NWgpK-0005zt-VO for grub-devel@gnu.org; Sun, 17 Jan 2010 20:54:47 -0500 X-TM-IMSS-Message-ID: <4175191400105f27@mercav16.na.sas.com> Received: from tempo.in.teragram.com ([172.25.89.16]) by mercav16.na.sas.com ([10.19.9.246]) with ESMTP (TREND IMSS SMTP Service 7.0; TLS: TLSv1/SSLv3,256bits,AES256-SHA) id 4175191400105f27 ; Sun, 17 Jan 2010 20:54:43 -0500 Received: from vmw0314.na.sas.com ([10.32.13.105] helo=vmw0314 ident=dgomez) by tempo with esmtp (Exim 4.63) (envelope-from ) id 1NWgpG-0007ZL-Qb for grub-devel@gnu.org; Sun, 17 Jan 2010 20:54:42 -0500 From: "Daniel Richard G." To: "'The development of GNU GRUB'" References: <000001ca9756$fae87380$f0b95a80$@com> <4B532073.2000706@isaac.cedarswampstudios.org> <000701ca97b5$f39bcff0$dad36fd0$@com> <20100118000715.GT5847@riva.ucam.org> In-Reply-To: <20100118000715.GT5847@riva.ucam.org> Date: Sun, 17 Jan 2010 20:54:42 -0500 Organization: Teragram Linguistic Technologies (a division of SAS) Message-ID: <000e01ca97e1$3406ff30$9c14fd90$@com> X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqX0mNlQWfTRZwFQNSN671gy4Sd8QAASmVg Content-Language: en-us X-detected-operating-system: by monty-python.gnu.org: Windows 2000 SP4, XP SP1+ Subject: RE: Trouble booting from a large USB hard drive X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 01:54:52 -0000 Colin Watson wrote: > > Unfortunately, I rather suspect that the very problem > being addressed > there means that we won't be able to implement your > idea automatically. > Artificially renumbering the partitions of an existing > operating system > while installing Ubuntu would be likely to break that > operating system > in many cases (as a convenient simple example, > consider a Unix-based > system referring to that partition in /etc/fstab using > traditional > device names rather than UUIDs), and we have no way I > can imagine to > tell whether that's going to be the case or not. I was just thinking of the narrow case of a new partition table, perhaps narrowed even further to USB drives (unless there's an advantage to the odd order with IDE/SATA/SCSI disks). If the user is only modifying an existing table, I agree that the numbering shouldn't be touched. > There are many > different possible BIOS limitations (see > http://tldp.org/HOWTO/Large-Disk-HOWTO-4.html) and I > doubt that we can > sensibly warn about all of them or even necessarily > evaluate accurately > which is the most likely. Well, the most recent barrier (aside from the one at 2TiB that's just around the corner) of 137GB dates back to 2001... I suppose you could check the BIOS release date via DMI and warn about smaller limits if it's anywhere near that old. Are machines of this vintage even a worthwhile concern? I thought I'd read somewhere that not even overseas digital-divide charities will bother with such hardware. > GRUB might be able to avoid the problem you describe > by using ata.mod, > provided that its core.img is embedded just before the > first partition, > as recommended, rather than being installed in a > partition boot record > past the BIOS barrier. This isn't the norm? Was I wrong about there not being enough space before the first partition to store non-BIOS disk-reading routines? This wasn't the case with the Karmic install, so I presumed there wasn't a way to do it. > For all kinds of reasons, I would love to have a way > to detect these > kinds of BIOS limitation in software, but I've never > found a sensible > way to do it. The best suggestion I've heard is to > read the BIOS > software version using DMI or similar and then check > it against some > kind of giant database, but I don't have the resources > (time or > expertise, really) to build up such a database, and I > don't even know > whether BIOS version numbering is reliable enough to > make it practical. And it's somewhat moot anyway, since disks can be moved between systems (though this is less likely with fixed disks, of course). I'm thinking the reasonable thing to do would be to show a warning if /boot is beyond 137GB (or maybe 33GB? 8.4GB?) on a USB disk unconditionally, and maybe on fixed disks if the BIOS is detected as being older than a certain date (much as how the kernel doesn't use ACPI if the BIOS predates 2000/2001). Beyond that, having the partitioner support out-of-order numbering would be great, though I don't see an obvious way of doing it in the manual-partitioning dialog. It would be easier to support it as a canned layout option, perhaps available only for USB disks. But I also like to have a separate /home, and that means manual partitioning, so.... (I'll be happy to file a wishlist bug report against ubuntu-installer if we can figure what would be reasonable for it to do.) --Daniel