Re: [RFC] Dynamic device.map
On Thu, Dec 10, 2009 at 01:55:27AM +0100, Robert Millan wrote: > On Wed, Dec 09, 2009 at 11:04:43PM +, Colin Watson wrote: > > I'm trying to figure out how to make Debian's grub-installer operate > > without a device.map; it has various legacy bits and pieces that need > > conversion, and I'm working on these. > > > > Along the way, though, I noticed that grub-install still unconditionally > > creates a device.map. This seems likely to become confusing if devices > > are changing around a lot, since it's never updated. I'd like to get to > > the point where it doesn't do this by default. How about we add support > > for an option to disable this, and make grub-installer and the Debian > > maintainer scripts pass it once they're ready? Some time later, we can > > flip the default value. > > Why is this option necessary? If we removed automated generation of > device.map, user can still call grub-mkdevicemap manually. Certainly, but I would like to be able to deliver a system that does not generate a device.map by default. > But first we'd need to figure out what we do with the "set root=xxx" > backward compatibility hack. Has it been a while long enough that > we can remove support for GRUB installs that didn't come with UUID > support? > > If we don't do anything on grub-mkconfig side and remove device.map, we'll > end up with things like "set root=(/dev/sda1)" which is not just useless > but also utterly confusing. No, I don't think we will. grub-probe is perfectly capable of mapping /dev/sda1 to (hd0,1) even without device.map; it's just that that mapping will be solely dependent on device iteration order at the time you run grub-mkconfig. (As opposed to whatever device iteration order happened to be the first time you installed GRUB, for the nearly-everyone who never edited device.map by hand ...) -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Dynamic device.map
Am Donnerstag, den 10.12.2009, 01:55 +0100 schrieb Robert Millan: > But first we'd need to figure out what we do with the "set root=xxx" > backward compatibility hack. Has it been a while long enough that > we can remove support for GRUB installs that didn't come with UUID > support? Well we still have Arthur Marsh' bug open that search --fs-uuid fails with right UUID even though ls (hdx,y) shows it. https://savannah.gnu.org/bugs/?26834 Also on Debian BTS and Launchpad. The good thing though is that only a grub_errno = GRUB_ERR_NONE; needs to be commited to have this fixed. Unfortunately he attached the full kern/device.c to the report not the patch Vladimir made for him. -- Felix Zielcke Proud Debian Maintainer and GNU GRUB developer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: autogen.sh warnings
Am Donnerstag, den 10.12.2009, 00:05 -0600 schrieb Bruce Dubbs: > On the other hand, config.guess is used to get build_cpu and build_os > and I don't see that being used at all right now by grub. Well just after the part you quoted from me, I thought I made it clear that the output of config.guess is used as an argument for config.sub So you just need both. At least as long as autoconf doestn't get changed. -- Felix Zielcke Proud Debian Maintainer and GNU GRUB developer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Broken common.rmk change
That was my intent, yes. --S Quoting BVK Chaitanya, who wrote the following on Thu, 10 Dec 2009: On Thu, Dec 10, 2009 at 3:15 AM, Robert Millan wrote: On Mon, Dec 07, 2009 at 10:23:51PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: Seth proposed a hinting technique: search --fs_uuid ... -s root --hint hd0,1 then hd0,1 will be checked first and only on failure it will revert to scanning I assume, this --hint argument can be given multiple times, and while searching their order is followed ??? regards, -- bvk.chaitanya ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
New Chinese (simplified) PO file for 'grub' (version 1.97+20091122)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'grub' has been submitted by the Chinese (simplified) team of translators. The file is available at: http://translationproject.org/latest/grub/zh_CN.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/grub/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/grub.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: autogen.sh warnings
Felix Zielcke wrote: Am Donnerstag, den 10.12.2009, 00:05 -0600 schrieb Bruce Dubbs: On the other hand, config.guess is used to get build_cpu and build_os and I don't see that being used at all right now by grub. Well just after the part you quoted from me, I thought I made it clear that the output of config.guess is used as an argument for config.sub So you just need both. At least as long as autoconf doestn't get changed. Exactly. I originally said that config.guess was required by configure even though the output not used. As you pointed out to me, config.sub output is used. This all goes back to the overall build process. I've been thinking about it a lot, but I'm not ready to offer any suggestions yet. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Documenting the GRUB configure (during build)
Robert Millan wrote: On Sat, Dec 05, 2009 at 03:42:24PM -0600, Bruce Dubbs wrote: I'm afraid I don't agree that the solution to documenting changes is not to document anything. That may be a little harsh, but I firmly believe that documentation is key to acceptance. It's OK. Well my concern is about long-term maintainability. We're very busy all the time, and redundancy in our codebase often results in birot. Can I count on your commitment that you'll be around to adjust this documentation if it gets out of sync, etc? Yes, I think you can. I've always been interested in the boot process. I remember disassembling the boot sector back in the late '80s to see what was going on. That was before I knew about open source and the use of the internet became generally available (I didn't have it). I went back to school late in life (91-93) and my dissertation was on the effects of comments on the maintainability of source code. :) Now I'm semi-retired and I think I can commit to a few years. I don't think my interest will wane. :) -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Documenting the GRUB configure (during build)
Quoting Bruce Dubbs, who wrote the following on Thu, 10 Dec 2009: Robert Millan wrote: On Sat, Dec 05, 2009 at 03:42:24PM -0600, Bruce Dubbs wrote: I'm afraid I don't agree that the solution to documenting changes is not to document anything. That may be a little harsh, but I firmly believe that documentation is key to acceptance. It's OK. Well my concern is about long-term maintainability. We're very busy all the time, and redundancy in our codebase often results in birot. Can I count on your commitment that you'll be around to adjust this documentation if it gets out of sync, etc? Yes, I think you can. I've always been interested in the boot process. I remember disassembling the boot sector back in the late '80s to see what was going on. That was before I knew about open source and the use of the internet became generally available (I didn't have it). I went back to school late in life (91-93) and my dissertation was on the effects of comments on the maintainability of source code. :) Now I'm semi-retired and I think I can commit to a few years. I don't think my interest will wane. :) You're the dream-person to do this job. And bless you for taking it on :). --S ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Build failures on Ubuntu due to gettext
Hi, On Dec/10/2009, Robert Millan wrote: > On Tue, Dec 08, 2009 at 12:10:34AM +, Colin Watson wrote: > Even if we're only discussing a change in five places, I assume we're > going to find this situation in lots of calls throurough GRUB code. > If this is so, it really calls for a solution that doesn't make GCC > generate two memory references and pass two arguments. > > So first of all, how many times are we going to find similar calls > that very rush numbers, based on my non-commited pending to improve patch to change commands/*: car...@pinux:~/grub2/grub/po$ grep -A 3 "\#\: commands\/" grub.pot | grep ^msgid | grep -c -v % 86 > need to be adjusted in some way? If we're going to find many of them > (as I expect), I think this warrants adding a new function (which, > btw, will also make GRUB slightly faster). Plus about 10 in normal/* (aprox, 5 that Colin did and some more in another pending patch I guess) I haven't looked in other code yet. I think that Vladimir proposed to do it in a macro now and then properly count and implement as a function or not later. From: Vladimir Date: Tue, 08 Dec 2009 01:15:30 +0100 > Then it's not worth it. But again we haven't gettext'ized whole grub2 > yet to know for sure. Perhaps a macro so we can change it later if > necessary? So, for about 86 in commands/* and probably some more in normal/*: function now? Now a macro and then we review? Colin: for me you can commit your patch some way or another so you could compile in Ubuntu and I can commit soon more things. Thanks, -- Carles Pina i Estany http://pinux.info ___ 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 Sat, Dec 05, 2009 at 04:16:45AM EST, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > Chris Jones wrote: [..] > > Why do I have to enable tracing to make it work? > > > Because a dprintf acted as a forgotten millisleep. This patch should > fix it. On my machine I still have issues because uhci.c has problems > with second port Excellent. > > 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..? > > > I'm working on it but the current problem is that I haven't found a > syscall in linux to get physical address of a page. Does anyone has a > suggestion? That would be great. The worst time to experiment and learn new tricks is when you're in a fix and your system won't boot. Be prepared! Thanks again for your help. CJ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
