Re: Windows,grub and grub2
Hi,
- Original Message
> From: Bean <[EMAIL PROTECTED]>
> To: The development of GRUB 2
> Sent: Tuesday, 23 September, 2008 7:20:49 PM
> Subject: Re: Windows,grub and grub2
>
> On Tue, Sep 23, 2008 at 4:23 PM, Viswesh S wrote:
> >
> >
> >
> >
> > - Original Message
> >> From: Bean
> >> To: The development of GRUB 2
> >> Sent: Monday, 22 September, 2008 9:10:26 AM
> >> Subject: Re: Windows,grub and grub2
> >>
> >> On Tue, Sep 9, 2008 at 2:00 PM, Viswesh S wrote:
> >> > Below is the dump of screen output while chainloading the ntfsnew file.
> >> > ***
> >> > DI=CFF0 SI=07EE BP=1FF0 SP=1FE8 BX= DX= CX= AX=
> >> > CS= SS= DS= ES= FG=0246 IP=7C57
> >> >
> >> > DI=7FF0 SI=07EE BP=1FF0 SP=7BF4 BX=55AA DX= CX= AX=0100 CX=07C0
> >> > DS=07C0 ES= FG=0007 IP=0082
> >> > **
> >> > Could you please let me know the way to disassemble the binary file
> >> > without
> >> > any header.The way in which you decoded the boot record.
> >> >
> >> > Also one more thing to let you know is that,
> >> >
> >> > with the grub-1.96 ( without the chainloader patch of disk->dev->read()
> >> > ) ,
> >> > with windows2003 in partition 1 and linux in partition 3, when we
> chainload,
> >> > if we look at the partition table passed to another bootloader ie
> >> > location
> >> > 0x7be - we can see that it is junk, but the surprising point is that, in
> >> > this case as I have mentioned in my first mail, windows boots up from
> >> > grub2.So it is that the partition table is not required for the
> >> > chainloader
> >> > thing and just the boot record is sufficient
> >>
> >> Hi,
> >>
> >> Oh, sorry for another long delay. I disassemble the file with ida,
> >> which is an amazing tool. I don't know if there is open source
> >> alternative, please let me know if you find one.
> >>
> >> The output from ida is in masm format, I modify it a bit so that it
> >> can be compiled using nasm. Please note that nasm doesn't generate the
> >> same binary file as original one, but you can get an idea what it
> >> does.
> >>
> >> From the output, the program fails at the second int 13 call, int
> >> 13/ah = 48h. Although I notice that DL=0, which is not supposed to
> >> happen. Perhaps you can add a grub_printf in grub_chainloader_boot to
> >> show the value of boot drive:
> >>
> >> static grub_err_t
> >> grub_chainloader_boot (void)
> >> {
> >> grub_printf ("boot_drive=%d\n", boot_drive);
> >> grub_chainloader_real_boot (boot_drive, boot_part_addr);
> >>
> >> /* Never reach here. */
> >> return GRUB_ERR_NONE;
> >> }
> >>
> >> --
> >> Bean
> >>
> >>
> >
> > Hi,
> >
> > The value of boot drive is 0x80.
> >
> > This was the same value in disk->drive also.
>
> Hi,
>
> Interesting, perhaps %dx is changed somewhere. Please try the
> following patch, it dumps the value of %dx just before jumping to the
> boot sector.
>
> --
> Bean
The patch works and now Windows is booting perfectly fine from Grub2.
I will go through the assembly and try to understand what modifications you
have done.So there is a problem in Grub2 code, which needs to be fixed ?
Till this point, I was chainloading grub from Grub2 and then chainloading
Windows2008 from it.
Thanks for the consistent help till this point and for the future also.
Viswesh
Connect with friends all over the world. Get Yahoo! India Messenger at
http://in.messenger.yahoo.com/?wm=n/
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
[RFC] Different keyborad layouts
Hello,
I was thinking how we could have different keyboard layouts and after
have some ideas I sent some emails to Robert about this topic (who had some
better ideas :-) )
Let me to explain here some plan/design. I would like to research on it
after some weeks, but if we need some discussion we could have it before
:-)
(this is the result of some mails with Robert, so I'm copying/pasting and
changing some things, if I'm wrong Robert correct me!)
Plan:
- in term/i386/pc/at_keyboard.c we could have something like this:
static char english_map[] = { x, x, x };
char *map = english_map;
- have a new module with different layouts and variable hook
- when user (or grub.cfg) change some variable (KEY_LAYOUT?), this module would
redefine the term/i386/pc/at_keybord.c char *map to KEY_LAYOUT_map (es_map,
de_map, etc.)
Nowadays at_keyboard.c is not used, I could enable for testing. It seems that
when USB keyboard will be integrated everybody will use at_keyboard.c (or at
least USB and i386-pc)
How it sounds?
It would be very nice for Grub, to have different layouts and localization :-)
Thanks,
--
Carles Pina i EstanyGPG id: 0x17756391
http://pinux.info
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: localization of Grub
Hello, On Sep/28/2008, Robert Millan wrote: > On Fri, Sep 26, 2008 at 02:19:09PM +0200, Carles Pina i Estany wrote: > > > > > > This is wanted but nobody did work on this yet afaik. > > > It would be good if there would be multiple keyboard layouts too I > > > think. > > > > I think that different keyboard layouts it's even more important than > > different languages... > > > > Do we have any plan? Maybe I will take a look (but during 20 days in > > october I will not have lot of time :-( so not sure if I will do it > > after October or not, I will see...) > > > > Any suggestion for the implementation? How user would change the > > keyboard layout? Or maybe at beginning some setting (variable) at > > grub.cfg? > > Hi, > > It's very nice you want to work on localisation. This is a very welcome > feature (and I think it's been discussed before). > > (I assume we're talking about a gettext equivalent rather than keyboard > layouts, which is a separate -but also nice- feature) Yes, I was talking about gettext/equivalent (I will send another email talking about keyboard layouts) > My recommendation for a roadmap (please comment/discuss/challenge/etc!) would > be: > > - gettextise the util tools, so they can be translated as normal > programs. ok! (I guess/hope that will be more "burocratic" work than new work) > - add support to grub (a gettext module or so) so that it can load our .mo > files and obtain strings from it, by implementing gettext() (aka _()). this is the interesting part, I think :-) > I'd also recommend making the user interface similar to posix locales, for > consistency's sake (which you know I hold dearly ;-)). I know! > Even if you only have time/interest to implement the first part, this > is already a significant benefit. Keep in mind that grub.cfg > generation is done by update-grub which happens entirely on userland, > so we get translated menu entries that way. I don't expect to have time until 22th October (aprox.). I have more interest in the second part (it's "newer") than first part, but first part has a practical and fast effects with (I think) less investment. I think that I will do both things, but will take some time. If somebody has time/interest to do it before: please, raise your hand! -- Carles Pina i EstanyGPG id: 0x17756391 http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Warning if grub.cfg not found
Hello,
On Sep/28/2008, Robert Millan wrote:
> On Sat, Sep 27, 2008 at 07:37:52PM +0200, Carles Pina i Estany wrote:
> > --- normal/main.c (revision 1877)
> > +++ normal/main.c (working copy)
> > @@ -230,7 +230,13 @@
> >/* Try to open the config file. */
> >file = grub_file_open (config);
> >if (! file)
> > -return 0;
> > +{
>
> This seems to include the possibility that file cannot be read simply because
> it's not there. Perhaps user intended so, and this shouldn't be reported as
> an error.
Do you mean that we could change:
+ grub_print_error ();
by "grub_print_warning"?
Or the whole point (warn the user if file is not there) is incorrect?
If user doesn't want a grub.cfg, he/she could "touch grub.cfg" and
that's all, no?
If some user is miss-configuring Grub2 (pointing to an invalid device,
partition, etc.) he will prefer to read "cannot find grub.cfg" than just
see a shell (it's quite confusing, or it was for me when it happened :-)
)
--
Carles Pina i EstanyGPG id: 0x17756391
http://pinux.info
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
strange iso9660 bug
Hi, I was having a look at this iso9660 image: http://syllable.info/Syllable-0.6.4-LiveCD-1.1.iso.bz2 and GRUB seems to behave strangely with it. When its contents are listed by Linux, GRUB Legacy or isoinfo, you get a long list (the "real" data), but when they're listed by GRUB 2, you get a short list with only 3 files: - autorun.inf - some *.ico file - readme.txt which are obviously aimed at MS-Windows users. I wonder if someone more knowledgeable than me about iso9660 has a clue on what's going on. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] iso uuid created vs modified
On Sun, Sep 28, 2008 at 02:56:24PM +0200, Robert Millan wrote: > > Hi, > > It seems our ISO UUID code was checking for modified date rather than created > date as the source suggests. I believe this is the right thing to do (since > theoretically two different images could share creation date), so my patch > just renames it (and adds the real field for creation date while at it). Committed (after ack from Felix) -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug-fix elf.c powerpc ieee1275
On Mon, Sep 29, 2008 at 12:42:36AM +1000, peter cros wrote: > Hi, > > There is a bug in /kern/elf.c/ (target powerpc, platform ieee1275), > causing load linux to fail on my powerpc64 g5 and ibook g4 32bit. > > Here is a diff of the fix I found necessary for rev 1878 (bug has existed in > previous versions). > > It was a one liner - > > diff -pu grubsvn/kern grubtry/kern/elf.c > - > --- grubsvn/kern/elf.c2008-09-28 17:27:56.0 +1000 > +++ grubtry/kern/elf.c2008-09-28 23:16:38.0 +1000 > @@ -234,7 +234,7 @@ grub_elf32_load (grub_elf_t _elf, grub_e > > if (load_hook && load_hook (phdr, &load_addr)) >return 1; > -load_addr = phdr->p_paddr; > +/** pxwdebug - not required - load_addr = phdr->p_paddr; **/ Hi, Thanks for pointing this out. Unless someone understands your change, we'd need you to explain why this line isn't necessary, and why it was causing trouble. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Bug-fix elf.c powerpc ieee1275
Hi, There is a bug in /kern/elf.c/ (target powerpc, platform ieee1275), causing load linux to fail on my powerpc64 g5 and ibook g4 32bit. Here is a diff of the fix I found necessary for rev 1878 (bug has existed in previous versions). It was a one liner - diff -pu grubsvn/kern grubtry/kern/elf.c - --- grubsvn/kern/elf.c2008-09-28 17:27:56.0 +1000 +++ grubtry/kern/elf.c2008-09-28 23:16:38.0 +1000 @@ -234,7 +234,7 @@ grub_elf32_load (grub_elf_t _elf, grub_e if (load_hook && load_hook (phdr, &load_addr)) return 1; -load_addr = phdr->p_paddr; +/** pxwdebug - not required - load_addr = phdr->p_paddr; **/ if (load_addr < load_base) load_base = load_addr; @@ -413,8 +413,7 @@ grub_elf64_load (grub_elf_t _elf, grub_e if (load_hook && load_hook (phdr, &load_addr)) return 1; -load_addr = phdr->p_paddr; - +/**pxwdebug - not required - load_addr = phdr->p_paddr; **/ if (load_addr < load_base) load_base = load_addr; - pcros. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] treat multiple slashes like one for JFS
Am Sonntag, den 28.09.2008, 15:32 +0200 schrieb Robert Millan:
> On Thu, Sep 25, 2008 at 05:17:06PM +0200, Felix Zielcke wrote:
> > Here's a patch to handle things like //boot/// for JFS which doestn't do
> > it currently but Linux does it.
> >
> > This was already brought up 2004 but I wonder why this isn't included
> > http://lists.gnu.org/archive/html/grub-devel/2004-08/msg00043.html
> >
> > Probable this can be right now commited but as always I just want to be
> > on the safe side.
>
> Assuming you tested it works, I don't see anything wrong in the code.
Yep I tested it first :)
> > + while (*next == '/')
> > + {
> > + next[0] = '\0';
> > + next++;
> > + }
>
> This seems to incorporate a one-liner of code from Tomas Ebenlendr, I'd
> recommend to mention that in the changelog.
Ok commited with a hint that it's based on code from Tomas Ebenlendr.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: localization of Grub
On Fri, Sep 26, 2008 at 02:19:09PM +0200, Carles Pina i Estany wrote: > > > > This is wanted but nobody did work on this yet afaik. > > It would be good if there would be multiple keyboard layouts too I > > think. > > I think that different keyboard layouts it's even more important than > different languages... > > Do we have any plan? Maybe I will take a look (but during 20 days in > october I will not have lot of time :-( so not sure if I will do it > after October or not, I will see...) > > Any suggestion for the implementation? How user would change the > keyboard layout? Or maybe at beginning some setting (variable) at > grub.cfg? Hi, It's very nice you want to work on localisation. This is a very welcome feature (and I think it's been discussed before). (I assume we're talking about a gettext equivalent rather than keyboard layouts, which is a separate -but also nice- feature) My recommendation for a roadmap (please comment/discuss/challenge/etc!) would be: - gettextise the util tools, so they can be translated as normal programs. - add support to grub (a gettext module or so) so that it can load our .mo files and obtain strings from it, by implementing gettext() (aka _()). I'd also recommend making the user interface similar to posix locales, for consistency's sake (which you know I hold dearly ;-)). Even if you only have time/interest to implement the first part, this is already a significant benefit. Keep in mind that grub.cfg generation is done by update-grub which happens entirely on userland, so we get translated menu entries that way. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] treat multiple slashes like one for JFS
On Thu, Sep 25, 2008 at 05:17:06PM +0200, Felix Zielcke wrote:
> Here's a patch to handle things like //boot/// for JFS which doestn't do
> it currently but Linux does it.
>
> This was already brought up 2004 but I wonder why this isn't included
> http://lists.gnu.org/archive/html/grub-devel/2004-08/msg00043.html
>
> Probable this can be right now commited but as always I just want to be
> on the safe side.
Assuming you tested it works, I don't see anything wrong in the code.
> + while (*next == '/')
> + {
> + next[0] = '\0';
> + next++;
> + }
This seems to incorporate a one-liner of code from Tomas Ebenlendr, I'd
recommend to mention that in the changelog.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Warning if grub.cfg not found
On Sat, Sep 27, 2008 at 07:37:52PM +0200, Carles Pina i Estany wrote:
> --- normal/main.c (revision 1877)
> +++ normal/main.c (working copy)
> @@ -230,7 +230,13 @@
>/* Try to open the config file. */
>file = grub_file_open (config);
>if (! file)
> -return 0;
> +{
This seems to include the possibility that file cannot be read simply because
it's not there. Perhaps user intended so, and this shouldn't be reported as
an error.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] iso uuid created vs modified
Hi,
It seems our ISO UUID code was checking for modified date rather than created
date as the source suggests. I believe this is the right thing to do (since
theoretically two different images could share creation date), so my patch
just renames it (and adds the real field for creation date while at it).
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
Index: fs/iso9660.c
===
--- fs/iso9660.c (revision 1878)
+++ fs/iso9660.c (working copy)
@@ -93,8 +93,9 @@
grub_uint32_t path_table;
grub_uint8_t unused5[12];
struct grub_iso9660_dir rootdir;
- grub_uint8_t unused6[641];
+ grub_uint8_t unused6[624];
struct grub_iso9660_date created;
+ struct grub_iso9660_date modified;
} __attribute__ ((packed));
/* A single entry in the path table. */
@@ -840,14 +841,14 @@
data = grub_iso9660_mount (disk);
if (data)
{
- if (! data->voldesc.created.year[0] && ! data->voldesc.created.year[1]
- && ! data->voldesc.created.year[2] && ! data->voldesc.created.year[3]
- && ! data->voldesc.created.month[0] && ! data->voldesc.created.month[1]
- && ! data->voldesc.created.day[0] && ! data->voldesc.created.day[1]
- && ! data->voldesc.created.hour[0] && ! data->voldesc.created.hour[1]
- && ! data->voldesc.created.minute[0] && ! data->voldesc.created.minute[1]
- && ! data->voldesc.created.second[0] && ! data->voldesc.created.second[1]
- && ! data->voldesc.created.hundredth[0] && ! data->voldesc.created.hundredth[1])
+ if (! data->voldesc.modified.year[0] && ! data->voldesc.modified.year[1]
+ && ! data->voldesc.modified.year[2] && ! data->voldesc.modified.year[3]
+ && ! data->voldesc.modified.month[0] && ! data->voldesc.modified.month[1]
+ && ! data->voldesc.modified.day[0] && ! data->voldesc.modified.day[1]
+ && ! data->voldesc.modified.hour[0] && ! data->voldesc.modified.hour[1]
+ && ! data->voldesc.modified.minute[0] && ! data->voldesc.modified.minute[1]
+ && ! data->voldesc.modified.second[0] && ! data->voldesc.modified.second[1]
+ && ! data->voldesc.modified.hundredth[0] && ! data->voldesc.modified.hundredth[1])
{
grub_error (GRUB_ERR_BAD_NUMBER, "No creation date in filesystem to generate UUID.");
*uuid = NULL;
@@ -856,14 +857,14 @@
{
*uuid = grub_malloc (sizeof ("-MM-DD-HH-mm-ss-hh"));
grub_sprintf (*uuid, "%c%c%c%c-%c%c-%c%c-%c%c-%c%c-%c%c-%c%c",
- data->voldesc.created.year[0], data->voldesc.created.year[1],
- data->voldesc.created.year[2], data->voldesc.created.year[3],
- data->voldesc.created.month[0], data->voldesc.created.month[1],
- data->voldesc.created.day[0], data->voldesc.created.day[1],
- data->voldesc.created.hour[0], data->voldesc.created.hour[1],
- data->voldesc.created.minute[0], data->voldesc.created.minute[1],
- data->voldesc.created.second[0], data->voldesc.created.second[1],
- data->voldesc.created.hundredth[0], data->voldesc.created.hundredth[1]);
+ data->voldesc.modified.year[0], data->voldesc.modified.year[1],
+ data->voldesc.modified.year[2], data->voldesc.modified.year[3],
+ data->voldesc.modified.month[0], data->voldesc.modified.month[1],
+ data->voldesc.modified.day[0], data->voldesc.modified.day[1],
+ data->voldesc.modified.hour[0], data->voldesc.modified.hour[1],
+ data->voldesc.modified.minute[0], data->voldesc.modified.minute[1],
+ data->voldesc.modified.second[0], data->voldesc.modified.second[1],
+ data->voldesc.modified.hundredth[0], data->voldesc.modified.hundredth[1]);
}
}
else
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
