On 26.11.2013 08:22, Beeblebrox wrote:
>>> Found the problem. Either use -d or upgrade.
> The -d flag did not work (gave error), so I I upgraded. Works now!
>
-d requires an argument (consult --help)
> # grub-mknetdir --net-directory=/data/tftp --subdir=boot
> Netboot directory for i386-pc create
OK, I'll try it. But I need clarification:
* Should I copy the repo and do a git rollback on the copy?
* Easier to copy only grub/docs to another folder, but how do I start
the build then? The Makefile in grub/docs will fail just as when run
from top-level.
>> just copy grub.texi over
>From my cu
On Tue, Nov 26, 2013 at 11:31 AM, Beeblebrox wrote:
> It's OK, I don't need it really. Unless you need me to test and get
> back to you with results.
Would be nice; as new release is planned in not so distant future, we
should try to iron out problems.
___
> Did earlier versions grub.texi compiled?
Yes, earlier versions of grub.texi did compile.
> Setup build tree outside of git checkout and just copy
> grub.texi over; it is self contained.
It's OK, I don't need it really. Unless you need me to test and get
back to you with results.
___
On Tue, Nov 26, 2013 at 11:19 AM, Beeblebrox wrote:
> Still have to manually clean out the "docs" references in Makefile however.
>
Did earlier versions grub.texi compiled? In this case you could try to
bisect it. Setup build tree outside of git checkout and just copy
grub.texi over; it is self
>> Found the problem. Either use -d or upgrade.
The -d flag did not work (gave error), so I I upgraded. Works now!
# grub-mknetdir --net-directory=/data/tftp --subdir=boot
Netboot directory for i386-pc created. Configure your DHCP server to
point to /data/tftp/boot/i386-pc/core.0
The DHCP messag
>> Or just update to current trunk, I committed this patch.
Updated to trunk, it all works & gets compiled.
Still have to manually clean out the "docs" references in Makefile however.
Thanks for the swift work.
___
Grub-devel mailing list
Grub-devel@gn
On 25.11.2013 23:37, Jon McCune wrote:
> [v0] new grub-*-setup flag to disable insertion of reed solomon codes
> [v0] grub-install support for option --no-rs-codes
> [v1] bugfix: also change the maxsec value in util/setup.c
> [v2] Modified to support new C-language install utilities, added
> d
On 25.11.2013 23:28, SevenBits wrote:
>
> On 11/25/2013 05:07 PM, Vladimir '?-coder/phcoder' Serbinenko wrote:
>> On 25.11.2013 23:03, SevenBits wrote:
>>>
>>> Thanks for your quick reply.
>>>
>>> I just have a couple of questions. How do you prefer I allow the user to
>>> specify the vendor UUID?
Il 14/11/2013 22:43, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
On 14.11.2013 22:11, M A Young wrote:
On Thu, 14 Nov 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
On 14.11.2013 19:57, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
On 14.11.2013 19:48, M A Young wrote:
On Thu, 14 No
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/25/2013 05:07 PM, Vladimir '?-coder/phcoder' Serbinenko wrote:
> On 25.11.2013 23:03, SevenBits wrote:
>>
>> Thanks for your quick reply.
>>
>> I just have a couple of questions. How do you prefer I allow the user to
>> specify the vendor UUID?
paste your grub.cfg to give context
On Nov 25, 2013 12:09 PM, "Beeblebrox" wrote:
> Hello.
> I have built and installed Grub from trunk (lbeit without docs and
> efiemu, which I don't need). I have also installed the boot code and
> have booted from grub. Here are my results:
> * grub-probe corre
On 25.11.2013 23:03, SevenBits wrote:
>
> Thanks for your quick reply.
>
> I just have a couple of questions. How do you prefer I allow the user to
> specify the vendor UUID? By typing it in via the keyboard? And secondly,
> by saying it needs "readable aliases for known types" do you mean that
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks for your quick reply.
I just have a couple of questions. How do you prefer I allow the user to
specify the vendor UUID? By typing it in via the keyboard? And secondly,
by saying it needs "readable aliases for known types" do you mean that
ther
please resend as proper and not as reverse patch. Anotjer issie that can be
seen from description alone is that you don't allow to specify vendor uuid.
it would be needed and slso it needs readable aliases for known types
On Nov 25, 2013 10:35 PM, "SevenBits" wrote:
> Hello everyone,
>
> This pat
Hello everyone,
This patch adds two GRUB two commands to allow the user to get and set
the values of (U)EFI firmware variables. When dealing with (U)EFI
firmware with GRUB I decided this would be a useful tool to have for
both developers and end-users.
The first command, setefivariable, takes two
On Mon, 25 Nov 2013, Fabio Fantoni wrote:
I did a test following informations on one of post before:
git clone git://git.sv.gnu.org/grub.git # commit
61e1b9a49d48035bde52784abb54c3212b647fc8
./autogen.sh
./configure --target=x86_64 --with-platform=xen
mkdir -p boot/grub/
cat > boot/grub/grub.c
В Mon, 25 Nov 2013 19:19:00 +0100
Vladimir 'φ-coder/phcoder' Serbinenko пишет:
> On 25.11.2013 19:13, Andrey Borzenkov wrote:
> > Similar to check for target linking format, also check for efiemu64
> > instead of hardcoding -melf_x86_64. This fixes compilation on *BSD
> > variants. We cannot easi
В Thu, 14 Nov 2013 15:20:10 +0200
Mikko Rantalainen пишет:
> Vladimir 'φ-coder/phcoder' Serbinenko, 2013-11-10 19:01 (Europe/Helsinki):
> > Hello, all. We've switched to git some time ago, now we should have some
> > kind of workflow documents. In particular I think of following points:
> > - Dev
On 25.11.2013 19:14, SevenBits wrote:
> It is too late, then, to submit a patch adding a new command to GRUB?
> I've been meaning to submit it but have been busy... it's already done
> and everything, just want to see if I can get upstream. :)
>
It's not frozen yet (see the date). Then, of course,
On 25.11.2013 19:13, Andrey Borzenkov wrote:
> Similar to check for target linking format, also check for efiemu64
> instead of hardcoding -melf_x86_64. This fixes compilation on *BSD
> variants. We cannot easily reuse main target check because platforms
> are different (main target is 32 bit and e
On 25.11.2013 17:25, Beeblebrox wrote:
> # grub-mknetdir -v => no output
> dmesg shows nothing
>
Found the problem. Either use -d or upgrade.
> ls -la /usr/local/bin/grub-mknetdir
> -rwxr-xr-x 1 root wheel 444009 Nov 24 17:53 grub-mknetdir*
>
> ___
It is too late, then, to submit a patch adding a new command to GRUB? I've
been meaning to submit it but have been busy... it's already done and
everything, just want to see if I can get upstream. :)
On Mon, Nov 25, 2013 at 12:58 PM, Vladimir 'φ-coder/phcoder' Serbinenko <
phco...@gmail.com> wrot
Similar to check for target linking format, also check for efiemu64
instead of hardcoding -melf_x86_64. This fixes compilation on *BSD
variants. We cannot easily reuse main target check because platforms
are different (main target is 32 bit and efiemu64 - 64 bit).
This commit adds EFIEMU64_LINK_FO
Hello, all. It's time to start gearing towards 2.02 release
- 2.01 number will be skipped in order to follow odd/even convention for
release/git.
On 17th December will be the feature freeze, after it only bugfixes and
documentation will be committed.
Release will be when we're confifent enough in a
On 25.11.2013 18:42, Andrey Borzenkov wrote:
> В Mon, 25 Nov 2013 05:22:58 +0100
> Vladimir 'φ-coder/phcoder' Serbinenko пишет:
>
>>> + CFLAGS="-m64 -nostdlib -O2 -mcmodel=large -mno-red-zone"
>>> + LDFLAGS="-m64 -Wl,$format -nostdlib"
>> You need -static as otherwise on Apple systems i
В Mon, 25 Nov 2013 05:22:58 +0100
Vladimir 'φ-coder/phcoder' Serbinenko пишет:
> > + CFLAGS="-m64 -nostdlib -O2 -mcmodel=large -mno-red-zone"
> > + LDFLAGS="-m64 -Wl,$format -nostdlib"
> You need -static as otherwise on Apple systems it will try to pull in
> the dynamic linker which we
В Mon, 25 Nov 2013 13:08:45 +0200
Beeblebrox пишет:
> * grub-mkconfig does not detect an ubuntu linux (btrfs) install on separate
> HDD.
Detection of other systems is implemented outside of grub2; it is done
by os-prober. grub-mkconfig will launch os-prober if it is found and
interpret its outp
On Fri, Nov 22, 2013 at 02:30:28PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 22.11.2013 14:16, Colin Watson wrote:
> > This will not be sufficient to build on GNU/Hurd (get_ofpathname isn't
> > directly relevant to that platform, but that function will be compiled
> > there anyway).
# grub-mknetdir -v => no output
dmesg shows nothing
ls -la /usr/local/bin/grub-mknetdir
-rwxr-xr-x 1 root wheel 444009 Nov 24 17:53 grub-mknetdir*
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Nov 25, 2013 4:29 PM, "Beeblebrox" wrote:
>
> I tried as suggested,
> # grub-mknetdir --net-directory=/data/tftp --subdir=boot
> And no files were plced in /data/tftp/boot
>
paste full output with -v
> I did not see the relevance, but I also tried,
> # grub-mknetdir --net-directory=/data/tftp -
I tried as suggested,
# grub-mknetdir --net-directory=/data/tftp --subdir=boot
And no files were plced in /data/tftp/boot
I did not see the relevance, but I also tried,
# grub-mknetdir --net-directory=/data/tftp --subdir=boot /dev/ada0
grub-mknetdir: Too many arguments
Try 'grub-mknetdir --help' o
Hello, I've added support to grub-install for HFS(+) installs in the
branch phcoder/mac. I tested it on my PowerPC mac (--macppc-dir). Could
someone test it on Intel one? Just use grub-install with --efi-directory
pointing to a mountpoint of an empty HFS(+) partition
signature.asc
Description: O
On 25.11.2013 12:08, Beeblebrox wrote:
> * At boot time, grub menu comes up, and starts to boot normally into
> the ZFS pool. However boot stops at mounting root because "no such
> file system", and BTX (the FreeBSD loader) is very unresponsive.
What do you mean by BTX? The standard GRUB entries fo
Hello.
I have built and installed Grub from trunk (lbeit without docs and
efiemu, which I don't need). I have also installed the boot code and
have booted from grub. Here are my results:
* grub-probe correctly identifies partitions as ZFS.
* grub-mkconfig correctly generates a config file and has t
On 11/20/13 07:36, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
It's not that easy. Trouble is that you need to also prevent
inconsistent rollback and for this you need to have a hash tree. Then
since power failure is a possibility you need this tree to be consistent
at every moment. Those issues
36 matches
Mail list logo