Easy grub2 installation for non Linux (Windows) systems?
Hi Grub2 Development team, I've worked with a colleague to successfully implement ICHxM SMBUS PLL overclocking using grub2 as described here: http://forum.notebookreview.com/showthread.php?p=5569693 This is great as it means an overclocked CPU state from the bootloader, providing a somewhat universal solution regardless of operating system being used. The module developed 'setfsb.mod' I presume must exist on a Linux partition. For non Linux users, it is possible to load the grub2 package and modules on an ntfs filesystem? If so, is there some easy to follow instructions on how to go about doing that? Nando ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: gettext: commands/hdparm.c
Jordi Mallach wrote:
> On Sun, Dec 06, 2009 at 06:25:33PM +, Carles Pina i Estany wrote:
> > grub_printf ("Model: \"%.40s\"\n", le16_to_char (tmp, &idw[27],
> > 40)); grub_printf ("Firmware: \"%.8s\"\n", le16_to_char (tmp,
> > &idw[23], 8)); grub_printf ("Serial: \"%.20s\"\n", le16_to_char
> > (tmp, &idw[10], 20));
> > To have a proper alignment it needs to code something (dynamic
> > "tab").
> >
> > I could change it to:
> > grub_printf (_("Model:\t\"%.40s\"\n"), le16_to_char (tmp, &idw[27],
> > 40)); grub_printf (_("Firmware:\t\"%.8s\"\n"), le16_to_char (tmp,
> > &idw[23], 8)); grub_printf (_("Serial:\t\"%.20s\"\n"), le16_to_char
> > (tmp, &idw[10], 20));
>
> It's not unusual to see stuff like this, but again, a small percent of
> translators will actually try to figure out if the string is correctly
> aligned or how many \t's they need to use (by manually calculating how
> the string will look, by reading the source code, or using qemu).
>
> If the alignment is just a cosmetic enhancement, dropping it could be
> a reasonable option.
>
Yes, it is only cosmetic - feel free to drop it.
--
Regards,
Christian Franke
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Request: hdparm module with -X
Nando wrote: > > I was pleasantly surprised when I saw a hdparm module as part of > grub2. So I tried the -X > parameter as is provided by the linux command line finding it > isn't implemented. eg: > > # hdparm -X udma5 /dev/sda > > Can the development team consider adding this feature? A number of > ppl's bios is incorrectly setting interfaces to UDMA2/MDMA2, > particularly on pata optical drive interfaces which users are using a > 2.5" HDDs instead via an optical bay caddy. The workaround being to > wait for a (slow) Linux/Windows boot and then typing the above > commandline. Doing this at the grub2 bootloader level being more > preferable. > OK, added to my local TODO list :-) Please note that GRUB hdparm does only work in conjunction with the ata+ata_pthru modules because a PC BIOS does not provide any ATA pass-through functionality. A 'hdparm -X' would only help if the actual boot works with ata.mod instead of biosdisk.mod. -- Regards, Christian Franke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Easy grub2 installation for non Linux (Windows) systems?
Nando wrote: > For non Linux users, it is possible to load the grub2 package and > modules on an ntfs filesystem? ... > Yes, GRUB 1.97 builds and runs out-of-the-box on Cygwin. (Note: requires previous binutils-20080624-2 due to a regression in ld from binutils-2.19.51-1) 1.96 is available as a Cygwin package, 1.97 will be provided when binutils regression is fixed. -- Regards, Christian Franke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Easy grub2 installation for non Linux (Windows) systems?
Hi Christian, Thank you. I'll keep an eye open for the 1.97 Cygwin package. Regards, Nando On Wed, Dec 9, 2009 at 11:45 PM, Christian Franke < christian.fra...@t-online.de> wrote: > Nando wrote: > > For non Linux users, it is possible to load the grub2 package and > > modules on an ntfs filesystem? ... > > > > Yes, GRUB 1.97 builds and runs out-of-the-box on Cygwin. > (Note: requires previous binutils-20080624-2 due to a regression in ld > from binutils-2.19.51-1) > > 1.96 is available as a Cygwin package, 1.97 will be provided when > binutils regression is fixed. > > -- > Regards, > Christian Franke > > > > > > ___ > 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
Re: [PATCH] Introduce xasprintf
On Mon, Dec 07, 2009 at 04:48:24PM +, Colin Watson wrote: > > I agree it's suboptimal, but I'm not sure this is possible without > shipping our own vsprintf implementation, which I would like to avoid > (gnulib does this properly, but it's much larger). For util/ code size is not such a big deal. Maintainability is much more important. If you need more Gnulib modules added, just let me know; there's no problem with importing more of 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: Just a cosmetic question about grub_vprintf()?
On Sat, Dec 05, 2009 at 09:58:01PM +, rubisher wrote: > +AC_ARG_ENABLE([sparse], > + AS_HELP_STRING([--enable-sparse], > + [enable sparse code checking]), , > +enable_sparse=no > +) > + > +# Set cgcc as compiler and add sparse flags if --enable-sparse was specified. > +if test "$enable_sparse" = "yes"; then > +CC="REAL_CC=$CC cgcc" > +CFLAGS="$CFLAGS -Wbitwise -Wnon-pointer-null" > +TARGET_CC="REAL_CC=$TARGET_CC cgcc" > +TARGET_CFLAGS="$TARGET_CFLAGS -Wbitwise -Wnon-pointer-null" > +fi > + This doesn't seem to be recognized by all versions of GCC we support. If we enable these flags this needs to be checked. -- 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: Miscellaneous file cleanup
On Sat, Dec 05, 2009 at 03:29:13PM -0600, Bruce Dubbs wrote:
> Robert Millan wrote:
>> On Fri, Dec 04, 2009 at 06:05:37PM -0600, Bruce Dubbs wrote:
>>> + docs/{grub.info,version.texi,stamp-vti}
>>
>> This seems bash-specific. Have you tested it with another shell?
>
> No I didn't. Sorry about that. Try this patch.
Thanks, committed.
--
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: Broken common.rmk change
On Mon, Dec 07, 2009 at 10:23:51PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > Seth proposed a hinting technique: > search --fs_uuid ... -s root --hint hd0,1 > then hd0,1 will be checked first and only on failure it will revert to > scanning Sounds good. -- 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: [RFC] Dynamic device.map
On Mon, Dec 07, 2009 at 05:25:22PM +, Colin Watson wrote: > On Mon, Dec 07, 2009 at 02:28:06PM +, Colin Watson wrote: > > As Robert said recently, we're trying to get rid of our reliance on > > device.map. Right now, it is still necessary to at least have entries in > > device.map for any disks you wish to use with GRUB, although they don't > > have to be particularly sensible; any bidirectional mapping will do (at > > least as long as the 'search' command works). > > > > I'd like to make it possible to run with no device.map at all, since > > that makes it possible to plug in new disks without having to > > reconfigure GRUB. Here's a draft patch to do this. I haven't supplied a > > ChangeLog entry yet since it isn't suitable for commit yet, as noted in > > TODO comments, but I'd welcome comments on the approach here. > > Ah, I hadn't noticed r1870, sorry. Am I right in believing that my patch > is obsolete, then? I'm not completely sure, but it seems so. Sorry about that :-( Anyhow, if you find more issues with systems that have no device.map, help is welcome fixing those of course. -- 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: my plan for Multiboot 2
On Mon, Dec 07, 2009 at 05:53:29PM +0100, Samuel Thibault wrote: > Robert Millan, le Mon 07 Dec 2009 16:08:31 +0100, a écrit : > > - Release a new revision of Multiboot 1, with only modifications that > > don't > > alter the spec. I.e. GRUB Legacy continues to be compliant, and we > > don't > > change the signature. These modifications would basically cope with the > > fact that Multiboot 1 is also usable on non-BIOS platforms, take > > advantage > > of modern 64-bit types to define equivalent structures, resolve some > > ambiguities, etc. > > I'm wondering about the multiboot_mod_list structure & 64bits: would > mod_start/end, cmdline and pad become 64bits? I think long-term we should treat ia64 and amd64 as separate architectures. Short-term we don't really support them, except to recognize and load amd64 ELF files. -- 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: my plan for Multiboot 2
Robert Millan wrote: > Hi, > > We have an obvious problem with the Multiboot 2 loader: It's in > severe bitrot. Nobody complains because nobody uses it, which is > understandable given that nobody programs for MB2, because it's not > ready (both in spec and in implementation), and we don't improve it > because nobody complains, etc. You get the point :-) > > I think the approach that was taken has proven wrong. It might have > worked with more manpower, but our time resources are scarce and we have > other priorities. In my opinion, as things stand now it is best if > Multiboot 2 is developed by piggybacking on Multiboot 1 rather than as an > isolated effort. This idea is twofold: both in spec and in implementation. > > Do you plan on removing multiboot2 loader from grub2 and marking multiboot2 draft as abandonded? The only major feature of multiboot2 is tagged mbi but it can be added in compatible way too. > Here's my plan for Multiboot: > > - Release Multiboot 1 as a standalone package, with no modifications. I > will > do this soon when I find some free time (and I think Vladimir had some > cleanup done to the package that isn't yet merged). > I'll merge it when time permits. > - Release a new revision of Multiboot 1, with only modifications that don't > alter the spec. I.e. GRUB Legacy continues to be compliant, and we don't > change the signature. These modifications would basically cope with the > fact that Multiboot 1 is also usable on non-BIOS platforms, take advantage > of modern 64-bit types to define equivalent structures, resolve some > ambiguities, etc. > > Good points. MAny kernels can be leveraged this way to pan-i386 > - Release a new version of Multiboot 1, with only the modifications > necessary > for it to support non-i386 CPUs. In principle, it should be possible to > do > this without affecting the i386 definitions. Hence GRUB Legacy continues > to be compliant. > > - Make loader/i386/multiboot.c CPU-independant, to the extent that this is > possible. The idea is that the most amount of code that can be reasonably > shared, should be. > > I think cpu-independency should come after possible incompatible changes since if we bring bad but compatible decision to non-x86 then it will be difficult to eradicate. I specifically want non-x86 to use only tagger multiboot header and mbi because of their expandability (we'll need it on CPUs like mips where theoretically same kernel could run on a wide range of hardware but needs a lot info for this, more than 8 features per category permit). Another problem is the difficulty to relocate non-tagged mbi. I would like eliminate this problem before going to non-x86 > - Release a new version of Multiboot, based on Multiboot 1, this time > contemplating changes that break compatibility. Proposed changes must > be accompanied with a patch for our loader before they're committed to > the spec. The Multiboot 2 draft in the wiki is a good source of ideas > for improvements, although not necessarily the only one. > > - Repeat last step untill we're satisfied with the result and can dub it > as "Multiboot 2". > > -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: autogen.sh warnings
On Mon, Dec 07, 2009 at 07:21:28PM +, Colin Watson wrote:
> On Mon, Dec 07, 2009 at 11:38:06AM -0600, Bruce Dubbs wrote:
> > configure.ac:176: required file `./config.rpath' not found
> >
> > The can be fixed by `touch config.rpath`
>
> configure does actually run this, so I'd recommend copying the file from
> gettext or gnulib instead.
config.{guess,sub} are automatically updated. Can't config.rpath be
handled the same way?
In any case, this warning is harmless AFAICT.
--
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: Easy grub2 installation for non Linux (Windows) systems?
On Wed, Dec 09, 2009 at 10:08:10PM +1100, Nando wrote: > Hi Grub2 Development team, > > I've worked with a colleague to successfully implement ICHxM SMBUS PLL > overclocking using grub2 as described here: > http://forum.notebookreview.com/showthread.php?p=5569693 > > This is great as it means an overclocked CPU state from the bootloader, > providing a somewhat universal solution regardless of operating system being > used. The module developed 'setfsb.mod' I presume must exist on a Linux > partition. > > For non Linux users, it is possible to load the grub2 package and modules on > an ntfs filesystem? If so, is there some easy to follow instructions on how > to go about doing that? Hi, Note that if you combine GRUB with GPLv2-only code, the resulting binaries aren't legally distributable. If the copyright holders of this GPLv2 code did this on purpose to prevent GPLv3 programs from using it, there isn't much that can be done. However, chances are they just didn't consider this situation, and it's probably no problem to them to have these files relicensed to GPLv2-or-later. -- 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: my plan for Multiboot 2
On Wed, Dec 09, 2009 at 10:51:03PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > Robert Millan wrote: > > Hi, > > > > We have an obvious problem with the Multiboot 2 loader: It's in > > severe bitrot. Nobody complains because nobody uses it, which is > > understandable given that nobody programs for MB2, because it's not > > ready (both in spec and in implementation), and we don't improve it > > because nobody complains, etc. You get the point :-) > > > > I think the approach that was taken has proven wrong. It might have > > worked with more manpower, but our time resources are scarce and we have > > other priorities. In my opinion, as things stand now it is best if > > Multiboot 2 is developed by piggybacking on Multiboot 1 rather than as an > > isolated effort. This idea is twofold: both in spec and in implementation. > > > > > Do you plan on removing multiboot2 loader from grub2 and marking > multiboot2 draft as abandonded? I don't know. Do you think this would be necessary? I was thinking we could gradually replace it in parallel, but I'm open to ideas/suggestions. > I think cpu-independency should come after possible incompatible changes > since if we bring bad but compatible decision to non-x86 then it will be > difficult to eradicate. I don't understand very well; could you give an example of problematic situation? -- 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: my plan for Multiboot 2
Robert Millan wrote: > On Wed, Dec 09, 2009 at 10:51:03PM +0100, Vladimir 'φ-coder/phcoder' > Serbinenko wrote: > >> Robert Millan wrote: >> >>> Hi, >>> >>> We have an obvious problem with the Multiboot 2 loader: It's in >>> severe bitrot. Nobody complains because nobody uses it, which is >>> understandable given that nobody programs for MB2, because it's not >>> ready (both in spec and in implementation), and we don't improve it >>> because nobody complains, etc. You get the point :-) >>> >>> I think the approach that was taken has proven wrong. It might have >>> worked with more manpower, but our time resources are scarce and we have >>> other priorities. In my opinion, as things stand now it is best if >>> Multiboot 2 is developed by piggybacking on Multiboot 1 rather than as an >>> isolated effort. This idea is twofold: both in spec and in implementation. >>> >>> >>> >> Do you plan on removing multiboot2 loader from grub2 and marking >> multiboot2 draft as abandonded? >> > > I don't know. Do you think this would be necessary? I was thinking we could > gradually replace it in parallel, but I'm open to ideas/suggestions. > > If I have multibootdraft correctly in head the only 2 new things are tagged mbi and multi-CPU. We can add tagged MBI to multiboot1 in compatible way but we have to rethink howexactly it will look like - current draft is contradictory and so it's easier to make new one inspired by old ideas than try to rescue old one. Although powerpc is defined in multiboot2 draft it's not implemented in grub2. Safe to assume nobody used it >> I think cpu-independency should come after possible incompatible changes >> since if we bring bad but compatible decision to non-x86 then it will be >> difficult to eradicate. >> > > I don't understand very well; could you give an example of problematic > situation? > > The most obvious are feature bits: we have statically allocated 32 bits, 16 optional, 16 required features. On platforms where OS needs a lot of hardware info it may be too few. Another problem is pointer-rich mbi which needs complicated processing before it can be relocated. Since often it has to be done before launching C code it makes startup assembly unnecessarily complex -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: autogen.sh warnings
Robert Millan wrote:
On Mon, Dec 07, 2009 at 07:21:28PM +, Colin Watson wrote:
On Mon, Dec 07, 2009 at 11:38:06AM -0600, Bruce Dubbs wrote:
configure.ac:176: required file `./config.rpath' not found
The can be fixed by `touch config.rpath`
configure does actually run this, so I'd recommend copying the file from
gettext or gnulib instead.
config.{guess,sub} are automatically updated. Can't config.rpath be
handled the same way?
In any case, this warning is harmless AFAICT.
Yes, it is harmless, but removing it is just more professional. I don't
have a problem with suppressing specific warnings if they have been
considered and found inappropriate.
I'm pretty sure config.rpath only exists for ld. There is is only used
when linking an ELF executable with shared objects. Since GRUB doesn't
create any libraries, then it is not appropriate. An empty config.rpath
is not unreasonable in this case.
config.guess, config.sub, missing, mkinstalldirs, and install-sh are
only copied from /usr/share/automake- as a part of automake.
AFAICT, they are not used in GRUB. I'm pretty sure they are the same on
all architectures, but I could be wrong about that.
-- Bruce
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: autogen.sh warnings
Am Mittwoch, den 09.12.2009, 16:19 -0600 schrieb Bruce Dubbs: > config.guess, config.sub, missing, mkinstalldirs, and install-sh are > only copied from /usr/share/automake- as a part of automake. > AFAICT, they are not used in GRUB. I'm pretty sure they are the same > on > all architectures, but I could be wrong about that. config.guess and config.sub are used by configure. mkinstalldirs is used by the generated Makefile. Looks like configure checks if install-sh is there but except of this it isn't used. missing isn't used because we don't use automake and maintainer mode. -- Felix Zielcke Proud Debian Maintainer and GNU GRUB developer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
RE: Easy grub2 installation for non Linux (Windows) systems?
Hello! No disrespect towards Nando, or you of course Robert, but is it possible that the author of this project may have made himself deliberately unaware of the GPLv3 license, and wasn't aware that it became the licensing scheme (or model) behind everything we do now? For example Nando does it say when he got it started? Next question is of course, Robert when did the GPLv3 license become fact? Ideally this would be the reasoning, both mine and the author's. -- Gregg C Levine hansolofal...@worldnet.att.net "The Force will be with you always." Obi-Wan Kenobi > -Original Message- > From: grub-devel-bounces+hansolofalcon=worldnet.att@gnu.org [mailto:grub-devel- > bounces+hansolofalcon=worldnet.att@gnu.org] On Behalf Of Robert Millan > Sent: Wednesday, December 09, 2009 4:58 PM > To: The development of GNU GRUB > Subject: Re: Easy grub2 installation for non Linux (Windows) systems? > > On Wed, Dec 09, 2009 at 10:08:10PM +1100, Nando wrote: > > Hi Grub2 Development team, > > > > I've worked with a colleague to successfully implement ICHxM SMBUS PLL > > overclocking using grub2 as described here: > > http://forum.notebookreview.com/showthread.php?p=5569693 > > > > This is great as it means an overclocked CPU state from the bootloader, > > providing a somewhat universal solution regardless of operating system being > > used. The module developed 'setfsb.mod' I presume must exist on a Linux > > partition. > > > > For non Linux users, it is possible to load the grub2 package and modules on > > an ntfs filesystem? If so, is there some easy to follow instructions on how > > to go about doing that? > > Hi, > > Note that if you combine GRUB with GPLv2-only code, the resulting binaries > aren't legally distributable. If the copyright holders of this GPLv2 code > did this on purpose to prevent GPLv3 programs from using it, there isn't much > that can be done. > > However, chances are they just didn't consider this situation, and it's > probably no problem to them to have these files relicensed to GPLv2-or-later. > > -- > Robert Millan ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: autogen.sh warnings
On Wed, Dec 09, 2009 at 04:19:08PM -0600, Bruce Dubbs wrote:
> Robert Millan wrote:
>> On Mon, Dec 07, 2009 at 07:21:28PM +, Colin Watson wrote:
>>> On Mon, Dec 07, 2009 at 11:38:06AM -0600, Bruce Dubbs wrote:
configure.ac:176: required file `./config.rpath' not found
The can be fixed by `touch config.rpath`
>>> configure does actually run this, so I'd recommend copying the file from
>>> gettext or gnulib instead.
>>
>> config.{guess,sub} are automatically updated. Can't config.rpath be
>> handled the same way?
>>
>> In any case, this warning is harmless AFAICT.
>
> Yes, it is harmless, but removing it is just more professional. I don't
> have a problem with suppressing specific warnings if they have been
> considered and found inappropriate.
>
> I'm pretty sure config.rpath only exists for ld. There is is only used
> when linking an ELF executable with shared objects. Since GRUB doesn't
> create any libraries, then it is not appropriate. An empty config.rpath
> is not unreasonable in this case.
I wouldn't spend a lot of time with this. If you think it's better to
remove the config.rpath warning, I don't mind. If you find an easy way
to have autogen.sh update it, all the better. I'd just like to avoid the
burden of perpetually updating this file by hand.
--
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: Easy grub2 installation for non Linux (Windows) systems?
On Wed, Dec 09, 2009 at 05:40:56PM -0500, Gregg C Levine wrote: > Hello! > No disrespect towards Nando, or you of course Robert, but is it possible > that the author of this project may have made himself deliberately unaware > of the GPLv3 license, and wasn't aware that it became the licensing scheme > (or model) behind everything we do now? Yes, of course. > For example Nando does it say when he got it started? Next question is of > course, Robert when did the GPLv3 license become fact? Version 3 was published June 29, 2007. GRUB switched shortly after, in July 21. -- 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: [RFC] Dynamic device.map
On Wed, Dec 09, 2009 at 10:49:15PM +0100, Robert Millan wrote: > On Mon, Dec 07, 2009 at 05:25:22PM +, Colin Watson wrote: > > Ah, I hadn't noticed r1870, sorry. Am I right in believing that my patch > > is obsolete, then? > > I'm not completely sure, but it seems so. Sorry about that :-( Don't apologise for doing something before I got round to it! :-) > Anyhow, if you find more issues with systems that have no device.map, help > is welcome fixing those of course. I'm trying to figure out how to make Debian's grub-installer operate without a device.map; it has various legacy bits and pieces that need conversion, and I'm working on these. Along the way, though, I noticed that grub-install still unconditionally creates a device.map. This seems likely to become confusing if devices are changing around a lot, since it's never updated. I'd like to get to the point where it doesn't do this by default. How about we add support for an option to disable this, and make grub-installer and the Debian maintainer scripts pass it once they're ready? Some time later, we can flip the default value. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: gettext: commands/hdparm.c
On Sun, Dec 6, 2009 at 12:25 PM, Carles Pina i Estany wrote:
>
> Hello,
>
> commands/hdparm.c has some grub_printf's:
> grub_printf ("Model: \"%.40s\"\n", le16_to_char (tmp, &idw[27], 40));
> grub_printf ("Firmware: \"%.8s\"\n", le16_to_char (tmp, &idw[23], 8));
> grub_printf ("Serial: \"%.20s\"\n", le16_to_char (tmp, &idw[10], 20));
>
> To have a proper alignment it needs to code something (dynamic "tab").
>
> I could change it to:
> grub_printf (_("Model:\t\"%.40s\"\n"), le16_to_char (tmp, &idw[27], 40));
> grub_printf (_("Firmware:\t\"%.8s\"\n"), le16_to_char (tmp, &idw[23], 8));
> grub_printf (_("Serial:\t\"%.20s\"\n"), le16_to_char (tmp, &idw[10], 20));
>
> Or just don't translate Model/Firmware/Serial (leave like it's now)
>
> Or do the dynamic coding that maybe it's not needed...
>
> Thoughts?
How about using the string width specifier to control padding?
grub_printf ("%20s \"%.40s\"\n", _("Model:"), le16_to_char (tmp, &idw[27], 40));
>
> --
> Carles Pina i Estany
> http://pinux.info
>
>
> ___
> 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
Re: autogen.sh warnings
Felix Zielcke wrote: Am Mittwoch, den 09.12.2009, 16:19 -0600 schrieb Bruce Dubbs: config.guess, config.sub, missing, mkinstalldirs, and install-sh are only copied from /usr/share/automake- as a part of automake. AFAICT, they are not used in GRUB. I'm pretty sure they are the same on all architectures, but I could be wrong about that. config.guess and config.sub are used by configure. Called yes, and it will give errors if not present, but is the output used? Looking at configure, I don't think so. mkinstalldirs is used by the generated Makefile. It looks like a part of the generated install and dist targets. Looking at the code of mkinstalldirs, it fundamentally does a mkdir -p. It can change the permissions of the final directory, but that is not used by the Makefile. It does do some cleanup for NextStep and OpenStep and makes sure that GNU mkdir is used on Sun. The odds this will change in the future are very small. Looks like configure checks if install-sh is there but except of this it isn't used. missing isn't used because we don't use automake and maintainer mode. Looks that way to me too. -- Bruce P.S. Some may ask why I am putting so much into the warnings generated by the build process. There are a few reasons. First, I feel that persistent warnings tend to make developers ignore ALL warnings and that makes it very easy to miss something relevant. Second, it gives new developers a feeling that the original developers paid attention to details and will give confidence that the rest of the package is correct. Third, it scratches an itch for me. :) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Build failures on Ubuntu due to gettext
Hi Vladimir, Colin,
On Dec/08/2009, Vladimir '??-coder/phcoder' Serbinenko wrote:
> > My patch made the following transformation:
> >
> > - grub_printf (_("literal string"));
> > + grub_printf ("%s", _("literal string"));
> >
> > This was only necessary in five places, so I doubt that a function is
> > worth it.
> >
> Then it's not worth it. But again we haven't gettext'ized whole grub2
> yet to know for sure. Perhaps a macro so we can change it later if
> necessary?
Vladimir, Colin: see the attached patch with the Colin changes but
macrofied.
Should compile fine in Ubuntu, but I have not tried.
Are we happy with grub_put_ function name?
Colin: could you apply this patch or similar?
I don't want to push more gettext strings before setting up the basic
infrastructure to avoid working twice.
Thanks,
--
Carles Pina i Estany
http://pinux.info
=== modified file 'include/grub/misc.h'
--- include/grub/misc.h 2009-12-08 00:08:52 +
+++ include/grub/misc.h 2009-12-09 23:51:07 +
@@ -34,6 +34,8 @@
/* XXX: If grub_memmove is too slow, we must implement grub_memcpy. */
#define grub_memcpy(d,s,n) grub_memmove ((d), (s), (n))
+#define grub_put_(str) grub_printf("%s", (str))
+
void *EXPORT_FUNC(grub_memmove) (void *dest, const void *src, grub_size_t n);
char *EXPORT_FUNC(grub_strcpy) (char *dest, const char *src);
char *EXPORT_FUNC(grub_strncpy) (char *dest, const char *src, int c);
=== modified file 'normal/menu_entry.c'
--- normal/menu_entry.c 2009-12-08 00:08:52 +
+++ normal/menu_entry.c 2009-12-09 23:46:36 +
@@ -1000,7 +1000,7 @@ run (struct screen *screen)
grub_cls ();
grub_printf (" ");
- grub_printf_ (N_("Booting a command list"));
+ grub_put_ (N_("Booting a command list"));
grub_printf ("\n\n");
@@ -1182,6 +1182,6 @@ grub_menu_entry_run (grub_menu_entry_t e
grub_print_error ();
grub_errno = GRUB_ERR_NONE;
grub_putchar ('\n');
- grub_printf_ (N_("Press any key to continue..."));
+ grub_put_ (N_("Press any key to continue..."));
(void) grub_getkey ();
}
=== modified file 'normal/menu_text.c'
--- normal/menu_text.c 2009-12-08 00:08:52 +
+++ normal/menu_text.c 2009-12-09 23:47:04 +
@@ -40,7 +40,7 @@ void
grub_wait_after_message (void)
{
grub_putchar ('\n');
- grub_printf_ (N_("Press any key to continue..."));
+ grub_put_ (N_("Press any key to continue..."));
(void) grub_getkey ();
grub_putchar ('\n');
}
@@ -206,7 +206,7 @@ entry is highlighted.");
if (nested)
{
grub_printf ("\n");
- grub_printf_ (N_("ESC to return previous menu."));
+ grub_put_ (N_("ESC to return previous menu."));
}
}
}
@@ -655,7 +655,7 @@ notify_execution_failure (void *userdata
grub_errno = GRUB_ERR_NONE;
}
grub_printf ("\n ");
- grub_printf_ (N_("Failed to boot default entries.\n"));
+ grub_put_ (N_("Failed to boot default entries.\n"));
grub_wait_after_message ();
}
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Build failures on Ubuntu due to gettext
Hi,
As Vladimir spotted:
On Dec/09/2009, Carles Pina i Estany wrote:
This...:
> +#define grub_put_(str) grub_printf("%s", (str))
should be:
#define grub_put_(str) grub_printf(N_ ("%s"), (str))
If you Colin commit it don't propagate my mistake.
--
Carles Pina i Estany
http://pinux.info
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: autogen.sh warnings
Am Mittwoch, den 09.12.2009, 17:28 -0600 schrieb Bruce Dubbs:
> Felix Zielcke wrote:
> > Am Mittwoch, den 09.12.2009, 16:19 -0600 schrieb Bruce Dubbs:
> >> config.guess, config.sub, missing, mkinstalldirs, and install-sh
> are
> >> only copied from /usr/share/automake- as a part of
> automake.
> >> AFAICT, they are not used in GRUB. I'm pretty sure they are the
> same
> >> on
> >> all architectures, but I could be wrong about that.
> >
> > config.guess and config.sub are used by configure.
>
> Called yes, and it will give errors if not present, but is the output
> used? Looking at configure, I don't think so.
Just looking at the second result for searching config.guess in
configure makes it pretty clear for what they're used:
$SHELL "$ac_aux_dir/config.sub" sun4 >/dev/null 2>&1 ||
as_fn_error "cannot run $SHELL $ac_aux_dir/config.sub" "$LINENO" 5
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking build system type" >&5
$as_echo_n "checking build system type... " >&6; }
if test "${ac_cv_build+set}" = set; then :
$as_echo_n "(cached) " >&6
else
ac_build_alias=$build_alias
test "x$ac_build_alias" = x &&
ac_build_alias=`$SHELL "$ac_aux_dir/config.guess"`
test "x$ac_build_alias" = x &&
as_fn_error "cannot guess build type; you must specify one" "$LINENO" 5
ac_cv_build=`$SHELL "$ac_aux_dir/config.sub" $ac_build_alias` ||
as_fn_error "$SHELL $ac_aux_dir/config.sub $ac_build_alias failed" "$LINENO" 5
[...]
build=$ac_cv_build
The output of ./config.sub $(./config.guess) is used as build system
type, if you don't use --build option.
--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Build failures on Ubuntu due to gettext
Hi,
On Dec/10/2009, Carles Pina i Estany wrote:
As Richard commented (thanks):
> #define grub_put_(str) grub_printf(N_ ("%s"), (str))
#define grub_put_(str) grub_printf("%s", N (str))
I should not be sending patches when too tired / without properly
testing with the .po that I've just deleted doing some other tests :-)
Now should be fine and after it's committed next gettext patches will
use it when needed.
Cheers,
--
Carles Pina i Estany
http://pinux.info
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: autogen.sh warnings
On Wed, Dec 09, 2009 at 05:28:21PM -0600, Bruce Dubbs wrote:
> Felix Zielcke wrote:
>> Am Mittwoch, den 09.12.2009, 16:19 -0600 schrieb Bruce Dubbs:
>>> config.guess, config.sub, missing, mkinstalldirs, and install-sh are
>>> only copied from /usr/share/automake- as a part of automake.
>>> AFAICT, they are not used in GRUB. I'm pretty sure they are the same
>>> on all architectures, but I could be wrong about that.
>>
>> config.guess and config.sub are used by configure.
>
> Called yes, and it will give errors if not present, but is the output
> used? Looking at configure, I don't think so.
Yes. All the checks that rely on ${host,target,build}_{os,cpu,vendor}
variables use those.
> P.S. Some may ask why I am putting so much into the warnings generated
> by the build process. There are a few reasons. First, I feel that
> persistent warnings tend to make developers ignore ALL warnings and that
> makes it very easy to miss something relevant.
Agreed.
--
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: [RFC] Dynamic device.map
On Wed, Dec 09, 2009 at 11:04:43PM +, Colin Watson wrote: > > I'm trying to figure out how to make Debian's grub-installer operate > without a device.map; it has various legacy bits and pieces that need > conversion, and I'm working on these. > > Along the way, though, I noticed that grub-install still unconditionally > creates a device.map. This seems likely to become confusing if devices > are changing around a lot, since it's never updated. I'd like to get to > the point where it doesn't do this by default. How about we add support > for an option to disable this, and make grub-installer and the Debian > maintainer scripts pass it once they're ready? Some time later, we can > flip the default value. Why is this option necessary? If we removed automated generation of device.map, user can still call grub-mkdevicemap manually. But first we'd need to figure out what we do with the "set root=xxx" backward compatibility hack. Has it been a while long enough that we can remove support for GRUB installs that didn't come with UUID support? If we don't do anything on grub-mkconfig side and remove device.map, we'll end up with things like "set root=(/dev/sda1)" which is not just useless but also utterly confusing. -- 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: my plan for Multiboot 2
On Wed, Dec 09, 2009 at 11:17:54PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > >> I think cpu-independency should come after possible incompatible changes > >> since if we bring bad but compatible decision to non-x86 then it will be > >> difficult to eradicate. > >> > > > > I don't understand very well; could you give an example of problematic > > situation? > > > > > > The most obvious are feature bits: we have statically allocated 32 bits, > 16 optional, 16 required features. On platforms where OS needs a lot of > hardware info it may be too few. > Another problem is pointer-rich mbi which needs complicated processing > before it can be relocated. Since often it has to be done before > launching C code it makes startup assembly unnecessarily complex It's not essential that we add non-x86 support first. I only suggested it because then non-x86 platforms wouldn't have to wait for the whole drafting process, and I wouldn't want to discuss spec decisions with the pressure of having it ready ASAP in order to support new platforms. -- 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: Build failures on Ubuntu due to gettext
On Tue, Dec 08, 2009 at 12:10:34AM +, Colin Watson wrote:
>
> My patch made the following transformation:
>
> - grub_printf (_("literal string"));
> + grub_printf ("%s", _("literal string"));
>
> This was only necessary in five places, so I doubt that a function is
> worth it.
I think we all agree that it's safer to avoid gettextizing the template;
furthemore I agree with Colin that this seems to be a correct approach,
but our case is unusual in that we're very pressed for size.
Even if we're only discussing a change in five places, I assume we're
going to find this situation in lots of calls throurough GRUB code. If
this is so, it really calls for a solution that doesn't make GCC generate
two memory references and pass two arguments.
So first of all, how many times are we going to find similar calls that
need to be adjusted in some way? If we're going to find many of them (as
I expect), I think this warrants adding a new function (which, btw, will
also make GRUB slightly faster).
--
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: Documenting the GRUB configure (during build)
On Sat, Dec 05, 2009 at 03:42:24PM -0600, Bruce Dubbs wrote: > > I'm afraid I don't agree that the solution to documenting changes is not > to document anything. That may be a little harsh, but I firmly believe > that documentation is key to acceptance. It's OK. Well my concern is about long-term maintainability. We're very busy all the time, and redundancy in our codebase often results in birot. Can I count on your commitment that you'll be around to adjust this documentation if it gets out of sync, etc? -- 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: autogen.sh warnings
Felix Zielcke wrote:
Am Mittwoch, den 09.12.2009, 17:28 -0600 schrieb Bruce Dubbs:
Felix Zielcke wrote:
Am Mittwoch, den 09.12.2009, 16:19 -0600 schrieb Bruce Dubbs:
config.guess and config.sub are used by configure.
Called yes, and it will give errors if not present, but is the output
used? Looking at configure, I don't think so.
Just looking at the second result for searching config.guess in
configure makes it pretty clear for what they're used:
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking build system type" >&5
$as_echo_n "checking build system type... " >&6; }
if test "${ac_cv_build+set}" = set; then :
$as_echo_n "(cached) " >&6
else
ac_build_alias=$build_alias
test "x$ac_build_alias" = x &&
ac_build_alias=`$SHELL "$ac_aux_dir/config.guess"`
test "x$ac_build_alias" = x &&
as_fn_error "cannot guess build type; you must specify one" "$LINENO" 5
ac_cv_build=`$SHELL "$ac_aux_dir/config.sub" $ac_build_alias` ||
as_fn_error "$SHELL $ac_aux_dir/config.sub $ac_build_alias failed" "$LINENO" 5
[...]
build=$ac_cv_build
OK, I see now what config.sub does and it is ultimately defining host_os
and target_cpu used by grub in several .in files.
On the other hand, config.guess is used to get build_cpu and build_os
and I don't see that being used at all right now by grub.
One thing I think we can agree on is that tracing through
autoconf/automake generated files is not easy. However, it's the only
way I know of to really understand what is going on. The autoconf
manual really doesn't explain it very well, at least for me. There are
several tutorials and books on autotools, but none that I've seen go
into the level of complexity required by grub.
-- Bruce
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: my plan for Multiboot 2
I don't have much knowledge in multiboot yet, but this case comes to my mind: Since GRUB2 is extensible (using modules), over time third party modules would be developed and they may want to pass their own parameters to kernels; so we should provide some scheme to differentiate standard (i.e, multiboot) parameters vs. non-standard (i.e, third-party) parameters. regards, -- bvk.chaitanya ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Broken common.rmk change
On Thu, Dec 10, 2009 at 3:15 AM, Robert Millan wrote: > On Mon, Dec 07, 2009 at 10:23:51PM +0100, Vladimir 'φ-coder/phcoder' > Serbinenko wrote: >> Seth proposed a hinting technique: >> search --fs_uuid ... -s root --hint hd0,1 >> then hd0,1 will be checked first and only on failure it will revert to >> scanning I assume, this --hint argument can be given multiple times, and while searching their order is followed ??? regards, -- bvk.chaitanya ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
