Re: [patch] grub incorrectly identifies ext3 as fat
Hi, 2009/10/30 Robert Millan r...@aybabtu.com: What about probing in the boot-loader? It's too late then. grub-install needs to know which filesystem module has to be included in core.img. What if the core.img contains modules for 2 or more file systems? Cheers, Andrew ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Any tutorial to configure grub menu interface ?
On Sat, Oct 31, 2009 at 1:02 PM, J. Bakshi baksh...@gmail.com wrote: On Wed, 28 Oct 2009 22:52:41 +0100 Vladimir 'phcoder' Serbinenko phco...@gmail.com wrote: J. Bakshi wrote: On Wed, 28 Oct 2009 04:01:05 +0800 Bean bean12...@gmail.com wrote: On Tue, Oct 27, 2009 at 10:41 PM, J. Bakshi baksh...@gmail.com wrote: I wonder if there is any tutorial to crate cool grub menu interface. Can we use the grub2 2009 summer project to get those fancy interfaces ? Hi, There are actually two menu system. Colin has written a fancy menu patch as part of gsoc project, you can still get the code from http://grub.gibibit.com/, there are also some docs there. It looks good, but a little slow, and some feature like edit boot command hasn't been implemented. Recently, I have rewritten the menu system and it's almost done by now. The project is hosted at https://launchpad.net/burg, you can also follow this post in ubuntu forum: http://ubuntuforums.org/showthread.php?t=1248647 I plans to add some doc on menu config soon. Hello Bean, It is nice to know about your project. I hope it can be in main line grub soon. Eagerly waiting for that and also for your doc. Till now Bean ignored all our requests to work on merging these changes in the mainline or experimental. Unless he collaborates on merging there is nothing we can do. Bean, may I request you merge your great work in mainline grub2 ? A Lot of grub2 users like me are really interested to try your great work in grub2. Hi, It's not that I don't merge it to mainline, but parts of my branch is not considered appropriate for grub2. So someone can just pull my branch, review it and merge whatever part they want. -- Bean My repository: https://launchpad.net/burg ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Any tutorial to configure grub menu interface ?
Bean wrote: On Sat, Oct 31, 2009 at 1:02 PM, J. Bakshi baksh...@gmail.com wrote: On Wed, 28 Oct 2009 22:52:41 +0100 Vladimir 'phcoder' Serbinenko phco...@gmail.com wrote: J. Bakshi wrote: On Wed, 28 Oct 2009 04:01:05 +0800 Bean bean12...@gmail.com wrote: On Tue, Oct 27, 2009 at 10:41 PM, J. Bakshi baksh...@gmail.com wrote: I wonder if there is any tutorial to crate cool grub menu interface. Can we use the grub2 2009 summer project to get those fancy interfaces ? Hi, There are actually two menu system. Colin has written a fancy menu patch as part of gsoc project, you can still get the code from http://grub.gibibit.com/, there are also some docs there. It looks good, but a little slow, and some feature like edit boot command hasn't been implemented. Recently, I have rewritten the menu system and it's almost done by now. The project is hosted at https://launchpad.net/burg, you can also follow this post in ubuntu forum: http://ubuntuforums.org/showthread.php?t=1248647 I plans to add some doc on menu config soon. Hello Bean, It is nice to know about your project. I hope it can be in main line grub soon. Eagerly waiting for that and also for your doc. Till now Bean ignored all our requests to work on merging these changes in the mainline or experimental. Unless he collaborates on merging there is nothing we can do. Bean, may I request you merge your great work in mainline grub2 ? A Lot of grub2 users like me are really interested to try your great work in grub2. Hi, It's not that I don't merge it to mainline, but parts of my branch is not considered appropriate for grub2. So someone can just pull my branch, review it and merge whatever part they want. Ok, then the next weekend I'll do the cherrypicking. This weekend I just have no time for it (I'm on regional ACM) -- 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
Re: [patch] grub incorrectly identifies ext3 as fat
Am Samstag, den 31.10.2009, 02:44 -0400 schrieb Andrew Clausen: Hi, 2009/10/30 Robert Millan r...@aybabtu.com: What about probing in the boot-loader? It's too late then. grub-install needs to know which filesystem module has to be included in core.img. What if the core.img contains modules for 2 or more file systems? That only happens if you use grub-install with --modules or you directly create it with grub-mkimage. By default there's just one module and there only needs to be one. The one to access /boot/grub. It doestn't make sense to include more then one fs module into core.img With grub.efi the situation seems to be different though. But IMO it's a bug there. -- 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: [PATCH] turn grub-emu into a port
On Sat, Oct 31, 2009 at 12:08:55AM +0100, Vladimir 'phcoder' Serbinenko wrote: Robert Millan wrote: This turns grub-emu into a port in order to make it easier to port GRUB to new CPUs. A porter can then do the CPU port without having to worry about firmware and/or hardware drivers initially. Patch attached. Branch is available in bzr+ssh://bzr.savannah.gnu.org/grub/people/robertmh/grub-emu/ Following hunk is a regression for me: - return (tv.tv_sec * GRUB_TICKS_PER_SECOND - + (((tv.tv_sec % GRUB_TICKS_PER_SECOND) * 100 + tv.tv_usec) -* GRUB_TICKS_PER_SECOND / 100)); + GRUB_COMPILE_TIME_ASSERT (GRUB_TICKS_PER_SECOND == 100); + return (tv.tv_sec * 100 + tv.tv_usec); Having virtual clock going at any rate is an advantage for debugging. I don't get what you mean. When GRUB runs on a Unix system, a tick represents a 100th fraction of a second, and therefore GRUB_TICKS_PER_SECOND is 100. The old behaviour tried to emulate the behaviour of the specific hardware platform, but with grub-emu being a standalone port this doesn't make sense. I don't think we can have both things (old tick behaviour + portable grub-emu). Was that behaviour useful? It seems to me that GRUB routines don't directly care about number of ticker per second, but rather just use it as a means to archieve something else. E.g. to compare output of grub_get_rtc(). -- 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] grub incorrectly identifies ext3 as fat
On Sat, Oct 31, 2009 at 02:44:08AM -0400, Andrew Clausen wrote: Hi, 2009/10/30 Robert Millan r...@aybabtu.com: What about probing in the boot-loader? It's too late then. grub-install needs to know which filesystem module has to be included in core.img. What if the core.img contains modules for 2 or more file systems? This should be a last ressort. Fortunately, we have a better solution, which you pointed out youself: make sure the filesystem works by actually reading the file. Felix, did you have some code to do make_path_relative_to_its_root() in C? Then we can re-enable the check in grub-probe, fixing this problem. -- 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] turn grub-emu into a port
Robert Millan wrote: On Sat, Oct 31, 2009 at 12:08:55AM +0100, Vladimir 'phcoder' Serbinenko wrote: Robert Millan wrote: This turns grub-emu into a port in order to make it easier to port GRUB to new CPUs. A porter can then do the CPU port without having to worry about firmware and/or hardware drivers initially. Patch attached. Branch is available in bzr+ssh://bzr.savannah.gnu.org/grub/people/robertmh/grub-emu/ Following hunk is a regression for me: - return (tv.tv_sec * GRUB_TICKS_PER_SECOND - + (((tv.tv_sec % GRUB_TICKS_PER_SECOND) * 100 + tv.tv_usec) -* GRUB_TICKS_PER_SECOND / 100)); + GRUB_COMPILE_TIME_ASSERT (GRUB_TICKS_PER_SECOND == 100); + return (tv.tv_sec * 100 + tv.tv_usec); Having virtual clock going at any rate is an advantage for debugging. I don't get what you mean. When GRUB runs on a Unix system, a tick represents a 100th fraction of a second, and therefore GRUB_TICKS_PER_SECOND is 100. The old behaviour tried to emulate the behaviour of the specific hardware platform, but with grub-emu being a standalone port this doesn't make sense. I don't think we can have both things (old tick behaviour + portable grub-emu). Was that behaviour useful? It seems to me that GRUB routines don't directly care about number of ticker per second, but rather just use it as a means to archieve something else. E.g. to compare output of grub_get_rtc(). I meant: keep GRUB_TICKS_PER_SECOND=100 per default but allow easy adjustment to any number by coder -- 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
Re: Any tutorial to configure grub menu interface ?
On Sat, Oct 31, 2009 at 10:58:09AM +0100, Vladimir 'phcoder' Serbinenko wrote: Bean wrote: Hi, It's not that I don't merge it to mainline, but parts of my branch is not considered appropriate for grub2. So someone can just pull my branch, review it and merge whatever part they want. Just for the record: I don't consider your new menu inappropiate, I simply had other priorities (like the release) and not enough time to follow the discussion (as I expressed back then, I think it is bad timing). Ok, then the next weekend I'll do the cherrypicking. This weekend I just have no time for it (I'm on regional ACM) Bean, if you put the changes that you think should be in GRUB into branches, I think this would make it easier to import into experimental than a monolithic all-in-one branch. And if you want to create /people/bean/ for this purpose in our repository, you're welcome to. -- 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] turn grub-emu into a port
On Sat, Oct 31, 2009 at 11:18:03AM +0100, Vladimir 'phcoder' Serbinenko wrote: - return (tv.tv_sec * GRUB_TICKS_PER_SECOND - + (((tv.tv_sec % GRUB_TICKS_PER_SECOND) * 100 + tv.tv_usec) -* GRUB_TICKS_PER_SECOND / 100)); + GRUB_COMPILE_TIME_ASSERT (GRUB_TICKS_PER_SECOND == 100); + return (tv.tv_sec * 100 + tv.tv_usec); I meant: keep GRUB_TICKS_PER_SECOND=100 per default but allow easy adjustment to any number by coder Ah, you mean instead of assuming (and asserting) that they're 100, leave it as a hardcoded #define GRUB_TICKS_PER_SECOND 100 so that this can be changed at source level? Seems fine. If that's what you mean, I'll adjust the patch and add it to experimental. -- 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] grub incorrectly identifies ext3 as fat
Am Samstag, den 31.10.2009, 11:10 +0100 schrieb Robert Millan: Felix, did you have some code to do make_path_relative_to_its_root() in C? Then we can re-enable the check in grub-probe, fixing this problem. Yes, the only missing thing is that you wanted to have the function imported from gnulib for the systems which don't have realpath() Would be easier if we didn't support mingw already, but then I can also look into including asprintf() from there. -- 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: [patch] grub incorrectly identifies ext3 as fat
On Sat, Oct 31, 2009 at 11:34:22AM +0100, Felix Zielcke wrote: Am Samstag, den 31.10.2009, 11:10 +0100 schrieb Robert Millan: Felix, did you have some code to do make_path_relative_to_its_root() in C? Then we can re-enable the check in grub-probe, fixing this problem. Yes, the only missing thing is that you wanted to have the function imported from gnulib for the systems which don't have realpath() But realpath() is posix AFAIK. Or you mean the realpath(name, NULL) GNU extension? -- 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] grub incorrectly identifies ext3 as fat
Am Samstag, den 31.10.2009, 12:30 +0100 schrieb Robert Millan: On Sat, Oct 31, 2009 at 11:34:22AM +0100, Felix Zielcke wrote: Am Samstag, den 31.10.2009, 11:10 +0100 schrieb Robert Millan: Felix, did you have some code to do make_path_relative_to_its_root() in C? Then we can re-enable the check in grub-probe, fixing this problem. Yes, the only missing thing is that you wanted to have the function imported from gnulib for the systems which don't have realpath() But realpath() is posix AFAIK. Or you mean the realpath(name, NULL) GNU extension? realpath(name,NULL) is POSIX too now. The only problem I know about is that we support mingw32, i.e. plain windows not cygwin. If we say we don't support this anymore then I don't think we need to import the gnulib function. -- 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: Any tutorial to configure grub menu interface ?
On Sat, 31 Oct 2009 10:58:09 +0100 Vladimir 'phcoder' Serbinenko phco...@gmail.com wrote: Bean wrote: On Sat, Oct 31, 2009 at 1:02 PM, J. Bakshi baksh...@gmail.com wrote: On Wed, 28 Oct 2009 22:52:41 +0100 Vladimir 'phcoder' Serbinenko phco...@gmail.com wrote: J. Bakshi wrote: On Wed, 28 Oct 2009 04:01:05 +0800 Bean bean12...@gmail.com wrote: On Tue, Oct 27, 2009 at 10:41 PM, J. Bakshi baksh...@gmail.com wrote: I wonder if there is any tutorial to crate cool grub menu interface. Can we use the grub2 2009 summer project to get those fancy interfaces ? Hi, There are actually two menu system. Colin has written a fancy menu patch as part of gsoc project, you can still get the code from http://grub.gibibit.com/, there are also some docs there. It looks good, but a little slow, and some feature like edit boot command hasn't been implemented. Recently, I have rewritten the menu system and it's almost done by now. The project is hosted at https://launchpad.net/burg, you can also follow this post in ubuntu forum: http://ubuntuforums.org/showthread.php?t=1248647 I plans to add some doc on menu config soon. Hello Bean, It is nice to know about your project. I hope it can be in main line grub soon. Eagerly waiting for that and also for your doc. Till now Bean ignored all our requests to work on merging these changes in the mainline or experimental. Unless he collaborates on merging there is nothing we can do. Bean, may I request you merge your great work in mainline grub2 ? A Lot of grub2 users like me are really interested to try your great work in grub2. Hi, It's not that I don't merge it to mainline, but parts of my branch is not considered appropriate for grub2. So someone can just pull my branch, review it and merge whatever part they want. Ok, then the next weekend I'll do the cherrypicking. This weekend I just have no time for it (I'm on regional ACM) so grub2 users, be ready to enjoy some really cool menu interfaces with better control. Thanks a lot to you all developers to give us such a great boot loader. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] import multiboot1 specification in grub trunk
On Mon, Aug 24, 2009 at 01:35:23PM +0200, Vladimir 'phcoder' Serbinenko wrote: 1) deleting files fails because of .svn directories 2) One of the hunks for configure.ac was rejected. 3) Is there any reason for keeping following line: HELP2MAN = help2man 4) version is still wrong. 5) It looks like --with-binutils can be kept but not necessary to do so since it's effect is the same as calling configure with CFLAGS=-Bdir 6) INSTALL, NEWS and README are out of sync 7) AUTHORS seem empty. At least following author must be added: * docs/multiboot.texi: New file. From Kunihiro Ishiguro. 8) COPYING contains GPLv2. fdl.texi isn't imported. 9) ChangeLog contains whole history of grub1, not just multiboot. Attached python file cleans it up (output still contains some junk but it's feasible to remove it by hand) 10) autogen.sh doesn't generate configure. I imported GRUB Legacy into Bazaar and made a Multiboot branch, in /trunk/multiboot, addressing most of the problems. Pending: 3, 5, 6, first part of 8, and (feel free to) 9. When the cleanup is finished, we can release 0.6.96 with unmodified text (except for Felix' spelling fixes). -- 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
Diff between Branches
Hi, I'm novice with Bazaar. I would like to diff between gettext branch and trunk. I did: bzr branch http://bzr.savannah.gnu.org/r/grub/people/robertmh/gettext/ cd gettext bzr diff -r branch:http://bzr.savannah.gnu.org/r/ub/trunk/grub But I have some unexpected results like adding files and removing files that I would not expect: === added file 'AUTHORS' --- AUTHORS 1970-01-01 00:00:00 + +++ AUTHORS 2009-10-31 12:19:08 + and then: === removed file 'AUTHORS' --- AUTHORS 2005-09-03 16:54:27 + +++ AUTHORS 1970-01-01 00:00:00 + The content of the old2 and new AUTHORS files looks similar, even though the date is not similar :-) Am I doing something in the incorrect way? Or I'm doing it in bad timing? 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: Diff between Branches
On Sat, Oct 31, 2009 at 12:36:57PM +, Carles Pina i Estany wrote: I'm novice with Bazaar. I would like to diff between gettext branch and trunk. I did: bzr branch http://bzr.savannah.gnu.org/r/grub/people/robertmh/gettext/ cd gettext bzr diff -r branch:http://bzr.savannah.gnu.org/r/ub/trunk/grub But I have some unexpected results like adding files and removing files that I would not expect: === added file 'AUTHORS' --- AUTHORS 1970-01-01 00:00:00 + +++ AUTHORS 2009-10-31 12:19:08 + and then: === removed file 'AUTHORS' --- AUTHORS 2005-09-03 16:54:27 + +++ AUTHORS 1970-01-01 00:00:00 + This usually means that there is a problem with the way the branches were created or with the way they've been managed, such that the files in each branch do not have common ancestry. (Bazaar assigns each file a unique file-id in order to support good rename tracking, and will only consider two files to be different versions of the same file if they have the same file-id; you can see the file-id with e.g. 'bzr ls --show-ids'.) I haven't looked at these two branches to find out exactly what's happened. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Diff between Branches
On Sat, Oct 31, 2009 at 12:36:57PM +, Carles Pina i Estany wrote: Hi, I'm novice with Bazaar. I would like to diff between gettext branch and trunk. I did: bzr branch http://bzr.savannah.gnu.org/r/grub/people/robertmh/gettext/ The gettext branch was based on an old trunk, I've just regenerated it, try branching again. bzr diff -r branch:http://bzr.savannah.gnu.org/r/ub/trunk/grub But I have some unexpected results like adding files and removing files that I would not expect: Is this what you wanted? bzr diff -r ancestor:bzr+ssh://bzr.savannah.gnu.org/grub/trunk/grub Btw, if you're just trying to resync, it's better if you use bzr for that, e.g.: $ bzr pull bzr+ssh://bzr.savannah.gnu.org/grub/trunk/grub bzr: ERROR: These branches have diverged. Use the missing command to see how. Use the merge command to reconcile them. $ bzr merge bzr+ssh://bzr.savannah.gnu.org/grub/trunk/grub [...] Text conflict in conf/common.rmk Text conflict in kern/misc.c Text conflict in util/grub-mkconfig_lib.in Text conflict in util/grub.d/00_header.in Text conflict in util/grub.d/10_linux.in 5 conflicts encountered. some manual work with conf/common.rmk and conf/common.rmk.* $ bzr resolve conf/common.rmk repeat untill all conflicts are resolved, then commit After this is done, you can push to /people/your-dir/gettext or so. -- 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: Diff between Branches
On Sat, Oct 31, 2009 at 01:26:22PM +, Colin Watson wrote: This usually means that there is a problem with the way the branches were created or with the way they've been managed, such that the files in each branch do not have common ancestry. I had to regenerate the commits one by one (fortunately there weren't many). Do you know a more efficient 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. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Diff between Branches
On Sat, Oct 31, 2009 at 02:45:49PM +0100, Robert Millan wrote: On Sat, Oct 31, 2009 at 01:26:22PM +, Colin Watson wrote: This usually means that there is a problem with the way the branches were created or with the way they've been managed, such that the files in each branch do not have common ancestry. I had to regenerate the commits one by one (fortunately there weren't many). Do you know a more efficient way? It may be possible to use the 'bzr replay' command from the bzr-rebase plugin. I don't use this often myself, but it seems like nominally the right answer. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Experimental branch of GRUB
Am Samstag, den 24.10.2009, 15:06 +0200 schrieb Robert Millan: An experimental branch of GNU GRUB is now available: [...] I'm appointing Vladimir Serbinenko as the developer in charge of this branch. Patches may be merged in it at his discretion. Vladimir whats your policy for merging trunk into experimental? Do you want to track it on your own to keep them in sync? -- 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
GRUB2 and DMRAID
Is there already a possibility to get DMRAID working with GRUB2? Even when the /boot device is on a DMRAID partition. Seems like we have already a dmraid_nvidia module, but that doesn't work? It would be very nice to get grub2 dmraid working nicely together. As we are now stuck to grub1 for that. Greets JL ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB2 and DMRAID
Am Samstag, den 31.10.2009, 16:11 +0100 schrieb Jean-Louis Dupond: Is there already a possibility to get DMRAID working with GRUB2? Even when the /boot device is on a DMRAID partition. Seems like we have already a dmraid_nvidia module, but that doesn't work? That module is only useful with ata.mod, which isn't the default. With default biosdisk.mod the BIOS handles the RAID for us. All the GRUB modules have nothing to do with handling the OS specific things like device names. It would be very nice to get grub2 dmraid working nicely together. As we are now stuck to grub1 for that. On Debian BTS and Launchpad there's a bug about this. And maybe even Savannah. The main problem is that our way to map Linux devices to GRUB devices doestn't work with multipath and dmraid devices. There's a first patch I made for nvidia_ pdc_ and some isw_ devices, but that's the wrong approach. -- 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: Experimental branch of GRUB
On Sat, Oct 31, 2009 at 03:49:27PM +0100, Felix Zielcke wrote: Am Samstag, den 24.10.2009, 15:06 +0200 schrieb Robert Millan: An experimental branch of GNU GRUB is now available: [...] I'm appointing Vladimir Serbinenko as the developer in charge of this branch. Patches may be merged in it at his discretion. Vladimir whats your policy for merging trunk into experimental? Do you want to track it on your own to keep them in sync? Experimental is the staging area for trunk, not the other way around. Everything that is already in trunk is also ok for experimental. -- 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: GRUB2 and DMRAID
On Sat, Oct 31, 2009 at 04:32:04PM +0100, Felix Zielcke wrote: There's a first patch I made for nvidia_ pdc_ and some isw_ devices, but that's the wrong approach. Perhaps you could make a branch out of it, so it's easily found? -- 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] grub incorrectly identifies ext3 as fat
Hi Felix, 2009/10/31 Felix Zielcke fziel...@z-51.de: That only happens if you use grub-install with --modules or you directly create it with grub-mkimage. By default there's just one module and there only needs to be one. The one to access /boot/grub. It doestn't make sense to include more then one fs module into core.img With grub.efi the situation seems to be different though. But IMO it's a bug there. What if you have a dual boot setup, with say ntfs and ext3? When you go to boot from a kernel from ext3, it might break if the user loaded the ntfs module. Isn't it easy to just fix the bug? Cheers, Andrew ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [patch] grub incorrectly identifies ext3 as fat
On Sat, Oct 31, 2009 at 11:39:16AM -0400, Andrew Clausen wrote: Hi Felix, 2009/10/31 Felix Zielcke fziel...@z-51.de: That only happens if you use grub-install with --modules or you directly create it with grub-mkimage. By default there's just one module and there only needs to be one. The one to access /boot/grub. It doestn't make sense to include more then one fs module into core.img With grub.efi the situation seems to be different though. But IMO it's a bug there. What if you have a dual boot setup, with say ntfs and ext3? The filesystem module that is embedded in core.img is only for bootstrap purposes. Once GRUB can access /boot/grub/, it automatically loads the modules required for menu entries. Isn't it easy to just fix the bug? First of all, it's not a bug. Filesystems weren't designed to be identifiable reliably. They could have been, but they weren't, and now we're stuck with that. Everything GRUB does to archieve filesystem detection is on a BEST EFFORT basis. With that in mind, we can find ways in which GRUB will be more succesful at identifiing them. For example (and we already do this), the search command gives priority to filesystem modules that are already loaded. Or we can attempt to read a given file when we expect it's there. For example, if we're looking for /boot/grub/, we can tell /boot/grub to the filesystem layer, so that it will require it as a precondition. There are many ways to improve this, but making arbitrary assumptions about the content of a filesystem (e.g. non-emptyness) doesn't sound like the best solution. In this particular case, you can be hit by both false positives and false negatives. -- 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
error: invalid magic number when booting from ISO loopback
Hi,
I was playing around with Grub2 (latest svn version) and its loopback
feature and had some problems to boot an ISO. The ISO file is the 32Bit
version of Ubuntu 9.10 which is located on a 8GB USB flash drive with
one FAT32 partition. I've tried to boot it with the following menu
entry:
menuentry Ubuntu {
set isofile=/boot/isos/ubuntu-9.10-desktop-i386.iso
loopback loop $isofile
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile
quiet splash noprompt --
initrd (loop)/casper/initrd.lz
}
This entry fails silently and when the commands were executed one by one
the linux command shows the error message error: invalid magic number.
A short google search gave me the following similar bug report but no
solution:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543924
I believe that Grub2 has some problems when the file is located nearly
at the end of the filesystem because I've put the file on the drive when
it was nearly full. Also I've checked the md5 value of the file under
Linux and it was correct but under Grub2 a crc value check shows a
mismatch. But the most interesting fact is that after I've deleted some
other files to make some space I made a copy from the ISO file on the
USB flash drive which booted without any problems.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: error: invalid magic number when booting from ISO loopback
On Sat, Oct 31, 2009 at 06:01:56PM +0100, Ron wrote:
Hi,
I was playing around with Grub2 (latest svn version) and its loopback
feature and had some problems to boot an ISO. The ISO file is the 32Bit
version of Ubuntu 9.10 which is located on a 8GB USB flash drive with
one FAT32 partition. I've tried to boot it with the following menu
entry:
menuentry Ubuntu {
set isofile=/boot/isos/ubuntu-9.10-desktop-i386.iso
loopback loop $isofile
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile
quiet splash noprompt --
initrd (loop)/casper/initrd.lz
}
This entry fails silently and when the commands were executed one by one
the linux command shows the error message error: invalid magic number.
This error means vmlinuz wasn't read correctly.
This could be either a problem in loopback/iso9660 or a problem in the
partition that contains ubuntu-9.10-desktop-i386.iso.
Can you figure out which applies? For example, if you put a physical CD
with ubuntu-9.10-desktop-i386.iso in the drive and access it from
GRUB (via ata.mod), are you able to load Linux this 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.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [patch] grub incorrectly identifies ext3 as fat
Hello Felix,
Felix Zielcke wrote:
Am Samstag, den 31.10.2009, 02:44 -0400 schrieb Andrew Clausen:
Hi,
2009/10/30 Robert Millan r...@aybabtu.com:
What about probing in the boot-loader?
It's too late then. grub-install needs to know which filesystem module has
to be included in core.img.
What if the core.img contains modules for 2 or more file systems?
That only happens if you use grub-install with --modules or you directly
create it with grub-mkimage.
By default there's just one module and there only needs to be one.
The one to access /boot/grub.
It doestn't make sense to include more then one fs module into core.img
With grub.efi the situation seems to be different though. But IMO it's a
bug there.
To boot my debian installation on an ibm p5 lpar, I am trying to install grub2
i.e. working with grub-ieee1275.
I try first to rebuild grub-1.97~beta4 but it was failing.
I finaly find out that I can build and boot grub2 (only) with another gcc
optimization option (-O0 in place of default -Os).
But it still failed to boot the linux kernel after grub-install:
1/ here is the chrooted mount points:
/dev/sdb6 on /mnt/NewInst type ext3 (rw)
/dev/sdb3 on /mnt/NewInst/boot type ext3 (rw)
/dev/sdb1 on /mnt/NewInst/boot/grub type vfat (rw)
/dev/mapper/p5tst001vg-var on /mnt/NewInst/var type ext3 (rw)
ps: /mnt/NewInst/boot/grub have to be a mount point for grub-install;
if it wasn't: # grub-install hd1
/boot/grub must be a mount point.
and must be a fat16 (or iirc hfs) for ofs
2/ a typical menu entry:
### BEGIN /etc/grub.d/10_linux ###
menuentry Debian GNU/Linux, with Linux 2.6.30-2-powerpc64 {
insmod ext2
set root=(hd1,3)
search --no-floppy --fs-uuid --set 16ef0754-c845-46e9-a948-b9669ee68329
linux /vmlinux-2.6.30-2-powerpc64
root=UUID=3c51c43e-63a7-4ff1-9b1c-cf98addcb7ed ro quiet
initrd /initrd.img-2.6.30-2-powerpc64
}
and at the grub sh prompt, ls doesn't report any disk?
Even thought: # more /boot/grub/device.map
(hd0) /dev/sda
(hd1) /dev/sdb
Could it be for the reason you explained above?
I am worry of it because when I copy vmlinux-2.6.30-2-powerpc64 and initrd.img-2.6.30-2-powerpc64 in the
/mnt/NewInst/boot/grub fs and this simple menuentry:
### BEGIN /etc/grub.d/10_linux ###
menuentry Debian GNU/Linux, with Linux 2.6.30-2-powerpc64 {
linux /vmlinux-2.6.30-2-powerpc64 root=UUID=3c51c43e-63a7-4ff1-9b1c-cf98addcb7ed ro sysrq=1 insmod=sym53c8xx
insmod=ipr quiet
initrd /initrd.img-2.6.30-2-powerpc64
}
the debian installation finaly boot fine ;)
The problem is that this vfat fs afaik must be then 24Mb and btw couldn't contained more then one kernel image (and its
initrd), though.
Tia for further advise,
J.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
GPT BIOS boot partition and installing to a partition
On my GPT-partitioned MacBook, I seem to have two options for booting with grub-pc: 1. Install grub to the start of an existing partition. This coexists well with the rEFIt boot menu, but requires blocklists to load core.img. 2. Use a BIOS boot partition. This allows embedding core.img, but installs to the MBR and makes rEFIt unhappy. I had the idea that we could get the advantages of both: Install the boot-image to an existing partition, but load core.img from a BIOS boot partition. With some creative hex-editing I got this working without much difficulty. Is there a technical reason why grub doesn't support this setup? If I were to write a patch allowing this, what behaviour would be preferred: Should 'grub-setup (hdX,Y)' automatically use a BIOS boot partition if one exists, or should a command-line flag be required? Dave Vasilevsky ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [patch] grub incorrectly identifies ext3 as fat
On Sat, Oct 31, 2009 at 12:38:41PM +0100, Felix Zielcke wrote: Am Samstag, den 31.10.2009, 12:30 +0100 schrieb Robert Millan: On Sat, Oct 31, 2009 at 11:34:22AM +0100, Felix Zielcke wrote: Am Samstag, den 31.10.2009, 11:10 +0100 schrieb Robert Millan: Felix, did you have some code to do make_path_relative_to_its_root() in C? Then we can re-enable the check in grub-probe, fixing this problem. Yes, the only missing thing is that you wanted to have the function imported from gnulib for the systems which don't have realpath() But realpath() is posix AFAIK. Or you mean the realpath(name, NULL) GNU extension? realpath(name,NULL) is POSIX too now. The only problem I know about is that we support mingw32, i.e. plain windows not cygwin. If we say we don't support this anymore then I don't think we need to import the gnulib function. We can continue supporting it, but we don't have to put bugfixes on hold because of it. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Experimental branch of GRUB
Felix Zielcke wrote: Am Samstag, den 24.10.2009, 15:06 +0200 schrieb Robert Millan: An experimental branch of GNU GRUB is now available: [...] I'm appointing Vladimir Serbinenko as the developer in charge of this branch. Patches may be merged in it at his discretion. Vladimir whats your policy for merging trunk into experimental? Do you want to track it on your own to keep them in sync? As nyu said everything which is ok for mainline is ok for experimental and so the only issue are conflicts but in practice any sane way to resolve them is ok. So I feel like no discussion should be necessary about this -- 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
Re: Experimental branch of GRUB
Robert Millan wrote: Hi, An experimental branch of GNU GRUB is now available: # readonly access bzr branch http://bzr.savannah.gnu.org/r/grub/branches/experimental/ # member access bzr branch sftp://username@bzr.savannah.gnu.org/srv/bzr/grub/branches/experimental The purpose of this branch is to serve as staging area so that new code can be tested and collaboratively maintained when we expect that it will be eventually merged into trunk, but it is not yet ready for this (e.g. too inmature or wrong time in the development cycle). I'm appointing Vladimir Serbinenko as the developer in charge of this branch. Patches may be merged in it at his discretion. Just few points about it 1) Use separate ChangeLog file for experimental features. E.g. I'll use ChangeLog.mips for my mips branch. No need to mention all the history, only what needs to be put when feature is merged back in mainline. 2) Members are encouraged to use /people/name/feature branches to simplifiy the management and merging to mainline once feature is considered mature 3) For non-members which have copyright assignment send the patch I'll apply it 4) Any inclusion of material non-covered by copyright assignment is above my authority and have to be approved by maintainer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- 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
Re: GPT BIOS boot partition and installing to a partition
Dave Vasilevsky wrote: On my GPT-partitioned MacBook, I seem to have two options for booting with grub-pc: 1. Install grub to the start of an existing partition. This coexists well with the rEFIt boot menu, but requires blocklists to load core.img. 2. Use a BIOS boot partition. This allows embedding core.img, but installs to the MBR and makes rEFIt unhappy. On EFI system try grub-efi. I had the idea that we could get the advantages of both: Install the boot-image to an existing partition, but load core.img from a BIOS boot partition. With some creative hex-editing I got this working without much difficulty. Is there a technical reason why grub doesn't support this setup? If I were to write a patch allowing this, what behaviour would be preferred: Should 'grub-setup (hdX,Y)' automatically use a BIOS boot partition if one exists, or should a command-line flag be required? It may be a good idea but the best way is to use first sector of BPB for this. But the usability is limited. For EFI systems we have grub-efi and for BIOS boot you still need a specially adapted MBR for it anyway Dave Vasilevsky ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- 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
Re: Experimental branch of GRUB
Am Samstag, den 31.10.2009, 19:33 +0100 schrieb Vladimir 'phcoder' Serbinenko: Felix Zielcke wrote: Am Samstag, den 24.10.2009, 15:06 +0200 schrieb Robert Millan: An experimental branch of GNU GRUB is now available: [...] I'm appointing Vladimir Serbinenko as the developer in charge of this branch. Patches may be merged in it at his discretion. Vladimir whats your policy for merging trunk into experimental? Do you want to track it on your own to keep them in sync? As nyu said everything which is ok for mainline is ok for experimental and so the only issue are conflicts but in practice any sane way to resolve them is ok. So I feel like no discussion should be necessary about this Well my question was mainly `Do you want to merge trunk into it or can anyone of us do it?' But seems like so :) -- 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: GPT BIOS boot partition and installing to a partition
phcoder wrote: On EFI system try grub-efi. I have indeed tried grub-efi, you can see the notes I left here: https://help.ubuntu.com/community/MactelSupportTeam/EFI-Boot-Mactel#MacBook4,1 . Unfortunately inability to use both accelerated X and the console makes me prefer grub-pc for the moment. I appreciate all the work you've put into grub-efi though, it's great to see it improving. the best way is to use first sector of BPB for this. But the usability is limited. I'm not sure I'm understanding, isn't the BPB just a few dozen bytes in the boot sector? Some filesystems have a bit more room, but usually not very much. The advantage of using the BIOS Boot Partition is that you can embed the entire core.img, no? for BIOS boot you still need a specially adapted MBR for it anyway Agreed that this is sub-optimal, but on my system it's the lesser of evils for now. Cheers, Dave ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [patch] grub incorrectly identifies ext3 as fat
Andrew Clausen wrote: Hi Robert, 2009/10/31 Robert Millan r...@aybabtu.com: What if you have a dual boot setup, with say ntfs and ext3? The filesystem module that is embedded in core.img is only for bootstrap purposes. Once GRUB can access /boot/grub/, it automatically loads the modules required for menu entries. OK, here's a realistic use case that could hit lots of users: * grub is installed on an ext3 partition * the user has OSX installed on an HFS file system (or whatever they use now) that has stale ext3 signatures * when grub tries to load the OSX kernel, it has two filesystem modules loaded: ext2 and hfs. * the stale signature causes it to misdetect it as hfs, and it fails. hfs+ and ext2 use same sector as superblock so it's not a problem I suppose you could solve this problem by unloading all filesystem modules except the ones you need at that moment? But Grub doesn't do that now, right? Isn't it easy to just fix the bug? First of all, it's not a bug. Filesystems weren't designed to be identifiable reliably. They could have been, but they weren't, and now we're stuck with that. Everything GRUB does to archieve filesystem detection is on a BEST EFFORT basis. I think this is where we disagree... I think that with good heuristics, you can cover all use cases without any problems. (For instance, GNU Parted has a fairly short list of heuristics that seem to be very reliable -- or they were when I maintained it. The relevant function is ped_file_system_probe().) Alternatively, you could allow the user to specify the file system? Or, you could warn when multiple file systems have matching signatures. Or you can modify the tools to clear first and last MiB on mkfs which solves problem at the root With that in mind, we can find ways in which GRUB will be more succesful at identifiing them. For example (and we already do this), the search command gives priority to filesystem modules that are already loaded. This heuristic could have a lot of problems. (See my example above.) Any heuristic means that something is wrong. Or we can attempt to read a given file when we expect it's there. For example, if we're looking for /boot/grub/, we can tell /boot/grub to the filesystem layer, so that it will require it as a precondition. I can see that that would work will for some use cases... It breaks encapsulation and makes code a lot less maintainable. And just offset clear bug to a lot of strange and weird bugs There are many ways to improve this, but making arbitrary assumptions about the content of a filesystem (e.g. non-emptyness) doesn't sound like the best solution. In this particular case, you can be hit by both false positives and false negatives. Huh? I can't see any way to get hit by either for this particular heuristic. It reduces the number of false positives, and the false negatives are irrelevant (because an undetected filesystem is equivalent to an empty one.) Many filesystems would look having some weird filenames but still having a directory if they are false positives. Big picture: I'm sorry for being irritating... I know that odd heuristics are an unpleasant technology to determine whether or not a computer can boot or not. We both have similar approaches: try to pick something that works well under difficult circumstances. I think we differ in the way we think about use cases. You don't like my heuristic because it has false positives and false negatives; but I claim that there is no use case (realistic or unrealistic) in which my heuristic makes things worse. Some of your proposed heuristics seem reasonable in addition to my own one, but I think it's clear that adding my heuristic will always make Grub work better. Every heurisitic makes code less clear and more prone to bugs and in long run results only in more heurisitc failures. -- 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
Slow grub boot when /boot/grub is not on first partition
Hello dear GRUB2 developers, I am a user of Ubuntu 9.10, which uses GRUB2 1.97. Unfortunately GRUB needs a rather long time loading the modules. For 2 minutes or so it just displays GRUB loading... until the boot menu is shown and I can start Ubuntu. The bug has already been reported at Launchpad: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/420933 I tried to find out what causes the problem. I have the following disk layout: A Windows HD with the following partitions /dev/sda1 /dev/sda2 /dev/sda3 /dev/sda4 /dev/sda5 A Ubuntu HD: /dev/sdb2 (Extended Partition) /dev/sdb5 (swap) /dev/sdb6 (small partition, holds some misc data) /dev/sdb7 (Ubuntu 9.10) /dev/sdb8 (Backup) So when I add set debug=disk at grub.cfg I can see grub accessing the disk. It cycles through all the partitions, then reads data from sdb7, cycles again through the partitions, reads again from sdb7, and so on... I can't really tell whats causing this, I used the Ubuntu 9.04 package of grub2 before and that had not this problem. The package dates back to to the grub2 version from the 24th July of 2008. Maybe it is possible to do some caching in GRUB2? So for example, if search -u someuuid is done, the result is saved, and if we do that again, we can lookup in the cache which drive has that uuid? The same for the FS type. If we once did detect ext2 on hd1,7 we should cache that, so we don't need to detect that again. I will try to add more grub_dprintf calls, so that I can better see what is going on. Sincerly Simon W. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GPT BIOS boot partition and installing to a partition
Dave Vasilevsky wrote: phcoder wrote: On EFI system try grub-efi. I have indeed tried grub-efi, you can see the notes I left here: https://help.ubuntu.com/community/MactelSupportTeam/EFI-Boot-Mactel#MacBook4,1 . Unfortunately inability to use both accelerated X and the console makes me prefer grub-pc for the moment. I appreciate all the work you've put into grub-efi though, it's great to see it improving. Workaround for your problem is described here: http://grub.enbug.org/TestingOnMacbook For the long run linux has to be fixed. the best way is to use first sector of BPB for this. But the usability is limited. I'm not sure I'm understanding, isn't the BPB just a few dozen bytes in the boot sector? Some filesystems have a bit more room, but usually not very much. The advantage of using the BIOS Boot Partition is that you can embed the entire core.img, no? It was a typo. I meant BBP (BIOS Boot Partition) -- 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
Re: Slow grub boot when /boot/grub is not on first partition
Simon Wagner wrote: Hello dear GRUB2 developers, I am a user of Ubuntu 9.10, which uses GRUB2 1.97. Unfortunately GRUB needs a rather long time loading the modules. For 2 minutes or so it just displays GRUB loading... until the boot menu is shown and I can start Ubuntu. The bug has already been reported at Launchpad: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/420933 I tried to find out what causes the problem. I have the following disk layout: A Windows HD with the following partitions /dev/sda1 /dev/sda2 /dev/sda3 /dev/sda4 /dev/sda5 A Ubuntu HD: /dev/sdb2 (Extended Partition) /dev/sdb5 (swap) /dev/sdb6 (small partition, holds some misc data) /dev/sdb7 (Ubuntu 9.10) /dev/sdb8 (Backup) So when I add set debug=disk at grub.cfg I can see grub accessing the disk. It cycles through all the partitions, then reads data from sdb7, cycles again through the partitions, reads again from sdb7, and so on... I can't really tell whats causing this, I used the Ubuntu 9.04 package of grub2 before and that had not this problem. The package dates back to to the grub2 version from the 24th July of 2008. Maybe it is possible to do some caching in GRUB2? So for example, if search -u someuuid is done, the result is saved, and if we do that again, we can lookup in the cache which drive has that uuid? The same for the FS type. If we once did detect ext2 on hd1,7 we should cache that, so we don't need to detect that again. I will try to add more grub_dprintf calls, so that I can better see what is going on. Sincerly Simon W. We're aware of this problem and have patch which I'll merge as soon as I'm back home ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- 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
Re: Experimental branch of GRUB
On Sat, Oct 31, 2009 at 07:37:22PM +0100, Vladimir 'phcoder' Serbinenko wrote: 1) Use separate ChangeLog file for experimental features. E.g. I'll use ChangeLog.mips for my mips branch. No need to mention all the history, only what needs to be put when feature is merged back in mainline. Since you suggested this earlier on IRC, I tentatively used ChangeLog.experimental for the existing changelog entries when restoring the repository. But feel free to change that. -- 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: GPT BIOS boot partition and installing to a partition
phcoder wrote: Workaround for your problem is described here: http://grub.enbug.org/TestingOnMacbook Are you talking about fix_video? When I tested, without fix_video I could use the console, but X was slow. With fix_video, X was accelerated, but the console was scrambled as soon as X started. the best way is to use first sector of [BIOS Boot Partition] This only works if the BBP is in the MBR. In my configuration, there are already 4 partitions in the MBR, with no room for the BBP. That's why I want to embed the boot-image in another partition, and have it pass control to the BBP. Dave ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GPT BIOS boot partition and installing to a partition
Dave Vasilevsky wrote: phcoder wrote: Workaround for your problem is described here: http://grub.enbug.org/TestingOnMacbook Are you talking about fix_video? When I tested, without fix_video I could use the console, but X was slow. With fix_video, X was accelerated, but the console was scrambled as soon as X started. This is X bug then the best way is to use first sector of [BIOS Boot Partition] This only works if the BBP is in the MBR. In my configuration, there are already 4 partitions in the MBR, with no room for the BBP. That's why I want to embed the boot-image in another partition, and have it pass control to the BBP. GRUB2 doesn't need BBP to be in pseudo-MBR to boot Dave ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- 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
Re: [patch] grub incorrectly identifies ext3 as fat
On Sat, Oct 31, 2009 at 02:43:19PM -0400, Andrew Clausen wrote: Or we can attempt to read a given file when we expect it's there. For example, if we're looking for /boot/grub/, we can tell /boot/grub to the filesystem layer, so that it will require it as a precondition. I can see that that would work will for some use cases... Most importantly, it's a net win. If we know a file is there, there's no harm in requiring that the filesystem driver is capable of reading it. It's a pity, because we already had this check, and we were forced to disable it. Would you like to help us restore it? I can give more details. I think this is very important: I spent hours trying to [...] Nobody questions that. It certainly is very important to me, but even then, we should look for solutions that are good in long-term. When using heuristics, if one's not careful can end up in a slippery slope, in which adding an heuristic fixes a problem at the cost of introducing a new one, and then you can only fix that by adding yet another heuristic (which can be repeated ad nauseam). -- 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: Experimental branch of GRUB
Felix Zielcke wrote: Am Samstag, den 31.10.2009, 19:33 +0100 schrieb Vladimir 'phcoder' Serbinenko: Felix Zielcke wrote: Am Samstag, den 24.10.2009, 15:06 +0200 schrieb Robert Millan: An experimental branch of GNU GRUB is now available: [...] I'm appointing Vladimir Serbinenko as the developer in charge of this branch. Patches may be merged in it at his discretion. Vladimir whats your policy for merging trunk into experimental? Do you want to track it on your own to keep them in sync? As nyu said everything which is ok for mainline is ok for experimental and so the only issue are conflicts but in practice any sane way to resolve them is ok. So I feel like no discussion should be necessary about this Well my question was mainly `Do you want to merge trunk into it or can anyone of us do it?' But seems like so :) In case of no conflicts or its trivial resolution you can do it. If it's more problematic please contact me -- 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
Re: error: invalid magic number when booting from ISO loopback
On Sat, 2009-10-31 at 18:30 +0100, Robert Millan wrote:
On Sat, Oct 31, 2009 at 06:01:56PM +0100, Ron wrote:
Hi,
I was playing around with Grub2 (latest svn version) and its loopback
feature and had some problems to boot an ISO. The ISO file is the 32Bit
version of Ubuntu 9.10 which is located on a 8GB USB flash drive with
one FAT32 partition. I've tried to boot it with the following menu
entry:
menuentry Ubuntu {
set isofile=/boot/isos/ubuntu-9.10-desktop-i386.iso
loopback loop $isofile
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile
quiet splash noprompt --
initrd (loop)/casper/initrd.lz
}
This entry fails silently and when the commands were executed one by one
the linux command shows the error message error: invalid magic number.
This error means vmlinuz wasn't read correctly.
This could be either a problem in loopback/iso9660 or a problem in the
partition that contains ubuntu-9.10-desktop-i386.iso.
Can you figure out which applies? For example, if you put a physical CD
with ubuntu-9.10-desktop-i386.iso in the drive and access it from
GRUB (via ata.mod), are you able to load Linux this way?
I'm sorry but right now I can't burn a CD. But I made some more test
with the ISO file that doesn't work and the copy from it that does work.
As I've mentioned both files shows the same correct MD5 sum under Linux.
Also GRUB shows with the ls command the same file size of 723488768
Bytes (690 MiB) for both of them. But the output of the blocklist
command is looking wrong.
blocklist output for the ISO that doesn't work:
11833144+161304, 13766112+8, 13853680+218800, 14072488+118288
blocklist output for the ISO that does work:
15128592+328728, 11652008+16, 11654088+1792, 11655888+8,11655912+440,
12089440+16, 12404120+126080, 12530256+99464, 12629728+761984, 13413432
+94536
So if you sum up the sectors from the ISO that doesn't work and multiply
it with 512 you get only 255180800 Bytes (243 MiB). It looks like the
blocklist command encounters an error and exits before it is done, but
no error message is visible.
Some more info that may help.
blocklist output from the vmlinuz file from the mounted ISO file (both
ISO files show the same output):
1384372+7598, 1391970[0-224]
fdisk -lu output from the USB flash drive:
Disk /dev/sdb: 8086 MB, 8086618112 bytes
255 heads, 63 sectors/track, 983 cylinders, total 15794176 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x2c6b7369
Device Boot Start End Blocks Id System
/dev/sdb1 * 6315791894 7895916b W95 FAT32
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GPT BIOS boot partition and installing to a partition
Le samedi 31 octobre 2009 à 15:09 -0400, Dave Vasilevsky a écrit :
phcoder wrote:
Workaround for your problem is described here:
http://grub.enbug.org/TestingOnMacbook
Are you talking about fix_video? When I tested, without fix_video I
could use the console, but X was slow. With fix_video, X was
accelerated, but the console was scrambled as soon as X started.
I have got it working with fix_video and with a working intel driver,
with accelerated 3d on a fedora 12 .
here is the grub entry :
menuentry Fedora boot {
root=(hd0,2)
fix_video
loadbios /EFI/grub/vbios.bin /EFI/grub/int10.bin
search -s -f /vmlinuz-2.6.31.5-96.fc12.i686.PAE
linux /vmlinuz-2.6.31.5-96.fc12.i686.PAE ro
root=/dev/mapper/vg_akroma-lv_root nomodeset rhgb=0
initrd /initramfs-2.6.31.5-96.fc12.i686.PAE.img
}
Even plymouth is working fine.
The xorg driver is the following :
xorg-x11-drv-intel-2.9.1-1.fc12.i686
--
Michael Scherer
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
