Re: powerpc/sparc problems

[Bean]

On Sat, Oct 24, 2009 at 4:34 AM, rubisher rubis...@scarlet.be wrote:
 Bean wrote:

 On Thu, Oct 22, 2009 at 5:12 PM, rubisher rubis...@scarlet.be 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 bean12...@gmail.com
 Date:   Wed Oct 21 01:11:27 2009 +0800

    Minor bug fix for parameter handling.

 commit 8a3390f0164c89e8ae73884672556a9b31cbd766
 Author: Bean bean12...@gmail.com
 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.


 Thanks that's help to continue and to finish the build but failed to assemle
 the image:
 /usr/bin/grub-mkelfimage --directory=/usr/lib/grub/powerpc-ieee1275
 --output=/boot/grub/grub fat part_msdos
 grub-mkimage: error: unresolved symbol _savegpr_29

 But if I manage to rebuild it with -O0 (or -O2), I reach to boot it ;-).
 But I guess there isn't enough module loaded because at grub prompt, it
 didn't find any disk?

 That said by default the dpkg build the kern.img as follow:

 # /usr/bin/grub-mkelfimage --directory=/usr/lib/grub/powerpc-ieee1275
 --output=/boot/grub/grub fat part_msdos

 and create for me a grub.cfg with severall menuentries like:
 ### BEGIN /etc/grub.d/10_linux ###
 menuentry Debian GNU/Linux, with Linux 2.6.30-2-powerpc64 {
        insmod ext2
        set root=(hd1,3)
        search --no-floppy --fs-uuid --set
 16ef0754-c845-46e9-a948-b9669ee68329
        linux   /vmlinux-2.6.30-2-powerpc64
 root=UUID=3c51c43e-63a7-4ff1-9b1c-cf98addcb7ed ro  quiet
        initrd  /initrd.img-2.6.30-2-powerpc64
 }

 Given those 2 elements, I presume that the fact grub2 isn't able to find any
 disk is because it lakes of one or more module either in the build image or
 in menuentry (I just started with grub2 2 weeks 

Re: [GITGRUB] New menu interface (implementation)

[Peter Cros]

I can use grub-mkrescue to create an El Torito image and burn CD which boots
and can run menu. Is that what you mean, or is there a way to boot  direct
from iso?

Thanks

On Fri, Oct 23, 2009 at 6:31 PM, Bean bean12...@gmail.com wrote:

 On Fri, Oct 23, 2009 at 1:59 PM, Peter Cros pxwp...@gmail.com wrote:
  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 bean12...@gmail.com
  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 .

 Hi,

 My menu patch haven't synced with latest svn yet, perhaps it's some
 bug fixed after my last sync. Anyway, I always create iso image when
 testing pc mode, so it's possible that there is issue in grub-install
 and I don't even noticed.

 --
 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




-- 
Cros (pxw)
___
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]

Hi Vlad,

 able to do the equivalent of setpci by calculating the addresses
  needing memory writes.

Except pciconf space


Are you saying that write_dword will not write to pciconf space?


 
  write_dump ADDRESS FILE
  eg: write_dump 0xF800  dump_file
 
 This has already been discussed and conclusion that it's too dangerous
 to write to FS from grub2. If it's one time operation you can just boot
 FreeDOS for it. IF it's not explain why do you need it on every boot


I've like *read* a dump file into pciexbar memory space to overcome my wifi
whitelisting. Currently doing this via a grub2 DOS Image entry explained at
http://www.wimsbios.com/phpBB2/topic9388-135.html#53650 . To have such an
ability would mean I could just add another menuitem Ubunto [reverse
whitelisting] and bypass the need for the DOS bootimage. This ability would
be further enhanced if a compressed dump file could be used to speed up the
process.

So I guess it should be a request for:

- 'read_dump ADDRESS FILE' for mPCIe wifi whitelsting could be done within
grub2. .
- a 'setpci' type command  to do pci-e pci-port bridge window fixups,
amongst other things.

Nando
___
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

[Vladimir 'phcoder' Serbinenko]

Nando wrote:
 Hi Vlad,

  able to do the equivalent of setpci by calculating the addresses
  needing memory writes.

 Except pciconf space


 Are you saying that write_dword will not write to pciconf space? 
pciconf space on x86 is acessible through inw/outw and not through memory
  

 
  write_dump ADDRESS FILE
  eg: write_dump 0xF800  dump_file
 
 This has already been discussed and conclusion that it's too dangerous
 to write to FS from grub2. If it's one time operation you can just
 boot
 FreeDOS for it. IF it's not explain why do you need it on every boot


 I've like *read* a dump file into pciexbar memory space to overcome my
 wifi whitelisting. Currently doing this via a grub2 DOS Image entry
 explained at http://www.wimsbios.com/phpBB2/topic9388-135.html#53650 .
 To have such an ability would mean I could just add another menuitem
 Ubunto [reverse whitelisting] and bypass the need for the DOS
 bootimage. This ability would be further enhanced if a compressed dump
 file could be used to speed up the process.

 So I guess it should be a request for:

 - 'read_dump ADDRESS FILE' for mPCIe wifi whitelsting could be done
 within grub2. .
 - a 'setpci' type command  to do pci-e pci-port bridge window fixups,
 amongst other things.

Then I'm ok with it but this link doesn't provide technical info on how
it was done. It looks a bit like it's changing acpi tables, if it's the
case grub2 is already able to do this with 'acpi' command. What are
first bytes of dump?
 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

Re: Feature Request: 32-bit mem write and 'setpci -s' type command in menu.lst

[Bean]

On Sat, Oct 24, 2009 at 4:42 PM, Nando nando4...@gmail.com wrote:
 Hi Vlad,

  able to do the equivalent of setpci by calculating the addresses
  needing memory writes.

 Except pciconf space

 Are you saying that write_dword will not write to pciconf space?

Hi,

write_dword can write to MMIO space. In fact, my initial reason to add
this command is to adjust the video card gart address for EFI.

-- 
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: Macbook, Efi, Display mode

[Stefan Bienert]

Hi again,

 Hi,
 
 I have compiled a binary version and uploaded at ubuntu forum:
 
 http://ubuntuforums.org/showthread.php?t=1248647

So, I've tried that binary: Now the menu, while it is still text based,
takes the whole screen, which is an improvement.

But I still have no output while booting. As far as I understand, this
would be the kernel side of the whole process. Hence, could it be that I
did not configure it in the right way?

greetings,

bienchen



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Macbook, Efi, Display mode

[Bean]

On Sat, Oct 24, 2009 at 6:09 PM, Stefan Bienert
bien...@zbh.uni-hamburg.de wrote:
 Hi again,

 Hi,

 I have compiled a binary version and uploaded at ubuntu forum:

 http://ubuntuforums.org/showthread.php?t=1248647

 So, I've tried that binary: Now the menu, while it is still text based,
 takes the whole screen, which is an improvement.

Hi,

Is graphic mode working ok in grub ?


 But I still have no output while booting. As far as I understand, this
 would be the kernel side of the whole process. Hence, could it be that I
 did not configure it in the right way?

What's the command line option to boot kernel ? In theory, if graphic
mode is working in grub, it should be ok in linux.

-- 
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: Macbook, Efi, Display mode

[Stefan Bienert]

Bean wrote:
 On Sat, Oct 24, 2009 at 6:09 PM, Stefan Bienert
 bien...@zbh.uni-hamburg.de wrote:
 Hi again,

 Hi,

 I have compiled a binary version and uploaded at ubuntu forum:

 http://ubuntuforums.org/showthread.php?t=1248647
 So, I've tried that binary: Now the menu, while it is still text based,
 takes the whole screen, which is an improvement.
 
 Hi,
 
 Is graphic mode working ok in grub ?

Sorry for this probably dull question: How do I know?

 But I still have no output while booting. As far as I understand, this
 would be the kernel side of the whole process. Hence, could it be that I
 did not configure it in the right way?
 
 What's the command line option to boot kernel ?

linux /boot/kernel-2.6.27-gentoo-r8-n root=/dev/sda4 video=efifb noefi
acpi=force

 In theory, if graphic
 mode is working in grub, it should be ok in linux.

Oh, I saw on some web page, that I need soemthing like 'EFI based
framebuffer support' in the kernel.

greetings,

Stefan


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Macbook, Efi, Display mode

[Bean]

On Sat, Oct 24, 2009 at 6:30 PM, Stefan Bienert
bien...@zbh.uni-hamburg.de wrote:
 Bean wrote:
 On Sat, Oct 24, 2009 at 6:09 PM, Stefan Bienert
 bien...@zbh.uni-hamburg.de wrote:
 Hi again,

 Hi,

 I have compiled a binary version and uploaded at ubuntu forum:

 http://ubuntuforums.org/showthread.php?t=1248647
 So, I've tried that binary: Now the menu, while it is still text based,
 takes the whole screen, which is an improvement.

 Hi,

 Is graphic mode working ok in grub ?

 Sorry for this probably dull question: How do I know?


Hi,

The easier way is to use my new menu test demo, download resource file at:

http://grub4dos.sourceforge.net/menu.zip

Unzip to the boot partition, you should see many files under /menu/ directory.

Then you just need to add this line at the end of grub.cfg:

source /menu/menu_efi.cfg

It'd boot into graphic mode by default, you can use F8 to switch
between text and graphic mode.

 But I still have no output while booting. As far as I understand, this
 would be the kernel side of the whole process. Hence, could it be that I
 did not configure it in the right way?

 What's the command line option to boot kernel ?

 linux /boot/kernel-2.6.27-gentoo-r8-n root=/dev/sda4 video=efifb noefi
 acpi=force

 In theory, if graphic
 mode is working in grub, it should be ok in linux.

 Oh, I saw on some web page, that I need soemthing like 'EFI based
 framebuffer support' in the kernel.

Yep, you need that, debian will enable it by default, I don't know
about gentoo thought.

-- 
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: Feature Request: 32-bit mem write and 'setpci -s' type command in menu.lst

[Seth Goldberg]

Quoting Vladimir 'phcoder' Serbinenko, who wrote the following on Sat, 24...:


Nando wrote:

Hi Vlad,

able to do the equivalent of setpci by calculating the addresses
needing memory writes.

Except pciconf space


Are you saying that write_dword will not write to pciconf space?

pciconf space on x86 is acessible through inw/outw and not through memory


 All modern systems equipped with PCI Express support memory-mapped config 
space access.  If we do implement a pciconf command, it should support 
accessing extended config space as well, via the MMCFG region (we'll need to 
look up the base address of such a region in the ACPI MCFG table).


 --S


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Macbook, Efi, Display mode

[Stefan Bienert]

 Hi,
 
 The easier way is to use my new menu test demo, download resource file at:
 
 http://grub4dos.sourceforge.net/menu.zip
 
 Unzip to the boot partition, you should see many files under /menu/ directory.
 
 Then you just need to add this line at the end of grub.cfg:
 
 source /menu/menu_efi.cfg
 
 It'd boot into graphic mode by default, you can use F8 to switch
 between text and graphic mode.

Nope, does not work. I still have text mode.

greetings,

Stefan


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: bazaar mirror available

[Robert Millan]

On Fri, Oct 23, 2009 at 04:40:06PM +0200, Vladimir 'phcoder' Serbinenko wrote:
 What's preventing of using it as a main repository? This should allow
 easy resync

Historically, it's been very hard for us to reach consensus on which revision
control system to use.  When we settled on SVN, it happened because we were
all fed up with CVS, not because it completely satisfied everyone.  In fact,
it was Bean who proposed it, even if he used GIT himself at the time!

Other developers were unsatisfied with this decision, but chose not to object
to it just so we could get rid of CVS.

Since a very wide consensus was reached, and it was so hard to archieve it,
I'm very reluctant to push for Bazaar as our trunk repository unless everyone
agrees this is what we want.

Personally, I prefer if we did this switch, but I also think SVN does a good
job at managing a trunk.  I don't mind living with it for the time being.

When I feel something is important, I don't hesitate to use my authority as
maintainer, but in this case I don't consider it necessary.  That said, if
I see consensus that we should switch to Bazaar as main repository, I won't
be the one to stop 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.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Experimental branch for GRUB

[Robert Millan]

On Fri, Oct 23, 2009 at 03:08:37PM +0100, Colin Watson wrote:
 On Fri, Oct 23, 2009 at 03:45:28PM +0200, Robert Millan wrote:
  
  I think building deb from snapshots of this experimental branch is a good
  idea, and it can be done in any place you see fit, BUT if a proprietary
  solution is used, the GNU project can't endorse those (e.g. we wouldn't
  link to them).  I haven't followed the latest developments on which parts
  of Launchpad have been liberated.
 
 Launchpad is entirely free software now (contrary to an earlier plan you
 may have heard of which involved holding back a couple of components;
 that plan was later discarded). I haven't thought much about whether it
 would be actively better for GRUB development, but I don't think there's
 an ideological reason preventing it nowadays.

Thank you Colin for clarifiing this.  Then I have no objection with endorsing
binary packages built with this service.

(A different question is whether we would consider them official; but this
depends on whether they originate from an official source tree, not on which
facility was used to build them)

 I'd be overjoyed to make use of Bazaar for GRUB development; I use it
 for as many Ubuntu projects as possible, and these days for most of my
 personal projects too since it generally does a good job of not getting
 in my way. It would be easiest to do so if the Debian source package
 were maintained in it too, as a straightforward branch of the
 appropriate upstream revision; that way, it would be possible to simply
 'bzr merge' changes.

Slightly off-topic, but let's ignore that just this time ;-)

Speaking as Debian maintainer, I have no objection to it.  However, Felix
would have to agree as well.  I'm fine with staying with SVN in the Debian
package too.

-- 
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

Experimental branch of GRUB

[Robert Millan]

Hi,

An experimental branch of GNU GRUB is now available:

  # readonly access
  bzr branch http://bzr.savannah.gnu.org/r/grub/branches/experimental/

  # member access
  bzr branch 
sftp://username@bzr.savannah.gnu.org/srv/bzr/grub/branches/experimental

The purpose of this branch is to serve as staging area so that new code can
be tested and collaboratively maintained when we expect that it will be
eventually merged into trunk, but it is not yet ready for this (e.g. too
inmature or wrong time in the development cycle).

I'm appointing Vladimir Serbinenko as the developer in charge of this branch.
Patches may be merged in it at his discretion.

-- 
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.


signature.asc
Description: Digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Experimental branch for GRUB

[Robert Millan]

On Fri, Oct 23, 2009 at 04:35:32PM +0200, Vladimir 'phcoder' Serbinenko wrote:
 
 I also propose to have some kind of version string which would identify
 from which experimental branch the grub was compiled and putting a
 warning at the end of configure script so users would exercise
 additional care

Sounds good (both things).

-- 
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

Personal branches in Bazaar repository

[Robert Millan]

Now that I have a bit more time, I explain about my own GRUB branches.  They
live in:

  http://bzr.savannah.gnu.org/r/grub/people/robertmh

and consist of a few pieces of unfinished work I used to have scattered around
my filesystem.

If others find it convenient to host their own branches at Savannah, they
may do that with e.g.

  username=foo

  bzr branch sftp://${userna...@bzr.savannah.gnu.org/srv/bzr/grub/trunk/
  # hack
  bzr commit
  bzr push --remember 
sftp://${userna...@bzr.savannah.gnu.org/srv/bzr/grub/people/${username}

If they prefer a Subversion-like workflow (i.e. commit implies push), they can
checkout the branch afterwards:

  bzr checkout 
sftp://${userna...@bzr.savannah.gnu.org/srv/bzr/grub/people/${username}

and work basically the same as they would in Subversion.

-- 
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: Personal branches in Bazaar repository

[Colin Watson]

On Sat, Oct 24, 2009 at 03:20:25PM +0200, Robert Millan wrote:
   bzr branch sftp://${userna...@bzr.savannah.gnu.org/srv/bzr/grub/trunk/
   # hack
   bzr commit
   bzr push --remember 
 sftp://${userna...@bzr.savannah.gnu.org/srv/bzr/grub/people/${username}
 
 If they prefer a Subversion-like workflow (i.e. commit implies push), they can
 checkout the branch afterwards:
 
   bzr checkout 
 sftp://${userna...@bzr.savannah.gnu.org/srv/bzr/grub/people/${username}
 
 and work basically the same as they would in Subversion.

Just another detail which may be useful: if you've done the former
(branch, push) and want to convert it into the latter (checkout) without
having to fetch the branch again from scratch, then you can do this:

  bzr bind :push

This converts the local branch into a checkout of the remembered push
location.


I would also generally recommend using bzr+ssh:// rather than sftp://
URLs. sftp:// involves copying all the metadata back and forward for a
number of operations. bzr+ssh:// runs a smart server on the remote
system and interacts with that, which is generally much faster. If you
do this, you'll need to drop /srv/bzr from the URL as well, so:

  bzr branch bzr+ssh://${userna...@bzr.sv.gnu.org/grub/trunk


Although I'm not a Bazaar developer myself, I have a lot of experience
with using it, and am happy to offer assistance to any GRUB developers
who may run into problems.

-- 
Colin Watson   [cjwat...@ubuntu.com]


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Bazaar and CIA

[Robert Millan]

If you commit to a Bazaar branch, please enable CIA so that we receive
notifications via IRC.  It's very simple; in your local branch / checkout:

  echo cia_project = GNU GRUB  .bzr/branch/branch.conf

then install the bzr/cia plugin.  In Debian it is provided by `cia-clients'
package and installed to /usr/share/pyshared/bzrlib/plugins/cia/.

Thanks!

-- 
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: Bazaar and CIA

[Robert Millan]

On Sat, Oct 24, 2009 at 11:01:14PM +0200, Robert Millan wrote:
 
 If you commit to a Bazaar branch, please enable CIA so that we receive
 notifications via IRC.  It's very simple; in your local branch / checkout:
 
   echo cia_project = GNU GRUB  .bzr/branch/branch.conf
 
 then install the bzr/cia plugin.  In Debian it is provided by `cia-clients'
 package and installed to /usr/share/pyshared/bzrlib/plugins/cia/.

I forgot to mention that for this to work you also need to set the
(user-wide) email variable:

  bzr whoami Frank Chu f...@example.com

(you can also enable CIA user-wide, but this is a bit invasive of your
privacy, as it sends a notification for every commit including those to
local branches)

-- 
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: Bazaar and CIA

[Robert Millan]

On Sat, Oct 24, 2009 at 11:07:17PM +0200, Robert Millan wrote:
 
 (you can also enable CIA user-wide, but this is a bit invasive of your
 privacy, as it sends a notification for every commit including those to
 local branches)

And now that I think, this would make us receive notifications for every
Bazaar commit done by you, even those that have nothing to do with GRUB.

-- 
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: Bazaar and CIA

[Colin Watson]

On Sat, Oct 24, 2009 at 11:01:14PM +0200, Robert Millan wrote:
 If you commit to a Bazaar branch, please enable CIA so that we receive
 notifications via IRC.  It's very simple; in your local branch / checkout:
 
   echo cia_project = GNU GRUB  .bzr/branch/branch.conf
 
 then install the bzr/cia plugin.  In Debian it is provided by `cia-clients'
 package and installed to /usr/share/pyshared/bzrlib/plugins/cia/.

Slightly neater, if you've already installed the cia plugin:

  bzr cia-project 'GNU GRUB'
  bzr nick branch-name # if the directory name is not meaningful enough

You may also wish to have something like this in the [DEFAULT] section
of ~/.bazaar/bazaar.conf:

  cia_user = your-cia-user-name
  cia_send_revno = true

Setting cia_user lets you set a particular username on the cia.vc web
site; this may be useful if you also commit to other projects and like
being able to see statistics on all of them in one place.

cia_send_revno is sort of a project preference I suppose, but I prefer
it myself as I don't find the full revision ids particularly memorable
or useful most of the time, at least not in IRC notifications. It means
that rather than things like this:

  CIA-36 GNU GRUB: Robert Millan rmh.g...@aybabtu.com * 
rrmh.g...@aybabtu.com-20091024205823-fv80obkubaqsi9vi test/test: test commit 2

... you get r764 or similar.

-- 
Colin Watson   [cjwat...@ubuntu.com]


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH,HURD] Fix GNU/Hurd boot

[Robert Millan]

On Wed, Oct 21, 2009 at 08:13:02PM +0200, Samuel Thibault wrote:
 Hello,
 
 The patch compensates the behavior change in the module command: it
 repeats the module name since GNU Mach expects it in the command line.

Committed, thanks.  Btw please include a ChangeLog entry next time.

-- 
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: bazaar mirror available

[Vladimir 'phcoder' Serbinenko]

Robert Millan wrote:
 On Fri, Oct 23, 2009 at 04:40:06PM +0200, Vladimir 'phcoder' Serbinenko wrote:
   
 What's preventing of using it as a main repository? This should allow
 easy resync
 

 Historically, it's been very hard for us to reach consensus on which revision
 control system to use.  When we settled on SVN, it happened because we were
 all fed up with CVS, not because it completely satisfied everyone.  In fact,
 it was Bean who proposed it, even if he used GIT himself at the time!

 Other developers were unsatisfied with this decision, but chose not to object
 to it just so we could get rid of CVS.

 Since a very wide consensus was reached, and it was so hard to archieve it,
 I'm very reluctant to push for Bazaar as our trunk repository unless everyone
 agrees this is what we want.

 Personally, I prefer if we did this switch, but I also think SVN does a good
 job at managing a trunk.  I don't mind living with it for the time being.

 When I feel something is important, I don't hesitate to use my authority as
 maintainer, but in this case I don't consider it necessary.  That said, if
 I see consensus that we should switch to Bazaar as main repository, I won't
 be the one to stop it.

   
Even though I'm git user and only bzr newbie, now when I started to
learn it I like it and am for its adoption as main repo

-- 
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: Macbook, Efi, Display mode

[Stefan Bienert]

 Hi,
 
 The easier way is to use my new menu test demo, download resource file at:
 
 http://grub4dos.sourceforge.net/menu.zip
 
 Unzip to the boot partition, you should see many files under /menu/ directory.
 
 Then you just need to add this line at the end of grub.cfg:
 
 source /menu/menu_efi.cfg
 
 It'd boot into graphic mode by default, you can use F8 to switch
 between text and graphic mode.
 

Hi bean,

I am such an idiot!

I just placed the menu folder in the wrong directory. Placed it in
/efi/grub on the MacOS partition. Once I've placed the folder on the
whole path from / to /efi/grub and now it's working! Looks great.

I really ope you didn't work on that problem, today.

 
 Yep, you need that, debian will enable it by default, I don't know
 about gentoo thought.
 

I have an idea what might be wrong in my gentoo kernel. I hope I find
the time for a little bit of testing, tomorrow.

greetings,

Stefan


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [patch] deadloop in grub_ext2_iterate_dir

[Robert Millan]

On Sat, Oct 17, 2009 at 04:17:52PM +0400, Vasily Averin wrote:
 fix for deadloop in grub_ext2_iterate_dir:
 fpos is not updated if dirent.direntlen == 0

Committed, thanks.

On Sat, Oct 17, 2009 at 02:54:24PM +0200, Felix Zielcke wrote:
 For consistency we should either always use the grub_Xe_to_cpuYZ
 functions or never when checking for a 0 value.

I've set it to keep not using 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.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Refuse to install on XFS destroying its superblock

[Robert Millan]

Ok, let's try this:  We refuse to install on a partition UNLESS:

  - A filesystem can be identified in it.

  - This filesystem is known to reserve the first block for DOS-style
chainload.

If these conditions aren't met, user will have to override our check.

Patch attached.  Also in people/robertmh/grub-setup-fs-probe.

-- 
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.
=== modified file 'ChangeLog'
--- ChangeLog	2009-10-24 23:13:27 +
+++ ChangeLog	2009-10-24 23:57:58 +
@@ -1,5 +1,15 @@
 2009-10-25  Robert Millan  rmh.g...@aybabtu.com
 
+	* include/grub/fs.h (struct grub_fs): Add `reserved_first_sector'
+	member.
+	* fs/ext2.c (grub_ext2_fs): Initialize `reserved_first_sector' to 1.
+	* util/i386/pc/grub-setup.c (setup): Add safety check that probes for
+	filesystems which begin at first sector.
+	(options): New option --skip-fs-probe.
+	(main): Handle --skip-fs-probe and pass it to setup().
+
+2009-10-25  Robert Millan  rmh.g...@aybabtu.com
+
 	* fs/cpio.c [MODE_USTAR]: Finish `tar' module instead of
 	`cpio'.
 	[! MODE_USTAR]: Finish `cpio' module instead of `tar'.

=== modified file 'fs/ext2.c'
--- fs/ext2.c	2009-07-19 13:59:21 +
+++ fs/ext2.c	2009-10-24 23:57:58 +
@@ -924,6 +924,7 @@
 .label = grub_ext2_label,
 .uuid = grub_ext2_uuid,
 .mtime = grub_ext2_mtime,
+.reserved_first_sector = 1,
 .next = 0
   };
 

=== modified file 'include/grub/fs.h'
--- include/grub/fs.h	2009-06-10 21:04:23 +
+++ include/grub/fs.h	2009-10-24 23:57:58 +
@@ -68,6 +68,11 @@
   /* Get writing time of filesystem. */
   grub_err_t (*mtime) (grub_device_t device, grub_int32_t *timebuf);
 
+#ifdef GRUB_UTIL
+  /* Whether this filesystem reserves first sector for DOS-style boot.  */
+  int reserved_first_sector;
+#endif
+
   /* The next filesystem.  */
   struct grub_fs *next;
 };

=== modified file 'util/i386/pc/grub-setup.c'
--- util/i386/pc/grub-setup.c	2009-08-25 08:28:13 +
+++ util/i386/pc/grub-setup.c	2009-10-24 23:57:58 +
@@ -86,7 +86,7 @@
 static void
 setup (const char *dir,
const char *boot_file, const char *core_file,
-   const char *root, const char *dest, int must_embed, int force)
+   const char *root, const char *dest, int must_embed, int force, int fs_probe)
 {
   char *boot_path, *core_path, *core_path_dev;
   char *boot_img, *core_img;
@@ -251,6 +251,21 @@
   if (grub_disk_read (dest_dev-disk, 0, 0, GRUB_DISK_SECTOR_SIZE, tmp_img))
 grub_util_error (%s, grub_errmsg);
 
+  if (dest_dev-disk-partition  fs_probe)
+{
+  grub_fs_t fs;
+  fs = grub_fs_probe (dest_dev);
+  if (! fs)
+	grub_util_error (Unable to identify a filesystem in %s; safety check can't be performed.);
+
+  if (! fs-reserved_first_sector)
+	grub_util_error (%s appears to contain a %s filesystem which isn't known to 
+			 reserve space for DOS-style boot.  Installing GRUB there could 
+			 result in FILESYSTEM DESTRUCTION if valuable data is overwritten 
+			 by grub-setup (--skip-fs-probe disables this 
+			 check, use at your own risk)., dest_dev-disk-name, fs-name);
+}
+
   /* Copy the possible DOS BPB.  */
   memcpy (boot_img + GRUB_BOOT_MACHINE_BPB_START,
 	  tmp_img + GRUB_BOOT_MACHINE_BPB_START,
@@ -556,6 +571,7 @@
 {device-map, required_argument, 0, 'm'},
 {root-device, required_argument, 0, 'r'},
 {force, no_argument, 0, 'f'},
+{skip-fs-probe, no_argument, 0, 's'},
 {help, no_argument, 0, 'h'},
 {version, no_argument, 0, 'V'},
 {verbose, no_argument, 0, 'v'},
@@ -580,6 +596,7 @@
   -m, --device-map=FILE   use FILE as the device map [default=%s]\n\
   -r, --root-device=DEV   use DEV as the root device [default=guessed]\n\
   -f, --force install even if problems are detected\n\
+  -s, --skip-fs-probe do not probe for filesystems in DEVICE\n\
   -h, --help  display this message and exit\n\
   -V, --version   print version information and exit\n\
   -v, --verbose   print verbose messages\n\
@@ -613,7 +630,7 @@
   char *dev_map = 0;
   char *root_dev = 0;
   char *dest_dev;
-  int must_embed = 0, force = 0;
+  int must_embed = 0, force = 0, fs_probe = 1;
 
   progname = grub-setup;
 
@@ -666,6 +683,10 @@
 	force = 1;
 	break;
 
+	  case 's':
+	fs_probe = 0;
+	break;
+
 	  case 'h':
 	usage (0);
 	break;
@@ -767,7 +788,7 @@
 	  setup (dir ? : DEFAULT_DIRECTORY,
 		 boot_file ? : DEFAULT_BOOT_FILE,
 		 core_file ? : DEFAULT_CORE_FILE,
-		 root_dev, grub_util_get_grub_dev (devicelist[i]), 1, force);
+		 root_dev, grub_util_get_grub_dev (devicelist[i]), 1, force, fs_probe);
 	}
 }
   else
@@ -776,7 +797,7 @@
 setup (dir ? : DEFAULT_DIRECTORY,
 	   boot_file ? : DEFAULT_BOOT_FILE,
 	   core_file ? : DEFAULT_CORE_FILE,
-	   root_dev, dest_dev, must_embed, force);
+	  

[Announce] Initial GRUB2 on Yeeloong

[Vladimir 'phcoder' Serbinenko]

Hello, I'm here to announce that grub2 port for yeeloong has already had
its first output. You can see it here:
http://robertmh.files.wordpress.com/2009/10/grub-yeeloong.jpeg (Thanks
to Robert Millan for hosting the image)
On the image you can see standard shell waiting for input.
What already works: booting as ELF from pmon, loading modules, graphics
output if gfx card is already inited (is a case when booted from pmon),
platform-independent parts
What doesn't work: keyboard and disks
Not checked: linux booting (works on qemu)
It also has stubs (e.g. rtc is just counting number of calls) and
hardcodes (e.g. RAM size) but is already something.
Compiling:
get mips branch of http://repo.or.cz/w/grub2/phcoder.git
./autogen.sh
./configure --target=mipsel --with-platform=yeeloong
make
Create a font.bin as explained here: http://grub.enbug.org/gfxterm
./grub-mkimage  -O elf -o grub.elf -d . -f font.bin sm712 gfxterm sh normal
Boot it as if it was linux kernel
Enjoy starring at unresponsive prompt

-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 




-- 
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: Macbook, Efi, Display mode

[richardvo...@gmail.com]

 I have an idea what might be wrong in my gentoo kernel. I hope I find
 the time for a little bit of testing, tomorrow.

Did you compile it yourself (emerge
gentoo-sources/vanilla-sources/hardened-sources then make menuconfig
then make bzImage) or did you use genkernel?


 greetings,

 Stefan


 ___
 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

[PATCH] Support RAID on virtio devices, and others

[Colin Watson]

GRUB only supports RAID on a relatively small number of device types, as
implemented by grub_util_getdiskname. I received a bug report noting
that this doesn't work for RAID arrays with virtio block devices (often
used in kvm) as components. This is difficult to support using the
approach taken by grub_util_getdiskname, as virtio devices use dynamic
major numbers.

find_root_device in util/getroot.c seemed to be exactly what I wanted:
it just trawls /dev for the appropriate major and minor numbers. This
code is not performance-critical, so that should be fine. I made the
function naming more consistent, added support for a default directory
in its interface (this may have problems on Cygwin; does anyone care
about RAID on Cygwin? If so, perhaps they can propose improvements), and
changed the RAID code to use it.

Bazaar users can merge this from:

  bzr+ssh://bzr.sv.gnu.org/grub/people/cjwatson/raid-virtio/

=== modified file 'ChangeLog'
--- ChangeLog   2009-10-21 12:22:05 +
+++ ChangeLog   2009-10-25 01:32:02 +
@@ -1,3 +1,22 @@
+2009-10-25  Colin Watson  cjwat...@ubuntu.com
+
+   Support RAID on virtio devices, and others.
+
+   * util/getroot.c [__MINGW32__] (find_root_device): Rename to ...
+   [__MINGW32__] (grub_find_device): ... this.
+   [! __MINGW32__  ! __CYGWIN__] (find_root_device): Rename to ...
+   [! __MINGW32__  ! __CYGWIN__] (grub_find_device): ... this.  Use a
+   reasonable default if dir is NULL.
+   [! __MINGW32__  __CYGWIN__] (find_cygwin_root_device): Rename to
+   ...
+   [! __MINGW32__  __CYGWIN__] (grub_find_device): ... this.
+   (grub_guess_root_device): Update callers.
+   * include/grub/util/getroot.h (grub_find_device): Add prototype.
+
+   * util/raid.c (grub_util_getdiskname): Remove.
+   (grub_util_raid_getmembers): Use grub_find_device rather than
+   grub_util_getdiskname.
+
 2009-10-21  Felix Zielcke  fziel...@z-51.de
 
* config.guess: Update to latest version from config git

=== modified file 'include/grub/util/getroot.h'
--- include/grub/util/getroot.h 2009-04-11 09:40:39 +
+++ include/grub/util/getroot.h 2009-10-25 01:22:15 +
@@ -19,12 +19,15 @@
 #ifndef GRUB_UTIL_GETROOT_HEADER
 #define GRUB_UTIL_GETROOT_HEADER   1
 
+#include sys/types.h
+
 enum grub_dev_abstraction_types {
   GRUB_DEV_ABSTRACTION_NONE,
   GRUB_DEV_ABSTRACTION_LVM,
   GRUB_DEV_ABSTRACTION_RAID,
 };
 
+char *grub_find_device (const char *dir, dev_t dev);
 char *grub_guess_root_device (const char *dir);
 char *grub_get_prefix (const char *dir);
 int grub_util_get_dev_abstraction (const char *os_dev);

=== modified file 'util/getroot.c'
--- util/getroot.c  2009-07-20 20:03:18 +
+++ util/getroot.c  2009-10-25 01:22:15 +
@@ -172,8 +172,8 @@ grub_get_prefix (const char *dir)
 
 #ifdef __MINGW32__
 
-static char *
-find_root_device (const char *dir __attribute__ ((unused)),
+char *
+grub_find_device (const char *dir __attribute__ ((unused)),
   dev_t dev __attribute__ ((unused)))
 {
   return 0;
@@ -181,13 +181,22 @@ find_root_device (const char *dir __attr
 
 #elif ! defined(__CYGWIN__)
 
-static char *
-find_root_device (const char *dir, dev_t dev)
+char *
+grub_find_device (const char *dir, dev_t dev)
 {
   DIR *dp;
   char *saved_cwd;
   struct dirent *ent;
 
+  if (! dir)
+{
+#ifdef __CYGWIN__
+  return NULL;
+#else
+  dir = /dev;
+#endif
+}
+
   dp = opendir (dir);
   if (! dp)
 return 0;
@@ -225,7 +234,7 @@ find_root_device (const char *dir, dev_t
  /* Find it recursively.  */
  char *res;
 
- res = find_root_device (ent-d_name, dev);
+ res = grub_find_device (ent-d_name, dev);
 
  if (res)
{
@@ -328,8 +337,8 @@ get_bootsec_serial (const char *os_dev, 
   return serial;
 }
 
-static char *
-find_cygwin_root_device (const char *path, dev_t dev)
+char *
+grub_find_device (const char *path, dev_t dev)
 {
   /* No root device for /cygdrive.  */
   if (dev == (DEV_CYGDRIVE_MAJOR  16))
@@ -350,7 +359,7 @@ find_cygwin_root_device (const char *pat
 
   /* Cygwin returns the partition serial number in stat.st_dev.
  This is never identical to the device number of the emulated
- /dev/sdXN device, so above find_root_device () does not work.
+ /dev/sdXN device, so above grub_find_device () does not work.
  Search the partition with the same serial in boot sector instead.  */
   char devpath[sizeof (/dev/sda15) + 13]; /* Size + Paranoia.  */
   int d;
@@ -386,12 +395,12 @@ grub_guess_root_device (const char *dir)
 
 #ifdef __CYGWIN__
   /* Cygwin specific function.  */
-  os_dev = find_cygwin_root_device (dir, st.st_dev);
+  os_dev = grub_find_device (dir, st.st_dev);
 
 #else
 
   /* This might be truly slow, but is there any better way?  */
-  os_dev = find_root_device (/dev, st.st_dev);
+  os_dev = grub_find_device (/dev, st.st_dev);
 #endif
 
   return os_dev;

=== modified file 'util/raid.c'
--- 

Re: Macbook, Efi, Display mode

[Stefan Bienert]

richardvo...@gmail.com wrote:
 I have an idea what might be wrong in my gentoo kernel. I hope I find
 the time for a little bit of testing, tomorrow.
 
 Did you compile it yourself (emerge
 gentoo-sources/vanilla-sources/hardened-sources then make menuconfig
 then make bzImage) or did you use genkernel?

I just used gentoo-ources without any patching by myself.

greetings,

Stefan


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Macbook, Efi, Display mode

[richardvo...@gmail.com]

On Sat, Oct 24, 2009 at 7:38 PM, Stefan Bienert
bien...@zbh.uni-hamburg.de wrote:
 richardvo...@gmail.com wrote:
 I have an idea what might be wrong in my gentoo kernel. I hope I find
 the time for a little bit of testing, tomorrow.

 Did you compile it yourself (emerge
 gentoo-sources/vanilla-sources/hardened-sources then make menuconfig
 then make bzImage) or did you use genkernel?

 I just used gentoo-ources without any patching by myself.

Then you should be able to add EFI display support quite easily during
the make menuconfig step


 greetings,

 Stefan


 ___
 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

any tutorial on grub2 menu interface ?

[J. Bakshi]

Hello,

Is there any tutorial on grub2 menu interface ?
Also tutorial on grub2 is very much welcome.

Thanks


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel