Bugfix: no cursor on command line

Bugfix: no cursor on command line

[phcoder]

Testing grub I noticed this bug. Here is bugfix
Vladimir 'phcoder' Serbinenko

Index: normal/cmdline.c
===================================================================
--- normal/cmdline.c	(revision 1959)
+++ normal/cmdline.c	(working copy)
@@ -148,6 +148,7 @@
      {
        static char cmdline[GRUB_MAX_CMDLINE];

+      grub_setcursor (1);
        grub_print_error ();
        grub_errno = GRUB_ERR_NONE;
        cmdline[0] = '\0';

Re: Bugfix: no cursor on command line

[Vesa Jääskeläinen]

phcoder wrote:
> Testing grub I noticed this bug. Here is bugfix
> Vladimir 'phcoder' Serbinenko
> 
> Index: normal/cmdline.c
> ===================================================================
> --- normal/cmdline.c    (revision 1959)
> +++ normal/cmdline.c    (working copy)
> @@ -148,6 +148,7 @@
>      {
>        static char cmdline[GRUB_MAX_CMDLINE];
> 
> +      grub_setcursor (1);
>        grub_print_error ();
>        grub_errno = GRUB_ERR_NONE;
>        cmdline[0] = '\0';

I do not remember seeing a problem here. So what is actually the problem
and how to reproduce it?

Re: Bugfix: no cursor on command line

[phcoder]

> I do not remember seeing a problem here. So what is actually the problem
> and how to reproduce it?

I booted GRUB2 by GRUB-Legacy, command prompt appeared and worked but 
there were no cursor. I think the same problem appears when the user 
opens command line from the menu.
Vladimir 'phcoder' Serbinenko

Re: Bugfix: no cursor on command line

[Vesa Jääskeläinen]

phcoder wrote:
>> I do not remember seeing a problem here. So what is actually the problem
>> and how to reproduce it?
> 
> I booted GRUB2 by GRUB-Legacy, command prompt appeared and worked but
> there were no cursor. I think the same problem appears when the user
> opens command line from the menu.

Still not seeing this. There is already a call to grub_setcursor (1) at
the beginning of this function... (and that was added somewhere in 2005)...

I tried both graphical and text console and none seem to be affected.

Grub 2 command : uppermem (patch proposal)

[Bandan Das]

Hello List,

I was going through the Grub 2 TODO here : http://grub.enbug.org/TodoList and 
I see that one of the many commands that need to be implemented is "uppermem". 

Having played around with uppermem quite a bit (thanks to the weird systems I 
have to work with) on Grub Legacy, I was wondering if a patch for the same 
would be considered for inclusion? Please note that I haven't started work on 
it yet. I wanted to make sure that it's something desirable before putting up 
a patch.

Thanks,
Bandan

-- 
BSD

Re: Bugfix: no cursor on command line

[phcoder]

Sorry it seems that my fs was corrupted which caused failure at install. 
fsck and reinstall fixed the problem
Thanks
Vladimir 'phcoder' Serbinenko
Vesa Jääskeläinen wrote:
> phcoder wrote:
>>> I do not remember seeing a problem here. So what is actually the problem
>>> and how to reproduce it?
>> I booted GRUB2 by GRUB-Legacy, command prompt appeared and worked but
>> there were no cursor. I think the same problem appears when the user
>> opens command line from the menu.
> 
> Still not seeing this. There is already a call to grub_setcursor (1) at
> the beginning of this function... (and that was added somewhere in 2005)...
> 
> I tried both graphical and text console and none seem to be affected.
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Grub 2 command : uppermem (patch proposal)

[Robert Millan]

On Tue, Jan 27, 2009 at 08:30:32PM -0500, Bandan Das wrote:
> Hello List,
> 
> I was going through the Grub 2 TODO here : http://grub.enbug.org/TodoList and 
> I see that one of the many commands that need to be implemented is "uppermem". 

The text in that list was a bit confusing.  We don't have to implement _all_
missing commands, only those we find useful.

> Having played around with uppermem quite a bit (thanks to the weird systems I 
> have to work with) on Grub Legacy, I was wondering if a patch for the same 
> would be considered for inclusion? Please note that I haven't started work on 
> it yet. I wanted to make sure that it's something desirable before putting up 
> a patch.

Could you describe your problem in more detail, so we can discuss if it's
something that makes uppermem worthy or we'd rather solve it in some other
way?  We don't want to leave your use case out in the cold, only to see if it
can be supported in a better way.

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

Re: Grub 2 command : uppermem (patch proposal)

[Bandan]

Hi, 

(Somehow I lost some of my emails, so copy pasting for reference.)

Robert, please have a look at http://savannah.gnu.org/bugs/?18471 for the 
related bug report on grub-legacy. This description is wrt grub-legacy and I 
will soon follow up with my observations with grub2.

In short, the systems have a memory hole somewhere at the beginning of the 
map, and the main problem is due to the fact that grub(legacy) does not find a 
contiguous memory region. So, if we have a large initrd or if we try to load a 
multiboot module (as in XEN), grub will bail out with error 28. 

With load_initrd(), we came up with a way to get away with the initial read of 
the initrd (please see patch attached with the above bug) and place it where 
the Linux kernel expects it to be. But with load_module(), it appeared there 
was no easy way out. So, we used uppermem to fool grub and place the multiboot 
module somewhere around 15M beyond the uppermem limit set by us. This took 
care of the problem temporarily.

I hadn't had a chance to try Grub2 on these machines, a first glance at 
grub_multiboot() and related functions tells me that things are significantly 
different from the way load_module() used to  work. I will soon try out grub2 
on these machines and come up with my observations.

Thanks,
Bandan

 
On Tue, Jan 27, 2009 at 08:30:32PM -0500, Bandan Das wrote:
> Hello List,
> 
> I was going through the Grub 2 TODO here : http://grub.enbug.org/TodoList 
and 
> I see that one of the many commands that need to be implemented is 
> "uppermem". 

The text in that list was a bit confusing.  We don't have to implement _all_
missing commands, only those we find useful.

> Having played around with uppermem quite a bit (thanks to the weird systems 
I 
> have to work with) on Grub Legacy, I was wondering if a patch for the same 
> would be considered for inclusion? Please note that I haven't started work 
on 
> it yet. I wanted to make sure that it's something desirable before putting 
up 
> a patch.

Could you describe your problem in more detail, so we can discuss if it's
something that makes uppermem worthy or we'd rather solve it in some other
way?  We don't want to leave your use case out in the cold, only to see if it
can be supported in a better way.

-- 
Robert Millan

Re: Grub 2 command : uppermem (patch proposal)

[Robert Millan]

On Mon, Feb 09, 2009 at 03:06:39PM -0500, Bandan wrote:
> This description is wrt grub-legacy and I 
> will soon follow up with my observations with grub2.

Hi,

Please try with GRUB 2 first.  GRUB Legacy is not maintained anymore.

In particular, the problem you describe is unlikely to affect the multiboot
loader, as the relocation process makes it very flexible.

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