Re: grub-setup: error: no mapping exists for ... in GRUB2 v1.97.1 on fake (IMSM) RAID
Please use proper quoting. It doestn't make it easier to read if your answer is directly below my sentences without any special quoting. Am Sonntag, den 03.01.2010, 20:29 -0800 schrieb Lapohos Tibor: > > Thanks for your help. Please see my further questions below. > > Based on your input, I cannot make this work, right? > No. Probable we could implement support for the newly added metadata formats, but that's IMO very very low priority. The normal ones are more important, especially now that 1.1 became the default instead of 0.90. > I made a Baazar branch for metadata 1.x support, but it's still > broken. > At least RAID != 1. > > So it works for RAID 1, and it is "broken" for the other RAID levels? It seems so. I haven't found out why exactly yet. > 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. > > Would I need to be able to achieve all this as I am assembling the > RAID devices? > You can also just rename the device files afterwards, but before you run grub-install or update-grub/grub-mkconfig. > If you want to try it nevertheless: > > bzr co http://bzr.savannah.gnu.org/r/grub/people/fzielcke/raid > > > Thanks, I'll give it a shot once I get a better grasp of what I'm > doing. > > > device.map isn't used at all for mdraid devices. > > But my device is not "mdraid" type device, is it? The kernel does not > detect it as it loads and starts running. The "mdraid" devices would > be formed of "fd" type partitions, would they not? > No. mdraid devices can have any partition type you want. As with any Linux filesystem etc. pp. fd has only the special meaning that Linux autoassembles them. But the prefered method is to let mdadm inside the initrd/initramfs handle it. And then it doestn't matter at all what partition type you use. /dev/mdXXX and /dev/md/XXX are all mdraid devices. As long as mdadm -Q --detail works on it. Doestn't matter what mdraid metadata you use. > > (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. > > OK, I understand this. But then I must ask, how come the grub shell > (got into by booting from a usb key) lists (hdX,Y) devices for all > these "imsm" contained devices and partitions? Ok I should have written (hdx,y) devices are normal BIOS devices. > Thanks again for your help, > Tibor -- 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: loader/efi/appleloader.c
Robert Millan wrote:
> Hi,
>
> I've removed loader/efi/appleloader.c, because it contained blobs of
> binary data. If someone can provide a satisfactory explanation for
> them, it can be added back. However, this command seems to be seldom
> needed.
>
> Please keep in mind binary blobs or other kind of obfuscated data is not
> acceptable in GRUB. If it's machine code, we need its source code. If
> it's a magic signature, we need a comment and/or macro explaining that,
> etc.
>
>
They are device identifiers in EFI format. E.g. This
static grub_uint8_t devpath_5[] = {
0x01, 0x03, 0x18, 0x00, 0x0B, 0x00, 0x00, 0x00,
0x00, 0x40, 0xCB, 0xFF, 0x00, 0x00, 0x00, 0x00,
0xFF, 0xBF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00,
0x04, 0x06, 0x14, 0x00, 0xEB, 0x85, 0x05, 0x2B,
0xB8, 0xD8, 0xA9, 0x49, 0x8B, 0x8C, 0xE2, 0x1B,
0x01, 0xAE, 0xF2, 0xB7, 0x7F, 0xFF, 0x04, 0x00,
};
Means MMIO(EfiMemoryMappedIO,
0xffcb4000-0xbfff)/PIWGVolume(2B0585EB-D8B8-49A9-8B8CE21B01AEF2B7)
I can add necessary prototypes and structures
--
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: loader/efi/appleloader.c
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Robert Millan wrote:
>
>> Hi,
>>
>> I've removed loader/efi/appleloader.c, because it contained blobs of
>> binary data. If someone can provide a satisfactory explanation for
>> them, it can be added back. However, this command seems to be seldom
>> needed.
>>
>> Please keep in mind binary blobs or other kind of obfuscated data is not
>> acceptable in GRUB. If it's machine code, we need its source code. If
>> it's a magic signature, we need a comment and/or macro explaining that,
>> etc.
>>
>>
>>
> They are device identifiers in EFI format. E.g. This
> static grub_uint8_t devpath_5[] = {
> 0x01, 0x03, 0x18, 0x00, 0x0B, 0x00, 0x00, 0x00,
> 0x00, 0x40, 0xCB, 0xFF, 0x00, 0x00, 0x00, 0x00,
> 0xFF, 0xBF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00,
> 0x04, 0x06, 0x14, 0x00, 0xEB, 0x85, 0x05, 0x2B,
> 0xB8, 0xD8, 0xA9, 0x49, 0x8B, 0x8C, 0xE2, 0x1B,
> 0x01, 0xAE, 0xF2, 0xB7, 0x7F, 0xFF, 0x04, 0x00,
> };
>
> Means MMIO(EfiMemoryMappedIO,
> 0xffcb4000-0xbfff)/PIWGVolume(2B0585EB-D8B8-49A9-8B8CE21B01AEF2B7)
> I can add necessary prototypes and structures
>
>
Deblobing patch attached. Binary is the same (checked)
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'include/grub/efi/api.h'
--- include/grub/efi/api.h 2009-09-03 17:19:59 +
+++ include/grub/efi/api.h 2010-01-04 13:07:45 +
@@ -584,6 +584,16 @@
};
typedef struct grub_efi_protocol_device_path grub_efi_protocol_device_path_t;
+#define GRUB_EFI_PIWG_DEVICE_PATH_SUBTYPE 6
+
+struct grub_efi_piwg_device_path
+{
+ grub_efi_device_path_t header;
+ grub_efi_guid_t guid __attribute__ ((packed));
+};
+typedef struct grub_efi_piwg_device_path grub_efi_piwg_device_path_t;
+
+
/* BIOS Boot Specification Device Path. */
#define GRUB_EFI_BIOS_DEVICE_PATH_TYPE 5
=== modified file 'loader/efi/appleloader.c'
--- loader/efi/appleloader.c 2009-12-25 23:50:59 +
+++ loader/efi/appleloader.c 2010-01-04 13:07:45 +
@@ -59,58 +59,171 @@
return grub_errno;
}
+struct piwg_full_device_path
+{
+ struct grub_efi_memory_mapped_device_path comp1;
+ struct grub_efi_piwg_device_path comp2;
+ struct grub_efi_device_path end;
+};
+
/* early 2006 Core Duo / Core Solo models */
-static grub_uint8_t devpath_1[] =
+static struct piwg_full_device_path devpath_1 =
{
- 0x01, 0x03, 0x18, 0x00, 0x0B, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0xE0, 0xFF, 0x00, 0x00, 0x00, 0x00,
- 0xFF, 0xFF, 0xF9, 0xFF, 0x00, 0x00, 0x00, 0x00,
- 0x04, 0x06, 0x14, 0x00, 0xEB, 0x85, 0x05, 0x2B,
- 0xB8, 0xD8, 0xA9, 0x49, 0x8B, 0x8C, 0xE2, 0x1B,
- 0x01, 0xAE, 0xF2, 0xB7, 0x7F, 0xFF, 0x04, 0x00,
+ .comp1 =
+ {
+.header = {
+ .type = GRUB_EFI_HARDWARE_DEVICE_PATH_TYPE,
+ .subtype = GRUB_EFI_MEMORY_MAPPED_DEVICE_PATH_SUBTYPE,
+ .length = {sizeof (struct grub_efi_memory_mapped_device_path), 0}
+},
+.memory_type = GRUB_EFI_MEMORY_MAPPED_IO,
+.start_address = 0xffe0,
+.end_address = 0xfff9
+ },
+ .comp2 =
+ {
+.header = {
+ .type = GRUB_EFI_MEDIA_DEVICE_PATH_TYPE,
+ .subtype = GRUB_EFI_PIWG_DEVICE_PATH_SUBTYPE,
+ .length = {sizeof (struct grub_efi_piwg_device_path), 0}
+},
+.guid = {0x2B0585EB, 0xD8B8, 0x49A9, {0x8B, 0x8C, 0xE2, 0x1B,
+ 0x01, 0xAE, 0xF2, 0xB7}}
+ },
+ .end =
+ {
+.type = GRUB_EFI_END_DEVICE_PATH_TYPE,
+.subtype = GRUB_EFI_END_ENTIRE_DEVICE_PATH_SUBTYPE,
+.length = {sizeof (struct grub_efi_device_path), 0}
+ }
};
/* mid-2006 Mac Pro (and probably other Core 2 models) */
-static grub_uint8_t devpath_2[] =
+static struct piwg_full_device_path devpath_2 =
{
- 0x01, 0x03, 0x18, 0x00, 0x0B, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0xE0, 0xFF, 0x00, 0x00, 0x00, 0x00,
- 0xFF, 0xFF, 0xF7, 0xFF, 0x00, 0x00, 0x00, 0x00,
- 0x04, 0x06, 0x14, 0x00, 0xEB, 0x85, 0x05, 0x2B,
- 0xB8, 0xD8, 0xA9, 0x49, 0x8B, 0x8C, 0xE2, 0x1B,
- 0x01, 0xAE, 0xF2, 0xB7, 0x7F, 0xFF, 0x04, 0x00,
+ .comp1 =
+ {
+.header = {
+ .type = GRUB_EFI_HARDWARE_DEVICE_PATH_TYPE,
+ .subtype = GRUB_EFI_MEMORY_MAPPED_DEVICE_PATH_SUBTYPE,
+ .length = {sizeof (struct grub_efi_memory_mapped_device_path), 0}
+},
+.memory_type = GRUB_EFI_MEMORY_MAPPED_IO,
+.start_address = 0xffe0,
+.end_address = 0xfff7
+ },
+ .comp2 =
+ {
+.header = {
+ .type = GRUB_EFI_MEDIA_DEVICE_PATH_TYPE,
+ .subtype = GRUB_EFI_PIWG_DEVICE_PATH_SUBTYPE,
+ .length = {sizeof (struct grub_efi_piwg_device_path), 0}
+},
+.guid = {0x2B0585EB, 0xD8B8, 0x49A9, {0x8B, 0x8C, 0xE2, 0x1B,
+ 0x01, 0xAE, 0xF2, 0xB7}}
+ },
+ .end =
+ {
+.type = GRUB_EFI_END_DEVICE_PATH_TYPE,
+.subtype = GRUB_EFI_END_ENTIRE_DEVICE_PATH_SUBTYPE,
+.length = {sizeof (struct grub_efi_device_path), 0}
+ }
};
/* mid-2007 MBP ("Santa Rosa" based models) */
-static grub_uint8_t devpath_3[] =
+static struct piwg_full_device_path devpath_3 =
{
- 0x01, 0x03, 0x18, 0x00, 0x0B, 0x00, 0x00, 0x00,
- 0x00, 0
[RFC] Tagged mbi
Hello. Currently mbi contains a lot of pointers and substructures. It's
has various problems like:
-Unused fields occupy space if any subsequent fields is used.
-Difficult to relocate since it may be spilled all over the memory
-It's unstraightforward to e.g. specify 2 framebuffers
I propose to use tagged MBI. I attach proposed patch for multiboot and
grub2. Patch for grub2 is based on my efiboot branch
The patched branches are available under people/phcoder/mbtag-spec and
people/phcoder/taggedmbi.
The parts for which I haven't defined tagged equivalent yet:
-Symbols
-ROM information table
-Drives table
-APM table
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'include/grub/i386/multiboot.h'
--- include/grub/i386/multiboot.h 2009-12-17 23:59:02 +
+++ include/grub/i386/multiboot.h 2010-01-02 02:04:52 +
@@ -39,4 +39,7 @@
void grub_multiboot_set_bootdev (void);
void grub_multiboot_set_accepts_video (int val);
+void grub_multiboot_set_tagged (int val);
+int grub_multiboot_get_tagged (void);
+
#endif /* ! GRUB_MULTIBOOT_CPU_HEADER */
=== modified file 'include/multiboot.h'
--- include/multiboot.h 2010-01-02 17:50:06 +
+++ include/multiboot.h 2010-01-02 21:06:42 +
@@ -31,8 +31,11 @@
/* This should be in %eax. */
#define MULTIBOOT_BOOTLOADER_MAGIC 0x2BADB002
+/* This should be in %eax. */
+#define MULTIBOOT_BOOTLOADER_MAGIC_TAGGED 0x3BADB002
+
/* The bits in the required part of flags field we don't support. */
-#define MULTIBOOT_UNSUPPORTED 0xfff8
+#define MULTIBOOT_UNSUPPORTED 0xfff0
/* Alignment of multiboot modules. */
#define MULTIBOOT_MOD_ALIGN 0x1000
@@ -51,6 +54,9 @@
/* Must pass video information to OS. */
#define MULTIBOOT_VIDEO_MODE 0x0004
+/* Must pass tagged mbi to OS. */
+#define MULTIBOOT_TAGGED_MBI 0x0008
+
/* This flag indicates the use of the address fields in the header. */
#define MULTIBOOT_AOUT_KLUDGE 0x0001
@@ -254,6 +260,114 @@
};
typedef struct multiboot_mod_list multiboot_module_t;
+struct multiboot_tag
+{
+ multiboot_uint32_t type;
+ multiboot_uint32_t size;
+};
+
+struct multiboot_tag_string
+{
+ multiboot_uint32_t type;
+ multiboot_uint32_t size;
+ char string[0];
+};
+
+struct multiboot_tag_module
+{
+ multiboot_uint32_t type;
+ multiboot_uint32_t size;
+ multiboot_uint32_t mod_start;
+ multiboot_uint32_t mod_end;
+ char cmdline[0];
+};
+
+struct multiboot_tag_basic_meminfo
+{
+ multiboot_uint32_t type;
+ multiboot_uint32_t size;
+ multiboot_uint32_t mem_lower;
+ multiboot_uint32_t mem_upper;
+};
+
+struct multiboot_tag_bootdev
+{
+ multiboot_uint32_t type;
+ multiboot_uint32_t size;
+ multiboot_uint32_t biosdev;
+ multiboot_uint32_t slice;
+ multiboot_uint32_t part;
+};
+
+struct multiboot_tag_mmap
+{
+ multiboot_uint32_t type;
+ multiboot_uint32_t size;
+ struct multiboot_mmap_entry entries[0];
+};
+
+#include
+
+struct multiboot_tag_vbe
+{
+ multiboot_uint32_t type;
+ multiboot_uint32_t size;
+
+ multiboot_uint16_t vbe_mode;
+ multiboot_uint16_t vbe_interface_seg;
+ multiboot_uint16_t vbe_interface_off;
+ multiboot_uint16_t vbe_interface_len;
+
+ struct grub_vbe_info_block vbe_control_info;
+ struct grub_vbe_mode_info_block vbe_mode_info;
+};
+
+struct multiboot_tag_framebuffer_common
+{
+ multiboot_uint32_t type;
+ multiboot_uint32_t size;
+
+ multiboot_uint64_t framebuffer_addr;
+ multiboot_uint32_t framebuffer_pitch;
+ multiboot_uint32_t framebuffer_width;
+ multiboot_uint32_t framebuffer_height;
+ multiboot_uint8_t framebuffer_bpp;
+ multiboot_uint8_t framebuffer_type;
+};
+
+struct multiboot_tag_framebuffer
+{
+ struct multiboot_tag_framebuffer_common common;
+
+ union
+ {
+struct
+{
+ multiboot_uint16_t framebuffer_palette_num_colors;
+ struct multiboot_color framebuffer_palette[0];
+};
+struct
+{
+ multiboot_uint8_t framebuffer_red_field_position;
+ multiboot_uint8_t framebuffer_red_mask_size;
+ multiboot_uint8_t framebuffer_green_field_position;
+ multiboot_uint8_t framebuffer_green_mask_size;
+ multiboot_uint8_t framebuffer_blue_field_position;
+ multiboot_uint8_t framebuffer_blue_mask_size;
+};
+ };
+};
+
+#define MULTIBOOT_TAG_TYPE_END 0
+#define MULTIBOOT_TAG_TYPE_CMDLINE 1
+#define MULTIBOOT_TAG_TYPE_BOOT_LOADER_NAME 2
+#define MULTIBOOT_TAG_TYPE_MODULE3
+#define MULTIBOOT_TAG_TYPE_BASIC_MEMINFO 4
+#define MULTIBOOT_TAG_TYPE_BOOTDEV 5
+#define MULTIBOOT_TAG_TYPE_MMAP 6
+#define MULTIBOOT_TAG_TYPE_VBE 7
+#define MULTIBOOT_TAG_TYPE_FRAMEBUFFER 8
+
#endif /* ! ASM_FILE */
#endif /* ! MULTIBOOT_HEADER */
=== modified file 'loader/i386/multiboot.c'
--- loader/i386/multiboot.c 2010-01-02 17:50:06 +
+++ loader/i386/multiboot.c 2010-01-02 21:57:30 +
@@ -62,7 +62,6 @@
grub_err_t err;
struct grub_relocator32_state state =
{
-
Re: [RFC] Multiboot ammendment: non-VBE video
Robert Millan wrote:
>
>> +.long 0
>> +.long 1024
>> +.long 768
>> +.long 32
>>
>
> Maybe better to use 640x480 instead? Not everyone has a large display.
>
>
It's only a recommended resolution. Bootloader will use a mode it
chooses. Perhaps we should remove recommended mode fields from the spec
altogether or make them somehow optional
>> /* The bits in the required part of flags field we don't support. */
>> -#define MULTIBOOT_UNSUPPORTED 0xfffc
>> +#define MULTIBOOT_UNSUPPORTED 0xfff8
>>
>
> Shouldn't this be 0xeffc ? (0xfffc & ~0x1000)
>
>
AOUT_KLUDGE field is 0x1 and not 0x1000
>> === modified file 'doc/multiboot.texi'
>> --- doc/multiboot.texi 2010-01-01 20:02:24 +
>> +++ doc/multiboot.texi 2010-01-02 16:58:33 +
>> @@ -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.
>>
>
> I agree with changing this, but the phrases seem to contradict each other. If
> the mode exists, what should bootloader do?
>
> I suggest we remove from "If the mode exists..." untill
> "...if available", leaving your "Boot loader may also..." only.
>
>
Actually they were contradicting because "should" means that loader may
choose not to follow the rule
>> @@ -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}
>>
>
> If the EGA option is obsolete/useless, I'd just make it:
>
> Reserved for backward compatibility. Always contains @samp{0}.
>
> and schedule it for removal in next major version.
>
>
It is useful. It allows payload to say: "I'm ok with video mode but
prefer text one"
>> 84 | vbe_interface_off |
>> 86 | vbe_interface_len |
>> +---+
>> +88 | framebuffer_addr |(present if flags[12] is set)
>> +96 | framebuffer_pitch |
>> +100 | framebuffer_width |
>> +104 | framebuffer_height|
>> +108 | framebuffer_bpp |
>> +109 | framebuffer_type |
>> +110-115 | color_info|
>>
>
> Perhaps it would be simpler for us to arrange it so that flags 11 and 12
> can't be used at the same time. We could just say that flag 11 is reserved
> and unused, and then put these declarations in the offset that used to be for
> VBE. IIRC there were no possible sections after VBE, so the Framebuffer
> section size wouldn't be constrained by that.
>
> But if you prefer to keep flag 11 operational, I don't object. I would
> probably object to GRUB implementing it though.
>
>
If payload wants to use VBE it will. I think that providing this
informtion saves payload a trip to real mode. So this way we encourage
saner real-mode-free OS design.
Do you think it would be useful to make flag 12 structure describe EGA
text too? I attach new diff for multiboot.texi. If it's approved it
should be simple to implement in grub2 and example kernel
--
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: [RFC] Multiboot ammendment: non-VBE video
On Sun, Jan 3, 2010 at 10:35 AM, Isaac Dupree
wrote:
> Robert Millan wrote:
>>>
>>> In this case color_info is defined as following:
>>
>> I'd appreciate if a native English speaker confirms this, but I believe
>> this should say "as follows" (same for the other instances of this
>> construct).
>
> "as follows" reads naturally to me, as a native speaker (also checked:
> online dictionaries mention the phrase "as follows" without saying it's
> specific to my area -- northeast U.S. -- so I think it's right to use)
+1 for as follows
>
>>> +...@samp{framebuffer_palette_addr} contains address of array of
>>> @samp{framebuffer_palette_num_colors} following structures:
>>
>> There seems to be some word missing here.
>
> "the following structures"?
> "as follows" would also work well if "structures" isn't an important word to
> keep?
> wait, it's like saying "array of 3 following structures", each of the same
> type. hmm. "@samp{framebuffer_palette_num_colors} structures as follows"?
How about this?
XYZZY contains _the_ address of _an_ array of N structures which follow
>
> -Isaac
>
>
> ___
> 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
GRUB Faq
I've been working on grub.texi and I notice a reference to http://www.gnu.org/software/grub/grub-faq.html. I will change that to grub-2-faq.en.html before I submit it. I think we should come up with a new list of FAQs here and agree on the answers. I'll be glad to format it. The current questions are: Why do you need to rewrite GRUB? What is the status of GRUB 2? I would remove both of these and and start with: I have questions about GRUB2! What operating systems does GRUB2 support? What hardware platforms does GRUB2 support? How does GRUB2 differ from GRUB Legacy (GRUB1)? How do I create a GRUB2 boot floppy? How do I create a GRUB2 boot CD-ROM? How are partitions specified? That seems to be very different from the notation in my operating system... How do I uninstall GRUB2 from my hard disk drive? I installed GRUB, but it just hangs up. What now? --- What others would you suggest? By the way, validator.w3.org says grub-2-faq.en.html has 24 errors, but that cascades errors. I only see 5 errors. I imagine the page is formatted by a standard header + body + standard footer, but there is one html error in the header too: ... alt="image of the Head of a GNU" width="129" height"122" /> height is missing an = sign. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
