possible? load extension ROMs when BIOS doesn't (e.g. laptops)

[richardvo...@gmail.com]

I searched and couldn't find anything like this in the archives,
apologies if this has already been discussed or is far off-topic.

Many notebook computers can't boot from PCI-express expansion cards
(example ExpressCard SATA controllers) for the simple reason that,
although the card contains an extension BIOS with boot support, the
main BIOS didn't invoke it.

Would it be possible for a bootloader on an internal (recognized by
main BIOS) disk to call these missed extension ROMs so that the
attached disk becomes available for boot?  The only thing hurdle I'm
aware of, (as an experienced programmer of microcontrollers and
user-mode x86, but never x86 boot/kernel code) would be if the main
BIOS has not performed Plug-n-Play configuration of these cards so the
BIOS isn't even mapped into memory yet.  I'm pretty sure that PCI and
PCI-express cards would have been configured, and PCMCIA cards
wouldn't, and I don't know whether ExpressCard would be waiting for
some form of card services.

Does this sound like something that can/should be solved in the bootloader?


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

Re: [PATCH] Some distributions ship compilers that include -fPIE in the default specs (Gentoo Hardened)

[richardvo...@gmail.com]

Why not just check if the compiler accepts -fno-PIE and use it?  No
harm done if -fPIE wasn't default, right?

On Tue, Sep 1, 2009 at 4:46 PM, Magnus Granberg wrote:
> Hi
>
> On Gentoo Hardened we compile with -fPIE in the default specs and
> grub fails to compile.
> This patch check if the compiler use -fPIE in the default specs and add
> -fno-PIE to TARGET_CFLAGS.
>
> --- aclocal.m4.zorry    2008-02-03 14:11:28.0 +0100
> +++ aclocal.m4  2009-08-22 01:05:56.0 +0200
> @@ -362,3 +362,31 @@
>   AC_MSG_RESULT([no])
>  [fi]
>  ])
> +
> +dnl Check if the C compiler supports `-fPIE'.
> +AC_DEFUN(grub_CHECK_PIE,[
> +[# Position independent executable.
> +pie_possible=yes]
> +AC_MSG_CHECKING([whether `$CC' has `-fPIE' as default])
> +# Is this a reliable test case?
> +AC_LANG_CONFTEST([[
> +#ifdef __PIE__
> +int main() {
> +       return 0;
> +}
> +#else
> +#error NO __PIE__ DEFINED
> +#endif
> +]])
> +
> +[# `$CC -c -o ...' might not be portable.  But, oh, well...  Is calling
> +# `ac_compile' like this correct, after all?
> +if eval "$ac_compile -S -o conftest.s" 2> /dev/null; then]
> +  AC_MSG_RESULT([yes])
> +  [# Should we clear up other files as well, having called 
> `AC_LANG_CONFTEST'?
> +  rm -f conftest.s
> +else
> +  pie_possible=no]
> +  AC_MSG_RESULT([no])
> +[fi]
> +])
> --- configure.ac.zorry  2008-02-03 14:41:51.0 +0100
> +++ configure.ac        2009-09-01 01:05:34.0 +0200
> @@ -251,6 +251,14 @@
>  # Compiler features.
>  #
>
> +# Position independent executable.
> +grub_CHECK_PIE
> +[# Need that, because some distributions ship compilers that include
> +# `-fPIE' in the default specs.
> +if [ x"$pie_possible" = xyes ]; then
> +  TARGET_CFLAGS="$TARGET_CFLAGS -fno-PIE"
> +fi]
> +
>  # Smashing stack protector.
>  grub_CHECK_STACK_PROTECTOR
>  [# Need that, because some distributions ship compilers that include
>
> ---
> Hardened-Development Overlay
> Magnus Granberg (Zorry) 
>
>
>
>
> ___
> 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: chmod of generated grub.cfg

[richardvo...@gmail.com]

On Sun, Sep 6, 2009 at 12:22 PM, Vladimir 'phcoder'
Serbinenko wrote:
> On Sun, Sep 6, 2009 at 3:38 PM, Colin Watson wrote:
>> On Sun, Sep 06, 2009 at 02:29:03PM +0200, Felix Zielcke wrote:
>>> Currently grub-mkconfig uses chmod 444 on the newly generated grub.cfg
>>> Wouldn't it be better to use 400 now that we have plaintext password
>>> support?
>>> Or should we add support for a GRUB_CHMOD variable so users can override
>>> this setting as they please?
>>
>> I'd prefer to see this done only if they set a password. A GRUB_CHMOD
>> variable seems overkill, though.
> Is there a reason a non-root would like to look at grub.cfg on
> production system? Developers can always override chmod. If there is
> no real reason for non-root to look into grub.cfg I would follow the
> best friend in security considerations called "paranoia" and just use
> mode 400

Shouldn't it be u+rw anyway, or 0600 ?


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

Re: [PATCH] save_env variable_name=value

[richardvo...@gmail.com]

On Fri, Sep 11, 2009 at 4:43 PM, Pavel Roskin  wrote:
> On Thu, 2009-09-03 at 17:08 +0200, Robert Millan wrote:
>
>> Pavel, please comment on this when you can.  It seems to me that doing it
>> in grub-mkconfig would require less ad-hoc code in loadenv.mod and make it
>> more efficient.
>
> I don't see how grub-mkconfig could compensate for a missing feature in
> save_env.  Perhaps I'm missing the context here.

AFAICT, it's grub.cfg that has to work around using two commands instead of one.

Therefore grub-mkconfig has to generate a longer grub.cfg (not sure
how this makes grub-mkconfig uglier), but that's an incomplete
assessment.  There's also a different burden placed on user-edited
configs and usage of the grub console, correct?

I don't think that the suggestion was meant to save a few bytes in
grub-mkconfig.  I think it was suggesting a nicer interface for users
working in the console.

>
> --
> Regards,
> Pavel Roskin
>
>
> ___
> 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: [GITGRUB] New menu interface (implementation)

[richardvo...@gmail.com]

On Sat, Sep 19, 2009 at 1:45 PM, Michal Suchanek  wrote:
> Hello
>
> why does the menu system have a glyph drawing function?
>
> Is the one in font.c not suitable?
>
> Why are there two methods for returning text width and height, one in
> gfx_region in pixels, the other in text_region in characters? Does
> size in characters make any sense? There might be proportional fonts
> or at least fonts of different size in the future.

Pixels and proportional fonts are meaningless to a serial console.

>
> Thanks
>
> Michal
>
>
> ___
> 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: -Werror and --disable-werror

[richardvo...@gmail.com]

On Sat, Sep 19, 2009 at 9:12 AM, Vladimir 'phcoder' Serbinenko
 wrote:
> Robert Millan wrote:
>> Hi,
>>
>> -Werror is not in effect.  This will help ensuring that all new code is
>> checked to be warning-free before commit (incidentally, I found a newly
>> introduced bug thanks to this just minutes before enabling it).
>>
>>
> If you mean this change:
>
> +  /* Any value different than `p.offset' will satisfy the check during
> +     first loop.  */
> +  lastaddr = !p.offset;
> +
>
> Then there was no bug here.
>      if (labeln && lastaddr == p.offset)
>        return grub_error (GRUB_ERR_BAD_PART_TABLE, "loop detected");
>
>      labeln++;
>      if ((labeln & (labeln - 1)) == 0)

This is a check for being an integral power of 2 (or 0), i.e. having a
single bit set.  Was that the intent?  It's probably worth an
explanatory comment for the sake of those who aren't familiar with the
test.

>        lastaddr = p.offset;
>
> labeln is 0 during first loop run and then lastaddr is set. I explicitly
> omitted initing variables to have smaller loop detector

I suspect initializing lastaddr, which takes place outside the loop,
is less expensive than testing labeln on every iteration.

>> Since -Werror may be a problem in some situations, I've added a
>> --disable-werror switch, which does the obvious thing.
>>
>>
>
>
>
> ___
> 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]: Save boot record before writing to the dest_drive

[richardvo...@gmail.com]

On Sat, Sep 19, 2009 at 5:09 PM, Colin Watson  wrote:
> On Sat, Sep 19, 2009 at 11:10:49PM +0200, Robert Millan wrote:
>> I'm sorry, but I really see very limited usefulness in this.  It's only
>> potentially useful to expert users, but those should know how to backup
>> sectors in their disk already.
>
> Of course, like many restore facilities, it's only useful if you
> remembered or realised that you needed to do the backup before the data
> was overwritten ...

As a user of grub, I think that automatically making a backup is nice,
as long as:
(1) I can specify not to make the backup
(2) It doesn't overwrite any existing file unless I explicitly specify
the filename

>
> It would be nice to have a straightforward answer to the sort of bug
> report that goes "argh, I installed Debian/Ubuntu and it ate the special
> magic boot loader I carefully installed there five years ago", I must
> admin.
>
> --
> Colin Watson                                       [cjwat...@ubuntu.com]
>
>
> ___
> 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: [GITGRUB] New menu interface (implementation)

[richardvo...@gmail.com]

On Sun, Sep 20, 2009 at 3:31 AM, Michal Suchanek  wrote:
> 2009/9/19 richardvo...@gmail.com :
>> On Sat, Sep 19, 2009 at 1:45 PM, Michal Suchanek  wrote:
>>> Hello
>>>
>>> why does the menu system have a glyph drawing function?
>>>
>>> Is the one in font.c not suitable?
>>>
>>> Why are there two methods for returning text width and height, one in
>>> gfx_region in pixels, the other in text_region in characters? Does
>>> size in characters make any sense? There might be proportional fonts
>>> or at least fonts of different size in the future.
>>
>> Pixels and proportional fonts are meaningless to a serial console.
>>
> So is element placement.

I know of multiple systems that support multiple columns, status bar,
menu bar, popup dialogs, etc in text mode over a serial connection.
If those things are considered out of scope for a bootloader, I'd tend
to agree.  But people seem to be defining rich interfaces for grub and
to do so requires the ability to measure sizes in characters.

>
> Thanks
>
> Michal
>
>
> ___
> 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] Create environment block safely

[richardvo...@gmail.com]

On Wed, Sep 30, 2009 at 5:54 PM, Colin Watson  wrote:
> If grub-editenv create is interrupted, it's theoretically possible for
> it to create an incomplete block that future grub-editenv calls won't
> recognise. It would be better for it to atomically create either a
> complete block or nothing. Any objections?

Be aware that this may lose security settings.  Write-in-place is also
different wrt hard links, but it would be pretty odd for that file to
have additional hard links.

You might also need to check for the alternate name, in case the
operation failed after writing the new content and unlinking the old
file, but before renaming the new file.


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

Re: [PATCH] Create environment block safely

[richardvo...@gmail.com]

>> You might also need to check for the alternate name, in case the
>> operation failed after writing the new content and unlinking the old
>> file, but before renaming the new file.
>
> There is no old file here, or if there is then the user has already
> explicitly indicated that they don't care about it. There is no unlink
> call in my code (and wouldn't be even if this weren't a create
> operation; no need to bother when you're renaming over the top anyway).

I guess I didn't look closely enough at the rename docs:

The rename() system call causes the link named old to be renamed as new.
 If new exists, it is first removed.  Both old and new must be of the same
 type (that is, both must be either directories or non-directories) and
 must reside on the same file system.

 The rename() system call guarantees that an instance of new will always
 exist, even if the system should crash in the middle of the operation.


So my unease was unfounded.


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

Re: Support for howmany option in grub2

[richardvo...@gmail.com]

On Fri, Oct 2, 2009 at 3:53 PM, Robert Millan  wrote:
> On Sun, Sep 27, 2009 at 08:04:51PM +0200, j...@hkfree.org wrote:
>> Hello,
>> I am using Debian GNU/Linux as my primary system. As a loader I am using 
>> GRUB.
>> Actually I have upgraded to GRUB2. I don't know, if it was feature of 
>> original
>> (legacy) GRUB or it was functionality provided by debian scripts 
>> (update-grub),
>> for generating menu.lst. There was feature - howmany. This option specifies
>> number of kernels, that user wants to have in boot menu. Script, that 
>> modifies
>> menu.lst, use this variable. I like this feature, because I have usually more
>> kernels, but I want to see only last two versions in GRUB menu. I have 
>> created
>> patch, that add support for this to /etc/grub.d/10_linux. I have created this
>> patch against version shipped with Debian (1.97~beta3-1) - I don't know if
>> there are some Debian specific modifications. Also there should be variable
>> GRUB_HOW_MANY propagated from /etc/default/grub (my patch don't do
>> this).
>> Kernel and it's rescue variant is counted as one kernel.
>>
>> I have already reported this bug to Debian BTS:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548600
>
> Does anyone else think we want an option for this?  It seems like "feature
> creep".

IMO this is the responsibility of the distro.  The distro's package
manager is presumably what adds and removes kernels, there's no way
that the grub scripts should be expected to know when past kernels
have been removed.

With more manual-install oriented distros like gentoo, trying to have
grub maintain the kernel list like this would be insane, since the
local admin determines the naming convention.

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


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

Re: [GITGRUB] New menu interface (implementation)

[richardvo...@gmail.com]

>>  - the border settings offer many options but I miss the option for
>>   - setting the text border explicitly to single/double border
>> without using an image
>
> I think image is most flexible, who want ascii border in graphic mode
> ? BTW, border in graphic mode doesn't necessary be full character
> size, so text may not draw properly anyway. About the single/double
> border, it's more suitable to config them using styles other that
> property.

Can't one obtain an N pixel solid border by using a parent panel with
background = border color, and client panel just a few pixels smaller
using the margin-positioning directives?

This should give a border without needing a new set of commands, nor
image files.


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

Re: [GITGRUB] New menu interface (implementation)

[richardvo...@gmail.com]

> Perhaps the naming of margin_* property is a little misleading,
> perhaps I can rename them distance_* to remind it they're used as
> fixed distance to borders of parent.

That's undoubtedly the problem.

For example, Motif uses the term "attach" to achieve fixed distance
from the edge of the parent (or from a sibling component).

See e.g. http://www.cs.cf.ac.uk/Dave/X_lecture/node8.html


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

Re: [GITGRUB] New menu interface (implementation)

[richardvo...@gmail.com]

> Hi,
>
> I think you've overlooked a detail about grub's menu layout. The
> smallest elements, text and image, both have fixed size, The largest
> element, the screen, also have fixed size, therefore, we need to
> adjust the middle layers to fit both ends, it's not as simple as it
> seems.
>
> There are two method to calculate the size of window. It can be
> calculate using children widget, with auto layout, or parent widget,
> with x,y,width,height coordinate, as the smallest and largest element
> are fixed, we need to switch from children determined size to parent
> determined size at some point during the walk of ui tree.
>
> For operation system, the switch is at the window boundary. Consider
> web browser. Inside the browser, elements are placed with layout
> manager, no coordinate is needed, but the browser itself is placed on
> the screen using x,y,width,height coordinate by the OS. For some OS
> like chrome, it seems to incorporate the concept of using the whole
> screen as browser. The menu system support both method, it's just a
> matter of how you define the border, that's, when to switch from
> x,y,width,height positioning to layout manager positioning.
>
> Therefore, it needs to have two set of margin properties:
>
> inner_*, outer_* : calculate from children to parent

I think that "margin" and "padding" are the standard names for this
spacing measurements (distance from content to border) and (distance
from border to bounding box), respectively.  Also in some systems
padding of adjacent elements can overlap.

> attach_* : calculate from parent to children
>
> --
> 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
>


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

Re: [GITGRUB] New menu interface (implementation)

[richardvo...@gmail.com]

> I am suggesting an interface that allows style commands like
>
> style {
>
> (class==button).(text==OK) { 

Re: [GITGRUB] New menu interface (implementation)

[richardvo...@gmail.com]

On Fri, Oct 9, 2009 at 12:09 PM, Michal Suchanek  wrote:
> 2009/10/9 richardvo...@gmail.com :
>>> I am suggesting an interface that allows style commands like
>>>
>>> style {
>>>
>>> (class==button).(text==OK) { 

Re: Handling multiple cores by GRUB

[richardvo...@gmail.com]

On Thu, Oct 15, 2009 at 11:44 AM, James Courtier-Dutton
 wrote:
> 2009/10/14 Robert Millan :
>> But I don't think this would be desireable except in very specific 
>> situations,
>> and I'm not sure which ones.  Perhaps loading a compressed file would be an
>> example (so that uncompression and disk poll can be done in parallel).
>>
>
> Not specifically related, but why is grub reading a file from a USB
> stick so slow when compared with say reading the HD.
> I mean slow, it is about 20 times slower here.

What model USB stick?  Consumer-grade NAND flash controllers really
are 10-15x slower than a recent SATA hard disk.  (7MB/s vs 110MB/s on
read).  Only the expensive SSD, which access many NAND flash chips in
parallel, can meet or exceed hard disk speeds.  And USB 2.0 High Speed
maxes out at about 1/3 of hard disk speed, Firewire 800 or USB 3.0
Ultra or eSATA would overcome that.  But most likely you are just
using slow flash memory with a cheap controller.

>
>
> ___
> 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: [2637] 2009-10-16 Colin Watson

[richardvo...@gmail.com]

On Sat, Oct 17, 2009 at 6:40 AM, Vladimir 'phcoder' Serbinenko
 wrote:
> Robert Millan wrote:
>> On Fri, Oct 16, 2009 at 03:38:44PM +, Colin Watson wrote:
>>
>>> Revision: 2637
>>>           http://svn.sv.gnu.org/viewvc/?view=rev&root=grub&revision=2637
>>> Author:   cjwatson
>>> Date:     2009-10-16 15:38:42 + (Fri, 16 Oct 2009)
>>> Log Message:
>>> ---
>>> 2009-10-16  Colin Watson  
>>>
>>>      * configure.ac (TARGET_CFLAGS): Add -mno-mmx -mno-sse -mno-sse2
>>>      -mno-3dnow on x86 architectures.  Some toolchains enable these
>>>      features by default, but they rely on registers that aren't enabled
>>>      in GRUB.  Thanks to Vladimir Serbinenko for the suggestion.
>>>
>>
>> Would it be preferable to enable those registers instead?
>>
>>
> They are disabled for following simple reason:
> imagine an OS which isn't aware of those registers. Then if user
> simultaneously launches two applications which use those registers then
> they won't be preserved accross context switches leading to bugs. I
> don't know if there is a way to disable these registers again after
> enabling them. I don't think grub2 will benefit a lot because of

I think this cannot be accurate because virtual machines would be
badly broken (registers enabled by the host, guest without awareness
is exactly the situation you describe).


> mmx/sse/sse2/3dnow because we don't use floating point arithmetics. If I
> remember correctly sse has some commands for operations on parallel
> operations on integers but the only place I see where benefit could be
> considerable is decompression and decryption. If it's proven that

For example, memcpy is much faster using those extended instruction
sets.  Maybe that's not an important use case for grub2 either.

> decompressing/decrypting with SSE makes it considerably faster then
> enabling SSE would be a good thing. Anyhow for now we can just disable
> MMX/SSE/SSE2/3dnow and when someone implements handling those registers
> he can enable them again
> On FreeBSD kernel itself is compiled without MMX, SSE, SSE2 and 3dnow to
> avoid to have to handle them on kernel threads switches.
>
>
> --
> 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
>


___
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

[richardvo...@gmail.com]

On Sat, Oct 17, 2009 at 7:09 AM, Vladimir 'phcoder' Serbinenko
 wrote:
> Robert Millan wrote:
>> On Sat, Oct 17, 2009 at 01:43:37PM +0200, Vladimir 'phcoder' Serbinenko 
>> wrote:
>>
>>> Robert Millan wrote:
>>>
 On Sat, Oct 17, 2009 at 12:18:05AM +0200, Vladimir 'phcoder' Serbinenko 
 wrote:


>  2009-10-16  Vladimir Serbinenko  
>
> +  * util/i386/pc/grub-setup.c (setup): Refuse to overwrite XFS 
> superblock.
> +  (options): New option --destroy-xfs.
> +  (main): Handle --destroy-xfs.
>
>
 I gave this some more thought, and I think this could be less ad-hoc.  
 We're
 treating XFS as if it were a "weird", unique thing just because it isn't 
 biased
 towards DOS-style boot like most filesystems are.

 Instead, I've done something more generic, using our standard filesystem
 probing engine which should be more reliable than a single memcmp.



>>> The danger is that fs_probe may reject filesystem as valid just because
>>> it's newer than expected.
>>>
>>
>> What do you mean with "reject filesystem as valid"?
>>
>>
> Sorry for being unclear. I just meant that if some XFS structures are
> updated then our xfs driver won't recognise it as xfs


Then instead of blacklisting xfs, why not whitelist filesystems which
are known to have usable blocks for embedding (doesn't the number of
blocks vary with filesystem anyway?) and an override parameter
(--into-unrecognized-fs).

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


___
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

Re: Macbook, Efi, Display mode

[richardvo...@gmail.com]

On Sat, Oct 24, 2009 at 7:38 PM, Stefan Bienert
 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

Re: grub-1.97

[richardvo...@gmail.com]

On Wed, Oct 28, 2009 at 11:02 AM, Bruce Dubbs  wrote:
> Michal Suchanek wrote:
>>
>> 2009/10/28 Bruce Dubbs :
>
>>> I'd also like to make a comment.  It may be useful if you split up the
>>> build
>>> into subdirectories by component.  When I extracted the tarball, there
>>> were
>>> 57 files/directories in the top of the build tree.  After configure it
>>> was
>>> 64.  So far so good.  However, after make it was over 2400 files, many
>>> with
>>> very long file names.  This makes it almost impossible to navigate form
>>> the
>>> command line, even on a very big screen.  If you split it up, you could
>>> also
>>> shorten the filenames.  I would think that would be an advantage to
>>> encourage programmers to read the code and contribute to the project.
>>>
>>
>> I guess it's meant to be used like this:
>>
>> tar -jxvf grub-version.tar.bz2
>> cd grub-version
>> mkdir build
>> cd build
>> ../configure./configure --prefix=/usr \
>
>            --sysconfdir=/etc \
>            --disable-largefile     \
>            --disable-grub-emu      \
>            --disable-grub-emu-usb  \
>            --disable-grub-fstest   \
>            --disable-efiemu --prefix=/some_prefix --options
>>
>> make
>> make install
>
> Yes, that is exactly what we are doing.  Right now the configure line is

Not "exactly", and the difference is important.Michal suggested
running "../configure" with a double-dot meaning parent directory.
Your line has only a single dot, meaning current directory.  As a
result your files are all mixed together instead of separated as
intended.

>
> ./configure --prefix=/usr           \
>            --sysconfdir=/etc       \
>            --disable-largefile     \
>            --disable-grub-emu      \
>            --disable-grub-emu-usb  \
>            --disable-grub-fstest   \
>            --disable-efiemu


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

Re: Imminent bugfix release (1.97.1)

[richardvo...@gmail.com]

On Mon, Nov 9, 2009 at 4:46 PM, Duboucher Thomas  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Robert Millan a écrit :
>> On Mon, Nov 09, 2009 at 10:43:48PM +0100, Duboucher Thomas wrote:
>>>      Well, the only way to solve that problem would be IMHO to add a limit
>>> to the size of s2, and use this maximum size as an end condition for the
>>> 'for' statement. Any better idea? :)
>>
>> We have a maximum line read size anyway.  If we do this, we might as
>> well make that limit global so that the macro can be shared with
>> this routine.
>>
>
> Sounds good to me. :)
> Any ideas for renaming s1 and s2?

correct_key and attempted_key

But there seems to still be potential for overflow on one of the
strings.  Are both strings in fixed-equal-length buffers?  That should
be clearly documented.


>
> Thomas.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkr4m8EACgkQBV7eXqefhqj9SgCgjHomnoIkzzu5WuTCZQVcB/8t
> cwcAn1EkevCL3PXGlIuhLzFPlER9fXD3
> =okR/
> -END PGP SIGNATURE-
>
>
> ___
> 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: Imminent bugfix release (1.97.1)

[richardvo...@gmail.com]

> Hello,
>
> I'd be concerned about (s1 != s2).  Depending on how efficiently this
> compiles, could not branch prediction make this faster for match vs. not
> match, etc?.  I'd be worried about all the ways (and future ways) compilers
> might help us and introduce time differences.

I was avoiding suggesting new conditionals for that reason, but didn't
see the one already there.  Good find.

>
> I'd feel most comfortable with the time delay, but why not stick to complete
> artithmetic?

I agree.  But I think you've inverted the return value (strcmp returns
0 on perfect match).

>
>
> int i;
> int acc = 0;
>
> for(i=0;i {
>   acc |= (*s1 ^ *s2);
>
>   if (*s1 == 0)
>      break;
> }
>
> return (acc == 0);
>
>
> Also, these strcmp functions don't properly return < or >.  Just = / !=.
>  However, my context being so new is quite limited.
>
>
> Darron
>
>
>
> ___
> 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: Grub-devel Digest, Vol 69, Issue 19

[richardvo...@gmail.com]

On Tue, Nov 10, 2009 at 4:06 AM, Pedro A ARANDA  wrote:
> Hi all,
>
> just my .2 euto-cents:
>
> With this function, you always assume that strlen(s1) <= strlen(s2),
> right?
>
>> int
>> grub_auth_strcmp (const char *s1, const char *s2)
>> {
>> int n;
>> volatile int ret = 0;
>>
>> for (n = grub_strlen (s1); n >= 0; n--)
>> {
>> if (*s1 != *s2)
>> ret |= 1;
>> else
>> ret |= 0;
>>
>> s1++; s2++;
>> }
>>
>> return ret;
>> }
>
> because if not, you'd have to
>
> if (*s1 == 0 || *s2 == 0)
> break;
>
> in the loop and the return would be something like
>
> return *s1 == 0 && *s2 == 0 && ret == 1;
>
> And then you can continue simplifying to
>
> while (1) {
>   if (*s1 != *s2) break;
>   if (*s1 == 0) break;
>   if (*s2 == 0) break;
>   s1++; s2++;
> }
> return *s1 == 0 && *s2 == 0;
>
> Again, just my .2 euro-cents or less

That's a good efficient strcmp, but the execution time leaks all kinds
of information about the secret.  Specifically, when there's a front
subset match, the function will run longer.  That allows a brute force
attacker to break the password in linear time with the password length
instead of exponential time.  auth_strcmp is specifically trying to
avoid any data-dependent branching.

>
> Cheers,/PA
>
> 
> Windows Live: Keep your friends up to date with what you do online.
> ___
> 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: Imminent bugfix release (1.97.1)

[richardvo...@gmail.com]

On Tue, Nov 10, 2009 at 8:25 AM, Duboucher Thomas  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Bean a écrit :
>> Hi,
>>
>> Oh, I just come up with a better way to do this:
>>
>> typedef char grub_password_t[1024];
>>
>> int
>> grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
>> {
>>  char r1 = 0;
>>  char r2 = 0;
>>  char *p;
>>  int i, c;
>>
>>  p = &r1;
>>  c = 0;
>>  for (i = 0; i < sizeof (grub_password_t); i++, s1++, s2++)
>>    {
>>      *p | = (*s1 ^ *s2);
>>      if ((int) *s1 == c)
>>        {
>>        p = &r2;
>>        c = 0x100;
>>        }
>>    }
>>
>>  return (r1 != 0);
>> }
>>
>> The condition (int) *s1 == c would be true exactly once.
>>
>
>        Well, it seems I lost something somewhere. I don't understand the need
> of doing it exactly sizeof (grub_password_t) times, except from having a
> perfectly symetric function. IMHO, stopping the comparison when the
> input buffer is done reading, or when the maximum size of a passphrase
> is reached does not leak any information to the attacker. So I would
> stick to
>
> typedef char grub_password_t[1024];
>
> int
> auth_strcmp (const grub_password_t input, grub_password_t key)
> {
>  int retval, it;
>
>  for (it = retval = 0; it < PASSPHRASE_MAXSIZE; it++, input++, key++)

After changing the parameter type, those postincrements won't do what
you expect.

>  {
>    retval |= (*input != *key);
>
>    if (*input == '\0')
>      break;
>  }
>
>  return !retval;
> }
>
>        Also, take care that it requires to check how the function is
> optimized; sometimes you have surprises ... ;)
>
>        Thomas.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkr5d90ACgkQBV7eXqefhqio+QCfba54+l45DiQNyI3IzfnwgvVe
> tbUAnRTPI+yYSZoVZLfM9fze7c7cvRQN
> =EjYS
> -END PGP SIGNATURE-
>
>
> ___
> 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] Faster glyph lookup by BMP index

[richardvo...@gmail.com]

Is this table stored in the file or built during font load?  128KiB in
memory is no issue at all on modern systems, 128KiB in a file is
somewhat more troublesome since it won't fit in a boot sector, is a
big chunk of a rescue diskette, and the I/O cost is noticeable.  These
glyphs are stored in sorted order in the file, correct?  May I suggest
that only every Nth index be stored in the file header (where N = 16
for example) and the intermediate ones discovered at runtime, in those
subranges containing a character actually used (and the indexes and
character data for those glyphs are then cached in memory)?  This also
means block reads from the file (block length is easily calculated as
the difference of two adjacent indices) instead of extraction of
individual characters, most languages tend to have good locality so
this should also be a win.  Or is the entire font file cached in
memory anyway?

2009/11/29 Vladimir 'φ-coder/phcoder' Serbinenko :
> Hello. Basic Multilingual Plane is range of Unicode characters in
> 0-65535 and it contains most of the characters needed by most of the
> languages of the world. By keeping an array with pointers to such
> characters at the cost of 128KiB per font we can almost instantenously
> lookup characters which are likely to be used in grub. Available in
> experimental
>
> --
> Regards
> Vladimir 'φ-coder/phcoder' Serbinenko
>
>
> ___
> 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: USB device not seen by grub

[richardvo...@gmail.com]

2009/12/3 Vladimir 'φ-coder/phcoder' Serbinenko :
> Chris Jones wrote:
>> I am trying to have grub boot off a partition on a USB stick.
>>
>>
> You can't chainload to disk invisible by BIOS. But you can load
> supported OSes from it.

What would be necessary to enable chainload to such devices?  Install
an IRQ 19 handler?  Invoke the extension ROM of the host adapter so
that it hooks IRQ 19?  Hook some other system calls?


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

Re: USB device not seen by grub

[richardvo...@gmail.com]

On Fri, Dec 4, 2009 at 3:36 PM, Robert Millan  wrote:
> On Thu, Dec 03, 2009 at 06:27:07PM -0600, richardvo...@gmail.com wrote:
>> 2009/12/3 Vladimir 'φ-coder/phcoder' Serbinenko :
>> > Chris Jones wrote:
>> >> I am trying to have grub boot off a partition on a USB stick.
>> >>
>> >>
>> > You can't chainload to disk invisible by BIOS. But you can load
>> > supported OSes from it.
>>
>> What would be necessary to enable chainload to such devices?  Install
>> an IRQ 19 handler?
>
> Yeah, something like that.  In essence, GRUB acting as a BIOS.  Sounds awful,
> but hey we already have "efiemu".

As Vladimir says, the legacy grub "map" command must already be
installing such a hook (although it proxies implementation to the
existing BIOS after changing the drive number, rather than calling a
grub storage driver).

>
>> Invoke the extension ROM of the host adapter so
>> that it hooks IRQ 19?
>
> There's usually no such ROM.  Except for adapters that come in discrete
> PCI cards.  And even then, I doubt it's always present.

There are actually quite a lot of devices like this.  Most notebooks
have broken BIOS that won't load the extension ROM from a PCMCIA slot,
if grub could do so it would enable booting from a wide variety of
PCMCIA/CardBus/ExpressCard-to-SCSI/SATA/USB adapters.

Here's one example that I happen to own, and got frustrated with
system BIOS not allowing boot from expansion card:
http://www.newegg.com/Product/Product.aspx?Item=N82E16820161325&cm_re=SolidGO-_-20-161-325-_-Product

I'm fairly sure there is an extension BIOS because some people report
being able to boot from it, however most laptops cannot.

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


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

Re: [solved] Re: USB device not seen by grub

[richardvo...@gmail.com]

On Fri, Dec 4, 2009 at 8:26 PM, Chris Jones  wrote:
> On Thu, Dec 03, 2009 at 05:52:37PM EST, Vladimir 'φ-coder/phcoder' Serbinenko 
> wrote:
>
> [..]
>
>> This is just module loading. I guess your terminal is slow which causes
>> an enormous slowback when loading module. You can using
>
>> debug=usb,uhci,ohci
>> instead of
>> debug=all
>
> I was able to boot the partition I had copied over to the USB stick after
> this:
>
> grub:> debug=uhci,ohci,usbms
> grub:> insmod uhci
> grub:> insmod usbms
> grub:> debug=
>
> Why do I have to enable tracing to make it work?

Yesterday Vladimir wrote:

(quote)
There is an issue that somewhere grub misses a delay between uhci
commands. When enabling debug=all this hang goes away. My laptop has
this issue too. I hope to have time soon to fix it
(/quote)

This makes a lot of sense, the UHCI controller may require some time
for processing certain commands before it can accept the next one, and
tracing slows things down enough to let the controller catch up.  It's
a very good sign (for having a fix soon) that one of the major
programmers has not only reproduced the problem but is affected by it.


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

Re: USB device not seen by grub

[richardvo...@gmail.com]

2009/12/4 Vladimir 'φ-coder/phcoder' Serbinenko :
> Robert Millan wrote:
>> On Thu, Dec 03, 2009 at 06:27:07PM -0600, richardvo...@gmail.com wrote:
>>
>>> 2009/12/3 Vladimir 'φ-coder/phcoder' Serbinenko :
>>>
>>>> Chris Jones wrote:
>>>>
>>>>> I am trying to have grub boot off a partition on a USB stick.
>>>>>
>>>>>
>>>>>
>>>> You can't chainload to disk invisible by BIOS. But you can load
>>>> supported OSes from it.
>>>>
>>> What would be necessary to enable chainload to such devices?  Install
>>> an IRQ 19 handler?
>>>
>>
>> Yeah, something like that.  In essence, GRUB acting as a BIOS.  Sounds awful,
>> but hey we already have "efiemu".
>>
>>
> It's by far not the same thing. EfiEmu emulates only RuntimeServices.
> EFI has two types of functions: BootServices and RuntimeServices.
> BootServices are only available when boot loader is running and are
> terminated on kernel launch. RuntimeServices are always available but
> have very small number of functions. And actually GRUB acts only as a
> loader to efiemu??.o and real functions are contained in efiemu??.o
> which is quite small
> For BIOS disks emulations we would need much more functions but we could
> adopt a similar approach. E.g:
> bioshook usbbios.o 
> chainloader (usb0,1)+1
> usbbiso.o may of course be compiled from GRUB files but has to be
> standalone. There are few tricky parts associated with this process but
> basically it would be an overblown drivemap.
>
> But I don't see any real reason to make even small fraction of required
> effort since GRUB2 is able to load many free OS directly and so can load
> them of an BIOS-invisible disks without any problems. Some free OS are
> still out of GRUB family like Minix is but I would gladly accept a port
> of it (which is orders of magnitude easier to do)
> As of proprietary OS I think we need to support them only to the etent
> of what they are able to do themselves. Documentation on such OS are
> often scarce and anything we do may completely break with new version.

SCSI adapter vendors manage to implement IRQ 19 in a way that provides
universal OS support, I don't see how this would be different.

> And all of this only to make good to someone who would like to see every
> free software die?

Not all supporters of free software share that philosophy, quite a few
of us like to be able to tell people "that proprietary software you
use, well, it works better with free software".  And sometimes free
software is enriched by playing well with closed-source.

For example, more people would dual-boot if there was a grub-tools
package for Windows and Mac OS that added "Reboot to linux" to the
start menu (by changing the default boot selection in the grub
config).  If grub-win existed which could install grub from inside
Windows, we'd have even more users of both grub and free OSes to
dual-boot with.  And a Windows driver that jumped directly to grub
code at an appropriate point during shutdown (i.e. after flushing disk
write caches, which is probably when anti-virus drivers unload)
thereby avoiding the BIOS POST delays and making dual-booting even
faster and less painless would equate to even more users.

I happen to have a licence for VMWare workstation 6.x which emulates a
USB host controller (IIRC devices include emulated mouse as well as
real devices attached to the host, including mass storage), but
doesn't support booting from it.  This annoyed me at one point when I
was trying to prepare a bootable USB stick and couldn't test it.  So
I'm willing to give this a shot.

Which Linux distribution do most of you use for grub development (I
value the fact that commands to install the correct version of bzr,
which I've not used before, were recently posted to the list).  That
was for Debian Lenny, but would I get started faster with another
version?  NB: I'm most experienced with gentoo, which is definitely
NOT a quick start.

Ben Voigt


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

Re: gettext: commands/hdparm.c

[richardvo...@gmail.com]

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: [PATCH] Backup old boot sectors before installation

[richardvo...@gmail.com]

>> In conclusion, I believe this backup feature is useful and either
>> implementation should do the work. If we can merge the good parts of
>> them, we can get a better one. I just curious why the thread is stuck
>> since September. Any blocking issues with it? Can we keep the topic
>> moving forward? Your comments are highly welcome.
>>
> The reason is very simple. If you are good user, you should have already
> backed up your copy on your own. And this feature is not necessary.

That opinion was voiced, then countered and I think even the author of
that opinion eventually retracted it.

An automatic backup is valuable both for savvy users who know how but
forgot, and for those who will find the backup and restore procedures
online only after their computer is bricked.


>
> -Garimella Kashyap
>
>
>
> ___
> 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: Grub is the bootloader used on Win7?

[richardvo...@gmail.com]

On Fri, Dec 25, 2009 at 3:21 PM, Felix Zielcke  wrote:
> Am Freitag, den 25.12.2009, 19:15 -0200 schrieb Renato S.Yamane:
>> Hi,
>>
>> I´m a GNU/Linux user, but I have a computer with Windows too (fresh
>> install, with NO Linux installed)
>>
>> Recently, my RAID5 failed, sometimes I get a corrupetd system and I
>> see Windows loading GRUB!
>>
>> Anyone now if Windows7 is using Grub as default bootloader (because I
>> don´t believe that Grub is installed on my BIOS)?
>>
>> - This is the first message error:
>> http://img31.imageshack.us/img31/7215/img0227s.jpg
>>
>> - When I press "Enter" I see this:
>> http://img10.imageshack.us/img10/5285/img0225jm.jpg
>>
>> - And this is the commands available:
>> http://img85.imageshack.us/img85/7056/img0229w.jpg
>>
>> Best regards and Merry Christimas!
>> Renato S. Yamane
>
> Official Windows 7 from Microsoft unmodified, i.e. not some preinstalled
> OEM Version does clearly not use GRUB4DOS nor plain GRUB Legacy nor GRUB
> 2.
> They still use bootmgr which they introduced with Vista, which is
> basically though the old ntldr from NT4/2000/XP just a bit modified.

SLIC is part of the mechanism Windows (many versions) uses to volume
license to OEMs and enable OEM recovery disks which only work on a
particular brand or model of computer.  The SLIC is supposed to be
included in the system BIOS by the OEM... but software pirates
sometimes patch the SLIC into the BIOS or use a hotpatch program to
load it before booting into Windows (Windows can't tell whether the
SLIC came legit from an OEM BIOS or from a user hack).  It looks like
this system is running an illegal copy of Windows, or at the very
least improperly activated.  Since Windows 7 was released only in
October, there should still be time to get a refund from the company
who sold you the fake copy of Windows, the Microsoft Anti-piracy
hotline would probably be helpful in forcing the company to provide
you with a legitimate copy.

http://www.microsoft.com/piracy/reporting.mspx


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

Re: [PATCH] Backup old boot sectors before installation

[richardvo...@gmail.com]

On Mon, Dec 28, 2009 at 9:21 PM, Zhu Yi  wrote:
> On Tue, 2009-12-29 at 06:04 +0800, Isaac Dupree wrote:
>> > Option 1~3 requires the recover has the knowledge of the backup file
>> > format somehow, but a simple dd is enough for option 4. What do you
>> > think?
>>
>> If the partitioning had been changed in the mean time, 4 would overwrite
>> it with the older values. Similar problem for a weird setup with
>> partitions in between (I dunno, might be possible with GPT or other
>> weirdness).
>
> Good point.
>
>> I think option 2 or 3 is soundest.  Option 2 would have three separate
>> files of information, (right?), and there must be a pretty
>> straightforwards `dd` option to skip to the correct start position.
>> Option 3 would omit the "start position" file... but that file is really
>> cheap, maybe we'd better keep things simple for restorers and stick with
>> three separate files.(Or, we could do something weird like putting
>> start-position somewhere in the filename of the backup.)
>
> This requires the restorer to understand the role of each of the 3 (or
> 2) files and use `dd' twice with correct options. So an important thing
> is, we need to document this somewhere. And I think the best place is to
> "document" it in the grub-install script. Because this will enable the
> not-so-advanced user to recover her boot sectors easily as well.
>
> If we decide so, we go back to option 1 (my original implementation).
> Because the backup file format is not important any more as it is
> totally transparent to the restorers. Am I right?

Another option would be to start the backup file with "#!/bin/sh" ...

>
> Thanks,
> -yi
>
>
>
> ___
> 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: grub.info

[richardvo...@gmail.com]

2009/12/31 Bruce O. Benson :
>
> 2009/12/31 Vladimir 'φ-coder/phcoder' Serbinenko 
>>
>> Bruce O. Benson wrote:
>> >
>> > 2009/12/30 Bruce Dubbs > > >
>> >
>> >     Bruce O. Benson wrote:
>> > All contributors can safely, legally add/merge/move stuff there if
>> > desired, delete anything/everything I wrote, add attributions I could
>> > not find, etc.
>> >
>> It's not how it works. For the documentation to be accepted to GNU
>> project contributors have to sign legal papers.
>> Now I'm going to comment on value of manual:
>> "Installation via Package Management" is distribution-specific so it's
>> inappropriate for upstream manual
>> "Building / Installation from Source" is a part of INSTALL and we
>> already have this
>> "Utilities" - description of tools is inappropriate. User doesn't care
>> if it's ELF or text file but how to use them.
>> "Pre-Boot" - is wrong. MBR doesn't point anywhere it's executable code.
>> "grub-rescue" part is wrong too
>> "Lua shell" is part of grub-extras, not grub itself.
>> In whole the manual is vague, contains inappropriate or inexact
>> information.
>> If we merge any part of this manual into bzr we would need to proofread
>> every patch
>
> This is the typical problem of contributing complaints vs. code.

In Vladimir's defense, he contributes lots of code.

Thanks for trying to do the documentation which he hasn't.

All of the above information ought to be findable from the grub online
manual.  Things which aren't part of grub core, such as
distro-specific packaging, are probably well-served by a link to the
package documentation at that distro's site; a link is better than
pretending the greater ecosystem doesn't exist, while avoiding making
the grub project responsible to documenting scripts and package
managers beyond their control.

>
> ___
> 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: [RFC] Multiboot ammendment: non-VBE video

[richardvo...@gmail.com]

On Sun, Jan 3, 2010 at 10:35 AM, Isaac Dupree
 wrote:
> Robert Millan wrote:
>>>
>>> In this case color_info is defined as following:
>>
>> I'd appreciate if a native English speaker confirms this, but I believe
>> this should say "as follows" (same for the other instances of this
>> construct).
>
> "as follows" reads naturally to me, as a native speaker (also checked:
> online dictionaries mention the phrase "as follows" without saying it's
> specific to my area -- northeast U.S. -- so I think it's right to use)

+1 for as follows

>
>>> +...@samp{framebuffer_palette_addr} contains address of array of
>>> @samp{framebuffer_palette_num_colors} following structures:
>>
>> There seems to be some word missing here.
>
> "the following structures"?
> "as follows" would also work well if "structures" isn't an important word to
> keep?
> wait, it's like saying "array of 3 following structures", each of the same
> type. hmm. "@samp{framebuffer_palette_num_colors} structures as follows"?

How about this?

XYZZY contains _the_ address of _an_ array of N structures which follow

>
> -Isaac
>
>
> ___
> 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: GRUB Faq

[richardvo...@gmail.com]

On Thu, Jan 7, 2010 at 1:40 PM, Robert Millan  wrote:
> On Tue, Jan 05, 2010 at 12:08:28AM -0600, Bruce Dubbs wrote:
>> I've been working on grub.texi and I notice a reference to
>> http://www.gnu.org/software/grub/grub-faq.html.  I will change that to
>> grub-2-faq.en.html before I submit it.
>
> Actually, I'd rather ditch the old FAQ and replace it completely.
>
> In general, references to "GRUB 2" need to disappear from the website, wiki
> and documentation.  Now that GRUB Legacy is completely obsolete it's not
> necessary to make the distinction in most contexts.

Development may have ended, but as long as there is a single boot
device supported by GRUB legacy and not GRUB 2 (whether certain RAID
flavors, floppies, filesystems with small embedding area, etc) legacy
isn't obsolete.  And given the number of users who still have it
installed, I suggest that removing documentation for legacy is a
mistake.

Consider either:
(1) Moving the old FAQ to a new URL, and putting a link on the top of
the new FAQ.
or
(2) Adding a link to the GRUB 2 FAQ prominently on top of the GRUB
Legacy FAQ, which stays where it is.

The second option is probably better since there are anchors in the
page, allowing links from outside to specific parts of the page.
Replacing the page will break all such links.

>
> Would you be interested in adapting the website?
>
> --
> 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
>


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

Re: Build error: "ENABLE_NLS" is not defined

[richardvo...@gmail.com]

2010/1/12 Grégoire Sutre :
> Hi,
>
> When NLS is disabled or not supported, the macro ENABLE_NLS is not defined,
> and this breaks compilation of GRUB modules as they are compiled with
> -Werror -Wundef by default.  This is with bazaar trunk.
>
> $ ./autogen.sh && ./configure && gmake
> [...]
> gcc -Ikern -I./kern -nostdinc -isystem /usr/include -I./include -I.
> -I./include -Wall -W  -Os -DGRUB_MACHINE_PCBIOS=1 -Wall -W -Wshadow
> -Wpointer-arith -Wmissing-prototypes                -Wundef
> -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1 -falign-functions=1
> -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -m32 -fno-stack-protector
> -mno-stack-arg-probe -Werror -fno-builtin -mrtd -mregparm=3 -m32   -MD -c -o
> kernel_img-kern_err.o kern/err.c
> In file included from kern/err.c:23:
> ./include/grub/i18n.h:29:5: error: "ENABLE_NLS" is not defined
> gmake: *** [kernel_img-kern_err.o] Error 1
>
> A possible fix consists in replacing the #if ENABLE_NLS by #if
> defined(ENABLE_NLS).  There are not many instances, so they can be changed
> manually, but the following command did the trick for me (assuming sed is
> GNU sed):
>
> find . -name '*.[ch]' -exec sed -i -e 's, ENABLE_NLS, defined(ENABLE_NLS),g'
> '{}' ';'

This fix breaks when ENABLE_NLS is defined as 0.

This gcc bug is blocking a better solution:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38105

>
> Best,
>
> Grégoire
>
>
> ___
> 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: Build error: "ENABLE_NLS" is not defined

[richardvo...@gmail.com]

2010/1/12 Grégoire Sutre :
> richardvo...@gmail.com wrote:
>
>> This fix breaks when ENABLE_NLS is defined as 0.
>
> AFAICS, in the implementation of AM_GNU_GETTEXT, ENABLE_NLS is either not
> defined or set to 1.
>
> But I agree that my proposed fix is too dependent on the implementation of
> AM_GNU_GETTEXT, which may change.
>
> Another option would be to replace #if ENABLE_NLS by #if defined(ENABLE_NLS)
> && ENABLE_NLS.

I know the C compiler short-circuits &&, if the preprocessor does also
then this looks like the best solution.  If not, then nested #if.

>
>> This gcc bug is blocking a better solution:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38105
>
> I didn't know that this was a gcc bug.  It felt like a normal behavior to me
> to get an error with both -Wundef and -Werror in that case.  From the gcc
> man page:
>
>  -Werror
>     Make all warnings into errors.
>
>  -Wundef
>     Warn if an undefined identifier is evaluated in an #if directive.

And -Wno-error=undef is supposed to change the severity of that class
of warning back to non-fatal.  But it currently doesn't.

>
>
> Grégoire
>
>
> ___
> 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: Secure Boot. Why don't you take the wind out of their sails?

[richardvo...@gmail.com]

I'll decloak to offer my response, but please remember that I'm not
one of the developers so my opinion is of limited value.  By the same
token, I've been recognized by Microsoft for community contributions,
but I do not work for them and do not speak for them.

First, putting things in simple language is very positive and necessary.

However, your short easy-to-understand summary is incorrect.  The
bootloader password doesn't protect against malware, and it offers
only a little protection against "anybody taking over your computer".
In fact, if some malware rewrote the grub configuration file, it could
be quite annoying to recover.

Also, the bootloader password solves a very different problem from the
secure boot initiative.  The grub password check doesn't verify
integrity of system files.

Finally, the secure boot initiative isn't a threat to open source
operating systems.  The computer administrator has to install a signed
OS and then enable signature verification in the firmware.  All
systems ship with verification disabled, and all the major motherboard
manufacturers have indicated that secure boot will always stay an
opt-in mechanism.  And even then, the firmware setup utility can be
used to once again disable verification, so it isn't even a hindrance
to resale of used equipment, as long as the sale is authorized and the
configuration is changed.  It might create some barrier to use of
stolen equipment, but even then it is likely that clearing the NVRAM
by removing the backup battery will gain access.  Full-disk encryption
is still the best safeguard in case physical security is compromised.

So definitely, this sort of thing needs to be summarized and then
explained in detail using plain English that can be understood by
those who aren't so technically astute.  But lets not sacrifice
accuracy in the desire to use simpler words.

Ben Voigt

On Mon, Jul 9, 2012 at 5:38 PM, Graham Cunnington  wrote:
> Subject:  Secure Boot. Why don't you take the wind out of their sails?
>
> (1) Now is the time to move quickly.
> The development needs to be short and clear so that even a beginner can use
> it immediately.
>
> (2)  The Problem:
>
> Microsoft and allied companies have an idea to force a Microsoft (Verisign)
> key on to hardware manufacturers which may be an attempt once again to bring
> in anti-competitive practices and may decrease the uptake of Linux systems.
> The "Secure boot key" proposed could in fact limit consumer choice and drag
> Grub2 into a fight none of its making.
>
> (3) The Problem of Verbosity:
>
> Grub2 already has the solution to protect Grub and therefore the kernels
> that Grub boots, but that solution is currently unavailable because Grub
> developers have no idea how to KISS.
>
> Keep It Simple Silly. Long-winded geeky sentences have no place in Grub.
>
> "in some environments, such as kiosks, it may be appropriate to lock down
> the boot loader to require authentication before performing certain
> operations.
> The ‘password’ (see Section 14.3.33 [password], page 62) and
> ‘password_pbkdf2’ (see
> Section 14.3.34 [password pbkdf2], page 62) commands can be used to define
> users, each
> of which has an associated password. ‘password’ sets the password in plain
> text, requiring
> ‘grub.cfg’ to be secure; ‘password_pbkdf2’ sets the password hashed using
> the Password-
> Based Key Derivation Function (RFC 2898), requiring the use of
> grub-mkpasswd-pbkdf2
> (see Chapter 30 [Invoking grub-mkpasswd-pbkdf2], page 101) to generate
> password hashes.
> In order to enable authentication support, the ‘superusers’ environment
> variable
> must be set to a list of usernames, separated by any of spaces, commas,
> semicolons, pipes,
> or ampersands. Superusers are permitted to use the GRUB command line, edit
> menu
> entries, and execute any menu entry. If ‘superusers’ is set, then use of the
> command line
> is automatically restricted to superusers."
>
> The above is incomprehensible to most users who are not developers.  Why not
> just say:
>
> "You can password-protect Grub.  This will secure it against malware and
> anybody taking over your computer."
>
>
> (4) The Solution:
>
> (a) Insert into the standard Grub Menu a link which says:  Set a password on
> Grub, which when clicked allows the user to do so.
>
> (b) If this has already been done, then on switching on the computer, the
> password dialog box should pop up prior to the boot Menu.
>
> (c) If this is done then we already have Secure Boot and the administrators
> of companies and home computers will have protected their computers and the
> Microsoft initiative becomes unnecessary, at least for Secure Boot (Secure
> Bios is another matter and another battle).
>
> (d) do it quickly, keep it simple, keep it smart then tell the world what
> you have done.
>
> Computer journalists will love you for it.
>
> Remember, it has to be easy to understand even to people new to computers
> can quickly set a password on their boot.
>
>
> (5

Re: Secure Boot. Why don't you take the wind out of their sails?

[richardvo...@gmail.com]

>> However, your short easy-to-understand summary is incorrect.  The
>> bootloader password doesn't protect against malware, and it offers
>> only a little protection against "anybody taking over your computer".
>> In fact, if some malware rewrote the grub configuration file, it could
>> be quite annoying to recover.
>
> No, you're incorrect. The password is stored IN the grub configuration file.
> So if that person can rewrite the grub configuration file it can rewrite the
> password too (or fully disable it or ...). Thus that protection becomes
> fully INEFFECTIVE. Even if the password were stored in a separate file that
> file could be changed just as well.

You just made my point ;)  Malware can change the bootloader password,
since it's simply stored in a file, making you jump through quite a
number of hoops before being able to use your computer again.


[snip]

>> Finally, the secure boot initiative isn't a threat to open source
>> operating systems.  The computer administrator has to install a signed
>> OS and then enable signature verification in the firmware.  All
>> systems ship with verification disabled, and all the major motherboard
>> manufacturers have indicated that secure boot will always stay an
>> opt-in mechanism.  And even then, the firmware setup utility can be
>> used to once again disable verification, so it isn't even a hindrance
>> to resale of used equipment, as long as the sale is authorized and the
>> configuration is changed.  It might create some barrier to use of
>> stolen equipment, but even then it is likely that clearing the NVRAM
>> by removing the backup battery will gain access.
>
> Nobody's saying that the basic technology which is not exactly new either is
> a threat. But the implementation SecureBoot is. You're misinformed. While on
> x86 systems there's a switch required to disable SecureBoot that same switch
> is NOT ALLOWED for ARM systems
> (https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/restricted-boot-comic-contest-defend-user-freedom-on-tablets-and-smartphones).
> Please get your facts straight.
> Apart from that even if there is a switch the question remains how easily
> accessible it is going to be? How obvious the need to use it is going to be?
> You're the guy asking for stuff to be simple so that point should be clear
> to you.

Uh no, I'm not "that guy".  I was calling out "that guy" on his claim
that a bootloader password protects against malware, while trying to
be very clear that it isn't the idea of a simple explanation I object
to, but the fact that accuracy was sacrificed.  I was in a meeting
between reading the OP and the time my response went out, I didn't see
the other replies.

>
>> Full-disk encryption
>> is still the best safeguard in case physical security is compromised.
>
> There's still some code loaded and executed before opening the volume. That
> code is responsible for initially decrypting the volume and loading
> something else from within it. Now I say "decrypt" so that means that code
> needs to get credentials from somewhere and if that code were malicious it
> would be given the credentials (as it would appear no different to the user)
> and could use them for anything. No way getting around verification of the
> code unless you have a firmware that supports booting from that volume
> directly but then again the firmware needs to be verified by some means too.
> Imagine you're giving a party and want some sort of entry control. As long
> as you don't verify somebody (code) to be trusted to execute the entry
> control by checking everybody's invite (credentials), there's no way to have
> it invites-only. If you're lacking credentials it won't work and if the
> doorman are untrusted they could not be checking the invites/credentials
> properly. You can't get rid of either one of them completely.

Where did I say otherwise?

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

Re: Secure Boot. Why don't you take the wind out of their sails?

[richardvo...@gmail.com]

On Tue, Jul 10, 2012 at 12:04 AM, Chris Murphy  wrote:
>
> On Jul 9, 2012, at 7:23 PM, richardvo...@gmail.com wrote:
>>  All
>> systems ship with verification disabled, and all the major motherboard
>> manufacturers have indicated that secure boot will always stay an
>> opt-in mechanism.
>
> This is mystifying because it directly contradicts the Microsoft Windows 
> hardware certification requirements, which require that to get the made for 
> Windows 8 certification, the hardware must be UEFI, must implement Secure 
> Boot, must have it enabled by default (except servers), and must have a 
> Microsoft key included. It also requires a user chooseable option to disable 
> Secure Boot on x86, but not ARM.

Maybe I'm missing something, but when I read this, it doesn't say the
hardware must have Secure Boot enabled by default.  Rather, it must be
enabled by the OEM as part of the Windows preinstallation process, so
that it's enabled when it reaches the end user.  System builders are
still going to purchase UEFI Secure Boot-capable motherboards with
Secure Boot disabled-by-default, and they will "just work" if you want
to install Linux.  End-users who bought pre-installed Windows will
have to change the configuration option in system setup, which for
someone planning to install a new OS from scratch is not a major
hurdle.  It will be a minor road bump for people using live-CD style
media (including USB), but won't be a showstopper if the user actually
has permission from the computer owner to boot the alternate media.
What likely is that it will prevent unauthorized (by the owner)
rebooting public computers using alternate media, but that's not
exactly a valid scenario to begin with.

ARM is a red herring, IMO.  Pretty much all ARM processors include
some sort of code security module that blocks external access to the
bootloader without the correct reprogramming key.  This is pretty
standard for embedded systems, and has been for decades.  Most
embedded systems aren't designed to boot from removable media.

Most tablets don't give the end user root privilege.  That's a shame,
and something we should work to fix, but going around telling everyone
that the world will end if Microsoft gets Secure Boot onto media
devices is just dishonest.  Those devices have been locked down
already, and the world didn't end.

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

Re: [PATCH] Removing nested functions, part one of lots

[richardvo...@gmail.com]

On Tue, Jan 1, 2013 at 4:37 PM, Andrey Borzenkov wrote:

> В Tue, 1 Jan 2013 14:42:04 +
> Colin Watson  пишет:
>
> >
> >  * If a hook requires more than one local variable from its parent
> >function, declare "struct _ctx" with the necessary
> >variables, and convert both the hook and the parent to access the
> >variables in question via that structure.
>
> Personally I find "ctx" part a bit confusing. It is not really execution
> context in usual sense, it is just collection of random variables. I
> would rather go with "struct _data" here.
>

It's acting as a closure.  That might be a more exact name.


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

Re: [PATCH] Correct spelling of *scheduled*

[richardvo...@gmail.com]

In the same line of the comment, "miscellaneous" is also spelled
incorrectly.

On Mon, May 25, 2015 at 3:13 AM, Paul Menzel <
paulepan...@users.sourceforge.net> wrote:

> Date: Sun, 24 May 2015 23:27:46 +0200
>
> Run the command below
>
> $ git grep -l schedulded | xargs sed -i 's/schedulded/scheduled/g'
>
> and revert the change in `ChangeLog-2015`.
> ---
>  gentpl.py | 2 +-
>  grub-core/disk/ahci.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gentpl.py b/gentpl.py
> index f177883..b0ef79f 100644
> --- a/gentpl.py
> +++ b/gentpl.py
> @@ -82,7 +82,7 @@ GROUPS["softdiv"] = GROUPS["arm"] + ["ia64_efi"]
>  GROUPS["no_softdiv"]   = GRUB_PLATFORMS[:]
>  for i in GROUPS["softdiv"]: GROUPS["no_softdiv"].remove(i)
>
> -# Miscelaneous groups schedulded to disappear in future
> +# Miscelaneous groups scheduled to disappear in future
>  GROUPS["i386_coreboot_multiboot_qemu"] = ["i386_coreboot",
> "i386_multiboot", "i386_qemu"]
>  GROUPS["nopc"] = GRUB_PLATFORMS[:]; GROUPS["nopc"].remove("i386_pc")
>
> diff --git a/grub-core/disk/ahci.c b/grub-core/disk/ahci.c
> index 7f75724..4e8619c 100644
> --- a/grub-core/disk/ahci.c
> +++ b/grub-core/disk/ahci.c
> @@ -1002,7 +1002,7 @@ grub_ahci_readwrite_real (struct grub_ahci_device
> *dev,
>if (parms->write)
>  grub_memcpy ((char *) grub_dma_get_virt (bufc), parms->buffer,
> parms->size);
>
> -  grub_dprintf ("ahci", "AHCI command schedulded\n");
> +  grub_dprintf ("ahci", "AHCI command scheduled\n");
>grub_dprintf ("ahci", "AHCI tfd = %x\n",
> dev->hba->ports[dev->port].task_file_data);
>grub_dprintf ("ahci", "AHCI inten = %x\n",
> --
> 2.1.4
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [multiboot] command-line format

[richardvo...@gmail.com]

> Also, I firmly believe that we shouldn't be satisfied with flawed solutions
> just because they're part of our legacy baggage.  We can do better than this
> because Free Software is more flexible and more powerful.  For example, NetBSD
> can distribute its own version of GRUB and patch it, and coordinate an
> interface change between GRUB and its kernel, etc.

I think a bootloader with "universal" in its name should be doing
everything possible to avoid this.  If I want to multiboot between
Linux, NetBSD, OpenSolaris, and OpenBSD, do I load my MBR with the BSD
fork of GRUB, the Linux fork of GRUB, or the Solaris fork of GRUB?

This really is a non-solution.

I think that defaulting the first parameter to the value used by what,
90% of kernels, but providing a way to override it (I like the
variable idea) will be the least surprising for users.  The path is
filesystem-relative anyway, so GRUB isn't required to know how the
kernel names its devices, nor do changes to grub device addressing
change the parameter passed.

But the current behavior requiring the user to explicitly specify the
0th parameter certainly works, and if the format is to be changed then
during the switch from GRUB Legacy to GRUB2 is the ideal time to do
it.


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

Re: Changes in GRUB help

[richardvo...@gmail.com]

On Mon, Jan 25, 2010 at 7:22 AM, KESHAV P.R.  wrote:
>> Date: Mon, 25 Jan 2010 09:08:45 +0100
>> From: Robert Millan 
>> Subject: Re: Changes in GRUB help
>> To: The development of GNU GRUB 
>> Message-ID: <20100125080845.gi13...@thorin>
>> Content-Type: text/plain; charset=us-ascii
>>
>> On Sun, Jan 24, 2010 at 11:15:11PM +0530, KESHAV P.R. wrote:
>> > * Add support for Fedora's initramfs (semi-patch attached) - name like
>> > initramfs-2.6.31.9-174.fc12.x86_64.img .
>>
>> Your patch looks like it ought to work;  have you tested it?
>>
>> > Please document grub-extras in grub.enbug.org website.
>>
>> You can do that if you like; it's a wiki.
>>
>> --
>> Robert Millan
>
> Yes, the patch definitely works. It is part of Fedora's GRUB2 src-rpm
> package. But I changed the 10_linux.in file manually before compiling grub2.
> The strange thing is that even without any initrd line in the menuentry, the
> Fedora system boots successfully (my guess is that the Fedora's kernel
> searches for its compatible initramfs file without relying on grub or
> grub2).

Linux initramfs is inside the kernel binary, not a separate file, and
so needs no extra support from the bootloader.

>
> As for documenting grub-extras, I don't know how to use a wiki . Also please
> change the behavior of the "help" command as soon as possible. Thank you.
>
> ___
> 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: Changes in GRUB help

[richardvo...@gmail.com]

On Mon, Jan 25, 2010 at 3:22 PM, Colin Watson  wrote:
> On Mon, Jan 25, 2010 at 03:12:51PM -0600, richardvo...@gmail.com wrote:
>> On Mon, Jan 25, 2010 at 7:22 AM, KESHAV P.R.  wrote:
>> > Yes, the patch definitely works. It is part of Fedora's GRUB2 src-rpm
>> > package. But I changed the 10_linux.in file manually before compiling 
>> > grub2.
>> > The strange thing is that even without any initrd line in the menuentry, 
>> > the
>> > Fedora system boots successfully (my guess is that the Fedora's kernel
>> > searches for its compatible initramfs file without relying on grub or
>> > grub2).
>>
>> Linux initramfs is inside the kernel binary, not a separate file, and
>> so needs no extra support from the bootloader.
>
> Linux *can* behave this way if you want it to, but most distributions do
> not set it up like that.  This mode is usually only used by self-built
> kernels, and it's not universal even there since sometimes it's more
> convenient to be able to change the initramfs separately.

Linux 2.6 MUST have an initramfs.  You can either embed one inside the
kernel or let the kernel create one dynamically with hardcoded
content.

I suspect you're thinking of initrd, which is optional.  After
creating or copying the initramfs from within the kernel image (thus
establishing a ramfs mount point), the kernel will decode and copy the
content of any initrd selected by the bootloader to the mounted ramfs.

>
> --
> Colin Watson                                       [cjwat...@ubuntu.com]
>
>
> ___
> 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: Setting of PE bit reboots the system

[richardvo...@gmail.com]

On Sat, Jan 30, 2010 at 12:26 PM, Swapnil Pimpale
 wrote:
> Hi all,
>
> I am working on GRUB 2 on Intel Core 2 Duo architecture. As a part of
> my academic project, I need to bring up the second core.
> When the second core comes up, I need to switch from real mode to
> protected mode.
> For this, I am trying to set the PE bit of cr0 register. But, whenever
> I set the PE bit the system reboots.
>
> Is there any solution on this problem?

What do you expect to accomplish on the second core?  Are you trying
to boot a different OS on each core?

Every general purpose OS expects to be activated on the first core
with no other cores running and to have possession of all RAM.  You'll
either need a specialty kernel (for all active OSes) or a
virtualization layer.

Does the reboot happen immediately when you set the PE bit, or does
that cause something to fail later (maybe in the OS startup code)?

>
> Thanks,
> Swapnil Pimpale.
>
>
> ___
> 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: Antialiased fonts patch.

[richardvo...@gmail.com]

On Thu, Feb 11, 2010 at 7:30 AM, Michal Suchanek  wrote:
> On 26 January 2010 11:04, Evgeny Kolesnikov  wrote:
>> Hi,
>>
>>> At first I was completely against antialiasing support because of
>>> performance impact. But it being optional decreases the later. However
>>> there is one problem: your patch relies on text_layer to be RGBA
>>> which was a mistake. RGBA for text layer is vastly inefficient
>>> especially on 16-bit framebuffer and CPUs with small cache. I had plans
>>> to switch it to indexed color. Do you really need 8bits and 4 aren't
>>> enough?
>>
>> I use 8-bit in order to give GRUB ability to look and feel exactly
>> as other parts of OS, so yes, 8 bits are required. If one can't allow
>
> Grub will never look and feel exactly as the OS unless you import
> GTK/QT, its themes, freetype, ...
>
>> this for his system - he can use 1-bit fonts. I don't really care about
>> such situation just because other parts of desktop on such a system will
>> be awful too.
>
> In fact I think that 4bit antialiasing should suffice. 16 tones of the
> same color should be more than enough for most cases. Still I am not
> sure that it will make the rendering really faster than 8bit AA.

By antialiasing it seems that you mean alpha channel.

Has anyone considered instead supersampling in the x-direction?  This
also results in anti-aliased text but in addition yields more accurate
kerning and on LCD displays can be used for sub-pixel rendering.  I'd
say 8x supersampling, but since LCD displays have three components
(R,G,B) 6x might be better.

>
> Only testing on various  real hardware can possibly answer the
> question if and when one of the methods is faster. I would even expect
> that none is overall faster and that system exist where either is.
>
> Thanks
>
> Michal
>
>
> ___
> 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: avoid possible overflow?

[richardvo...@gmail.com]

2010/2/16 Vladimir 'φ-coder/phcoder' Serbinenko :
> Carles Pina i Estany wrote:
>> Hello,
>>
>> The common pattern when doing a search by bisection is something like:
>> +      current = min + (max - min) / 2;
>>
>> Instead of the first natural idea:
>> -      current = (max + min) / 2;
>>
>> To avoid overflows.
>>
>> In gettext/gettext.c it's used in the "incorrect" way. It's not a big
>> problem since would happen only with .mo files with lot of strings, like
>> number that int represents in that architecture divided by 2 (aprox
>> aprox.).
>>
>> See the attached file for a patch if we want to patch.
>>
> You forgot to make the same change before the loop. But actually it
> doesn't matter because overflow in this statement:
>  internal_position = offsettranslation + position * 8;
> is reached well before the overflow in bisecting. Anyway this
> mattersonly for >4GiB files and unless we put videos in .po I don't see
> how this limit would be reached. So I prefer readability and would
> reject this patch.

There's a very readable way to express the "better" code that's immune
to the overflow:

int const range = max - min; /* or unsigned int, if min and max are
declared that way */
current = min + range / 2;


>> Else I would at least add a comment that we simplified because we
>> consider that will not happen.
>>
>> Thanks,
>>
>>
>> 
>>
>> ___
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
> --
> Regards
> Vladimir 'φ-coder/phcoder' Serbinenko
>
>
>
> ___
> 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: [RFC] Framebuffer rotation patch

[richardvo...@gmail.com]

On Tue, Feb 16, 2010 at 12:03 PM, Isaac Dupree
 wrote:
> On 02/16/10 10:52, Michal Suchanek wrote:
>>>
>>> enum allows it just fine
>>
>> Not here:
>>
>> typedef enum t1 { BTI1 = 1,
>
> typo, should be "BIT1". then it works. (In C.  Also remember not to get
> confused by the fact that it doesn't work in C++, for type-related reasons

Says who?

Comeau is perfectly happy with this code, in strict C++ mode:

enum flags
{
  BIT1 = 1,
  BIT2 = 2,
  BIT12 = BIT1 | BIT2
};

int main(int argc, char** argv) { return 0 ; }


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

Re: [PATCH][UPDATED] support for xz compression format

[richardvo...@gmail.com]

On Tue, Feb 16, 2010 at 12:58 PM, Szymon Janc  wrote:
> Dnia wtorek 16 luty 2010 o 14:44:45 Vladimir 'φ-coder/phcoder' Serbinenko
> napisał(a):
>
>> + #define VLI_MAX_DIGITS 9
>> Are you sure it's 9? It gives only 63 and not 64 bits
> It is a limitation of xz format.
>
>> +   if (! test_header(file) || ! test_footer(file))
>> +   {
>> Seeking to the end of file is very expensive on pxe. Can it be skipped?
> xz stores uncompressed data size at the end of file, without it file size 
> can't
> be set.
>
> gzio has same issue, it reads last 4 bytes of file to determine uncompressed
> data size.

Then maybe use of a more sensible format should be strongly
encouraged.  For sequentially accessed devices like tape, it may be
expensive to return to the header to add the size.  For flash memory,
it may require an overwrite (and flash memory has fast random access,
this is pretty much the only case to prefer a footer).  And formats
which support pipelining of course can't rewind to update a header.
But in general the archive will be read many times for each time it is
created, so it's best to put the size in the place which is best for
the decompressor.

Since gzip format allows decompression in pipeline mode, it's a
virtual certainty that nothing from the footer is required for
processing.

And of course this is true of the xz format as well.  I quote from the
documentation:

"Streamable: It is always possible to create and decompress .xz files
in a pipe; no seeking is required."
http://tukaani.org/xz/format.html


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

Re: [RFC] Framebuffer rotation patch

[richardvo...@gmail.com]

On Tue, Feb 16, 2010 at 3:05 PM, Michal Suchanek  wrote:
> 2010/2/16 Vladimir 'φ-coder/phcoder' Serbinenko :
>> Michal Suchanek wrote:
 With typeof macro this can be made type-neutral avoiding potential 
 mistakes.
 +static inline long
 +grub_min (long x, long y)
 +{
 +  if (x > y)
 +    return y;
 +  else
 +    return x;
 +}
 +

>>>
>>> I don't see how typeof would be used. As I understand the docs it can
>>> only set types relative to something what is already defined (and in
>>> some cases actually dereference/call it) and there is nothing defined
>>> at the point these functions are declared to copy the type from.
>>>
>> #include 
>> #define swap(a,b) {typeof (a) mytemp ## __LINE__; mytemp ## __LINE__ =
>> b; b = a; a = mytemp ## __LINE__; }
>>
>
> Unlike inlines this pollutes the local namespace with unexpected
> identifiers.. Perhaps the temporary variable should be at least
> prefixed with an underscore or something.

The braces introduce a block and the variable goes out of scope, in
fact there's no need for __LINE__ because of this.


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

Re: [PATCH][UPDATED] support for xz compression format

[richardvo...@gmail.com]

On Tue, Feb 16, 2010 at 3:28 PM, Seth Goldberg  wrote:
> y
>
> Quoting richardvo...@gmail.com, who wrote the following on Tue, 16 Feb 2010:
>
>> On Tue, Feb 16, 2010 at 12:58 PM, Szymon Janc  wrote:
>>>
>>> Dnia wtorek 16 luty 2010 o 14:44:45 Vladimir 'φ-coder/phcoder' Serbinenko
>>> napisał(a):
>>>
>>>> + #define VLI_MAX_DIGITS 9
>>>> Are you sure it's 9? It gives only 63 and not 64 bits
>>>
>>> It is a limitation of xz format.
>>>
>>>> +   if (! test_header(file) || ! test_footer(file))
>>>> +   {
>>>> Seeking to the end of file is very expensive on pxe. Can it be skipped?
>>>
>>> xz stores uncompressed data size at the end of file, without it file size
>>> can't
>>> be set.
>>>
>>> gzio has same issue, it reads last 4 bytes of file to determine
>>> uncompressed
>>> data size.
>>
>> Then maybe use of a more sensible format should be strongly
>> encouraged.  For sequentially accessed devices like tape, it may be
>> expensive to return to the header to add the size.  For flash memory,
>> it may require an overwrite (and flash memory has fast random access,
>> this is pretty much the only case to prefer a footer).  And formats
>> which support pipelining of course can't rewind to update a header.
>> But in general the archive will be read many times for each time it is
>> created, so it's best to put the size in the place which is best for
>> the decompressor.
>>
>> Since gzip format allows decompression in pipeline mode, it's a
>> virtual certainty that nothing from the footer is required for
>> processing.
>
>  I know I've said this before, but it bears repeating: Don't forget about
> network booting!  This is precisely the problem for which we came up with a
> different solution for loading large compressed archives via tftp when PXE
> booting.  The assumption, of course, is that you can size a buffer maximally
> (with some sane maximum)  then shrink it once the archive has been
> decompressed.  That's what we do and it's served us will with Legacy GRUB
> for years now.

In the case of .xz, there appear to be block headers, where the
uncompressed size is stored up front.  So as long as separate blocks
can go into independent memory allocations, there'd be no need to
oversize the buffer.

>
>  --S
>
> ___
> 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: Lead-up message 'Welcome to GRUB!' inverted text printed lowlevel via BIOS ?!?

[richardvo...@gmail.com]

On Thu, Feb 18, 2010 at 4:24 AM, Robo L  wrote:
> Hi All
> I have a problem with remove the message "Welcome to GRUB!" in text Mode.
> In source 1.96 I remove Welcome text message, when call function
> grub_printf().
> In gfx mod is all OK, but If I not initialize gfx mode grub steel show
> "Welcome to GRUB!" inverted (black on white)
> I mean, that Grub print via lowlevel printig (int 0x10) with proprietary
> string data.
> Please can You tell me what is a reason? How is a solution? Is it a correct
> by the licence?

The license does not allow you to install or run GRUB on a computer
without telling the user, if that's what you're after.

The license lets you remove the welcome message, but you still MUST
inform the user of their GPL rights to the copy of GRUB you've given
them (and if you are using a copy of GRUB modified to remove the
welcome message, then you are responsible for meeting the GPL source
code copy requirements yourself, and can't simply direct users to an
official download page).


>
> Many thanks
> Robo
> --
> -
> E=mc2
>
> ___
> 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: Lead-up message 'Welcome to GRUB!' inverted text printed lowlevel via BIOS ?!?

[richardvo...@gmail.com]

2010/2/20 Vladimir 'φ-coder/phcoder' Serbinenko :
> Robo L wrote:
>>
>> I mean, that Grub print via lowlevel printig (int 0x10) with
>> proprietary string data.
> It's true that most BIOSes are proprietary and we're against non-free
> firmware. Unfortunately, however, most motherboards around aren't
> supported by any free firmware so we have to cope with what we have. We

How is any of this relevant to the OP's question?  I think it is,
somewhat, but you haven't made the connection.

Also, the OP doesn't appear to be looking for a better way to print
the welcome message, or to understand why the welcome message is
printing via int 0x10, but actually to remove the welcome message.

About the only legitimate case I can think of is if the BIOS is
redirecting output to a serial port and the presence of a welcome
message confuses an automated system on the other end of the serial
link that isn't expecting it.


> encourage you to use motherboards with free firmware. I'm aware of 3
> categories of such:
> 1) Coreboot has made a great job in freeing x86-based mobos. You can
> consult their list here: http://www.coreboot.org/Supported_Motherboards
> 2) Touchbook by always innovating
> http://alwaysinnovating.com/home/index.htm claims to use U-Boot and
> supply the complete sources. I haven't checked this claim however
> 3) Yeeloong by Lemote http://www.lemote.com/english/yeeloong.html. It
> uses PMON, soon GRUB will work as firmware on it too (big parts are done)
> On BIOS grub uses its interrupts by default because this interface
> usually supports the hardware user has and on coreimg stage it allows to
> shave off few bytes. However we move to using our own drivers since
> firmware interface is often buggy and/or incomplete.
>>
>> Please can You tell me what is a reason? How is a solution? Is it a
>> correct by the licence?
> GRUB doesn't link with BIOS
>>
>> Many thanks
>>
>> Robo
>>
>> --
>> -
>> E=mc2
>> 
>>
>> ___
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
>
> --
> Regards
> Vladimir 'φ-coder/phcoder' Serbinenko
>
>
>
> ___
> 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: Lead-up message 'Welcome to GRUB!' inverted text printed lowlevel via BIOS ?!?

[richardvo...@gmail.com]

On Sun, Feb 21, 2010 at 4:00 AM, Robo L  wrote:
>
> Hi all,
>
> Firstly I would like to thank everyone for the reply and Your time.
>
> I would like to clarify the issue.
> First I need to hide the very first Welcom message because I need to hide
> GRUB for other users of MS Windows on my PC. I need it only for myself.

I'm not entirely certain, but:

(1) I think GRUB is licensed under GPLv3 or higher only
(2) GPLv3 covers what were considered to be loopholes in GPLv2
(firmware enforced signature, software-as-a-service)
therefore
(3) Your use of GRUB (copying it into the boot record) requires you to
provide your users with notice of their GPL rights to your version of
GRUB.

So one can hardly say that "another user on my PC not venture a guess
that there is a GRUB" if you are required to tell them that GRUB is
there and offer them the source code.

> Richard: redirection is not good idea for me, becouse II need classical
> console. I wrote a module with hidden password (secret process - no response
> on console - silent) If match then redirect to boot linux. The nature of the
> process is that another user on my PC not venture a guess that there is a
> GRUB and secound linux OS!

Security through obscurity is never a good idea and especially not
when you have to give away the source code.


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

Re: Licensing Re: Lead-up message 'Welcome to GRUB!' ...

[richardvo...@gmail.com]

On Mon, Feb 22, 2010 at 4:31 PM, Isaac Dupree
 wrote:
> On 02/21/10 15:38, richardvo...@gmail.com wrote:
>>
>> On Sun, Feb 21, 2010 at 4:00 AM, Robo L  wrote:
>>>
>>> Hi all,
>>>
>>> Firstly I would like to thank everyone for the reply and Your time.
>>>
>>> I would like to clarify the issue.
>>> First I need to hide the very first Welcom message because I need to hide
>>> GRUB for other users of MS Windows on my PC. I need it only for myself.
>>
>> I'm not entirely certain, but:
>>
>> (1) I think GRUB is licensed under GPLv3 or higher only
>
> yes
>
>> (2) GPLv3 covers what were considered to be loopholes in GPLv2
>> (firmware enforced signature, software-as-a-service)
>> therefore
>
> well, GPLv3 is not identical to GPLv2, but I don't think the differences are
> important to this issue.
>
>> (3) Your use of GRUB (copying it into the boot record) requires you to
>> provide your users with notice of their GPL rights to your version of
>> GRUB.
>
> No, I think it probably does not.  Firstly, because Robo L may not be
> "conveying" the program (see definition in GPLv3), and if not, cannot
> possibly be violating GPLv3.

You're right, the loophole I mentioned in #2 was plugged in AGPL in a
way that only covers over-the-network use and thus probably not Robo's
scenario.

>
> http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
>
> Secondly, even if installing it to the hard disk of a computer that is
> shared between you and other people (or other corporations) is "conveying",
> GPLv3 Section 5 says, "d) If the work has interactive user interfaces, each
> must display Appropriate Legal Notices; however, if the Program has
> interactive interfaces that do not display Appropriate Legal Notices, your
> work need not make them do so."
>
> I didn't check whether mainstream GRUB interaction displays Appropriate
> Legal Notices.  ("Welcome to GRUB!" is most certainly NOT an Appropriate
> Legal Notice.)  If it doesn't, you're free.  If it does, I think you still

I never meant to suggest that removing the message was forbidden, just
that if there is a requirement to offer source code to the users then
it's pointless to hide the message.

> do not need to display Appropriate Legal Notices until "interactive user
> interfaces" have been activated; say, by typing in the secret code that
> activates them.  In section 0. Definitions, "An interactive user interface

Anything that accepts a secret code and responds to it is an
interactive user interface.

> displays “Appropriate Legal Notices” to the extent that it includes a
> convenient and prominently visible feature that [says it's GPLed, etc.].  If
> the interface presents a list of user commands or options, such as a menu, a
> prominent item in the list meets this criterion."  I don't see "interactive
> user interfaces" defined anywhere in the GPL or mentioned in GPL-FAQ, so I
> am hardly sure whether a secret password-entry system that only interacts by
> secretly reading a password (and then brings up the "real" interactive
> interface) would count as an interactive interface in its own right that
> must tell the user about itself even when they don't know the password...
> The Affero-GPL is written with further language about interaction, but as I
> guess that the normal GPL wouldn't make a GPL'd SSH server program have to
> break the SSH protocol in order to fulfill Legal Notices, there must be some
> limits on what is considered "interaction"...
>
> I doubt the GPL was written with surreptitious installation of software on
> other people's computers in mind... well, maybe it was

It definitely covers putting a copy on someone else's computer.  But
Robo said he's installing it on his own computer.  And GPLv3 doesn't
seem to put restrictions on that like AGPLv3 does.

>
>>
>> So one can hardly say that "another user on my PC not venture a guess
>> that there is a GRUB" if you are required to tell them that GRUB is
>> there and offer them the source code.
>>
>>> Richard: redirection is not good idea for me, becouse II need classical
>>> console. I wrote a module with hidden password (secret process - no
>>> response
>>> on console - silent) If match then redirect to boot linux. The nature of
>>> the
>>> process is that another user on my PC not venture a guess that there is a
>>> GRUB and secound linux OS!
>>
>> Security through obscurity is never a good idea and especially not

Re: Help regarding booting application processor

[richardvo...@gmail.com]

On Wed, Feb 24, 2010 at 12:57 AM, Swapnil Pimpale
 wrote:
> Hi all,
>
>  I am a final year engineering student and I am doing my project in
> GRUB-1.97~beta4 and Linux Kernel 2.6.24.7.
>
>  I am working on Intel Core 2 Duo architecture. I want to boot a
> separate kernel on the second core.
>  As of now, I have brought up the halted AP from the GRUB by sending
> IPIs in the INIT-SIPI-SIPI sequence. I have also allocated a 4KB page
> below 1MB and asked the AP to jump to that address.
>
>  I am trying to put the BSP in while(1) loop and I want the AP to
> switch from real to protected mode and then jump to start of kernel.
> But whenever I do a jump to 1MB the system reboots.

Remember that the RAM physical address space is shared between both
processors.  You'll need to tell Linux not to touch the second core
and not to touch the memory used by your second OS.  I think you can
accomplish both of these goals using the right kernel command line.
Then you'll have to divide up other hardware, like PCI devices, so
that only one OS accesses any given device.  For example, the second
OS won't be able to use a hard disk connected to a SATA controller
visible to the first one.  Especially the second kernel needs to be
written not to address the PCI bus controller(s), including
enumeration of bus devices.

If you can't partition the hardware like this then you'll need a
hypervisor, which uses protected mode to intercept and virtualize
attempted hardware access from the other OS.

>  I am using the following code as the trampoline code for the AP.
>
>  Can someone please let me know what is wrong in the following code.

Probably you've stomped on a shared resource being used by the first
processor.  Even if you run an infinite while loop on the first core,
it can still execute interrupt service routines installed by grub (or
by the second kernel, if not careful about interrupt-processor masks)
which would access grub global data structures.  If you overwrite
anything you may end up with a protection fault or invalid instruction
exception, both of which would probably vector back to BIOS startup
code.

>  Awaiting your reply,
>
> Thanks,
> Swapnil Pimpale
>
> - trampoline.S -
> /* Tell GAS to generate 16-bit instructions so that this code works
>          in real mode. */
>
> #include 
> #include 
>
>
> .align 4096
> .code16
> FUNCTION(TRAMPOLINE_CODE)
> initial:
>
>       mov     %cs, %ax
>       mov     %ax, %ds
>       cli
>
>       lidtl   idtdesc - initial
>       lgdtl   gdtdesc - initial
>
>       mov $0x9e00, %bx                   // 9e00 is the cs
>       shl $4, %ebx
>       movl $(gdt - initial + 8), %eax
>       movl %ebx, %eax
>
>        mov $0x10, %bx
>        xor %ecx, %ecx
>        mov $0xb800, %cx                 // address of video RAM in %cx
>        shl $4, %ecx
>        mov $0x0744, %dx                 // for printing D
>        xor %eax, %eax
>        pushw %ax
>        mov $0x08, %ax
>        pushw %ax
>        xor %eax, %eax
>        mov $0x9e00, %ax
>        shl $4, %eax
>        add protcseg - initial, %eax
>        pushl %eax
>
>       xor %eax, %eax
>       movl %cr0, %eax                 // turn on the PE bit
>       orl $0x1, %eax
>       movl %eax, %cr0
>
>      jmp l1
>
> l1:
>
>  mov %bx, %ds
>  mov %dx, (%ecx)                 // Print D
>  add $2, %ecx
>  add $1, %dx
>
>  ADDR32 ljmpl $0x8,$((protcseg - initial) + (0x9e00 << 4))
>
>  .align 256
>  .code32
>  protcseg:
>
> l3:
>  mov %dx, (%ecx)
>
>  movw %bx, %es
>  movw %bx, %fs
>  movw %bx, %gs
>  movw %bx, %ss
>
> l4:
> // The following is the code used by /loader/i386/linux.c for entering Linux
>  mov $0x8c000, %esi
>  xor %ebx, %ebx
>  mov $0x8c000, %eax
>  jmp *0x214(%eax)         // System reboots here
>
> l5:
>       jmp l5
>
>
> .p2align 2
> gdt:
>       .word   0, 0
>       .byte   0, 0, 0, 0
>
>       .word   0x, 0
>       .byte   0, 0x9A, 0xCF, 0
>
>       .word   0x, 0
>       .byte   0, 0x92, 0xCF, 0
>
>       .word   0x, 0
>       .byte   0, 0x9E, 0, 0
>
>       .word   0x, 0
>       .byte   0, 0x92, 0, 0
>
> gdtdesc:
>       .word   0x27
>       .long   gdt
>
> idtdesc:
>       .word 0
>       .long 0
> FUNCTION(TRAMPOLINE_END)
>
>
> ___
> 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: Help regarding booting application processor

[richardvo...@gmail.com]

> Ok, I will think in this direction. I just wanted to verify whether
> the code in the trampoline.S is correct or not.

Well, I'm not qualified to review your trampoline, I read x86
assembler but I'm not familiar with the details of the boot sequence.
I think you're in the right place to find someone who is, though.


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

Re: Broken build

[richardvo...@gmail.com]

2010/3/26 Vladimir 'φ-coder/phcoder' Serbinenko :
> Bruce Dubbs wrote:
>> Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>> Carles Pina i Estany wrote:
 Hi,

 On Mar/17/2010, Bruce Dubbs wrote:

> With the addition of the internationalization code, building GRUB in
> a separate directory fails.
>
 I'll take a look into it "soon" (next days or next week)

 Probably it's an easy thing, if someone checks it before please report
 :-)

>>>         cd $(srcdir) && $(XGETTEXT) -ctranslate --from-code=utf-8 -o $@
>>> -f $< --keyword=_ --keyword=N_
>>> to
>>>         cd $(srcdir) && $(XGETTEXT) -ctranslate --from-code=utf-8 -o $@
>>> -f po/POTFILES --keyword=_ --keyword=N_
>>> Feel free to test & commit
>>
>> I don't think so.
> Well you have a funny way of disagreeing arriving to the same result as
> I told: replace
>        cd $(srcdir) && $(XGETTEXT) -ctranslate --from-code=utf-8 -o $@
> -f $< --keyword=_ --keyword=N_
> with
>        cd $(srcdir) && $(XGETTEXT) -ctranslate --from-code=utf-8 -o $@
> -f po/POTFILES --keyword=_ --keyword=N_
> Have you tested it?

This is still clearly wrong.  When building outside the source tree,
make should not create any files in the source tree.  Write permission
to the source tree should not be required.


>
>> When generated, the makefile has:
>>
>> $(srcdir)/po/$(PACKAGE).pot: po/POTFILES po/POTFILES-shell
>>    cd $(srcdir) && $(XGETTEXT) -ctranslate --from-code=utf-8 -o $@ -f
>> $< --keyword=_ --keyword=N_
>>
>> which when instantiated by make is:
>>
>> ../po/grub.pot: po/POTFILES po/POTFILES-shell
>>   cd .. && /usr/bin/xgettext -ctranslate --from-code=utf-8 \
>>            -o ../po/grub.pot -f po/POTFILES --keyword=_ --keyword=N_
>>
>> /usr/bin/xgettext: cannot create output file "../po/grub.pot": No such
>> file or directory
>>
>> If I change this to:
>>
>> po/grub.pot: $(srcdir)/po/POTFILES $(srcdir)/po/POTFILES-shell
>>   mkdir -p po
>>   $(XGETTEXT) -ctranslate --from-code=utf-8 -o $@ \
>>   -f $< --keyword=_ --keyword=N
>>
>> I get the error:
>>
>>   /usr/bin/xgettext: error while opening "commands/acpi.c" for
>> reading: No such file or directory
>>
>> We need something like:
>>
>> po/grub.pot: $(srcdir)/po/POTFILES $(srcdir)/po/POTFILES-shell
>>   mkdir -p po
>>   DIR=$PWD
>>   cd $(srcdir) && $(XGETTEXT) -ctranslate --from-code=utf-8 \
>>     -o $(DIR)/$@ -f po/POTFILES --keyword=_ --keyword=N
>>
>> The use of $< is wrong here because of the cd command.

This looks like a better fix, if gettext looks for files relative to
the current directory.


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

Re: Multiboot2 Suggestions

[richardvo...@gmail.com]

>>> 8) Any RAM that is not immediately usable by the OS should not be
>>> reported as "usable RAM" in the memory map. An example of this is the
>>> "ACPI reclaimable" area (which is RAM that isn't usable until the OS
>>> has finished using the ACPI tables). RAM used to store the multi-boot
>>> information, RAM used to store the "kernel" and RAM used to store any
>>> modules should be treated in the same way. I suggest using "area type
>>> 0xFFFE = RAM used for multi-boot information" and "area type
>>> 0xFFFD = RAM used for kernel/modules". This makes it much easier
>>> to write a kernel's early initialisation code, because it can use RAM
>>> without worrying about trashing data that is needed by the kernel/OS
>>> later.
>>>
>> kernel should know itself what it asked bootloader to do. MBI now is a
>> single chunk. Further than that there are only elf section tag and
>> module tags which refer to external memory. I think it should be easily
>> trackable now.
>
> Unfortunately a lot of OSs are written by C programmers who do the
> absolute minimum to setup paging in a small piece of startup code
> written in assembly, before jumping to their "main()". This means they
> allocate RAM for page tables, etc before they've parsed or checked
> anything; usually by searching the memory map for the first "usable"
> area and using the first pages of that area.
>
> Unfortunately I'm often the person that needs to explain to them that
> "usable" doesn't mean usable; and that their code only works by
> accident (and their initialisation code could overwrite things needed
> by the OS later if it's booted by a different multi-boot compliant
> boot loader; including future versions of GRUB and not excluding
> non-GRUB boot loaders); and that the only memory they can safely use
> before determining what is usable and what isn't is the space in their
> ".bss", which usually happens to be linked to a virtual address (e.g.
> above 0xC) and not the address it's actually loaded at.The
> other alternative is for the initialisation code to copy everything
> from the "usable" areas into their ".bss" so that they can assume that
> "usable" means usable (but there's no maximum size for the multi-boot
> information and no way to know how big "big enough" is, and this won't
> work if there's any extra modules).
>
> Basically, regardless of how the OS handles the problem, the "small
> piece of startup code written in assembly" ends up being an ugly mess.
>
> If multi-boot guaranteed that "usable" actually did mean usable then
> the problem goes away. Alternatively you could rename it, so that
> "type 1 = potentially usable maybe" so that beginners realise they're
> screwed before they write their dodgy code... ;-)

This does sound like there ought to be different codes for "usable -
unused" vs "usable - valid".  I think the original objection may have
been to enumerating all the different kinds of "usable - valid"
regions which could snowball into a very large number of IDs.


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

Re: escape strings in grub.cfg

[richardvo...@gmail.com]

On Sun, Apr 11, 2010 at 7:09 PM, Colin Watson  wrote:
> On Sat, Apr 10, 2010 at 10:10:15PM +0100, Carles Pina i Estany wrote:
>> Last weekend, the Asturian team found a bug in Grub. Thanks for the
>> debugging. The string that appears in grub.cfg for "Loading the initram"
>> in Asturian is "Cargando'l discu RAM inicial...". So grub.cfg looks
>> like:
>>         echo    Cargando'l discu RAM inicial...
>>
>> This is syntactically invalid because the character "'".
>>
>> Easy work around: generate the line like:
>>       echo    "Cargando'l discu RAM inicial..."
>>
>> New problem: in some language, this string could have a double quote
>> inside.
>>
>> New solution: escape the double quotes strings when they are used in
>> gettext and always use these strings with double quotes.
>>
>> See the attached patch.
>>
>> I'm not convinced of the patch, does anybody has a cleaner idea/patch?
>
> This doesn't cover everything - you've just moved the goalposts a bit.
> Here's the relevant bit of the lexer:
>
> {
>  \'            {
>                  yy_pop_state (yyscanner);
>                  ARG (GRUB_SCRIPT_ARG_TYPE_SQSTR);
>                }
>  [^\']+        { COPY (yytext, yyleng); }
> }
>
> {
>  \"            {
>                  yy_pop_state (yyscanner);
>                  ARG (GRUB_SCRIPT_ARG_TYPE_DQSTR);
>                }
>  \$            {
>                  yy_push_state (VAR, yyscanner);
>                  ARG (GRUB_SCRIPT_ARG_TYPE_DQSTR);
>                }
>            { COPY ("\\", 1); }
>  \\\"          { COPY ("\"", 1); }
>  \\\n          { /* ignore */ }
>  [^\"$\\\n]+   { COPY (yytext, yyleng); }
>  (.|\n)        { COPY (yytext, yyleng); }
> }
>
> In other words, only ' is special (as a terminator) when reading a
> single-quoted string, and the sequences " $ \\ \" \n are special inside
> a double-quoted string.  (Incidentally, I think there's another bug
> here; if $ is special, \$ should be special as well.)
>
> Given this, wouldn't you be better off using single-quotes instead?
> You'd then end up with:
>
>          echo    'Cargando'\''l discu RAM inicial...'
>
> ... where the construction used to escape ' is "close quotes, literal ',
> reopen quotes".  (Tested in grub-emu.)
>
>> +gettext_escape_double_quotes ()
>> +{
>> +  echo -n $(gettext $@) | sed 's/\"/\\\"/'
>> +}
>
> This is underquoted, and in any case the 'echo -n' is redundant since
> gettext itself already writes to standard output and $() substitution
> strips trailing newlines.  $@ requires special treatment, and that sed
> s/// command needs /g.  With my suggestion, I'd recommend:
>
>  gettext_quoted () {
>    gettext "$@" | sed "s/'/'''/g"
>  }

I haven't tried it myself, but you just said the newline is stripped
by $() and then took out the $(), seems like the newline would be
present again.


>
> ... and then make sure it's enclosed in '' rather than "" wherever it's
> used (or modify the sed to put single-quotes at the start and end, if
> that works out neater).
>
> --
> Colin Watson                                       [cjwat...@ubuntu.com]
>
>
> ___
> 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: Which partitioning schemes should be supported by GRUB?

[richardvo...@gmail.com]

> I can think of an alternative.  We do still need grub_install_dos_part
> and grub_install_bsd_part for the multiboot trampoline, which is in
> assembly, so it's difficult to abandon them altogether.  However,
> there's no reason we need to use them in make_install_device.  How about
> we invent a way to encode most of the information in string form in
> grub_prefix, while leaving a placeholder for make_install_device to fill
> in the disk?  There are 64 bytes available for grub_prefix, which should
> be plenty.  For example, how about the following (with \0 standing for
> ASCII NUL):
>
>  (\0,msdos1,bsd1)/boot/grub
>
> It's then just a matter of spotting the "(\0," sequence and replacing
> the \0 with the drive name.  I think this can probably be done using
> less code than the first option above, and all told it feels a bit less
> hacky to me.

Instead of doing string replacement, why not just define a
disk-relative partition format?

Also, the '\0' seems unnecessary.  Is having "(," meaningful in some
way already?


>
>
> What do people prefer?
>
> --
> Colin Watson                                       [cjwat...@ubuntu.com]
>
> ___
> 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] Simple USB hub support

[richardvo...@gmail.com]

On Sun, Jun 20, 2010 at 4:21 AM, Aleš Nesrsta  wrote:
> Hi,
>
> included patch should make USB hubs operational.
>
> It works in the same simple way as whole GRUB2 USB support, i.e. USB hub
> and device must be connected to computer BEFORE uhci/ohci module is
> loaded.
>
> Note (mainly for Vladimir):
> Via hub are normally working also devices which I reported to be not
> functional on UHCI. So, from my point of view it looks like there is
> surely some problem in powering of UHCI root hubs on my computer. But I
> still don't know why only some devices are sensitive to this problem
> (all of them are not big consumers of power).

When connected via USB-HS hub, even low-speed and full-speed devices
enumerate under the EHCI, not UHCI.  So it's not surprising that the
behavior changes and the devices start working.

Can you verify the speed of the devices in question, and that the hub
is USB 2.0 high-speed?

>
> Best regards
> Ales
>
>
> ___
> 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: Bug in multiboot_mbi2.c

[richardvo...@gmail.com]

What, you want to control color channels independently?  Aren't
monochromatic amber displays good enough any more?

:)

On Mon, Jun 21, 2010 at 9:22 PM, Seth Goldberg  wrote:
>
>  The code that constructs the framebuffer info has a nasty bug where the
> field position and mask size for red are set to the GREEN values:
>
>      tag->common.framebuffer_type = MULTIBOOT_FRAMEBUFFER_TYPE_RGB;
>      tag->common.framebuffer_type = MULTIBOOT_FRAMEBUFFER_TYPE_RGB;
> -->   tag->framebuffer_red_field_position = mode_info.green_field_pos;
> -->   tag->framebuffer_red_mask_size = mode_info.green_mask_size;
>      tag->framebuffer_green_field_position = mode_info.green_field_pos;
>      tag->framebuffer_green_mask_size = mode_info.green_mask_size;
>      tag->framebuffer_blue_field_position = mode_info.blue_field_pos;
>      tag->framebuffer_blue_mask_size = mode_info.blue_mask_size;
>
>
>  --S
>
> ___
> 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] Optimise memset on i386

[richardvo...@gmail.com]

[snip]

> +  unsigned long patternl = 0;
> +  grub_size_t i;
> +
> +  for (i = 0; i < sizeof (unsigned long); i++)
> +   patternl |= ((unsigned long) pattern8) << (8 * i);
> +
>

might I suggest:

unsigned long patternl = pattern8;
patternl |= patternl << 8;
patternl |= patternl << 16;
patternl |= patternl << 32;
patternl |= patternl << 64;

O(lg N) instead of O(N), no loop, no branches, and the compiler should be
smart enough to optimize away the last two lines on systems with narrower
long.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Optimise memset on i386

[richardvo...@gmail.com]

On Fri, Jul 23, 2010 at 12:34 PM, Christian Franke <
christian.fra...@t-online.de> wrote:

> richardvoigt wrote:
>
>>
>> might I suggest:
>>
>> unsigned long patternl = pattern8;
>> patternl |= patternl << 8;
>> patternl |= patternl << 16;
>> patternl |= patternl << 32;
>> patternl |= patternl << 64;
>>
>> O(lg N) instead of O(N), no loop, no branches, and the compiler should be
>> smart enough to optimize away the last two lines on systems with narrower
>> long.
>>
>
> The latter is unfortunately not the case. At least gcc 4.5.0 prints a
> warning but still produces code.
>
>
Ok then, a compile-time conditional should fix that.

unsigned long patternl = pattern8;
if (8 < sizeof patternl) patternl |= patternl << 8;
if (16 < sizeof patternl) patternl |= patternl << 16;
if (32 < sizeof patternl) patternl |= patternl << 32;
if (64 < sizeof patternl) patternl |= patternl << 64;

I'm pretty confident in gcc's ability to optimize this version.  I hope.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Optimise memset on i386

[richardvo...@gmail.com]

On Fri, Jul 23, 2010 at 2:48 PM, richardvo...@gmail.com <
richardvo...@gmail.com> wrote:

>
>
> On Fri, Jul 23, 2010 at 12:34 PM, Christian Franke <
> christian.fra...@t-online.de> wrote:
>
>> richardvoigt wrote:
>>
>>>
>>> might I suggest:
>>>
>>> unsigned long patternl = pattern8;
>>> patternl |= patternl << 8;
>>> patternl |= patternl << 16;
>>> patternl |= patternl << 32;
>>> patternl |= patternl << 64;
>>>
>>> O(lg N) instead of O(N), no loop, no branches, and the compiler should be
>>> smart enough to optimize away the last two lines on systems with narrower
>>> long.
>>>
>>
>> The latter is unfortunately not the case. At least gcc 4.5.0 prints a
>> warning but still produces code.
>>
>>
> Ok then, a compile-time conditional should fix that.
>
>

Thanks to Seth for pointing out my obvious bug.

unsigned long patternl = pattern8;
if (1 < sizeof patternl) patternl |= patternl << 8;
if (2 < sizeof patternl) patternl |= patternl << 16;
if (4 < sizeof patternl) patternl |= patternl << 32;
if (8 < sizeof patternl) patternl |= patternl << 64;



> I'm pretty confident in gcc's ability to optimize this version.  I hope.
>
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [RFC] Detect other software using embedding area

[richardvo...@gmail.com]

On Sun, Sep 5, 2010 at 10:14 AM, C. P. Ghost  wrote:

> On Tue, Aug 31, 2010 at 2:54 PM, Thomas Schmitt  wrote:
> > Maybe one should use external boot media of
> > which GRUB can claim complete ownership.
> > I.e. an USB stick or a CD which hosts GRUB and
> > a custom configuration.
> > This way, GRUB would have no shares in the
> > embattled area at all.
>
> This way, GRUB would be unusable on rack-mounted
> servers in data centers. You can't add a USB stick or CD
> there, if all you have is remote serial console access...
>

On servers hopefully you are setting up a special partition for grub to use.

The embedding area sounds like it is trying to solve a problem with
dual-boot systems where the first OS is already installed and cannot be
moved.


>
> -cpghost.
>
> --
> Cordula's Web. http://www.cordula.ws/
>
> ___
> 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: Guidance on conflicts between GNU GRUB and proprietary software

[richardvo...@gmail.com]

On Fri, Sep 24, 2010 at 9:09 AM, Richard Stallman wrote:

>> It appears that, rather than the operating system itself being at
> fault,
>> a number of Windows applications take over a sector in the boot track
>> and store bits and pieces of data there.
>
> I am surprised applications can do that.  Isn't that a security hole
> in Windows?
>

Is it a security hole if the linux superuser can write to /dev/sda ?  If you
block this level of access, how's fdisk (or any number of other partition
managers) supposed to do its job?  How's one supposed to install grub in the
first place, if access to those blocks is forbidden by every OS?

We are talking about the owner of the machine, and software they choose to
run.  An OS that prevented the owner from having full control over his own
machine would be something to complain about, letting the owner write to his
boot track is not.

If we think there's a real security hole here, like unprivileged
applications able to overwrite grub code, I'll go advocate with Microsoft to
have it fixed.  Until then I just agree that it's a tragedy that
applications which aren't bootloaders or partition managers mess around in
this area, but it shouldn't be up to the OS to decide which applications run
by the superuser are specially privileged to manage partitions, and which
aren't.

Yours truly,
R Benjamin Voigt
Microsoft Visual C++ MVP and Windows private beta tester

P.S. Does anyone know if the Linux versions of those same proprietary
license managers abuse the boot track like their Windows behavior?
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Documentation bug?

[richardvo...@gmail.com]

>
>
> I have just downloaded a tarball of grub-1.99~rc1, and a ‘find’ command
> on the untarred tree did not return any positives either.
>

What tarball have you downloaded?  Source code, probably.  stage2_eltorito
is machine code that has to be compiled for the particular architecture.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Improve documentation of BIOS installation

[richardvo...@gmail.com]

> -@strong{Caution:} Be very careful which partition you select!  When GRUB
> -finds a BIOS Boot Partition during installation, it will automatically
> -overwrite part of it.  Make sure that the partition does not contain any
> -other data.
+@xref{BIOS installation}, for details on where the core image can be
+installed on PC systems.

I would suggest NOT moving warnings into links introduced as "for
details".  Something should be kept here, like:

( ! ) Caution: If your system has a BIOS Boot Partition, GRUB
automatic installation will overwrite it and data could be lost.  Be
sure to read @xref{BIOS installation/GPT}.

And then that section needs to also contain a simple test which users
can do to discover that they have no BIOS Boot Partition to worry
about.

Please also check whether it's more correct to say that GRUB will
automatically overwrite during installation, or GRUB will overwrite
during automatic installation.

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

Re: Out of Memory Error

[richardvo...@gmail.com]

On Mon, Mar 28, 2011 at 2:56 PM, Gus Zernial  wrote:
> I've posted my problem to this list before without getting a
> solution - also to grub-help and Ubuntu forum(s), no answer - I'm
> stumped and would really appreciate help.
>
> I have Kubuntu 10.10, a custom 2.6.37.1 kernel, and GRUB2. I was on
> v1.98 when the problem started, I'm now on 1.99~rc1 which I downloaded
> and compiled, the upgrade didn't help.
>
> My system has three disks - / is on an SSD, and /home is on the other

Which SSD?  This sounds rather like the infamous OCZ time warp.  Are
other changes made to the SSD lost, or only the boot sector?

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

Re: Out of Memory Error

[richardvo...@gmail.com]

> On 03/29/2011 05:48 PM, richardvo...@gmail.com wrote:
>> Which SSD?  This sounds rather like the infamous OCZ time warp.  Are
>> other changes made to the SSD lost, or only the boot sector?

On Tue, Mar 29, 2011 at 7:50 PM, Phillip Susi  wrote:
> What OCZ time warp?  I have an OCZ SSD and don't have any trouble with
> it.  Hadn't noticed anything about this on their forums either.

I don't have any trouble with mine either, but it seems to plague
certain systems.  It was discussed extensively during the most recent
firmware release cycle, which is how I learned about it.

http://www.ocztechnologyforum.com/forum/search.php?securitytoken=guest&do=process&query=%22time%20warp%22

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

Re: Full documentation for GRUB2

[richardvo...@gmail.com]

> I've wondered occasionally whether it would be worth it to include
> something like GRUB_STATIC in upstream grub-mkconfig; if set, this would
> cause grub-mkconfig to do nothing, perhaps printing a message.  This
> would mean you wouldn't have to figure out how to disable distribution
> facilities that run grub-mkconfig for you; you could just set
> GRUB_STATIC=1 and write your own grub.cfg if you wanted.  Vladimir, do
> you think you'd take such a change for 1.99?

Based on other messages in this thread, this likely wouldn't be very
effective.  Boot from a LiveCD?  It won't have GRUB_STATIC set.

IMO, a better option would be to control this from the config file
itself (and obviously it's already too late from one perspective,
there already exist distro releases with tools that won't respect it).

I would lean toward a solution wherein the tools refuse to modify a
config that contains any of

config_protected 1
config_protected yes
config_protected true

(and prints an appropriate message so a user who is trying to run a
boot fix-it tool is informed how to disable the protection, better
have a specific exit code as well so that wrapper tools which don't
show tool stdout/stderr to the user can detect this condition and
display their own message, possibly localized)

Then the tools can generate a config that starts with

# this file is auto-generated, allow re-generation (manual edits will be lost)
config_protected false

Any user who opens the config in an editor should understand that a
change needs to be made to switch off auto-generation, they can most
likely infer the syntax they want or go read the documentation.


Ben

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

Re: Automatic module license checking

[richardvo...@gmail.com]

When does this check run?  Seems ridiculous to do this on every boot
cycle, a bootloader should execute as quickly as possible, not try to
solve the world's legal problems.

Just my $0.02

2011/4/11 Vladimir 'φ-coder/phcoder' Serbinenko :
> Hello, all. Due to recent case of non-compliance with GPL in a project
> using GRUB2 codebase and according to new GNU guidelines I've
> implemented an automatic module license checking. This checks doesn't
> change in nothing the distributor obligation: any GRUB2 module is
> covered by GPLv3(+) (and optionally dual-licensed under another
> license). However, this change makes this compliance requirement
> explicit by requiring author to put a GRUB_MOD_LICENSE macro. Also note
> that everybody is allowed to remove the said check but doing so doesn't
> free from legal GPL obligation. When implementing this check I've added
> a bunch of GRUB_MOD_LICENSE and GRUB_MOD_DUAL_LICENSE, I'll be grateful
> if everyone who sees a problem (e.g. non-correspondance between license
> header and macro) would report it to me and I'll fix it as soon as time
> permits.
>
> --
> Regards
> Vladimir 'φ-coder/phcoder' Serbinenko
>
>
>
> ___
> 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: Timeout broken with serial port

[richardvo...@gmail.com]

On Mon, Sep 5, 2011 at 3:51 PM, Aleš Nesrsta  wrote:
> Hi,
>
> I think it is not GRUB related problem, more probably there is some HW
> problem on Your serial port. Try to check idle voltage on RxD pin of
> serial port (best with oscilloscope... :-) ). Or You can have some
> unwanted "leakage" between pins of connector or wires in cable (check
> resistance between wires of cable) etc.
>
> Normal serial port should NEVER do anything if there is nothing
> connected to it. According to RS232 (V24) specification there should be
> voltage in range from -12V to -3V on RxD pin in idle state (in simplest
> case there is some internal pull-up resistor connected from RxD to -Vcc
> directly inside UART or something else...).
> In this normal case nothing is received by serial port and nothing will
> be interpreted as keypress in GRUB, i.e. GRUB will boot normally.
>
> In Your case, probably something causes some noise on RxD pin or there
> is bad voltage level on RxD pin (e.g. >= +3V or near to 0V etc.) when
> nothing is connected - so serial port interprets it as receiving some
> character(s).


An idle transmitter should be in the range -3V...-12V.  But here there
is no transmitter.  I would not be at all surprised if some hardware
implements "cable detect" using a weak pull to 0V.

Still, data shouldn't be reported by the receiver unless the voltage
is in the valid range, and the input should not be left floating
either.

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