Trouble booting from a large USB hard drive
I recently installed Ubuntu Linux to a 500GB external hard drive, with GRUB2,
and at first could not boot the system due to a GRUB unknown filesystem
error. Resolving this problem led to some interesting revelations that I
wanted to share here.
Initially, the hard drive in question was partitioned to have a large (400GB)
FAT32 partition at the beginning. Knowing that Windows would only mount the
first partition when the drive was plugged in, I figured this was the way to
make the USB drive usable as a data vehicle on non-Linux systems. After that
partition came ones for swap, root, and /home.
After installing Ubuntu, and rebooting, I got the GRUB error. This was on an
HP laptop; later on, I connected the same drive to a Dell desktop
machine---and lo, Ubuntu booted!
I believe that the cause of the problem with the HP laptop was a good
ol'-fashioned BIOS barrier (a la don't put /boot more than 8.4GB/33GB/137GB
from the start of the disk). The laptop was a fairly recent model---an HP
EliteBook 6930p---but I'm guessing the code to boot from USB devices didn't
have all the LBA workarounds and whatnot that have been standard in IDE/SATA
boot code for years.
What all but confirmed it for me was an ingenious solution I saw posted
somewhere: an out-of-order partition table. Put the Linux partitions first on
the disk, then the big FAT32 partition---but the FAT32 partition is /dev/sdx1,
and the Linux partitions are /dev/sdx{2,3,4}. Windows mounts the FAT32
partition and ignores the others, just as intended, and Ubuntu boots
flawlessly on the HP laptop.
Aside: All this is also covered in a GRUB bug report at
https://savannah.gnu.org/bugs/?27069
With all that said, I don't consider this to be a bug in GRUB, and this is not
meant to be taken as a bug report. (I presume grub-pc can't work around such
limitations in the BIOS, because there isn't enough room in the MBR to stuff
in a disk-reading library that makes BIOS disk calls unnecessary.) Rather, I
think it is a corner case of which users should be aware---and perhaps GRUB
and/or the Ubuntu installer could do a better job of warning the user if the
disk layout may lead to that. Beyond that, broader awareness/support/use of
out-of-order partition tables [for large USB drives in similar usage
scenarios] doesn't seem like a bad idea.
(Which is not to say I'm certain of all this; that it's a BIOS barrier issue
is only my hypothesis, consistent with what I've observed. Folks here might be
aware of something else that may have been going on.)
--Daniel
--
Daniel Richard G. || dani...@teragram.com || Software Developer
Teragram Linguistic Technologies (a division of SAS)
http://www.teragram.com/
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] switch from sprintf to asprintf and snprintf
Colin Watson wrote: On Tue, Dec 29, 2009 at 10:30:12AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: +char *EXPORT_FUNC(grub_asprintf) (const char *fmt, ...) + __attribute__ ((format (printf, 1, 2))); It's very confusing that you've made grub_asprintf have a dramatically different interface from asprintf. Perhaps you could call this grub_xasprintf instead? (Although I notice that it doesn't die when malloc fails, but merely returns NULL.) What about grub_aprintf ? -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] switch from sprintf to asprintf and snprintf
Robert Millan wrote: On Tue, Dec 29, 2009 at 10:30:12AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: sprintf is potentially dangerous especially with gettext, when messages may be larger than coder would expect. I attach the patch to fix it Could you split the patches into one for asprintf and one for *nprintf? The asprintf one is something I'd really like to see in trunk. For the rest I'm not so sure. Implementing sprintf on top of this would be just a waste. It would need to add conditions to ignore size limits. IMHO unavailability of sprintf decreases temptaion of making a 1024-bytes buffer and hoping it fits, or at very least we don't have a memory corruption when it doesn't -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] switch from sprintf to asprintf and snprintf
Robert Millan wrote: On Fri, Jan 01, 2010 at 09:32:24AM +, Colin Watson wrote: On Tue, Dec 29, 2009 at 10:30:12AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: +char *EXPORT_FUNC(grub_asprintf) (const char *fmt, ...) + __attribute__ ((format (printf, 1, 2))); It's very confusing that you've made grub_asprintf have a dramatically different interface from asprintf. Perhaps you could call this grub_xasprintf instead? Is it feasible to implement the same interface as asprintf instead? it's feasible but the only advantage it gives is the return value nobody uses anyway -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Trouble booting from a large USB hard drive
Daniel Richard G. wrote: What all but confirmed it for me was an ingenious solution I saw posted somewhere: an out-of-order partition table. Put the Linux partitions first on I accidentally have an out-of-order partition table and I was surprised that such a thing is possible (vs. that everything gets automatically numbered in order). Nevertheless, it is a useful feature, though not obvious how to control with 'gparted' and the like. extended partitions probably add a bit of complication too. With all that said, I don't consider this to be a bug in GRUB, and this is not meant to be taken as a bug report. (I presume grub-pc can't work around such limitations in the BIOS, because there isn't enough room in the MBR to stuff in a disk-reading library that makes BIOS disk calls unnecessary.) Rather, I think it is a corner case of which users should be aware---and perhaps GRUB and/or the Ubuntu installer could do a better job of warning the user if grub-install, which doesn't have code space limitations, could possibly check for it, it would be a great help. But is it possible for a running system to check the BIOS like that? (or possible for grub to check somehow on a non-running system in a safe testing sort of manner?) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [multiboot] command-line format
Hi Robert, Thanks for your detailed explanation, it was really helpful to me. I understand that for compatibility with some platforms, GRUB must provide a way to specify two potentially different file parameters: (a) the GRUB path to the booted file; this path does not appear in the multiboot command-line. (b) the path that shall be passed to the booted file; this path (if any) is the first argument in the multiboot command-line. However, my first post in this thread was more about the multiboot specification itself. In light of your explanations, I would re-phrase my suggestion as follows: in the multiboot specification, require that the first argument of the MB command-line be a path to the booted file *in a notation that is specific to the booted kernel*. Or, if this is too constraining or too confusing, simply ask that the first argument is an informative string that does not contain kernel options (i.e. it can safely be skipped). This way, the specification would be closer to the reference implementation (GRUB Legacy), and, more importantly, to what multiboot-compliant kernels already *assume* about the format of the command-line (NetBSD, OpenSolaris, Xen, others?). For GRUB 2, this could be implemented by a multiboot command that, by default, behaves as GRUB Legacy, but also offers a way to modify the implicit first argument of the multiboot command-line. Something like: multiboot $path[;$ospath] ... (a) $path is the GRUB path to the booted file. (b) $ospath is the path that shall be passed to the booted file. By default, if there is no ';' in the first argument, $ospath is set to the value that GRUB Legacy would have used. Maybe a GRUB shell variable `multiboot_ospath' would be better than this ';' marker. This way, we keep the extra flexibility of having different paths, but we also: - keep backward compatibility with GRUB Legacy: kernels can still assume that the first argument of the multiboot command-line is not a kernel option. - don't force users to repeat the path for kernels that are happy with the way GRUB Legacy worked (all of them except OpenSolaris?). I agree that this point is of no concern to most users, but in some cases grub-mkconfig does not work (e.g. grub-mkconfig does not support --root-directory at the moment), and some users prefer the flexibility of the command line anyway. Grégoire ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [multiboot] command-line format
Also, I firmly believe that we shouldn't be satisfied with flawed solutions just because they're part of our legacy baggage. We can do better than this because Free Software is more flexible and more powerful. For example, NetBSD can distribute its own version of GRUB and patch it, and coordinate an interface change between GRUB and its kernel, etc. I think a bootloader with universal in its name should be doing everything possible to avoid this. If I want to multiboot between Linux, NetBSD, OpenSolaris, and OpenBSD, do I load my MBR with the BSD fork of GRUB, the Linux fork of GRUB, or the Solaris fork of GRUB? This really is a non-solution. I think that defaulting the first parameter to the value used by what, 90% of kernels, but providing a way to override it (I like the variable idea) will be the least surprising for users. The path is filesystem-relative anyway, so GRUB isn't required to know how the kernel names its devices, nor do changes to grub device addressing change the parameter passed. But the current behavior requiring the user to explicitly specify the 0th parameter certainly works, and if the format is to be changed then during the switch from GRUB Legacy to GRUB2 is the ideal time to do it. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Proof of concept interrupt wrapping
Robert Millan wrote:
On Thu, Dec 31, 2009 at 01:28:30PM +0100, Vladimir 'φ-coder/phcoder'
Serbinenko wrote:
Hello. We were discussing with Robert how to move BIOS interrupt
routines out of kernel. There are following possibilities:
1) Have a .lowmem section in every concerned module which will always be
placed in low memory. Currently in experimental.
Advantages:
a) moving functions to modules is straightforward
b) functions grow neither in size nor in complexity
Disadvantages:
c) needs lowmem allocators in core
2) Make every function needing bios interrupts setup its own trampoline.
Due to complexity of trampolines it's not a real option
3) Have an universal routine grub_interrupt (int intno, struct
grub_cpu_interrupt_regs *regs) which will be used by C routine to do the
interrupt calls. This would move the complexity from asm to C.
Advantages:
a) simplicity in core
b) complexity moved to a more readable language
c) we can also rename grub_interrupt to grub_interrupt_real and make
grub_interrupt dprintf registers before and after the call. This would
make debugging BIOS quirks easier.
Disadvantages:
a) Moving functions needs effort
b) C functions are probably bigger but it may be offset by possibility
of inlining functions
c) repeadetly changing from/to real mode is an overhead when executing
multiple interrupts in series. Fortunately this condition is rare in our
codebase and is only on non performance-critical parts like halting.
d) Some functions aren't covered by this. At least grub_pxe_call is in
this case. But we can use method 2 for them
We could diminish #1.c with ifdef GRUB_MACHINE_PCBIOS, but it's still ugly.
I like #3 a lot more.
As for C being bigger than asm, it's argueable, taking into account that
we have regparm, function alignment hacks, and gcc size optimizations :-)
In any case #3 looks a lot cleaner.
Some comments about the patch:
+struct grub_cpu_int_registers
+{
+ grub_uint16_t bx;
+ grub_uint16_t es;
+ grub_uint16_t cx;
+ grub_uint16_t ax;
+ grub_uint16_t dx;
+ grub_uint16_t ds;
+ grub_uint16_t di;
+ grub_uint16_t flags;
+ grub_uint16_t si;
+};
This structure is named in generic way, but its member names are CPU-specific.
Is it useful to make this generic? In practice, it will be impossible for
CPU-independant code to use it.
I changed it to _bios_
I think it would be better to admit that this is a pure ad-hoc kludge. It's
not beautiful, but it's *much* better than what we have now.
I added 32-bit register support since it's needed for APM. Can wrapper
be merged to mainline or is it better for it to be in a separate branch
and be merged with first bunch of BIOS code going out of kernel?
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'conf/i386-pc.rmk'
--- conf/i386-pc.rmk 2010-01-15 20:11:51 +
+++ conf/i386-pc.rmk 2010-01-17 20:16:27 +
@@ -64,7 +64,7 @@
partition.h msdos_partition.h reader.h symbol.h term.h time.h types.h \
machine/biosdisk.h machine/boot.h machine/console.h machine/init.h \
machine/memory.h machine/loader.h machine/vga.h machine/vbe.h \
- machine/kernel.h machine/pxe.h i386/pit.h list.h handler.h command.h i18n.h
+ machine/kernel.h machine/pxe.h i386/pit.h list.h handler.h command.h i18n.h machine/int.h
kernel_img_CFLAGS = $(COMMON_CFLAGS) $(TARGET_IMG_CFLAGS)
kernel_img_ASFLAGS = $(COMMON_ASFLAGS)
kernel_img_LDFLAGS = $(COMMON_LDFLAGS) $(TARGET_IMG_LDFLAGS)$(GRUB_KERNEL_MACHINE_LINK_ADDR) $(COMMON_CFLAGS)
=== modified file 'disk/i386/pc/biosdisk.c'
--- disk/i386/pc/biosdisk.c 2010-01-04 23:30:27 +
+++ disk/i386/pc/biosdisk.c 2010-01-17 20:16:27 +
@@ -19,6 +19,7 @@
#include grub/machine/biosdisk.h
#include grub/machine/memory.h
#include grub/machine/kernel.h
+#include grub/machine/int.h
#include grub/disk.h
#include grub/dl.h
#include grub/mm.h
@@ -28,6 +29,59 @@
#include grub/term.h
static int cd_drive = 0;
+static int grub_biosdisk_rw_int13_extensions (int ah, int drive, void *dap);
+
+static int grub_biosdisk_get_num_floppies (void)
+{
+ struct grub_bios_int_registers regs;
+ int drive;
+
+ /* reset the disk system first */
+ regs.eax = 0;
+ regs.edx = 0;
+ regs.flags = GRUB_CPU_INT_FLAGS_DEFAULT;
+
+ grub_bios_interrupt (0x13, regs);
+
+ for (drive = 0; drive 2; drive++)
+{
+ regs.flags = GRUB_CPU_INT_FLAGS_DEFAULT | GRUB_CPU_INT_FLAGS_CARRY;
+ regs.edx = drive;
+
+ /* call GET DISK TYPE */
+ regs.eax = 0x1500;
+ grub_bios_interrupt (0x13, regs);
+ if (regs.flags GRUB_CPU_INT_FLAGS_CARRY)
+ break;
+
+ /* check if this drive exists */
+ if (!(regs.eax 0x300))
+ break;
+}
+
+ return drive;
+}
+
+/*
+ * Call IBM/MS INT13 Extensions (int 13 %ah=AH) for DRIVE. DAP
+ * is passed for disk address packet. If an error occurs, return
+ * non-zero, otherwise zero.
+ */
+
+static int
+grub_biosdisk_rw_int13_extensions (int ah, int drive,
RE: Trouble booting from a large USB hard drive
[Replying with Outlook, please forgive the atrocious formatting] Isaac Dupree wrote: I accidentally have an out-of-order partition table and I was surprised that such a thing is possible (vs. that everything gets automatically numbered in order). Nevertheless, it is a useful feature, though not obvious how to control with 'gparted' and the like. extended partitions probably add a bit of complication too. Yes, I used fdisk(8) to get the effect, but with most user-friendly partitioning tools I'd have been SOL. I'm thinking about the implications for something like the Ubuntu installer/partitioner, which has to be dead simple for the user, and yet producing an out-of-order table would be a helpful measure of interoperability with Windows systems. if grub-install, which doesn't have code space limitations, could possibly check for it, it would be a great help. But is it possible for a running system to check the BIOS like that? (or possible for grub to check somehow on a non-running system in a safe testing sort of manner?) Consider, too, that GRUB may be installed on a system where the BIOS is good, and then booted on a system where it borks. USB drives have a natural mobility to them, of course, and even IDE/SATA drives may be transplanted from one computer to another. --Daniel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Trouble booting from a large USB hard drive
On Sun, Jan 17, 2010 at 03:45:06PM -0500, Daniel Richard G. wrote: Isaac Dupree wrote: I accidentally have an out-of-order partition table and I was surprised that such a thing is possible (vs. that everything gets automatically numbered in order). Nevertheless, it is a useful feature, though not obvious how to control with 'gparted' and the like. extended partitions probably add a bit of complication too. Yes, I used fdisk(8) to get the effect, but with most user-friendly partitioning tools I'd have been SOL. I'm thinking about the implications for something like the Ubuntu installer/partitioner, which has to be dead simple for the user, and yet producing an out-of-order table would be a helpful measure of interoperability with Windows systems. The Ubuntu installer's partitioner (essentially due to how libparted works, so I expect any libparted-based partitioner is similar) will produce out-of-order partition tables when it's convenient for itself to do so: it avoids renumbering partitions since that tends to break existing operating systems relying on those partitions, so when you resize a partition to make some space and then create new partitions in that space you'll typically get an out-of-order partition table. 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. 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. 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. 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. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
keyboard layout patches
Hello,
I've done a first version of keyboard_layout. Find a patch attached, or
check the branch:
bzr.savannah.gnu.org/srv/bzr/grub/people/cpina/keyboard_layouts
I've tested only in at_keyboard. Using something like:
insmod at_keyboard
terminal_input at_keyboard
insmod keyboard_layouts
set keymaps_dir=/boot/grub/layouts
load_keyboard es
and before I generate the file called es and copied into
/boot/grub/layouts using grub-mklayout es
How could grub-mkinstall (00_header.in) know the current keyboard in the
system? I wold tweak 00_header.in to generate the keymap file and setup
it.
Comments about the current patch are welcomed, I would change it on next
days.
Some days ago I read:
There are 2 hard problems in computer science: cache invalidation,
naming things, and off-by-1 errors.
Don't hesitate to tell me how would you rename some things, I'll do.
I'm not happy with the name of some variables/functions but I cannot
think about it today :-)
Cheers,
--
Carles Pina i Estany
http://pinux.info
=== modified file 'conf/common.rmk'
--- conf/common.rmk 2010-01-14 14:04:44 +
+++ conf/common.rmk 2010-01-17 14:35:00 +
@@ -88,6 +88,10 @@ endif
bin_UTILITIES += grub-mkrelpath
grub_mkrelpath_SOURCES = gnulib/progname.c util/grub-mkrelpath.c util/misc.c
+# For grub-mklayouts.
+bin_UTILITIES += grub-mklayouts
+grub_mklayouts_SOURCES = gnulib/progname.c util/grub-mklayouts.c util/misc.c
+
# For the parser.
grub_script.tab.c grub_script.tab.h: script/parser.y
$(YACC) -d -p grub_script_yy -b grub_script $(srcdir)/script/parser.y
@@ -647,6 +651,12 @@ gettext_mod_SOURCES = gettext/gettext.c
gettext_mod_CFLAGS = $(COMMON_CFLAGS)
gettext_mod_LDFLAGS = $(COMMON_LDFLAGS)
+# For keyboard_layouts.mod
+pkglib_MODULES += keyboard_layouts.mod
+keyboard_layouts_mod_SOURCES = keyboard_layouts/keyboard_layouts.c
+keyboard_layouts_mod_CFLAGS = $(COMMON_CFLAGS)
+keyboard_layouts_mod_LDFLAGS = $(COMMON_LDFLAGS)
+
# Misc.
pkglib_MODULES += xnu_uuid.mod
=== added file 'include/grub/keys.h'
--- include/grub/keys.h 1970-01-01 00:00:00 +
+++ include/grub/keys.h 2010-01-17 18:21:42 +
@@ -0,0 +1,36 @@
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2010 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see http://www.gnu.org/licenses/.
+ */
+
+#ifndef GRUB_KEYS_HEADER
+#define GRUB_KEYS_HEADER 1
+
+/* Internal codes used by GRUB to represent terminal input. */
+#define GRUB_TERM_LEFT 2
+#define GRUB_TERM_RIGHT 6
+#define GRUB_TERM_UP16
+#define GRUB_TERM_DOWN 14
+#define GRUB_TERM_HOME 1
+#define GRUB_TERM_END 5
+#define GRUB_TERM_DC4
+#define GRUB_TERM_PPAGE 7
+#define GRUB_TERM_NPAGE 3
+#define GRUB_TERM_ESC '\e'
+#define GRUB_TERM_TAB '\t'
+#define GRUB_TERM_BACKSPACE 8
+
+#endif /* ! GRUB_KEYS_HEADER */
=== modified file 'include/grub/term.h'
--- include/grub/term.h 2010-01-09 22:42:17 +
+++ include/grub/term.h 2010-01-17 22:25:58 +
@@ -19,19 +19,7 @@
#ifndef GRUB_TERM_HEADER
#define GRUB_TERM_HEADER 1
-/* Internal codes used by GRUB to represent terminal input. */
-#define GRUB_TERM_LEFT 2
-#define GRUB_TERM_RIGHT 6
-#define GRUB_TERM_UP 16
-#define GRUB_TERM_DOWN 14
-#define GRUB_TERM_HOME 1
-#define GRUB_TERM_END 5
-#define GRUB_TERM_DC 4
-#define GRUB_TERM_PPAGE 7
-#define GRUB_TERM_NPAGE 3
-#define GRUB_TERM_ESC '\e'
-#define GRUB_TERM_TAB '\t'
-#define GRUB_TERM_BACKSPACE 8
+#include grub/keys.h
#ifndef ASM_FILE
@@ -198,6 +186,14 @@ extern struct grub_term_input *EXPORT_VA
extern struct grub_term_output *EXPORT_VAR(grub_term_outputs);
extern struct grub_term_input *EXPORT_VAR(grub_term_inputs);
+struct grub_keyboard_map_s
+{
+ char *normal;
+ char *shift;
+};
+
+extern struct grub_keyboard_map_s *EXPORT_VAR(grub_keyboard_map);
+
static inline void
grub_term_register_input (const char *name __attribute__ ((unused)),
grub_term_input_t term)
=== modified file 'kern/term.c'
--- kern/term.c 2009-12-27 21:35:40 +
+++ kern/term.c 2010-01-17 21:52:16 +
@@ -30,6 +30,8 @@ struct grub_term_input *grub_term_inputs
void (*grub_newline_hook) (void) = NULL;
+struct grub_keyboard_map_s *grub_keyboard_map = NULL;
+
/* Put a Unicode character. */
void
grub_putcode (grub_uint32_t code, struct grub_term_output *term)
=== added directory
Re: Trouble booting from a large USB hard drive
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. Me too, but for this reason: putting /boot near the beginning will be normal partitioner stuff, but this person's reason for caring about the partition order is that he knows which partition he wants to be mounted by Windows, and that's #1. Which is an idea that could be implemented in a GUI, given the right libraries, (potentially though, if there's a different current partition-#1, at the expense of anything that refers to *that* partition by number) (and it might be too hacky an idea, i.e. being Windows-related and all, for gnu/linux developers to want to support so cleanly anyway) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Trouble booting from a large USB hard drive
Daniel Richard G. wrote: Knowing that Windows would only mount the first partition when the drive was plugged in Does this only apply to external hard drives? I've always put Linux as my first partition on my single hard drive without any problem (now it's with XP, but AFAIR also with 98SE before). I mean first partition both ``logically'' and ``physically'', e.g. what I have now is: Device Boot Start End Blocks Id System /dev/sda1 * 1261120972826 83 Linux /dev/sda226124569157276357 HPFS/NTFS And if I remember right, the Windows installer (booting from a windows install CD) had the bad habit of renumbering the primary partitions if their logical order was not consistent with their physical order. At least it did it once, and I've never played with out-of-order partition tables since ;-) Grégoire ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
RE: Trouble booting from a large USB hard drive
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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
RE: Trouble booting from a large USB hard drive
Grégoire Sutre wrote: Knowing that Windows would only mount the first partition when the drive was plugged in Does this only apply to external hard drives? Windows treats removable and fixed drives (as distinguished by what is called the removable media bit) differently, the difference being that it will mount all the partitions of a fixed disk (presuming they are of a compatible partition type and filesystem), whereas for a removable disk, it will mount only the first one and ignore all the others. I've seen Windows tools out there that can flip the removable-media bit on a USB drive, with the raison d'etre of allowing users to work with multiple partitions on same. (Note: For the purposes of this discussion, Windows mounting a partition means an icon for it appears in My Computer when I plug the disk in) I've always put Linux as my first partition on my single hard drive without any problem (now it's with XP, but AFAIR also with 98SE before). I mean first partition both ``logically'' and ``physically'', e.g. what I have now is: That's a different scenario, that of Windows skipping over partitions that it doesn't know about to get to those that it does. I don't know anything about that---I thought Windows just gave up at the first non-Windows partition it encounters, because that would be such a Windows-y thing for it to do :-] --Daniel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
