idea for storing menu.lst with 1_5 stage or equivalent on grub2
This is a idea for making installations of Grub safer. It is based on Grub Legacy but I think you will find an equivalent on grub2. Most people ask about grub showing grub> and not knowing what do to do when that happens. (Usually when they remove Linux from pc). If I understand it correctly that means that 1_5 stage has been loaded but it does not have found /boot/grub/menu.lst because it does not exist. My idea is that when embedd 1_5 stage we should also add a configuration file with the following contents: timeout 0 default 0 title correct install configfile /boot/grub/menu.lst HERE GOES CONTENTS of /boot/grub/menu.lst from the first title. This way if the file /boot/grub/menu.lst is there it is loaded but if it does not exists its backup is loaded. So... everyone is happy. adrian15 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Fte-devel] unicode support
Vesa Jääskeläinen <[EMAIL PROTECTED]> writes: > Timo Sirainen wrote: [...] >> I don't think it's such a good idea to start moving to C++ strings or >> wxWindows or any of that yet. Those would be pretty huge changes and I >> fear they would just never get finished. [...] > The problem here is that you can't change only one component, you have > to change them all if you want to test it out. So braking it to smaller > components was my idea on previous mails. But if you are also willing to > work on this it would be nice. I can manage the Win32 specific console > code, but we need people for other areas. And that UTF-8 is not the only > target formatting we need to think about. Ehm, I assume you posted this on the wrong list? Or is there anything relevant for us in this email? -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: idea for storing menu.lst with 1_5 stage or equivalent on grub2
adrian15 <[EMAIL PROTECTED]> writes: > My idea is that when embedd 1_5 stage we should also add a > configuration file with the following contents: > > timeout 0 > default 0 > title correct install > configfile /boot/grub/menu.lst > HERE GOES CONTENTS of /boot/grub/menu.lst > from the first title. When grub.cfg can not be loaded because it is removed, it most likely is not possible to load normal.mod. So because of this your idea can not be realized in practise. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Boot an ISO on an external/internal HD partition.
On Sun, Feb 19, 2006 at 11:58:27AM +1030, Phil wrote: >* A developer is building a bootable CD and wants to test it before > wasting a disk s/he could put Boot.ISO in the root of this partition > and have Grub boot it like a normail CD. Developers usually use a virtual machine like bochs or qemu for this. Leslie -- gpg --keyserver pgp.mit.edu --recv-keys 0x52D70289 http://nic-nac-project.de/~skypher/ pgpJaKHesIQCc.pgp Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Fte-devel] unicode support
Marco Gerards wrote: > Vesa Jääskeläinen <[EMAIL PROTECTED]> writes: > >> Timo Sirainen wrote: > > [...] > >>> I don't think it's such a good idea to start moving to C++ strings or >>> wxWindows or any of that yet. Those would be pretty huge changes and I >>> fear they would just never get finished. > > [...] > >> The problem here is that you can't change only one component, you have >> to change them all if you want to test it out. So braking it to smaller >> components was my idea on previous mails. But if you are also willing to >> work on this it would be nice. I can manage the Win32 specific console >> code, but we need people for other areas. And that UTF-8 is not the only >> target formatting we need to think about. > > Ehm, I assume you posted this on the wrong list? Or is there anything > relevant for us in this email? umh. no :) Sorry. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Terminal interface and how it should be used?
Hi, I have made some progress with video subsystem and currently the font manager is slowing down (we need to cache fonts) and there are some issues with grub_term. I am not sure if all parts of the code use it correctly or then I am just understanding it differently. After those issues are solved I think we could start to migrate this code back to tree. Here are selected features that might need more information in order to get correct results. /* Put a character. C is encoded in Unicode. */ void (*putchar) (grub_uint32_t c); Should putchar() instantly show results of the operation? Or after calling refresh(). /* Go to the position (X, Y). */ void (*gotoxy) (grub_uint8_t x, grub_uint8_t y); Should gotoxy() instantly move cursor to specified location and if output is not yet drawn, should it be drawn at this point. /* Clear the screen. */ void (*cls) (void); Should screen be cleared instantly? Or should it be after refresh(). /* Set the current color to be used */ void (*setcolorstate) (grub_term_color_state state); /* Set the normal color and the highlight color. The format of each color is VGA's. */ void (*setcolor) (grub_uint8_t normal_color, grub_uint8_t highlight_color); And what exactly should these two be doing ? :).. setcolorstate and setcolor. I can imagine that it changes color, but to what. Should this be changed to some kinda theming system. Or should I just assume that those are palette indexes and in RGB modes, use emulated RGB palette? /* Update the screen. */ void (*refresh) (void); This one is a trickier, should it cause redraw to be done to whole screen, or to render actions in queue. I am asking this because it would look like it is being used to render actions in queue. If I code it to render whole screen, we get nice flickering as screen is being rendered multiple times for nothing. (I am not interested at this point to optimize video drawing as I want to have solid terminal interface first) If I remove some extra refreshes terminal works quite nicely, but then it might not be semantically correct usage. Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
