Re: grub-setup: error: no mapping exists for ... in GRUB2 v1.97.1 on fake (IMSM) RAID
Am Sonntag, den 27.12.2009, 17:50 -0800 schrieb Lapohos Tibor: Thanks for your reply. What the OROM says is that both of my volumes are bootable. /dev/md126 corresponds to Volume0, and its first partition (ext4) has the boot flag set. My problem is that I cannot get grub2 installed on the device at all. I did try, as you suggested, to set You're problem is that you're using metadata 1.x and not the older default 0.90. Which we don't support yet. I made a Baazar branch for metadata 1.x support, but it's still broken. At least RAID != 1. But I tested RAID 1 only with grub-probe, not actual booting from it. And it's a bit complicated to get grub-probe working, because the devicename must macht the name stored in the superblock. If you want to try it nevertheless: bzr co http://bzr.savannah.gnu.org/r/grub/people/fzielcke/raid (hd0) /dev/md126 in the device.map file and then issue grub-install --modules=raid /dev/md126 but I still get the same error message(s): grub-probe: error: no mapping exists for 'md126' grub-setup: error: no mapping exists for 'md126' device.map isn't used at all for mdraid devices. What is interesting is that, at the grub shell, I can do grub probe -l (hd0,1) it returns OS which is the label I set for it, so the device can, under certain circumstances, definitely be detected. Nevertheless, grub-install does not seem to behave the same way. (hdX,Y) devices are normal disk devices though and not the RAID ones. They're (mdX) and (mdX,Y) so it only works with RAID 1, but only by using one disk of them. -- Felix Zielcke Proud Debian Maintainer and GNU GRUB developer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Multiboot ammendment: non-VBE video
Robert Millan wrote:
On Tue, Sep 01, 2009 at 05:37:11PM +0200, Vladimir 'phcoder' Serbinenko wrote:
Hello. I'm implementing video part of multiboot specification.
Currently the only defined interface is for providing VBE info. I
propose following way to set fields if video is non VBE:
vbe_control_info=0x
When vbe_control_info is set to 0x all VBE-specific fields are
invalid
vbe_mode set to 0x
vbe_interface_seg=0x
vbe_interface_off=0x
vbe_interface_len=0xff
vbe_mode_info points to structure similar to vbe_mode_info but with
all vbe-specific fields set to zero. Remaining (valid) fields are
(full structur is in include/grub/i386/pc/vbe.h)
This seems like one of these cases in which legacy gets in the way. Why
don't we just replace the legacy structure with something that doesn't need
dummy fields?
Actually it seems like we already define possible dummy fields if
vbe_interface isn't available. vbe_mode_info although contains some vbe
callback info and framebuffer information info. We need only second. My
idea was that payloads that only use info for framebuffer may be readily
working on non-VBE. Alternatively we may define a structure which
contains only framebuffer info. This would avoid the requirement to set
vbe display line to 0 before calling the payload. The draft I have
locally is the following:
=== modified file 'docs/multiboot.texi'
--- docs/multiboot.texi2008-09-03 20:15:15 +
+++ docs/multiboot.texi2009-12-17 20:04:47 +
@@ -479,7 +479,8 @@
preferred graphics mode. Note that that is only a @emph{recommended}
mode by the OS image. If the mode exists, the boot loader should set
it, when the user doesn't specify a mode explicitly. Otherwise, the
-boot loader should fall back to a similar mode, if available.
+boot loader should fall back to a similar mode, if available. Boot loader
+may also choose another mode if it sees fit.
The meaning of each is as follows:
@@ -488,7 +489,9 @@
Contains @samp{0} for linear graphics mode or @samp{1} for
EGA-standard text mode. Everything else is reserved for future
expansion. Note that the boot loader may set a text mode, even if this
-field contains @samp{0}.
+field contains @samp{0}. If video adapter doesn't support EGA text mode or
+bootloader doesn't know how to initialise this mode it may set video
+mode even if field contains @samp{1}
@item width
Contains the number of the columns. This is specified in pixels in a
@@ -917,16 +920,62 @@
Management (APM) BIOS Interface Specification}, for more information.
If bit 11 in the @samp{flags} is set, the graphics table is available.
-This must only be done if the kernel has indicated in the
-...@samp{multiboot Header} that it accepts a graphics mode.
The fields @samp{vbe_control_info} and @samp{vbe_mode_info} contain
the physical addresses of @sc{vbe} control information returned by the
@sc{vbe} Function 00h and @sc{vbe} mode information returned by the
-...@sc{vbe} Function 01h, respectively.
+...@sc{vbe} Function 01h, respectively. In case of n...@sc{vbe} video driver
+...@samp{vbe_control_info} contains zero and @samp{vbe_mode_info} points
to the
+following 256-byte structure:
+
+...@example
+...@group
++--+
+0 | flags|
+2 | zeros|
+16 | pitch|
+18 | width|
+20 | height |
+22 | zeros|
+25 | bits per pixel |
+26 | zeros|
+27 | memory model |
+28 | zeros|
+31 | red mask size|
+32 | red field position |
+33 | green mask size |
+34 | green field position |
+35 | blue mask size |
+36 | blue field position |
+37 | alpha mask size |
+38 | alpha field position |
+39 | zero |
+40 | framebuffer address |
+44 | zero |
+50 | pitch|
+52 | zero |
+54 | red mask size|
+55 | red field position |
+56 | green mask size |
+57 | green field position |
+58 | blue mask size |
+59 | blue field position |
+60 | alpha mask size |
+61 | alpha field position |
+62 | zeros|
++--+
+...@end group
+...@end example
+
+All fields have the same meaning as the corresponding VBE mode info
+structure except fields marked as zeros which are zero-filled.
+
+If video is a linear framebuffer boot loader has to ensure that
+displayed region starts at offset @samp{0} of linear framebuffer.
The field @samp{vbe_mode} indicates current video mode in the format
-specified in @sc{vbe} 3.0.
+specified in @sc{vbe} 3.0. In case of n...@sc{vbe} video driver
+...@samp{vbe_mode} contains 0x.
The rest fields @samp{vbe_interface_seg}, @samp{vbe_interface_off}, and
[PATCH] Search hinting support
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'commands/search.c'
--- commands/search.c 2009-12-25 23:50:59 +
+++ commands/search.c 2009-12-28 13:02:23 +
@@ -30,7 +30,8 @@
#include grub/i18n.h
void
-FUNC_NAME (const char *key, const char *var, int no_floppy)
+FUNC_NAME (const char *key, const char *var, int no_floppy,
+ const char **hints, unsigned nhints)
{
int count = 0;
char *buf = NULL;
@@ -118,22 +119,32 @@
return (found var);
}
+ auto void try (void);
+ void try (void)
+ {
+unsigned i;
+for (i = 0; i nhints; i++)
+ if (iterate_device (hints[i]))
+ return;
+grub_device_iterate (iterate_device);
+ }
+
/* First try without autoloading if we're setting variable. */
if (var)
{
saved_autoload = grub_fs_autoload_hook;
grub_fs_autoload_hook = 0;
- grub_device_iterate (iterate_device);
+ try ();
/* Restore autoload hook. */
grub_fs_autoload_hook = saved_autoload;
/* Retry with autoload if nothing found. */
if (grub_errno == GRUB_ERR_NONE count == 0)
- grub_device_iterate (iterate_device);
+ try ();
}
else
-grub_device_iterate (iterate_device);
+try ();
grub_free (buf);
@@ -148,7 +159,8 @@
if (argc == 0)
return grub_error (GRUB_ERR_BAD_ARGUMENT, no argument specified);
- FUNC_NAME (args[0], argc == 1 ? 0 : args[1], 0);
+ FUNC_NAME (args[0], argc == 1 ? 0 : args[1], 0, (const char **) (args + 2),
+ argc 2 ? argc - 2 : 0);
return grub_errno;
}
@@ -165,7 +177,7 @@
{
cmd =
grub_register_command (COMMAND_NAME, grub_cmd_do_search,
- NAME [VARIABLE],
+ NAME [VARIABLE] [HINTS],
Search devices by SEARCH_TARGET .
If VARIABLE is specified,
the first device found is set to a variable.);
=== modified file 'commands/search_wrap.c'
--- commands/search_wrap.c 2009-12-25 22:06:52 +
+++ commands/search_wrap.c 2009-12-28 13:02:23 +
@@ -62,11 +62,14 @@
var = state[SEARCH_SET].arg ? state[SEARCH_SET].arg : root;
if (state[SEARCH_LABEL].set)
-grub_search_label (args[0], var, state[SEARCH_NO_FLOPPY].set);
+grub_search_label (args[0], var, state[SEARCH_NO_FLOPPY].set,
+ (const char **) (args + 1), argc - 1);
else if (state[SEARCH_FS_UUID].set)
-grub_search_fs_uuid (args[0], var, state[SEARCH_NO_FLOPPY].set);
+grub_search_fs_uuid (args[0], var, state[SEARCH_NO_FLOPPY].set,
+ (const char **) (args + 1), argc - 1);
else if (state[SEARCH_FILE].set)
-grub_search_fs_file (args[0], var, state[SEARCH_NO_FLOPPY].set);
+grub_search_fs_file (args[0], var, state[SEARCH_NO_FLOPPY].set,
+ (const char **) (args + 1), argc - 1);
else
return grub_error (GRUB_ERR_INVALID_COMMAND, unspecified search type);
@@ -80,7 +83,7 @@
cmd =
grub_register_extcmd (search, grub_cmd_search,
GRUB_COMMAND_FLAG_BOTH,
- N_(search [-f|-l|-u|-s|-n] NAME),
+ N_([-f|-l|-u|-s|-n] NAME [HINTS]),
N_(Search devices by file, filesystem label
or filesystem UUID.
If --set is specified, the first device found is
=== modified file 'include/grub/search.h'
--- include/grub/search.h 2009-11-23 20:15:44 +
+++ include/grub/search.h 2009-12-28 13:02:23 +
@@ -19,8 +19,11 @@
#ifndef GRUB_SEARCH_HEADER
#define GRUB_SEARCH_HEADER 1
-void grub_search_fs_file (const char *key, const char *var, int no_floppy);
-void grub_search_fs_uuid (const char *key, const char *var, int no_floppy);
-void grub_search_label (const char *key, const char *var, int no_floppy);
+void grub_search_fs_file (const char *key, const char *var, int no_floppy,
+ const char **hints, unsigned nhints);
+void grub_search_fs_uuid (const char *key, const char *var, int no_floppy,
+ const char **hints, unsigned nhints);
+void grub_search_label (const char *key, const char *var, int no_floppy,
+ const char **hints, unsigned nhints);
#endif
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] spaces (label, UUID)
Hi, On Dec/28/2009, Carles Pina i Estany wrote: This patch should fix a small problem that Vladimir spotted and Committed. -- Carles Pina i Estany http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] grub-probe support for NetBSD
Hi,
Here is a new version of the patch (the change log remains the same as
in the original email). The new version does not attempt to read from a
floppy device in grub_util_biosdisk_open. Indeed, on NetBSD, reading
from the floppy device (e.g. cat /dev/fd0a) takes a _long_ time to abort
when there is no floppy in the drive.
With this patch (and with a few other changes [1] discussed here or on
bug-grub), I could successfully install grub with grub-install on a USB
stick (and then boot from it) on NetBSD 5.0 i386 and amd64.
Regards,
Grégoire
[1]
http://pkgsrc-wip.cvs.sourceforge.net/viewvc/pkgsrc-wip/wip/grub2-current/patches/
--- util/getroot.c.orig 2009-12-29 00:43:31.0 +0100
+++ util/getroot.c
@@ -266,8 +266,14 @@ find_root_device (const char *dir, dev_t
char *cwd;
cwd = xgetcwd ();
+#if defined(__NetBSD__)
+ /* Convert this block device to its character (raw) device */
+ res = xmalloc (strlen (cwd) + strlen (ent-d_name) + 3);
+ sprintf (res, %s/r%s, cwd, ent-d_name);
+#else
res = xmalloc (strlen (cwd) + strlen (ent-d_name) + 2);
sprintf (res, %s/%s, cwd, ent-d_name);
+#endif
strip_extra_slashes (res);
free (cwd);
--- util/grub-probe.c.orig 2009-12-29 00:43:31.0 +0100
+++ util/grub-probe.c
@@ -111,7 +111,7 @@ probe (const char *path, char *device_na
if (path == NULL)
{
-#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__NetBSD__)
if (! grub_util_check_char_device (device_name))
grub_util_error (%s is not a character device.\n, device_name);
#else
--- util/hostdisk.c.orig2009-12-29 00:43:31.0 +0100
+++ util/hostdisk.c
@@ -97,6 +97,15 @@ struct hd_geometry
# include sys/disk.h
#endif
+#if defined(__NetBSD__)
+# include sys/ioctl.h
+# include sys/disklabel.h/* struct disklabel */
+# include util.h/* getrawpartition */
+# ifndef RAW_FLOPPY_MAJOR
+# define RAW_FLOPPY_MAJOR 9
+# endif /* ! RAW_FLOPPY_MAJOR */
+#endif
+
struct
{
char *drive;
@@ -191,16 +200,20 @@ grub_util_biosdisk_open (const char *nam
return GRUB_ERR_NONE;
}
#elif defined(__linux__) || defined(__CYGWIN__) || defined(__FreeBSD__) || \
- defined(__FreeBSD_kernel__) || defined(__APPLE__)
+ defined(__FreeBSD_kernel__) || defined(__APPLE__) || defined(__NetBSD__)
{
+# if defined(__NetBSD__)
+struct disklabel label;
+# else
unsigned long long nr;
+# endif
int fd;
fd = open (map[drive].device, O_RDONLY);
if (fd == -1)
return grub_error (GRUB_ERR_BAD_DEVICE, cannot open `%s' while
attempting to get disk size, map[drive].device);
-# if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__APPLE__)
+# if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__APPLE__)
|| defined(__NetBSD__)
if (fstat (fd, st) 0 || ! S_ISCHR (st.st_mode))
# else
if (fstat (fd, st) 0 || ! S_ISBLK (st.st_mode))
@@ -214,6 +227,11 @@ grub_util_biosdisk_open (const char *nam
if (ioctl (fd, DIOCGMEDIASIZE, nr))
# elif defined(__APPLE__)
if (ioctl (fd, DKIOCGETBLOCKCOUNT, nr))
+# elif defined(__NetBSD__)
+/* Do not attempt to read from a floppy device as it may take a long
+ time before aborting if there is no floppy in the drive. */
+if ((major(st.st_rdev) == RAW_FLOPPY_MAJOR) ||
+ ioctl (fd, DIOCGDINFO, label))
# else
if (ioctl (fd, BLKGETSIZE64, nr))
# endif
@@ -224,14 +242,16 @@ grub_util_biosdisk_open (const char *nam
close (fd);
-#if defined (__APPLE__)
+# if defined (__APPLE__)
disk-total_sectors = nr;
-#else
+# elif defined(__NetBSD__)
+disk-total_sectors = label.d_secperunit;
+# else
disk-total_sectors = nr / 512;
if (nr % 512)
grub_util_error (unaligned device size);
-#endif
+# endif
grub_util_info (the size of %s is %llu, name, disk-total_sectors);
@@ -683,7 +703,7 @@ make_device_name (int drive, int dos_par
dos_part_str = xasprintf (,%d, dos_part + 1);
if (bsd_part = 0)
-bsd_part_str = xasprintf (,%c, dos_part + 'a');
+bsd_part_str = xasprintf (,%c, bsd_part + 'a');
ret = xasprintf (%s%s%s, map[drive].drive,
dos_part_str ? : ,
@@ -853,6 +873,26 @@ convert_system_partition_to_system_disk
}
return path;
+#elif defined(__NetBSD__)
+ /* NetBSD uses /dev/r[wsc]d[0-9]+[a-z]. */
+ char *path = xstrdup (os_dev);
+ if (strncmp (/dev/rwd, path, 8) == 0 ||
+ strncmp (/dev/rsd, path, 8) == 0 ||
+ strncmp (/dev/rcd, path, 8) == 0)
+{
+ char *q;
+ q = path + strlen(path) - 1;/* last character */
+ if (grub_isalpha(*q) grub_isdigit(*(q-1)))
+{
+ int rawpart;
+ rawpart = getrawpartition();
+ if (rawpart 0)
+rawpart = 3;/* default on i386 */
+ *q = 'a' + rawpart;
+}
+}
+ return
Re: autogen.sh warnings
Robert Millan wrote:
On Thu, Dec 10, 2009 at 10:20:21AM -0600, Bruce Dubbs wrote:
Felix Zielcke wrote:
Am Donnerstag, den 10.12.2009, 00:05 -0600 schrieb Bruce Dubbs:
On the other hand, config.guess is used to get build_cpu and build_os
and I don't see that being used at all right now by grub.
Well just after the part you quoted from me, I thought I made it clear
that the output of config.guess is used as an argument for config.sub
So you just need both. At least as long as autoconf doestn't get
changed.
Exactly. I originally said that config.guess was required by configure
even though the output not used. As you pointed out to me, config.sub
output is used.
This all goes back to the overall build process. I've been thinking
about it a lot, but I'm not ready to offer any suggestions yet.
What is exactly the problem?
Using automake without Makefile.am is non-standard and not provided for
within automake. The only thing we use automake for is to copy
config.{guess,sub} to the root of the root of the source.
Also, building as one large monolithic Makefile with includes built via
scripts is probably not optimal from a comprehension point of view.
Our use of config.{guess,sub} is pretty standard,
at least as far as invoking the scripts is concerned.
Yes, as we discussed, they are used in configure.
-- Bruce
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Backup old boot sectors before installation
On Mon, Dec 28, 2009 at 9:21 PM, Zhu Yi yi@intel.com wrote: On Tue, 2009-12-29 at 06:04 +0800, Isaac Dupree wrote: Option 1~3 requires the recover has the knowledge of the backup file format somehow, but a simple dd is enough for option 4. What do you think? If the partitioning had been changed in the mean time, 4 would overwrite it with the older values. Similar problem for a weird setup with partitions in between (I dunno, might be possible with GPT or other weirdness). Good point. I think option 2 or 3 is soundest. Option 2 would have three separate files of information, (right?), and there must be a pretty straightforwards `dd` option to skip to the correct start position. Option 3 would omit the start position file... but that file is really cheap, maybe we'd better keep things simple for restorers and stick with three separate files.(Or, we could do something weird like putting start-position somewhere in the filename of the backup.) This requires the restorer to understand the role of each of the 3 (or 2) files and use `dd' twice with correct options. So an important thing is, we need to document this somewhere. And I think the best place is to document it in the grub-install script. Because this will enable the not-so-advanced user to recover her boot sectors easily as well. If we decide so, we go back to option 1 (my original implementation). Because the backup file format is not important any more as it is totally transparent to the restorers. Am I right? Another option would be to start the backup file with #!/bin/sh ... Thanks, -yi ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub.info
2009/12/3 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com I have examined the hierarchy of the manual and it currently has the structure below. I also did some research and propose a different layout, also shown below. The current layout of the grub2 manual is actually here: http://grub.enbug.org/Manual Enjoy, Bruce. -- Bruce O. Benson, mailto:bben...@gmail.com | http://www.tux.org Donating spare CPU to science: fold...@home Team Debian (#2019) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub.info
Bruce O. Benson wrote:
I have examined the hierarchy of the manual and it currently has the
structure below. I also did some research and propose a different
layout, also shown below.
The current layout of the grub2 manual is actually here:
http://grub.enbug.org/Manual
From one Bruce to another:
The content of bzr trunk/docs has a file, grub.texi. Line 6 says:
@settitle GNU GRUB Manual @value{VERSION}
The wiki is indeed helpful, but not the official GRUB Manual. Both
'Manuals' are terribly incomplete.
-- Bruce Dubbs
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub.info
2009/12/29 Bruce Dubbs bruce.du...@gmail.com
Bruce O. Benson wrote:
I have examined the hierarchy of the manual and it currently has the
structure below. I also did some research and propose a different
layout, also shown below.
The current layout of the grub2 manual is actually here:
http://grub.enbug.org/Manual
From one Bruce to another:
The content of bzr trunk/docs has a file, grub.texi. Line 6 says:
@settitle GNU GRUB Manual @value{VERSION}
The wiki is indeed helpful, but not the official GRUB Manual. Both
'Manuals' are terribly incomplete.
Yes Bruce, I certainly stand corrected. My post probably sounded more
presumptuous than helpful.
If I:
- ...merged the contents of both existing documents into a new one...
- ...that adhered to the outline you enumerated...
- ...assigned copyright to FSF...
- ...rendered in texi, html, and pdf.
...Would that be useful for someone to check in to trunk/docs? I don't
wanna get deep into a piece of work like that if it's not wanted.
Yours,
Bruce
--
Bruce O. Benson, mailto:bben...@gmail.com | http://www.tux.org
Donating spare CPU to science: fold...@home Team Debian (#2019)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Backup old boot sectors before installation
On Tue, 2009-12-29 at 11:59 +0800, richardvo...@gmail.com wrote: If we decide so, we go back to option 1 (my original implementation). Because the backup file format is not important any more as it is totally transparent to the restorers. Am I right? Another option would be to start the backup file with #!/bin/sh ... Create this shell script in grub-setup.c? I don't see how this is less invasive than changing grub-install script. But if everyone agree to add the sharutils package dependency (for uuencode/uudecode), I can implement this in V2. Thanks, -yi ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
