Re: [GITGRUB] New menu interface (implementation)
I don't know what is the testing status for pc machines, but I have grub-install problem for platform pc on Apple with the current menu source. commit eb03e2575b2c0b1b4fd83f33a741f6fef3b93339 Author: Bean Date: Wed Oct 21 01:11:27 2009 +0800 Compiling for grub-pc test of menu on Apple, --wth-platform=pc, I get this stopper in grub-install (after successful make && make install). OS is ubuntu904 on imac81. p...@im:~/src/grub/buildpc$ sudo ./grub-install --no-floppy --force /dev/sda ./grub-install: 312: realpath: not found ( I got the same back from start of the menu tests with git branch master, the change to realpath problem, then I went to efi tests, no problems). I had no problem --with-platform=pc from the new Bazaar mirror bzr branch http://bzr.savannah.gnu.org/r/grub/ which compiles installs and boots grub-pc with no errors . p...@im:~/src/bzr/trunk$ bzr log -l 1 revno: 1768 committer: fzielcke timestamp: Wed 2009-10-21 12:22:05 + message: 2009-10-21 Felix Zielcke --- -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Experimental branch for GRUB
On Thu, Oct 22, 2009 at 05:17:55PM +0800, Bean wrote: > Hi, > > I think it could be beneficial to have a experimental branch for GRUB. > Minor bug fixes can be applied to mainstream directly. But for big and > intrusive changes, such as the new menu system, we can place it in the > experimental branch first. Users interested in the latest fancy > feature can use the experimental branch, while more conservative users > can use mainstream code. When the code in experimental branch become > stable enough, we can integrate it back to the main repository. Sometimes I find myself in need of that too. As you probably noticed, I recently got started with GNU Bazaar (initially as part of my involvement with gNewSense). There's now a Bazaar mirror of GRUB SVN, and I'm beginning to use it to manage my own patchsets. I think it is natural that, since it's part of the GNU system, Bazaar is the first option to be taken into consideration for this task. I think we all agree that while SVN is (and will continue to be) a good consensus solution for managing a trunk, it doesn't excel when it comes to branching. My experience with it is limited, but it seems to be capable of dealing with the workflow you're proposing (branching, resyncing, etc), and I have observed that its UI is quite simple and easy to figure out. Perhaps someone who's more seasoned than me in using Bazaar can provide his/her insight, or perhaps you'd like to play with it (if you haven't already) by branching off the mirror I just finished setting up (see my other mail). -- 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
Sourcing scripts from lua
Hi everyone, Is there a good way to source lua scripts from within lua? I've tried require() but the function doesn't exist. loadfile() and loadstring() exist but always return nil. -- Jordan Uggla ( Jordan_U on irc.freenode.net ) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
bazaar mirror available
Hi, As you may have noticed, a GNU Bazaar mirror of SVN trunk is now available. It can be accessed via: bzr branch http://bzr.savannah.gnu.org/r/grub/trunk bzr branch sftp://@bzr.savannah.gnu.org/srv/bzr/grub/trunk It'll be regularly resynced to latest SVN. -- 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: Feature Request: 32-bit mem write and 'setpci -s' type command in menu.lst
Nando wrote: > Hi everyone, > > I wanted to ask if the following features could be added to grub? > > 1/ Ability to write to 32-bit memory space > === > > I need to set my ICH8M chipset to enable the SMBUS, since the bios > disables it. Rather than add the code to the kernel, I'd prefer to do > it in grub. Grub4dos has such a facility but no such facility in > grub's menu.lst. We don't support grub legacy anymore. Switch to grub2 > None that I found anyway. I need to write to following to have access > ot my ICS PLL to be able to do overclocking: > > write 0xFED93418 0xC330005 look at write_dword > > 2/ Ability to do a setpci -s type command > == > > Also, if possible, could a small subset of 'setpci' be incorporated as > well? I guess I could figure out the address I need to write to by > calculation, but would be nice if I could do the equivalent of the > following in grub, associated with a menu entry. This would help the > DIY ViDock project that needs to setup PCI Bridge windows prior to > Windows load, something that many bios doesn't do, neither does Windows. > > setpci -s 00:02.0 40l=20 > it's not implemented yet but is trivial to do. Would you send us a patch? > Comments?? Suggestions?? > > Nando > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Feature Request: 32-bit mem write and 'setpci -s' type command in menu.lst
Hi everyone, I wanted to ask if the following features could be added to grub? 1/ Ability to write to 32-bit memory space === I need to set my ICH8M chipset to enable the SMBUS, since the bios disables it. Rather than add the code to the kernel, I'd prefer to do it in grub. Grub4dos has such a facility but no such facility in grub's menu.lst. None that I found anyway. I need to write to following to have access ot my ICS PLL to be able to do overclocking: write 0xFED93418 0xC330005 2/ Ability to do a setpci -s type command == Also, if possible, could a small subset of 'setpci' be incorporated as well? I guess I could figure out the address I need to write to by calculation, but would be nice if I could do the equivalent of the following in grub, associated with a menu entry. This would help the DIY ViDock project that needs to setup PCI Bridge windows prior to Windows load, something that many bios doesn't do, neither does Windows. setpci -s 00:02.0 40l=20 Comments?? Suggestions?? Nando ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
On Thu, Oct 22, 2009 at 5:12 PM, rubisher wrote: >> On Thu, Oct 22, 2009 at 12:03 AM, rubisher wrote: >> > Bean wrote: >> >> >> >> On Mon, Oct 12, 2009 at 4:55 PM, Felix Zielcke wrote: >> >>> >> >>> David are you still there? >> >>> And also anyone who has access to a powerpc machine (and experience)? >> >>> >> >>> In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols >> >>> can't be found in the grub-ieee1275 build on powerpc and also sparc. >> >>> >> >>> Jordi already noticed this with the 1.96+20090721-4 IIRC and now other >> >>> people noticed this with 1.97~beta3 >> >>> AFAICS there wasn't anything relevant changed on our side, so seems to >> >>> be a gcc issue. >> >>> >> >>> `__ashldi3' is listed in include/grub/powerpc/libgcc.h and >> >>> `__bswapsi2' >> >>> in the sparc64 header. >> >>> But something has now changed that this isn't enough anymore, at least >> >>> in Debian. >> >>> >> >>> We used gcc 4.3.3 at the time Jordi noticed this and now switched to >> >>> gcc-4.4.1. >> >>> >> >>> And David we still have this sparc bug open, which I forwared to >> >>> grub-devel: >> >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030 >> >> >> >> Hi, >> >> >> >> Try my branch, it includes the libgcc functions in grub instead of >> >> rely on external library. It builds and run properly for >> >> powerpc-ieee1275 last time I check. >> >> >> > Hello Mr bean ;<) >> > >> > I reach to grab your git tree but even a fresh pull still failed to >> > build >> > from src as follow: >> > grub_emu-normal_main.o: In function `uitree_append': >> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined >> > reference to `grub_uitree_root' >> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined >> > reference to `grub_uitree_root' >> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined >> > reference to `grub_uitree_find' >> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:179: undefined >> > reference to `grub_uitree_create_node' >> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:184: undefined >> > reference to `grub_uitree_set_prop' >> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:185: undefined >> > reference to `grub_uitree_set_prop' >> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:186: undefined >> > reference to `grub_tree_add_child' >> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:172: undefined >> > reference to `grub_uitree_create_node' >> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:175: undefined >> > reference to `grub_tree_add_child' >> > collect2: ld returned 1 exit status >> > make[1]: *** [grub-emu] Error 1 >> > make[1]: Leaving directory >> > `/Sources/jso/Grub2.deb/grub2-git091021/build/grub-common' >> > make: *** [build/grub-common] Error 2 >> > dpkg-buildpackage: error: debian/rules build gave error exit status 2 >> > >> > Any idea/advise? >> >> Hi, >> >> I forget to add some file for grub-emu previously, but it's fixed >> already, pull the latest code. >> >> -- >> Bean >> >> gitgrub home: http://github.com/grub/grub/ >> my fork page: http://github.com/bean123/grub/ >> > Sorry I would have to be more accurate: > the git log said: > commit eb03e2575b2c0b1b4fd83f33a741f6fef3b93339 > Author: Bean > Date: Wed Oct 21 01:11:27 2009 +0800 > > Minor bug fix for parameter handling. > > commit 8a3390f0164c89e8ae73884672556a9b31cbd766 > Author: Bean > Date: Tue Oct 20 22:37:32 2009 +0800 > > Support dialog and template, set maximum text mode for EFI. > > Anyway, I remove all and clone it again: > git clone http://github.com/bean123/grub.git > copy this git tree in a working dir then run autogen.sh; mkdir build; cd > build; ../configure; make > which still failed the same way. > > Did i miss something??? Hi, Oh I see, you use the powepc port, I only fix the x86 port. A quick fix is to open conf/powerpc_ieee1275.rmk, find grub_emu_SOURCES and add menu/tree.c and menu/uitree.c. -- Bean gitgrub home: http://github.com/grub/grub/ my fork page: http://github.com/bean123/grub/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Experimental branch for GRUB
Hi, I think it could be beneficial to have a experimental branch for GRUB. Minor bug fixes can be applied to mainstream directly. But for big and intrusive changes, such as the new menu system, we can place it in the experimental branch first. Users interested in the latest fancy feature can use the experimental branch, while more conservative users can use mainstream code. When the code in experimental branch become stable enough, we can integrate it back to the main repository. -- Bean gitgrub home: http://github.com/grub/grub/ my fork page: http://github.com/bean123/grub/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
> On Thu, Oct 22, 2009 at 12:03 AM, rubisher wrote: > > Bean wrote: > >> > >> On Mon, Oct 12, 2009 at 4:55 PM, Felix Zielcke wrote: > >>> > >>> David are you still there? > >>> And also anyone who has access to a powerpc machine (and experience)? > >>> > >>> In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols > >>> can't be found in the grub-ieee1275 build on powerpc and also sparc. > >>> > >>> Jordi already noticed this with the 1.96+20090721-4 IIRC and now other > >>> people noticed this with 1.97~beta3 > >>> AFAICS there wasn't anything relevant changed on our side, so seems to > >>> be a gcc issue. > >>> > >>> `__ashldi3' is listed in include/grub/powerpc/libgcc.h and `__bswapsi2' > >>> in the sparc64 header. > >>> But something has now changed that this isn't enough anymore, at least > >>> in Debian. > >>> > >>> We used gcc 4.3.3 at the time Jordi noticed this and now switched to > >>> gcc-4.4.1. > >>> > >>> And David we still have this sparc bug open, which I forwared to > >>> grub-devel: > >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030 > >> > >> Hi, > >> > >> Try my branch, it includes the libgcc functions in grub instead of > >> rely on external library. It builds and run properly for > >> powerpc-ieee1275 last time I check. > >> > > Hello Mr bean ;<) > > > > I reach to grab your git tree but even a fresh pull still failed to build > > from src as follow: > > grub_emu-normal_main.o: In function `uitree_append': > > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined > > reference to `grub_uitree_root' > > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined > > reference to `grub_uitree_root' > > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined > > reference to `grub_uitree_find' > > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:179: undefined > > reference to `grub_uitree_create_node' > > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:184: undefined > > reference to `grub_uitree_set_prop' > > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:185: undefined > > reference to `grub_uitree_set_prop' > > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:186: undefined > > reference to `grub_tree_add_child' > > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:172: undefined > > reference to `grub_uitree_create_node' > > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:175: undefined > > reference to `grub_tree_add_child' > > collect2: ld returned 1 exit status > > make[1]: *** [grub-emu] Error 1 > > make[1]: Leaving directory > > `/Sources/jso/Grub2.deb/grub2-git091021/build/grub-common' > > make: *** [build/grub-common] Error 2 > > dpkg-buildpackage: error: debian/rules build gave error exit status 2 > > > > Any idea/advise? > > Hi, > > I forget to add some file for grub-emu previously, but it's fixed > already, pull the latest code. > > -- > Bean > > gitgrub home: http://github.com/grub/grub/ > my fork page: http://github.com/bean123/grub/ > Sorry I would have to be more accurate: the git log said: commit eb03e2575b2c0b1b4fd83f33a741f6fef3b93339 Author: Bean Date: Wed Oct 21 01:11:27 2009 +0800 Minor bug fix for parameter handling. commit 8a3390f0164c89e8ae73884672556a9b31cbd766 Author: Bean Date: Tue Oct 20 22:37:32 2009 +0800 Support dialog and template, set maximum text mode for EFI. Anyway, I remove all and clone it again: git clone http://github.com/bean123/grub.git copy this git tree in a working dir then run autogen.sh; mkdir build; cd build; ../configure; make which still failed the same way. Did i miss something??? Tx again, J. _ Scarlet Mobile, free subscription in combination with your Scarlet One or ADSL, visit http://www.scarlet.be/fr/mobile3g ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
On Thu, Oct 22, 2009 at 3:41 PM, Michal Suchanek wrote: >> Here, function means C function. In config file, all configurable >> command is grub command, no command is specific to certain widget. >> Widget have a onkey callback function which gives it the chance to >> handle the current key press, if it doesn't handle it, it would be >> passed to system. > > if it's handled by the widget it must be a function specific to a > widget, otherwise it would not be handled by a widget but do something > global, even in widget's onkey. > Hi, Yep, this is how it's handled now, if the widget doesn't interested in the key, it return a value of SKIP and the global key mapping is checked. >> >> So, you can use mapkey to map a key to the one interested by the >> widget. For example, edit control use ctrl-x key to indicate the >> finish of edit. If ctrl-x can't be input, you map F5 to it so that you >> can finish the edit. >> >> This is similar to the vim style of key handling, that's, each key >> defines a specific function. I guess it's possible to use emacs style, >> where each function is named with string. But I think that system is a >> little overkill, you need to bind every function to some key before >> you have a working system, while the current method works out of the >> box, you just change the mapping you need. > > I think that naming the function is the first step to writing out the > mapping in a user readable form so that it can be automatically > included in help texts. > > Having the functions named does not mean that grub cannot include a > default map. It just means that the functions mapped by default and > not yet mapped are equal, and they can be mapped and remapped in the > configuration the same way. > > Binding functions to key names sucks. Not all keyboards have the same > labels and some people might want to use different input, etc. > I understand that named method is better than using keys directly. But the current method works and it's simpler to implement. There are other area that needs more attention at the moment, so it's not a priority to change it now. >> c open a terminal window, e open a edit box to edit the current >> command, use ctrl-x to save it. f7 runs the layout demo test, f8 >> toggle between text and graphic mode, f9 shutdown, f10 reboot. >> >> Data binding for popup windows, for example, in the above example, >> >> menu_popup edit_window edit.text=command >> >> property text in the edit widget in the popup dialog binds to the >> command property of current node, this is used to implement the edit >> function. >> >> Add two property attach_hcenter and attach_vcenter for layout manager. > > What is the actual use case for windows which are not managed in the > layout and thus potentially overlap other windows in a system where > window overlapping is not handled? Popup window. For example, the e hotkey popup a edit box to edit current command. The top window of popup is placed in screen directly and not controlled by layout manger. >>> >>> In gfxterm the edit box is fullscreen and some lines still wrap for me >>> so I think it is the right way to handle these edits. They should get >>> as much space as possible, there can be (and typically is) quite a bit >>> of text. >>> >>> You can add the title of the edited item as a label at the top of the >>> edit screen perhaps. >>> >> >> I'm not sure showing a edit with only one or two lines full screen >> have the best look, especially when screen is very large. Although you >> can certainly config it that way. The choice is in the theme writer. > > You can't know how much text the editor will have. However, there's no > reason to clutter the screen with other unusable elements. I would > rather include the list of keys that can be used in the editor if you > feel the edit screen is too empty. > > Also I would like a way to easily scale the layout so that it is the > same size regardless of screen resolution. That is, if I have a > 1600x1200 screen and a layout designed for 640x480 it might be useful > to just scale it to fit the on screen. > You can't scale fonts, for other element, you just use the percentage notion and it will scale according to the screen size. > > Yes, a menu can be larger than the screen even when it is displayed > fullscreen. > > The problem is that displaying a large menu that does not fit next to > its parent menu makes the scrolling confusing. Scrolling is typically > not present on these kinds of menus. The other problem is that the > place covered by the parent is what the menu would require to fit > fully on screen which is ineffective. You cannot use the parent menu > while in the sublemenu but it uses screen space. The point of displaying the parent menu is to provide navigation clues to the current location. If the tree level is deep, users can get lost pretty quickly if all menu looks the same. By displ
Re: using GRUB with FreeBSD gmirror
Brian R. Jones wrote: > I'm trying to get GRUB1.97~beta4 working with FreeBSD 8.0 RC1 amd64 > and gmirror, but I'm not sure the correct way to to a kernel module. > I'm guessing something like: > > freebsd_module=/boot/kernel/geom_mirror.ko type=??? > > or > > freebsd_module_elf=/boot/kernel/geom_mirror.ko It's freebsd_module_elf /boot/kernel/geom_mirror.ko (no '=') but since grub2 has no module dependency tracking you'll have to explicitly load any dependencies as well > > I'll probably have tried both of these before I get a response to this > email, but what would be really useful is if someone could give me a > clue as to where to look in the source for freebsd_whatever, as I have > had no luck so far finding it. > > > and yes, I'll switch to beta5 and kfreebsd_whatever as soon as I get > it working. > > -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
2009/10/22 Bean :
> On Thu, Oct 22, 2009 at 4:47 AM, Michal Suchanek wrote:
>> 2009/10/21 Bean :
>>> On Wed, Oct 21, 2009 at 3:20 AM, Michal Suchanek
>>> wrote:
2009/10/18 Bean :
> Hi,
>
> Update:
>
> Add mapkey section. For example:
>
> mapkey {
> f5 = ctrl-x
> }
Does this also generate a mapkey text which you can dump into a text
box so that people know what is mapped to what (and the same for the
default bindings and grub version/last git commit)?
Wouldn't it be more practical and transparent to just make the
mappings configurable?
That is write the current mappings as key->function assignments and
then allow change mappings / add new mappings.
>
> maps f5 key to ctrl-x, this is important for platforms like EFI as
> ctrl-x can't be input.
>
> key name should be lowercase, it can be single character, f1 to f10,
> ctrl-a to ctrl-z, left, right, up, down, home, end, delete, page_up,
> page_down, esc, tab, backspace and space.
>
> Add onkey section, which allow you to assign a function when a key is
> pressed. For example ,this is the onkey section for the demo:
>
> onkey {
> c = "menu_popup term_window"
> e = "menu_popup edit_window edit.text=command"
> f7 = "menu_popup layout_test"
> f8 = menu_toggle_mode
> f9 = halt
> f10 = reboot
> }
This should be merged with the mapkey into a single key mapping function.
>>>
>>> Hi,
>>>
>>> The difference of mapkey and onkey is when they're executed. The order
>>> is as follows:
>>>
>>> mapkey
>>> onkey function of current widget
>>> key binding in onkey section
>>>
>>> For example in the edit widget, you use ctrl-x to finish current edit.
>>> But in EFI, you can't input ctrl-x. The way to solve this is to map
>>> another key as ctrl-x, which use mapkey function. Adding function in
>>> onkey doesn't help, as by the time it reaches there, the edit widget
>>> has finish handling.
>>>
>>> Also, if the key is used by widget, the binding in onkey doesn't help.
>>> This is actually a good thing, for example, we can add hotkey c to
>>> open a terminal window. This has effect on main menu, but we certainly
>>> don't want it when inside term already. But if we do need to change a
>>> key used by widget, we can map it in mapkey section.
>>
>> Why do you need a separate mapping?
>>
>> The widget either handles the key or not, and it should pass it to its
>> parent if it does not handle it.
>>
>> The function in question is either a widget specific function or not
>> so you know where it should be processed.
>>
>> I am not sure what is the difference in mapkey and "onkey in current widget".
>>
>
> Hi,
>
> Here, function means C function. In config file, all configurable
> command is grub command, no command is specific to certain widget.
> Widget have a onkey callback function which gives it the chance to
> handle the current key press, if it doesn't handle it, it would be
> passed to system.
if it's handled by the widget it must be a function specific to a
widget, otherwise it would not be handled by a widget but do something
global, even in widget's onkey.
>
> So, you can use mapkey to map a key to the one interested by the
> widget. For example, edit control use ctrl-x key to indicate the
> finish of edit. If ctrl-x can't be input, you map F5 to it so that you
> can finish the edit.
>
> This is similar to the vim style of key handling, that's, each key
> defines a specific function. I guess it's possible to use emacs style,
> where each function is named with string. But I think that system is a
> little overkill, you need to bind every function to some key before
> you have a working system, while the current method works out of the
> box, you just change the mapping you need.
I think that naming the function is the first step to writing out the
mapping in a user readable form so that it can be automatically
included in help texts.
Having the functions named does not mean that grub cannot include a
default map. It just means that the functions mapped by default and
not yet mapped are equal, and they can be mapped and remapped in the
configuration the same way.
Binding functions to key names sucks. Not all keyboards have the same
labels and some people might want to use different input, etc.
>
>
> c open a terminal window, e open a edit box to edit the current
> command, use ctrl-x to save it. f7 runs the layout demo test, f8
> toggle between text and graphic mode, f9 shutdown, f10 reboot.
>
> Data binding for popup windows, for example, in the above example,
>
> menu_popup edit_window edit.text=command
>
> property text in the edit widget in the popup dialog binds to the
> command property of current node, this is used to implement the edit
> function.
>
> Add two property attach_hcenter and attach_vcenter for layout man
IP addresses from PXE into grub2 enviroment
Greetings, I don't care about your academical and also pointless discussions. I only care for working solution, because in current state there is no way in GRUB2 how to get IP address of the machine and the server from PXE to GRUBs environment. Our solution in the one which is less invasive in current code. I don't care about which solution you are going to use, but do something to move forward. Best regards Aleš Kapica -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
