GSoC: CD-ROM booting options
Hello, Last week I started working on my GSoC project for GRUB2: CD-ROM boot support. I wanted to make sure I understand what we want to support in GRUB2. Do we want to be able to boot the computer from GRUB2 installed on a medium (whatever it may be), then be able to boot from a CD (in whatever mode - emulation or no emulation)? Do we also want to be able to boot the computer through the BIOS from a CD on which GRUB2 was installed and continue booting from the CD (like GRUB legacy does)? Do we want to support both? Personally, I think both are important to support, but I want to see what the majority of developers and users think we should support. Thanks in advance! -- Alex Roman <[EMAIL PROTECTED]> ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GSoC: CD-ROM booting options
"Alex Roman" <[EMAIL PROTECTED]> writes: Hi Alex, [...] > Do we want to be able to boot the computer from GRUB2 installed on a > medium (whatever it may be), then be able to boot from a CD (in > whatever mode - emulation or no emulation)? Yes. > Do we also want to be able to boot the computer through the BIOS from > a CD on which GRUB2 was installed and continue booting from the CD > (like GRUB legacy does)? Yes. > Do we want to support both? Yes. > Personally, I think both are important to support, but I want to see > what the majority of developers and users think we should support. Just focus on one thing first. I think booting from a BIOS that supports CDROMs already won't be too hard. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: test -e patch
adrian15 <[EMAIL PROTECTED]> writes:
> Attached you will find the patch adding test -e support for grub2.
>
> This is my first patch. I have compiled it without no errors.
Urgh... I thought/hoped I told you I had a test.c rewrite sitting on
my harddisk? Or did I tell Robert to poke me until next weekend so I
will work on it? It includes everything you expect from test.c,
expect the cleanup and testing. ;-)
> However as long as the grub2.tar.gz that Marco gave me did not have any
> documentation about how to create a floppy (or at least I did not manage
> to find it) I have not tested it.
Please have a look at the wiki. It has quite some information about
GRUB 2.
> I have applied the GNU Coding Standards Style on the patch although the
> copy-pasted code that you will find in the mail body has not the GCS
> applied.
>
> Here there are some doubts:
>
>> static const struct grub_arg_option options[] =
>> {
>> {"file", 'e', 0, "test if a file exists", 0, 0},
>> {0, 0, 0, 0, 0, 0}
>> };
>
> Is this correct? What's that last line for? Is it compulsory ?
It means that this is the last option. There is no other way to tell
if this is the last option without this.
> Should I write "Test if a file exists" instead of "test if a file
> exists" or "FILE exists"?
FILE
>>
>> static void
>> test_file_exists (const char *key)
>
> Do you prefer another name like: file_exists_test ?
>
>> {
>> grub_file_t file;
>>
>> file = grub_file_open (key);
>> if (file)
>> {
>>grub_printf (" %s", key);
> Should I prompt the existent file or not?
> Should I prompt %s exists maybe ?
> Should I prompt an \n also?
>>grub_file_close (file);
>>grub_errno = GRUB_ERR_NONE;
>> }
>> else
>> {
>>grub_error (GRUB_ERR_FILE_NOT_FOUND, "File does not exists.");
>
> How the hell should I treat grub errors. Maybe the test_file_exists has
> to return a static grub_err_t and then from grub_cmd_test I should call
> it like this: return (test_file_exists (args[0])) so that the error
> propagates ?
Right. Otherwise the error will be lost.
> What are the error polices ?
Returning the err_t that grub_error returns when possible.
>> }
>> }
>>
>>
>> static grub_err_t
>> grub_cmd_test (struct grub_arg_list *state __attribute__ ((unused)), int
>> argc,
>> char **args)
>>
>> {
>>
>> char *eq;
>> char *eqis;
>>
>> if (state[0].set)
>
> I suppose this refers to the first line of static const struct
> grub_arg_option options and thus as -e is the first option and if its
> set we should run the correspondent function.
Yes.
> One question. Should we put the test-e function into a separate file or
> not ?
No, the problem is that the design of test.c (which is just a
placeholder) is wrong. It needs a proper parser for the arguments and
a way to deal with this...
>> test_file_exists (args[0]);
>> else
>> {
>> /* XXX: No fancy expression evaluation yet. */
>> if (argc == 0)
>> return 0;
>> eq = grub_strdup (args[0]);
>> eqis = grub_strchr (eq, '=');
>> if (! eqis)
>> return 0;
>>
>> *eqis = '\0';
>> eqis++;
>> /* Check an expression in the form `A=B'. */
>> if (grub_strcmp (eq, eqis))
>> grub_error (GRUB_ERR_TEST_FAILURE, "false");
>> grub_free (eq);
>> }
>> return grub_errno;
>>
>>
>> }
>>
>>
>>
>> GRUB_MOD_INIT(test)
>> {
>> (void)mod; /* To stop warning. */
>> grub_register_command ("[", grub_cmd_test, GRUB_COMMAND_FLAG_CMDLINE,
>> "[ EXPRESSION ]", "Evaluate an expression", 0);
>> grub_register_command ("test", grub_cmd_test, GRUB_COMMAND_FLAG_CMDLINE,
>> "test EXPRESSION", "Evaluate an expression", 0);
>> }
>
> I understand this register commands. I suppose this information is read
> from the help command or it isn't ?
Yes, the help command uses this information.
> Or maybe it also reads from:
> static const struct grub_arg_option options ?
Help only does when you use "help test". So it can use both.
> The question is if the user will see the -e, -f or other options when
> querying the test command help or not ?
They should. But I am not sure if the final version will support
this. Especially because of the nested syntax of the test arguments.
>>
>> GRUB_MOD_FINI(test)
>> {
>> grub_unregister_command ("[");
>> grub_unregister_command ("test");
>> }
>
> That's all for my first compiled patch.
> I hope that Marco_g is happy :).
> But you know Marco_g I will continue my non-sense grub legacy
> development too. ;)
:-))
> adrian15
>
> diff -urN grub2_2007_05_31_original/commands/test.c
> grub2_2007_05_31/commands/test.c
> --- grub2_2007_05_31_original/commands/test.c 2005-11-13 16:47:08.0
> +0100
> +++ grub2_2007_05_31/commands/test.c 2007-06-01 12:13:11.0 +0200
> @@ -24,32 +24,64 @@
> #include
> #include
> #include
> +#include
> +
> +static const struct grub_
Re: gcs doubt #1
adrian15 <[EMAIL PROTECTED]> writes: > Please put a comment on each function saying what the function does, > what sorts of arguments it gets, and what the possible values of > arguments mean and are used for. > > Is it ok that the search.c and test.c (commands/ folder) do not have any > of these comments at all? The currect test.c is a dummy so the `if' expression can be used/tested. If you can provide a patch for sourcecode to improve or add comments in a sane way, I am willing to commit those patches. Just please don't make the mistake to add useless comments. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: test -e patch
adrian15 <[EMAIL PROTECTED]> writes:
>>> GRUB_MOD_INIT(test)
>>> {
>>> (void)mod;/* To stop warning. */
>>> grub_register_command ("[", grub_cmd_test, GRUB_COMMAND_FLAG_CMDLINE,
>>> "[ EXPRESSION ]", "Evaluate an expression", 0);
>>> grub_register_command ("test", grub_cmd_test, GRUB_COMMAND_FLAG_CMDLINE,
>>> "test EXPRESSION", "Evaluate an expression", 0);
>>> }
>>
>> I understand this register commands. I suppose this information is read
>> from the help command or it isn't ?
>>
>> Or maybe it also reads from:
>> static const struct grub_arg_option options ?
>
> I've found it.
>
> It reads from the register command and ALSO from options IF you tell it
> to do so with:
>
> (void)mod; /* To stop warning. */
> grub_register_command ("[", grub_cmd_test, GRUB_COMMAND_FLAG_CMDLINE,
>"[ EXPRESSION ]", "Evaluate an expression", options);
> grub_register_command ("test", grub_cmd_test, GRUB_COMMAND_FLAG_CMDLINE,
>"test EXPRESSION", "Evaluate an expression", options);
If you don't pass the options to this functions, the options won't be
parsed. One fun thing you can try: options can be tab-completed in
GRUB 2 :-)
--
Marco
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
linux headers
How is it that util/biosdisk.c makes effort to avoid including Linux headers and defines Linux ioctl macros on its own? This adds an extra maintainance burden, so I guess there must be a reason to do it, but can't think of one.. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] make grub2 compile with libc-less crosscompilers
Yoshinori K. Okuji schrieb: Also, without grub-emu, how do you plan to debug GRUB? I'd have some questions relating to that to improve the patch, if possible. But first, please note that grub-emu currently can't work because argp.h and its features aren't provided on Solaris, so I can't test the proper operation of it. As for grub-emu, does it use the target-built objects (ie. .mod files) and loads them in the host system? If so, is this why you need the _start/start (and the other) detection, so the modules contain the right symbol for the host? In this case, the right solution would probably be to do those tests using the host compiler, not the target's. The target doesn't care one way or the other (there is no non-grub code around that looks for symbols at boot time), so it can just inherit, what the host is doing. I can provide a patch that takes this into account, if my guesses are correct, but I'd need some more insights in what exactly is required. Thanks, Patrick Georgi ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: linux headers
On Mon, Jun 04, 2007 at 06:59:30PM +0200, Robert Millan wrote: > > How is it that util/biosdisk.c makes effort to avoid including Linux headers > and defines Linux ioctl macros on its own? > > This adds an extra maintainance burden, so I guess there must be a reason to > do > it, but can't think of one.. Ah, and also I'm not really sure that ioctl definitions are always architecture independant. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
grub2 common argument parser
I have an idea that I am not able to implement in bash because I have
no time. It consists about an xml file that has all the arguments of a
command and how they should be (a file, a device, an string), if an
argument is compulsory or not, if two arguments are incompatible.
This xml file can be read by a GUI program that can present you a GUI
to any of your console programs. Like if it was an interactive 'man'.
Each option has its explanation and you can fill the empty boxes.
And the next step is that the man files instead of being man files
would be these xml files.
Well one thing more or less equivalent that could be done in grub2 is a
"grub2 common argument parser".
I think it can be done because most of the argument types are the same
ones: FILE, ENVVAR, MODULE, TERM, EXPRESSION, DEVICENME, PATTERN.
Why we should let every command parse its own arguments when we could
have a common argument parser.
The idea is the following one:
When you define a command argument by the means of options...
static const struct grub_arg_option options[] =
{
{"file", 'f', 0, "search devices by a file (default)", 0, 0},
{"label", 'l', 0, "search devices by a filesystem label", 0, 0},
{"set", 's', GRUB_ARG_OPTION_OPTIONAL, "set a variable to the first
device found", "VAR", ARG_TYPE_STRING},
{0, 0, 0, 0, 0, 0}
};
Hey... there's something about it on the search.c code but it is not
complete. It seems that the 3rd filed is what I need and maybe the last one.
Hey it seems that this is already in the TODO list.
(normal/arg.c)
case ARG_TYPE_DEVICE:
case ARG_TYPE_DIR:
case ARG_TYPE_FILE:
case ARG_TYPE_PATHNAME:
/* XXX: Not implemented. */
That's a good and bad piece of news. That means that I will have to
reimplement the test -e command in a future in order to take advantage
of this implementation.
The ARG_TYPE_FILE check is only trying to open it with grub_file_open ()
or maybe the grub_file_stat ... hummm... someone on the mailing list
adviced me to use this second one but I do not find it.
It seems for me that the filesystem modules or drivers do only have
these commands:
.name = "ext2",
.dir = grub_ext2_dir,
.open = grub_ext2_open,
.read = grub_ext2_read,
.close = grub_ext2_close,
.label = grub_ext2_label,
.next = 0
A question for marco_g
==
This .next is for file iteration inside a folder, maybe?
And another question for everybody... do we need to implement a
grub_file_stat function or not?
adrian15
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
grub2 miscelanea questions (1/2)
Dear grub2 developers, here there are some questions about grub2 that I have that would have generated too many little emails. 1)lst files on a grub2 floppy == As I told you in another email, in order to build my grub2 floppy I did a soft link from /usr/local/lib/grub/i386-pc to /home/adrian/Desktop/gnu/grub2/grub2_2007_05_31 (compiled sources dir) and my floppy is full of lst files. Usually in a grub2 floppy there are not any lst file, isn't it? 2) What are these lst files for, are they useful or are they like the C .o files, only needed for compilation purposes? 3) Why any grub2.cfg file (I suppose it's the substitute for menu.lst) is inside the grub2 source code? 4) Why any doc folder is inside the grub2 source code? 5) grub2 lacks == 5.1) pager - When I want to do a big ls the output does not stop screen by screen... Is there any hidden pager that I do not know? Maybe is not implemented yet? 5.2) Chainload DEVICES How the hell do you boot windows? Maybe from a file that has inside it the first 512 bytes from the Windows partition? 6) Compulsory Argument dilemma If I run help I can seen things like this: ls [-f|-l|-s] NAME and [ EXPRESSION ] If [ ] means optional it should also mean optional in the case of the test alias [ .!!! 7) set help incomplete Set help should say that if no argument is set then it shows all the environment variables. 8) exported and no exported variables === Why the set does not show any difference (like a * in the beginning) about the exported and no exported variables (with the export command) 9) help does not complain when no command help is available = The commands: help marco_g help okuji help dachaac do not complain at all, and it is not a "hidden pascua egg" from these people,... any non-command has the same answer: NONE. I think there should be something like: Error: This command does not exist. Or better even: It should prompt all the commands. 10) help --all = In grub-legacy when typing help some commands were some sort of hidden. However if you typed help --all these commands were also shown. Do we need this functionality in grub2? 11) help help === Running help help says: Usage: help [PATTERN ...] Show a help message. It should say that if no argument is entered then all the commands are shown. And it should say: Show a command help described in PATTERN. (Or something like this). 12) ls and -h argument This is not an error but it curious. You can ask for the help of command with this: command -h however ls -h works in a different way. I suppose we may have the same problem with '-u' in the future. 13) videotest This is a test command and it will not be available when grub2 is out there. Isn't it ? :) Continues on grub2 miscelanea questions (2/2) adrian15 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
grub2 miscelanea questions (2/2)
Comes from grub2 miscelanea questions (1/2) 14) help linux = Usage: linux FILE [ARGS...] Load a linux kernel. I think that a message telling the user that the ARGS are arguments for the linux kernel instead of arguments for the grub's linux command would be a good idea. 15) lsmod == As long as I am unable to run a pager can anyone tell me what the three columns mean? cat 1 normal,gzio gzio6 boot1 normal 16) help play === Usage: play FILE Play a tune What is the FILE format? Is it an AIFF, an AU, a WAV, or is it an ASCII file that has tones? I should not go to the source code for knowing it. 17) play ideas == It seems a rather complicated file... is there any utility for creating it from grub2 or is it standard file that I do not know of? Maybe it should have a --loop and -l argument. So that if no key is pressed the file is played again. Another --delay -d argument can be useful for determining the delay period between one reproduction and another. 18) source, . , and configfile = If both source and '.' commands say that: Load another config file without changing context. Then the configfile command should say: Load another config file (with a new context) instead of saying: Load another config file. 19) rescue and exit failure on qemu == I think that booting from my computer does not give this error. If I boot from QEMU and type: grub> rescue and then : grub rescue> exit it says: FATAL: INT18: BOOT FAILURE 20) grub rescue help help : Types the commands and a minimal explanation: OK help any_command : Types the commands and a minimal explanation: NOT OK help not_a_command : Types the commands and a minimal explanation: NOT OK 21) grub rescue exit help === When you are in grub rescue mode and you type help the exit line it's the following one: exitexit from GRUB Should it not prompt ? exitexit from GRUB rescue 22) copyright message missing Why isn't there (when Grub is running) any message about the GRUB Copyright and the GPL license and that you should have received and this and that? Is it a memory problem? (In grub legacy there was not any message like this either) Maybe we should implement an 'about' command and run it when booting :) ? 23) set read only variables == unset prefix lets me "delete" the prefix variable. unset root does not let me the "root" variable. I remember that bash has an option to set read only variables. Maybe the root variable is a read only variable? 24) 'Command' commands == Is there any special reason why the rescue, set, unset, export, insmod, rmmod, lsmod commands are in a single file called: normal/command.c instead of being in separate files in commands/ folder ? adrian15 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: linux headers
At Mon, 4 Jun 2007 18:59:30 +0200, Robert Millan wrote: > > > How is it that util/biosdisk.c makes effort to avoid including Linux headers > and defines Linux ioctl macros on its own? > > This adds an extra maintainance burden, so I guess there must be a reason to > do > it, but can't think of one.. It only defines it when it isn't defined yet. It seems to be taken from GRUB Legacy's lib/device.c and probably comes from a time those things weren't always defined. The checks for glibc also don't seem that useful to me. It needs a cleanup. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GSoC: CD-ROM booting options
At Mon, 04 Jun 2007 17:10:53 +0200, Marco Gerards wrote: > > "Alex Roman" <[EMAIL PROTECTED]> writes: > > > Personally, I think both are important to support, but I want to see > > what the majority of developers and users think we should support. > > Just focus on one thing first. I think booting from a BIOS that > supports CDROMs already won't be too hard. I think booting installation and live CDs directly from the BIOS will be the most used way to boot a CD, so I guess support for that is the most important. And it indeed shouldn't be that hard. Jeroen dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GSoC: CD-ROM booting options
On 04/06/07, Jeroen Dekkers <[EMAIL PROTECTED]> wrote: At Mon, 04 Jun 2007 17:10:53 +0200, Marco Gerards wrote: > > "Alex Roman" <[EMAIL PROTECTED]> writes: > > > Personally, I think both are important to support, but I want to see > > what the majority of developers and users think we should support. > > Just focus on one thing first. I think booting from a BIOS that > supports CDROMs already won't be too hard. I think booting installation and live CDs directly from the BIOS will be the most used way to boot a CD, so I guess support for that is the most important. And it indeed shouldn't be that hard. Sounds good. I think I will start by focusing on "no emulation" mode. ISOLINUX seems to be using this mode and it makes use of EDD 3.0 INT 13 extensions to read from the CD. The only problem I see here is if we boot from a BIOS that doesn't support EDD 3.0. We may not be able to read from the CD in that case, so we would have to use emulation mode. In any case, I'll keep you all posted on the progress I make. -- Alex Roman <[EMAIL PROTECTED]> ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
a pair of things I found when debugging..
A pair of things I found when debugging powerpc issues. Let me know what
you think (context comment follows).
--
Robert Millan
My spam trap is [EMAIL PROTECTED] Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
diff -ur grub2-1.95+20070520.old/util/biosdisk.c grub2-1.95+20070520/util/biosdisk.c
--- grub2-1.95+20070520.old/util/biosdisk.c 2007-06-04 20:35:48.0 +0200
+++ grub2-1.95+20070520/util/biosdisk.c 2007-06-04 20:35:53.0 +0200
@@ -732,7 +732,7 @@
int find_partition (grub_disk_t disk __attribute__ ((unused)),
const grub_partition_t partition)
{
- struct grub_pc_partition *pcdata = 0;
+ struct grub_pc_partition *pcdata = NULL;
if (strcmp (partition->partmap->name, "pc_partition_map") == 0)
pcdata = partition->data;
@@ -816,8 +816,7 @@
if (dos_part < 0)
{
grub_disk_close (disk);
- grub_error (GRUB_ERR_BAD_DEVICE,
- "cannot find the partition of `%s'", os_dev);
+ grub_util_error ("cannot find the partition of `%s'", os_dev);
return 0;
}
diff -ur grub2-1.95+20070520.old/util/grub-probe.c grub2-1.95+20070520/util/grub-probe.c
--- grub2-1.95+20070520.old/util/grub-probe.c 2007-06-04 20:35:48.0 +0200
+++ grub2-1.95+20070520/util/grub-probe.c 2007-06-04 20:35:53.0 +0200
@@ -81,7 +81,7 @@
probe (const char *path)
{
char *device_name;
- char *drive_name = 0;
+ char *drive_name = NULL;
grub_device_t dev;
grub_fs_t fs;
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: a pair of things I found when debugging..
On Mon, Jun 04, 2007 at 09:00:21PM +0200, Robert Millan wrote:
> - struct grub_pc_partition *pcdata = 0;
> + struct grub_pc_partition *pcdata = NULL;
>
>[...]
>
> - char *drive_name = 0;
> + char *drive_name = NULL;
I generaly find that NULL makes it clearer for pointers, do you have a
preference for 0 on these?
> @@ -816,8 +816,7 @@
> if (dos_part < 0)
>{
> grub_disk_close (disk);
> - grub_error (GRUB_ERR_BAD_DEVICE,
> - "cannot find the partition of `%s'", os_dev);
> + grub_util_error ("cannot find the partition of `%s'", os_dev);
> return 0;
Not sure what I'm missing, but these grub_error calls seem to be pretty
useless. This one in particular was the culprit to one of the powerpc
problems I just fixed, and I had to replace it with grub_util_error() to find
out.
--
Robert Millan
My spam trap is [EMAIL PROTECTED] Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: a pair of things I found when debugging..
At Mon, 4 Jun 2007 21:03:11 +0200,
Robert Millan wrote:
>
> On Mon, Jun 04, 2007 at 09:00:21PM +0200, Robert Millan wrote:
> > - struct grub_pc_partition *pcdata = 0;
> > + struct grub_pc_partition *pcdata = NULL;
> >
> >[...]
> >
> > - char *drive_name = 0;
> > + char *drive_name = NULL;
>
> I generaly find that NULL makes it clearer for pointers, do you have a
> preference for 0 on these?
I agree.
> > @@ -816,8 +816,7 @@
> > if (dos_part < 0)
> >{
> > grub_disk_close (disk);
> > - grub_error (GRUB_ERR_BAD_DEVICE,
> > - "cannot find the partition of `%s'", os_dev);
> > + grub_util_error ("cannot find the partition of `%s'", os_dev);
> > return 0;
>
> Not sure what I'm missing, but these grub_error calls seem to be pretty
> useless. This one in particular was the culprit to one of the powerpc
> problems I just fixed, and I had to replace it with grub_util_error() to find
> out.
Yes, as I already wrote in relation to the RAID thing, handling of
errors and warnings need some care.
Jeroen Dekkers
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug#427289: more LVM stuff (Re: Bug#427289: grub-probe: error: unknown device when / is an encrypted LVM)
At Sun, 3 Jun 2007 23:37:25 +0200, Robert Millan wrote: > Here's another report with issues about LVM. I notice the device name is > different than previous ones (note: device.map only has /dev/sda). The problem seems to be that grub-install is probing for things outside of /boot. GRUB shouldn't use anything outside of /boot to start. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug#427289: more LVM stuff (Re: Bug#427289: grub-probe: error: unknown device when / is an encrypted LVM)
On Mon, Jun 04, 2007 at 10:11:30PM +0200, Jeroen Dekkers wrote: > At Sun, 3 Jun 2007 23:37:25 +0200, > Robert Millan wrote: > > Here's another report with issues about LVM. I notice the device name is > > different than previous ones (note: device.map only has /dev/sda). > > The problem seems to be that grub-install is probing for things > outside of /boot. GRUB shouldn't use anything outside of /boot to > start. update-grub calls grub-probe a few times, in different places. Some of them could be avoided, but at least these appear to be necessary: # Device containing our userland. Typicaly used for root= parameter. GRUB_DEVICE="`grub-probe --target=device /`" # Filesystem for the device containing our userland. Used for stuff like # choosing Hurd filesystem module. GRUB_FS="`grub-probe --target=fs /`" See also 00_header.in for code that might scan /usr/share/ in search of unifont. If e.g. /usr is a separate partition, grub needs to know that somehow to load the font later. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug#427289: more LVM stuff (Re: Bug#427289: grub-probe: error: unknown device when / is an encrypted LVM)
At Mon, 4 Jun 2007 22:30:12 +0200, Robert Millan wrote: > > On Mon, Jun 04, 2007 at 10:11:30PM +0200, Jeroen Dekkers wrote: > > At Sun, 3 Jun 2007 23:37:25 +0200, > > Robert Millan wrote: > > > Here's another report with issues about LVM. I notice the device name is > > > different than previous ones (note: device.map only has /dev/sda). > > > > The problem seems to be that grub-install is probing for things > > outside of /boot. GRUB shouldn't use anything outside of /boot to > > start. > > update-grub calls grub-probe a few times, in different places. Some of them > could be avoided, but at least these appear to be necessary: > > # Device containing our userland. Typicaly used for root= parameter. > GRUB_DEVICE="`grub-probe --target=device /`" > > # Filesystem for the device containing our userland. Used for stuff like > # choosing Hurd filesystem module. > GRUB_FS="`grub-probe --target=fs /`" > > See also 00_header.in for code that might scan /usr/share/ in search of > unifont. If e.g. /usr is a separate partition, grub needs to know that > somehow to load the font later. GRUB shouldn't load anything from any other partition than /boot. The whole reason that we have /boot partitions is that it might be possible that the rest isn't readable by GRUB. The reason we have grub-probe is to find out which modules need to be in core.img. You're currently using grub-probe for other things and that isn't always going to work. Grub-probe won't be able to parse encrypted LVM volumes for example, and thus grub-probe --target=fs / is never going to work if your / is encrypted. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
