oot for ZFS without libzfs?" thread). Did you see this part
of the thread?
--
Robert Millan
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
2011/10/16 Robert Millan :
>> What is the device node list used for? To list devices that each need grub
>> installed, or for something else?
>
> grub-probe internally needs access to the raw devices because it wants
> to use GRUB codepaths to obtain fs_uuid and such.
In oth
d externally. ABI changes without notice, there's no soname
update and no versioning information. See:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645305
--
Robert Millan
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
for? To list devices that each need grub
> installed, or for something else?
grub-probe internally needs access to the raw devices because it wants
to use GRUB codepaths to obtain fs_uuid and such.
--
Robert Millan
___
Grub-devel mailing list
Grub-de
layer like they
currently do with LVM or mdRAID, but they don't need the device node
list anymore (since it's filled with a full scan, as with LVM).
--
Robert Millan
=== modified file 'configure.ac'
--- configure.ac 2011-08-19 20:49:48 +
+++ configure.ac 2011-10-15 16:42:10 +00
> not intended for linking against also makes me wonder if the syslib exception
> is a concern for that.
But SUN/Oracle has linked GRUB with libzfs. This is a good indication
that they trust this method to be safe (it's our copyright which would
be infringed by them
, it's probably moot for now. It might be slightly more
> elegant to use pure Grub code given that all of the underlying functionality
> is there already,
I agree. But I'm still concerned about the technical problems.
--
Robert Millan
__
le to us is /dev/zfs. But is that device
meant to be used directly? How stable is this interface?
--
Robert Millan
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
rub_machine_mmap_iterate() with something like:
grub_err_t
grub_machine_mmap_iterate (grub_memory_hook_t hook)
{
hook (0x8100, 8200, GRUB_MEMORY_AVAILABLE);
return GRUB_ERR_NONE;
}
--
Robert Millan
___
Grub-devel mailing list
Grub-deve
4-14
- kfreebsd /boot/kfreebsd-8.1-1-amd64.gz
- kfreebsd_module_elf /lib/modules/8.1-1-amd64/opensolaris.ko
- kfreebsd_module_elf /lib/modules/8.1-1-amd64/zfs.ko
--
Robert Millan
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
e applied to the result. This doesn't imply that you
licensed any code under GPL, only that your license terms
(or in this case, your lack of copyright assertion) are compatible
with the GPL.
--
Robert Millan
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
ifferent
one is leaving the GNU system without its bootloader.
--
Robert Millan
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
t the code covered by them can be
used freely. If you intend for your code to be free for all users,
always use the latest version of the GPL.
--
Robert Millan
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
2010/9/10, lode leroy :
> It may be easy to copy files onto the filesystem, but
> not-so-easy
> to create a working native grub.
What's hard about grub-install /dev/sda ?
--
Robert Millan
___
Grub-devel mailing list
Grub-deve
from GRUB is not possible. Given that setup command can only
perform part of this, it is unrealistic to pretend setup command is useful.
This is why it was removed.
--
Robert Millan
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
is not allocated but we free it anyway.
Or perhaps I'm missing something? (it's late here, I need some sleep)
--
Robert Millan
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
iewsvn/d-i/trunk/installer/build/boot/kfreebsd/grub-kfreebsd-cdrom.cfg?revision=64460&view=markup
--
Robert Millan
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
; the monitor; it's mostly only a problem with Linux itself now.
Not with Linux either, just "set gfxpayload=keep" and GRUB will preserve
video mode when giving control to Linux.
--
Robert Millan
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
arded). Let me know if there were a problem with other filesystems.
--
Robert Millan
=== modified file 'ChangeLog'
--- ChangeLog 2010-08-19 23:15:23 +
+++ ChangeLog 2010-08-20 14:34:56 +
@@ -1,3 +1,13 @@
+2010-08-20 Robert Millan
+
+ Make kFreeBSD code more generic to support ext2
it would be possible to
build UFS as a module.
--
Robert Millan
2010-08-20 Robert Millan
* util/grub.d/10_kfreebsd.in (kfreebsd_entry): Add generic module
load routine.
Map GRUB `ext2' to kFreeBSD `ext2fs'.
=== modified file 'util/grub.d/10_kfreebsd.in'
--- util/grub.
ot), but I can't see any
advantage in providing two ways to do the same thing, specially when it
isn't obvious they are equivalent.
Also, in ZFS there isn't a single device name that identifies the whole pool
(as with mdraid), which would make the semantics even more confusing.
--
Ro
filename, mbh->load_addr);
+ return 0;
+ }
--
Robert Millan
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
2010/8/10, Scott Moser :
> Hi all,
>I've been playing around with multiboot images, and found grub 0.97's
> 'mbchk' to be very useful. Its really nice from a shell script or other
> to easily answer "is this file a multiboot image?".
>
>The attached patch basically copies mbchk.c from grub
I'd also point out that the device where grub-setup will embed
core.img is a minor issue here, since it's trivial to run grub-setup
multiple times. The real problem is putting /boot/grub/ in a
mirrored filesystem so that either copy of core.img will be able
to access this directory from any of the
2010/8/4, Seth Goldberg :
>> I don't think this is the appropiate place for this kind of sanity check.
>> Keep in mind "grub-probe -t device" has many purposes, and for some of
>> them
>> (e.g. determining the partmap) the ZFS status is irrelevant.
>
>Hmm. I do see your point here, but then I'
Committed, with some adjustments. I put the new code in misc.c instead
of getroot.c to prevent grub-mkrelpath (and others) from having to drag
a gazillon other files in.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinf
2010/7/30, Robert Millan :
> Unfortunately there are availability problems with libzfs.h and libnvpair.h.
> On
> FreeBSD they're not installed system-wide. On OpenSolaris I can't see them
> installed either (although in this one I'm probably missing something).
This adds support for ZFS root in 10_kfreebsd.in. It works with
current trunk if my grub-mkrelpath patch has been applied, and if
ZFS from grub-extras has been built into GRUB.
2010-07-31 Robert Millan
* util/grub.d/10_kfreebsd.in: Initialize ${kfreebsd_device} as the
kFreeBSD device name
2010/7/30, Seth Goldberg :
>
> You need to ensure that the deivce given isn't degraded. It's certainly
> possible to boot with a mirrored root with one device degraded. If you
> choose
> that device for grub-setup, you may fail to write to it or you may succeed,
> but something else may prevent
2010/7/30, Seth Goldberg :
> Ah, ok. As long as we try the system-installed libzfs.h first, I'm ok
> then.
We do now.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
2010/7/30, Seth Goldberg :
>I saw your commit of these changes. Why are you delivering a libzfs.h
> and libnvpair.h?
> I think GRUB should be using the headers that are installed on
> the systems [...]
Unfortunately there are availability problems with libzfs.h and libnvpair.h. On
FreeBSD t
Same patch with a bit of cleanup, and ChangeLog entry.
2010/7/29, Robert Millan :
> This patch is a proof of concept for solving the ZFS "(dev)/foo@/"
> pathname problem at the lowest possible level: a small change in
> grub_make_system_path_relative_to_its_root() propagates in
This patch adds OpenSolaris support as well, but unfortunately I can't
test it. I will commit if someone (Seth?) can confirm it works.
=== modified file 'configure.ac'
--- configure.ac 2010-07-30 19:43:12 +
+++ configure.ac 2010-07-30 20:20:43 +
@@ -247,7 +247,7 @@ else
fi
# Check for
2010/7/30, Seth Goldberg :
> Don't forget to check the state of the device also.
Can you be more specific? I notice a "state" integer variable associated
with the pool (none associated with the device), which has a zero-value in
my case (I assume this indicates no error).
What kind of errors can
2010/7/29, Seth Goldberg :
>
> This code will not handle a mirrored root pool. See the Solaris
> implementation of vdev_get_physpaths() and zpool_get_config_physpath().
Thanks for the pointer. I avoid reading libzfs source, but looking at the dump
from nvlist_print(), the problem seems obvious
This patch is a proof of concept for solving the ZFS "(dev)/foo@/"
pathname problem at the lowest possible level: a small change in
grub_make_system_path_relative_to_its_root() propagates into
all the places in grub-install and grub-mkconfig that are affected
by the problem.
It factors some of the
New version, with a few bugfixes (find_mount_point_from_dir logic,
use heap allocation, support pools with multiple filesystems).
ChangeLog entry is the same.
=== modified file 'configure.ac'
--- configure.ac 2010-07-04 22:45:14 +
+++ configure.ac 2010-07-29 13:43:00 +
@@ -247,7 +247,7 @@
Please test / comment / etc.
2010-07-29 Robert Millan
Enable `grub-probe -t device' resolution on ZFS.
* configure.ac: Check for getfsstat(), libzfs and libnvpair.
* include/grub/util/libnvpair.h: New file.
* include/grub/util/libzfs.h: New file.
* kern/emu/getroot.c: Include `
2010/7/28, Tuco :
> I was already on this. I made some progress and have libzfs now,
> expect zpool/zfs to follow soon. Here is my patch if you want to build
> libzfs yourself:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=libzfs.diff;att=1;bug=590639
Very nice. Thanks.
__
2010/7/28, Vladimir 'φ-coder/phcoder' Serbinenko :
> I don't think that the design needs changes but I'm open to discussion.
My proposal seemed like an improvement in design, which I wanted to do before
dealing with grub-install/grub-mkconfig. But obviously I've missed some details,
and things are
The problem I see with current zfs.mod is that it integrates with GRUB using
the "filesystem model", i.e. each pool has one
backend (the storage device) and one frontend (the filesystem).
But ZFS is different in both ends: each pool can use N storage devices
and provide M filesystems. In the curre
2010/7/21 Tuco :
> Is this a known problem? Should I investigate? Can you give some guideline?
If you want to help, you could have a look at porting libzfs over to
GNU/kFreeBSD.
It's likely that GRUB will need it, and in either case the Debian
folks definitely will.
__
2010/7/22 Seth Goldberg
>> I guess the API exported by libzfs can serve for this? But first, I
>> have some concern about zfs.mod, I'll write a detailed mail about that
>> later.
>
> That's how I'm implementing it, though libzfs is technically an uncommitted
> interface.
What are you currently
Hi,
This has been on my radar for a while now, I'll have a look at it
(today I start my vacation and have some spare time (but don't hold
your breath...)).
2010/7/21, Seth Goldberg :
> The main problem is that the st_dev that you'll get from a call to stat() of
> a file on a ZFS filesystem won't
2010/7/3, Vladimir 'φ-coder/phcoder' Serbinenko :
> Using GUID in GPT to locate the embedded zone would be good but it has
> nothing to do with this standard. Robert made some work in this
> direction but never finished (he wrote MBR but not some required changes
> to diskboot.img) and nobody picke
Hi,
Sorry for breaking the thread, but I just stepped in because I
participated in the standarisation of the BIOS Boot Partition
mechanism, and in early discussions about this hybrid DOS/GPT protocol
which led to the standard being discussed, and I want to clarify
something.
GRUB implements the B
Hi,
trunk repository is now frozen in preparation for GRUB 1.98, which will be
released soon, most likely this month.
I leave Vladimir in charge of this freeze process. Please ask him for
approval when in doubt.
--
Robert Millan
"Be the change you want to see in the world"
e on this Cell.
> Robert where did you find this bit of news?
IRC.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
't as much as getting Grub to work, but finding an exploit
> that works without hardware interaction.
Well that would be very interesing indeed, but in GRUB project we're generally
concerned about improving GRUB...
--
Robert Millan
"Be the
whereas projects that don't
use ELF are almost invariably proprietary OS and never showed any interest
in Multiboot.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
ummer.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
ing, what would be a good solution to this? We could add
a proper probe() function and switch all filesystems to it, but only
for the benefit of pxe it seems a bit overkill.
Does someone have a better idea?
--
Robert Millan
"Be the change you want
k_ata_pass_through' is a hack. A cleaner design would be
> possible with a grub_disk_dev.ioctl(.) call.
The problem I see with 'grub_disk_ata_pass_through' is that it shouldn't be
in kernel. The interface itself is less relevant IMO.
--
R
ug.org website.
You can do that if you lile; it's a wiki.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
out.mod, which is just a helper for loaders of *BSD
kernels.
Please also see Okuji's article on this subject:
http://grub.enbug.org/OnSplittingModules
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Gr
some size
increase. Has this changed, or I'm missing something?
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
ant to help with polishing at_keyboard, usb_keyboard and the USB stack,
that'd be most welcome.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
On Mon, Jan 25, 2010 at 08:31:35AM +0100, Robert Millan wrote:
> When you hide complexity from the user, the user doesn't generally care or
> want to understand what this involves. When we accept "(hd0,1)" from the
> user, it implies we know what's the partition
ow and afterwards when looking at Bazaar history).
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
know if you'd call this hardware
information, but if a screen is physically rotated, it's clearly not
software.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
er, the user doesn't generally care or
want to understand what this involves. When we accept "(hd0,1)" from the
user, it implies we know what's the partition label in hd0, but reality is
that we're just guessing. User, however, will expect things to "just work",
and
s that use probing don't necessarily imply that. For example, GRUB
could do:
grub> ls (hd0)
Possible msdos label: 1 2 3
Possible gpt label: 1 2
etc.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
x0518
> Now going to write high coreboot table at 0xbfffe000
> rom_table_end = 0xbfffe000
Did you try with testing coreboot+GRUB on qemu?
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
would be nice. If you'd like to implement it, I think it
should be possible to verify this entirely in build time.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.
hitecturally it's not a problem to
> support (as Vladimir's existing implementation already supports arbitrary
> nesting).
Note that it is very easy for Intel to specify and implement that: in their
world there's only one partition label type (plus another one which is
backward co
they like,
but they will also have to deal with the problem of identifiing the labels.
Minix: (hd0,msdos1,msdos1)
Solaris: (hd0,msdos2,sun1)
*BSD: (hd0,msdos3,bsd1)
With this approach, the burden is no longer in GRUB. Then I don't care
how weird disk layouts can become, because GRUB doesn
> the OS so that the OS console output is displayed the same way
> automatically.
Makes sense. Can you draft a proposal?
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-d
On Sun, Jan 24, 2010 at 07:36:51PM +0100, Robert Millan wrote:
> - A number of header declarations had their copyright/license headers
> missing. They had been imported in GRUB Legacy many years ago, and
> recently found their way into the 1.97 release.
The files in ques
ys DEA2C38E
and rerun the `gpg --verify' command.
This release was bootstrapped with the following tools:
Autoconf 2.61
Ruby 1.8.7
GCC 4.4 is the recommended version for building it, although any version
starting with 4.1.3 is supported in this release.
--
Robert Millan
"Be the cha
nes have. If you strive for compatibility, GPT is a good choice IMO (and
the rest of the free world seems to be moving in this direction thanks to 2 TiB
limit).
[1] I know the first one is already implemented, but your approach makes it
less ad-hoc and splits code off part_msdos.mod, whic
This makes it possible to use relative paths in the "file" component of
gfxmenu images. I've tested that it works, but I'd appreciate if someone
more familiar with gfxmenu can review it.
--
Robert Millan
"Be the change you want to see in the world" -- Gan
STEM_PATH})
prepare_grub_to_access_device ${SYSTEM_PATH}
echo "multiboot ${GRUB_PATH} ${SYSTEM_PATH}"
Then your system tools obtain a path that makes sense to them.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
ind . -name '*.[ch]' -exec sed -i -e 's, ENABLE_NLS,
> (defined(ENABLE_NLS) \&\& ENABLE_NLS),g' '{}' ';'
This affects gnulib/error.c and gnulib/gettext.h which would be much better
not to change, as they're being imported semi-automatically.
Perhap
On Wed, Jan 20, 2010 at 12:17:26AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> Robert Millan wrote:
> > On Fri, Jan 15, 2010 at 06:18:43PM +0100, Vladimir 'φ-coder/phcoder'
> > Serbinenko wrote:
> >
> >> Hello. This defines
> and then in font/font.c:
>
> static const char section_names_file[4] = { 'F', 'I', 'L', 'E' };
> static const char pff2_magic[4] = { 'P', 'F', 'F', '2' };
>
> ?
>
> If should be in a macro (as I
cue mode and at_keyboard? I mean, extreme cases
> that Grub for some reason could not reach the keyboard layout file.
What's the total size we're talking about?
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
use keyboard layouts with languages! You probably meant US
keyboard.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
On Tue, Jan 19, 2010 at 10:56:48PM +, Colin Watson wrote:
> On Tue, Jan 19, 2010 at 11:29:14PM +0100, Robert Millan wrote:
> > On Sun, Jan 17, 2010 at 01:02:55PM +0100, Vladimir 'φ-coder/phcoder'
> > Serbinenko wrote:
> > > Robert Millan wrote:
> > >
that in principle it shouldn't go in trunk untill after next release (1.98).
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
us are relatively new to Bazaar, so we might be just missing it.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
icense header.
Btw, feel free to commit this and also add new tests directly into trunk,
as long as they can run succesfuly in any sane build environment.
Thanks
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
__
's the difference between this reserved memory and a reserved area?
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
are these
> assumptions?
Loader in GRUB 2 tends to put MBI and associated structures right after
payload code (unlike GRUB Legacy which uses a fixed location below 1 MiB).
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
trunk and experimental) unless someone provides a
very good reason to provide it.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
published) and then merge it into trunk.
We had worse problems with the situation Colin Watson described.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://li
ier macbooks (e.g. MBP4,1).
Given this note in commit log:
> [...] This is somewhat hacky, but it
> appears to be the only way to do this that does not break some some
> set of existing bootloaders.
I think you should report it to them.
--
Robert Millan
"Be the cha
On Sun, Jan 17, 2010 at 01:02:55PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> Robert Millan wrote:
> > On Fri, Jan 01, 2010 at 09:32:24AM +, Colin Watson wrote:
> >
> >> On Tue, Dec 29, 2009 at 10:30:12AM +0100, Vladimir '
; internationalization. Suggestions of wildly different
> approaches/configuration interfaces are welcome.
I think this is growing severely overengineered. It is already more
complex than it needs to be.
The scripts in /etc/grub.d *are* config files. There
oadable module support.
(btw FAT fixes were merged separately)
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
ation. It would almost be funny if it wasn't because they
managed to put their i8086-encumbered legacy in every modern machine around
the world.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
on (OpenSolaris').
P.S: please forward this message to the relevant NetBSD mailing list(s) if
you think this is appropiate. TIA
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
e.
Could the EFI parts be split into a separate patch? I definitely want both
things, but they're separate changes, would be good to have the additional
granularity if possible.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Hi,
I committed your last patch with some minor stylistic adjustments, plus
your changes to the example kernel.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gn
On Fri, Jan 08, 2010 at 01:44:25AM +0100, Grégoire Sutre wrote:
> Robert Millan wrote:
>
>> I suggest you test if GRUB Legacy's Multiboot loader supports this
>> properly, as the code I used derives from that.
>
> Yes, the problem disappears with GRUB Legacy's m
not sure how to make this happen.
FWIW, if anyone who reads this is willing to help the GRUB project by
watching help-grub and helping with user requests there, he/she's more
than welcome to do that.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
__
already has the desired information.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
On Thu, Jan 07, 2010 at 02:38:24PM -0800, Colin D Bennett wrote:
>
> When you say “existing fonts” do you mean there is a font other than
> unifont?
Not that we currently provide.
--
Robert Millan
"Be the change you want to see in the wo
On Thu, Jan 07, 2010 at 07:59:57PM +0530, J. Bakshi wrote:
> Hello everyone,
>
> I am happy to see the availability of grub 1.98
That's very unlikely. I don't recall having released 1.98 yet ;-)
--
Robert Millan
"Be the change you want to see
xmenu to mainstream as soon as possible, I would _strongly_
recommend to use the existing fonts for now)
Also, if you'd like to make an official GRUB theme with GNU-based image set,
you're more than welcome.
--
Robert Millan
"Be the c
his. See:
https://savannah.gnu.org/task/?10024
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
1 - 100 of 2895 matches
Mail list logo
