Re: [solved] Re: USB device not seen by grub
On Fri, Dec 04, 2009 at 09:58:23PM EST, richardvo...@gmail.com wrote: > On Fri, Dec 4, 2009 at 8:26 PM, Chris Jones wrote: [..] > > 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. Thanks for reminding me. CJ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: USB device not seen by grub
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: [solved] Re: USB device not seen by grub
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
[solved] Re: USB device not seen by grub
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? Also, is there any way I can run the grub command line on a system that's already booted, so I can explore its possibities in a context where I have internet access, browse documentation, etc..? Thanks, CJ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Documenting the GRUB configure (during build)
I want to submit an update to the INSTALL file. In looking at ./configure, it does some guessing. We have: `--enable-efiemu' Build and install the efiemu runtimes (default=guessed) `--enable-grub-emu' Build and install the `grub-emu' debugging utility (default=guessed) `--enable-grub-emu-usb' Build and install the `grub-emu' debugging utility with USB support (default=guessed) `--enable-grub-fstest' Build and install the `grub-fstest' debugging utility (default=guessed) `--enable-grub-mkfont' Build and install the `grub-mkfont' utility (default=guessed) -- I am trying to see how configure guesses. It looks like: enable-efiemu depends on gcc supporting -m64 -mcmodel=large -mno-red-zone -nostdlib enable-grub-emu depends on ncurses enable-grub-emu-usb depends on enable-grub-emu and libusb enable-grub-fstest really has a default of yes enable-grub-mkfont depends on fontconfig --- Is this analysis right? Should the description of enable-grub-fstest be changed to yes in configure.ac? Actually, I would think the four testing/debug programs above should default to no with perhaps a global --enable-testing-programs to turn them all on. Of course grub-mkfont should be on by default if fontconfig is available, as it is now. --- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Miscellaneous file cleanup
As a first attempt at an update, I am attaching a minor change to
Makefile.in to remove left over files in docs when making distclean.
-- Bruce
=== modified file 'ChangeLog'
--- ChangeLog 2009-11-30 01:25:57 +
+++ ChangeLog 2009-12-04 23:59:11 +
@@ -1,3 +1,9 @@
+2009-12-04 Bruce Dubbs
+
+ Remove miscellaneous files in distclean target.
+
+ * Makefile.in: Remove docs/{grub.info,version.texi,stamp-vti}
+
2009-11-30 Robert Millan
Fix $srcdir != $objdir build.
=== modified file 'Makefile.in'
--- Makefile.in 2009-11-30 01:25:57 +
+++ Makefile.in 2009-12-05 00:00:31 +
@@ -139,7 +139,9 @@
MOSTLYCLEANFILES =
DISTCLEANFILES = config.status config.cache config.log config.h \
Makefile stamp-h include/grub/cpu include/grub/machine \
- gensymlist.sh genkernsyms.sh build_env.mk
+ gensymlist.sh genkernsyms.sh build_env.mk \
+ docs/{grub.info,version.texi,stamp-vti}
+
MAINTAINER_CLEANFILES = $(srcdir)/configure $(addprefix $(srcdir)/,$(MKFILES))
\
$(srcdir)/DISTLIST $(srcdir)/config.h.in $(srcdir)/stamp-h.in $(INFOS)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: USB device not seen by grub
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: USB device not seen by grub
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. And all of this only to make good to someone who would like to see every free software die? -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Customization of GRUB2
It should be noted that use of the generation scripts is optional and may not be used on some systems... --S On Dec 4, 2009, at 1:25 PM, Robert Millan wrote: On Tue, Dec 01, 2009 at 11:04:56PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: Bruce Dubbs wrote: Vladimir 'φ-coder/phcoder' Serbinenko wrote: Bruce Dubbs wrote: I am trying to provide documentation about GRUB2 (1.97.1) customization for the Linux From Scratch book. I am having quite a bit of trouble finding anything describing how to set up a splash screen directly in grub.cfg. Could you help us with documenting grub better? Patches against texinfo manual are welcome I may be able to do that, however, I need to learn it myself. I don't really mind reading code either, but a general idea about where the drawing of the menu entries is located would be helpful. I quick check shows that GRUB2 has 287 .c files, but I suspect that most of the menu customization is handled in the term/ directory. Actually most is in normal/ and gfxmenu/. Some stuff is in term/ gfxterm.c And util/ (notably, util/grub.d) for the menu generation scripts. -- 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: var=foo should be valid?
Hi,
On Dec/04/2009, Robert Millan wrote:
> On Sun, Nov 29, 2009 at 06:39:36PM +, Carles Pina i Estany wrote:
> > (first one has a bug but very easy to fix, even thought I would maybe
> > refactor this code to implement in other way)
>
> Can you give more details about this bug and the refactor that would be
> needed?
Find attached the simple patch (without refactoring) (it resets
grub_errno _before_ grub_env_set, because grub_env_set calls the hooked
functions).
The refactoring would be in file script/execute.c, function
grub_script_execute_cmdline. See the attached file set_refactor.patch
for the idea. It's more work/things in Grub but I think that more
robust since now will be the same code using set or without using set.
Of course, maybe this extra-complexity is not needed.
I have not looked into the Grub parser: maybe the extra-best place to
implement it it's there, but I'm not familiar with Lex/Yacc/Bison/... .
Cheers,
--
Carles Pina i Estany
http://pinux.info
=== modified file 'script/execute.c'
--- script/execute.c 2009-11-23 15:37:33 +
+++ script/execute.c 2009-12-04 21:43:28 +
@@ -116,10 +116,11 @@ grub_script_execute_cmdline (struct grub
/* Create two strings and set the variable. */
*eq = '\0';
eq++;
- grub_env_set (assign, eq);
/* This was set because the command was not found. */
grub_errno = GRUB_ERR_NONE;
+
+ grub_env_set (assign, eq);
}
grub_free (assign);
=== modified file 'script/execute.c'
--- script/execute.c 2009-11-23 15:37:33 +
+++ script/execute.c 2009-12-04 21:51:41 +
@@ -113,13 +113,15 @@ grub_script_execute_cmdline (struct grub
if (eq)
{
- /* Create two strings and set the variable. */
- *eq = '\0';
- eq++;
- grub_env_set (assign, eq);
-
- /* This was set because the command was not found. */
- grub_errno = GRUB_ERR_NONE;
+ // TODO
+ // New Command Line Function = set
+ // New arguments = Old Command Line Function concatenate Old arguments
+ // Call grub_script_execute_cmdline (newCmd)
+ //
+ // So if before user typed a=b we call recursively:
+ // set a=b
+ //
+ // Alternatively: Don't need to check for "="
}
grub_free (assign);
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Syntax checker for GRUB script config file
On Fri, Dec 04, 2009 at 07:12:12AM +, BVK wrote: > Hi, > > > > Attached patch (experimental) adds a new tool, grub-script-check, that > can be used to check grub.cfg file syntax. Idea is to use this tool > during update-grub to catch any syntax errors and reject the update. > > This tool uses the same parsing code as the normal mode script engine, > except that it doesn't (cannot) execute any commands. Let me know > your comments. Excellent idea. > As part of this tool, I found few bugs in parser.y script and is > updated as necessary. Basically, current parser.y can parse only one > menuentry or function command (and expects an $end after '}'), which > is wrong because grub.cfg contains multiple function/menuentry > definitions. This was raising a syntax error, which is fixed by > modifying the gammar to support multiple menuentry/function commands. Could you send this as a separate patch? Also, if you can, please use text/plain attachments, this makes it easier to review with context replies. Thanks! -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: USB device not seen by grub
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". > 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. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Fix sparc64 build...
From: Robert Millan Date: Fri, 4 Dec 2009 21:58:25 +0100 > On Thu, Dec 03, 2009 at 01:03:09PM -0800, David Miller wrote: >> >> Thanks, but I don't feel comfortable enough with bzr yet. >> >> I had to struggle just to get things checked out, as the bzr >> package in Debian stable is too old to use to access to repo. >> >> (For the record I disagree with the source control system choosen, >> and the fact that a common current Linux distribution doesn't even >> provide a version of the tool necessary to access the repo really >> convinces me further of that.) > > For a Lenny system the following should do the trick: > > echo "deb http://backports.org/debian lenny-backports main" | sudo tee -a > /etc/apt/sources.list > gpg --keyserver pgp.mit.edu --recv-keys 16BA136C > gpg --export -a 16BA136C | sudo apt-key add - > sudo apt-get update > sudo apt-get install -t lenny-backports bzr That's not a straightforward and low barrier of entry for new developers who want to simply check out the grub code and start contributing. That's my point. Do you want lots of people involved, or do you want people to have to jump through hoops and go out of their way to get at your tree? Heck, for this reason alone, subversion was a better situation. Mercurial, GIT, or pretty any other distributed source control system would have worked out of the box with the client versions provided in debian stable and other distributions. So, I still believe BZR was a bad choice of a source control system. And how many times have you guys wrecked your repository already? :-) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Fixed some typos
On Wed, Dec 02, 2009 at 10:14:29AM +, Colin Watson wrote: > On Wed, Dec 02, 2009 at 10:01:44AM +0100, Richard Hartmann wrote: > > On Wed, Dec 2, 2009 at 09:47, Colin Watson wrote: > > > Thanks for your patch. However, it appears to be against GRUB Legacy, > > > which no longer has an upstream maintainer. The same typos aren't > > > present in GRUB 2. > > > > Correct, GRUB 2 is fine. > > > > Personally, I think it's worth committing to legacy because _if_, for > > whatever reason, there is another release, it will help a tiny bit. If not, > > no harm is done and no one needs to care. > > I'm not even sure how to go about committing to GRUB Legacy. :-) Is > sftp://bzr.sv.gnu.org/srv/bzr/grub/trunk/grub-legacy/ likely to work, or > is it meant to be a read-only mirror of something? It's not clear there'll be another release of GRUB Legacy, but if there is, I'd use that URI. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Customization of GRUB2
On Tue, Dec 01, 2009 at 01:49:07PM -0800, Seth Goldberg wrote: > Hi, > > I'm going to make an unpopular suggestion, so feel free to tell me to > take a hike, but I think Bruce's question highlights a very important > point-- the documentation that we have for GRUB2 at this point is very > poor. In order to continue to get new users to use GRUB2, we need > quality documentation at least initially written by the people who > authored the code. User documentation is at least as important as the > multitude of features that are pouring in, and I think we'll see a > dramatic uptake of GRUB2 as well as a more-satisfied userbase with > comprehensive documentation. Feel free to flame me, but this is my > opinion. Seth, Feel free to speak your mind :-) And I think it's a very nice idea and would be cool if everyone followed it, but we can't make a rule out of this. If it was mandatory for new code, contributors might feel encumbered by it, and it could stall development. Then again, whenever someone comes with code in one hand and docs in the other, that effort has all my appreciation ;-) -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Customization of GRUB2
On Tue, Dec 01, 2009 at 11:04:56PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > Bruce Dubbs wrote: > > Vladimir 'φ-coder/phcoder' Serbinenko wrote: > >> Bruce Dubbs wrote: > >>> I am trying to provide documentation about GRUB2 (1.97.1) > >>> customization for the Linux From Scratch book. I am having quite a > >>> bit of trouble finding anything describing how to set up a splash > >>> screen directly in grub.cfg. > > > >> Could you help us with documenting grub better? Patches against texinfo > >> manual are welcome > > > > I may be able to do that, however, I need to learn it myself. > > I don't really mind reading code either, but a general idea about > > where the drawing of the menu entries is located would be helpful. > > > > I quick check shows that GRUB2 has 287 .c files, but I suspect that > > most of the menu customization is handled in the term/ directory. > > > Actually most is in normal/ and gfxmenu/. Some stuff is in term/gfxterm.c And util/ (notably, util/grub.d) for the menu generation scripts. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: handling mount points in grub-mkrelpath
On Sun, Nov 29, 2009 at 09:52:32PM +0100, Felix Zielcke wrote:
> Vladimir wanted to have this discussed on ML
>
> The old shell function make_system_path_relative_to_its_root outputed /
> if you gave it /boot and it was on a seperate partition.
> grub-mkrelpath currently outputs /boot
>
> This breaks booting at least with the 10_linux generated entries.
>
> Attached is my fix for that, which I'll update today to Debian.
>
> We already broke backward compatibility with the commandline for Xen.
> IMO in this grub-mkrelpath case there's no need to break compatibility.
>
> But maybe I can find a good way to handle this inside
> util/grub-mkconfig_lib.in just for compatibility.
Hi,
The old behaviour seems correct, so there's no need to break compatibility.
Please could you commit this in trunk?
> 2009-11-29 Felix Zielcke
>
> * util/misc.c (make_system_path_relative_to_its_root): Correctly cope
> with
> mount points.
> === modified file 'util/misc.c'
> --- util/misc.c 2009-11-25 23:10:02 +
> +++ util/misc.c 2009-11-29 19:19:28 +
> @@ -500,7 +500,17 @@ make_system_path_relative_to_its_root (c
>
>/* buf is another filesystem; we found it. */
>if (st.st_dev != num)
> - break;
> + {
> + /* offset == 0 means path given is the mount point. */
> + if (offset == 0)
> + {
> + free (buf);
> + free (buf2);
> + return strdup ("/");
> + }
> + else
> + break;
> + }
>
>offset = p - buf;
>/* offset == 1 means root directory. */
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: var=foo should be valid?
On Sun, Nov 29, 2009 at 06:39:36PM +, Carles Pina i Estany wrote: > (first one has a bug but very easy to fix, even thought I would maybe > refactor this code to implement in other way) Can you give more details about this bug and the refactor that would be needed? -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: var=foo should be valid?
On Mon, Nov 30, 2009 at 09:39:50AM +, Colin Watson wrote: > > I would appreciate it if we left it as it is now. It is not > intrinsically bad to have both, and GRUB 2 is already deployed in > production so it's quite likely that people will in fact be using both > syntaxes. (Indeed, the configuration file I'm delivering by default in > Ubuntu 9.10 uses both syntaxes! I should probably normalise that but I > simply hadn't thought about it as being any kind of problem.) We should > not break production installations when there is no reason to do so. Don't worry, we can't promise we'll stick to an interface forever, but we're careful not to break existing setups. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Faster glyph lookup by BMP index
On Sun, Nov 29, 2009 at 03:29:18PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> 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
Seems fine (for trunk as well), just one thing:
> + grub_memset (font->bmp_idx, 0xff, 0x1 * sizeof (grub_uint16_t));
> [...]
> + if (entry->code < 0x1)
> [...]
> + /* Use BMP index if possible. */
> + if (code < 0x1)
> +{
> + if (font->bmp_idx[code] == 0x)
Could these be macroified? Makes it harder to do mistakes in the future.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub_halt()
On Sat, Nov 28, 2009 at 08:01:01PM +0100, Robert Millan wrote: > On Fri, Nov 27, 2009 at 10:24:39PM +0100, Vladimir 'φ-coder/phcoder' > Serbinenko wrote: > > Felix Zielcke wrote: > > > grub_halt is on i386-pc defined as `void grub_halt (int no_apm)' but > > > everywhere else as `grub_halt (void)' > > > util/grub-emu.c has a #ifdef for these 2 > > > > > > Shouldn't we just add an int parameter everywhere to make this more > > > simple? > > > > > > > > I think in future we'll have more different halt methods on different > > platforms. So we could do: > > grub_halt (int methods) > > And have e.g. > > GRUB_HALT_DEFAULT_METHODS > > And e.g. on i386: > > #define GRUB_HALT_DEFAULT_METHODS > > (GRUB_HALT_APM|GRUB_HALT_ACPI|GRUB_HALT_HANG) > > I was hoping we could remove complexity rather than add more of it. > > Why would higher layer (who's just calling grub_halt because it wants the > system to shutdown) want to know about things like APM or ACPI ? Well, for now I just unified the headers but kept the current i386-pc function parameters. This restores experimental to a buildable state. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: mips/*/time.h
On Fri, Dec 04, 2009 at 05:24:02PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > Robert Millan wrote: > > Hi, > > > > In mips branch grub_cpu_idle() is provided by grub/mips/yeeloong/time.h > > and grub/mips/qemu-mips/time.h, but there's no grub/mips/time.h. > > > > This breaks mipsel-emu port, which lacks this definition. Why not merge > > mips/yeeloong/time.h and mips/qemu-mips/time.h into mips/time.h ? Both > > files are identical. > > > > > Both are stubs actually. Why does *-emu needs these files at all? *-emu > doesn't see this type of machine info. It should just use host function > for both cpu_idle and get_rtc grub_cpu_idle is implemented as an inline stub, which resides in time.h. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Fix sparc64 build...
On Thu, Dec 03, 2009 at 01:03:09PM -0800, David Miller wrote: > > Thanks, but I don't feel comfortable enough with bzr yet. > > I had to struggle just to get things checked out, as the bzr > package in Debian stable is too old to use to access to repo. > > (For the record I disagree with the source control system choosen, > and the fact that a common current Linux distribution doesn't even > provide a version of the tool necessary to access the repo really > convinces me further of that.) For a Lenny system the following should do the trick: echo "deb http://backports.org/debian lenny-backports main" | sudo tee -a /etc/apt/sources.list gpg --keyserver pgp.mit.edu --recv-keys 16BA136C gpg --export -a 16BA136C | sudo apt-key add - sudo apt-get update sudo apt-get install -t lenny-backports bzr -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Fix sparc64 build...
On Thu, Dec 03, 2009 at 12:59:00PM -0800, David Miller wrote: > > I have about half a year of potential regressions I'm about to > discover on sparc64. That's not an acceptable situation, long term. > > I might get hit by a bus or whatever, so it would be nice if someone > other than me were at least testing the code base out on sparc64. > > That way problems get spotted when they get added, or soon afterwards, > not 6 months later like some things are about to. :-) Actually, we have this debian buildd thing regularly testing sparc buildability: https://buildd.debian.org/build.php?arch=sparc&pkg=grub2 I assure you we'd have noticed in less than 6 months :-) (though I admit, not as efficiently as you did) -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Fix sparc64 build...
On Thu, Dec 03, 2009 at 09:22:27PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > You can commit to bzr yourself actually. And unless Robert objects I > guess your permission to tangle with sparc parts as you see fit is still > valid Of course. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Fix sparc64 build...
On Thu, Dec 03, 2009 at 02:17:29AM -0800, David Miller wrote: > > So I finally am about to have enough time to start looking into > sparc64 support again. > > And, surprise! The trunk doesn't even build. :-) I guess this one's my fault. Must have left it when adding all those progname.c, progname.h and gettext calls everywhere. Glad there's someone watching! :-) -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Rename kernel.mod to kernel.img on EFI.
On Wed, Dec 02, 2009 at 05:30:07PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > Fixes problem of users including kernel.mod as a module Great. Please do. Btw, this is a relief, I thought for some odd reason it actually *was* a module. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: gettext: install the *.mo files
On Sun, Nov 29, 2009 at 11:28:02AM +, Carles Pina i Estany wrote: > > Hello, > > Find attached a patch to install the *.mo files. > > I've tested grub-mkrescue.in but not grub-install.in (yet) > > Using for + if + cp and not cp with wildcards to really check that the > files exists and so on (like other parts of the file). > > Comments? Looks fine, please go ahead. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: mips/*/time.h
Robert Millan wrote: > Hi, > > In mips branch grub_cpu_idle() is provided by grub/mips/yeeloong/time.h > and grub/mips/qemu-mips/time.h, but there's no grub/mips/time.h. > > This breaks mipsel-emu port, which lacks this definition. Why not merge > mips/yeeloong/time.h and mips/qemu-mips/time.h into mips/time.h ? Both > files are identical. > > Both are stubs actually. Why does *-emu needs these files at all? *-emu doesn't see this type of machine info. It should just use host function for both cpu_idle and get_rtc -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
mips/*/time.h
Hi, In mips branch grub_cpu_idle() is provided by grub/mips/yeeloong/time.h and grub/mips/qemu-mips/time.h, but there's no grub/mips/time.h. This breaks mipsel-emu port, which lacks this definition. Why not merge mips/yeeloong/time.h and mips/qemu-mips/time.h into mips/time.h ? Both files are identical. -- 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
