"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
> Once this is implemented, the rest is trivial. So, who wants to work on
> this? ;)
If the copyright problem is solved, I will. If someone else wants to
do it now, please do!
--
Marco
___
Grub-deve
On Thursday 14 April 2005 05:46 am, Hollis Blanchard wrote:
> I think I like this idea a lot. It would also be nice if the various
> file-based commands (like cat and cmp) also looked at the current
> working directory as well.
>
> lsdev (or lsdisk?) also makes a lot of sense to me.
Ok. Then, let'
On Apr 8, 2005, at 1:39 AM, Marco Gerards wrote:
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
This should not be the case. Not if both tab, ls, linux, etc work
from pwd. In that case you can cd somewhere and everything you use
is
in the current dir. And there are relative (../foo) and absol
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
> On Friday 08 April 2005 08:39 am, Marco Gerards wrote:
>> We could make a switch for this (`ls --devices', or `ls -d') or a new
>> command called `lsdev'. If we do this everything will work like
>> expected, I think.
>
> Do you think it would be
On Friday 08 April 2005 08:39 am, Marco Gerards wrote:
> We could make a switch for this (`ls --devices', or `ls -d') or a new
> command called `lsdev'. If we do this everything will work like
> expected, I think.
Do you think it would be more convenient than the current behavior of ls? I'm
not
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
>> This should not be the case. Not if both tab, ls, linux, etc work
>> from pwd. In that case you can cd somewhere and everything you use is
>> in the current dir. And there are relative (../foo) and absolute
>> (/foo) paths.
>
> The question is
On Thursday 07 April 2005 04:37 pm, Marco Gerards wrote:
> Someone suggested bootdevice on IRC. I like that one, while is not
> that generic.
I feel that it is too long to type.
> This should not be the case. Not if both tab, ls, linux, etc work
> from pwd. In that case you can cd somewhere an
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
> On Thursday 07 April 2005 02:02 am, Hollis Blanchard wrote:
>> It's clear to you and I, but seeing "root=foo" "root=bar" is obviously
>> not very friendly and in general should be avoided.
>
> I understand your point. But I don't like "device", be
On Thursday 07 April 2005 02:02 am, Hollis Blanchard wrote:
> It's clear to you and I, but seeing "root=foo" "root=bar" is obviously
> not very friendly and in general should be avoided.
I understand your point. But I don't like "device", because it is too generic.
The advantage of "root" is that
On Apr 6, 2005, at 10:43 AM, Antoine Terrienne wrote:
Selon Hollis Blanchard <[EMAIL PROTECTED]>:
Okuji? Hmm, what about "device"?
title foo
set device=bar
multiboot /kernel root=baz
I would like to avoid this:
title foo
set root=bar
Selon Hollis Blanchard <[EMAIL PROTECTED]>:
>
> Okuji? Hmm, what about "device"?
> title foo
> set device=bar
> multiboot /kernel root=baz
>
> I would like to avoid this:
> title foo
> set root=bar
> multiboot /kernel root=baz
> .
On Apr 6, 2005, at 1:32 AM, Marco Gerards wrote:
Hollis Blanchard <[EMAIL PROTECTED]> writes:
Perhaps using "grubroot", "grubprefix", "grubbase", or similar will be
acceptable?
For me it is, of course, open or discussion. However, I just like
`root'. I do not like the grub prefix. When removing
Hollis Blanchard <[EMAIL PROTECTED]> writes:
>> Personally I do not care about if GRUB is confusing for linux users.
>> As I see it, GRUB is not only a linux loader.
>
> I see that Mach also uses "root" as a kernel argument. I certainly
> agree that GRUB is not only a Linux loader. However I stron
On Apr 5, 2005, at 11:45 AM, Marco Gerards wrote:
Hollis Blanchard <[EMAIL PROTECTED]> writes:
root is not a command but a variable in GRUB 2.
Actually, I see now that it is a command: grub_rescue_cmd_root() in
kern/rescue.c. Is that only a rescue mode thing? That seems to be
exactly what I need...
Hollis Blanchard <[EMAIL PROTECTED]> writes:
>> root is not a command but a variable in GRUB 2.
>
> Actually, I see now that it is a command: grub_rescue_cmd_root() in
> kern/rescue.c. Is that only a rescue mode thing? That seems to be
> exactly what I need... aside from the very confusing use of
On Apr 5, 2005, at 2:02 AM, Marco Gerards wrote:
Vernon Mauery <[EMAIL PROTECTED]> writes:
Putting a restraint that says /boot/grub must be a separate
partition doesn't sound like a good idea. It just clutters the
partition table with another small partition.
For the apple this was always the case
On Apr 5, 2005, at 12:41 AM, Yoshinori K. Okuji wrote:
On Tuesday 05 April 2005 02:38 am, Hollis Blanchard wrote:
Can we have a shortcut to avoid specifying that "(hd,7)/" part
repeatedly? I think that was the "root" command in GRUB Legacy, which
was replaced by the "prefix" environment variable? B
On Apr 4, 2005, at 11:55 PM, Vernon Mauery wrote:
Hollis Blanchard wrote:
I've been thinking about how to install grub2 on an Open Firmware
system. Here's one possibility:
/boot -- Linux-native filesystem (e.g. ext3)
holds kernels, initrd, etc
/boot/grub -- firmware-native filesyste
On Apr 5, 2005, at 2:00 AM, Marco Gerards wrote:
Hollis Blanchard <[EMAIL PROTECTED]> writes:
The other possibility is to have all of /boot as a firmware-native
filesystem. I think that's not ideal though, because those filesystems
(HFS+, FAT) might not support features like symlinks or Unix-style
Vernon Mauery <[EMAIL PROTECTED]> writes:
>> The discussion is about automatically setting prefix.
>
> But if prefix is what root used to be (the location of the kernels,
> initrds, etc.) then I don't see how having a grub partition helps in
> setting this. It will help locate the grub binaries,
Marco Gerards wrote:
> Vernon Mauery <[EMAIL PROTECTED]> writes:
>>If all it gains us is that we know where we booted from, we still
>>need to know where /boot is. I don't see what this gains us -- the
>>root command or prefix variable is still required. It sounds to me
>>that if you want to hav
> I've been thinking about how to install grub2 on an Open Firmware
> system. Here's one possibility:
> /boot -- Linux-native filesystem (e.g. ext3)
> holds kernels, initrd, etc
> /boot/grub -- firmware-native filesystem (on Mac HFS+, on others
> FAT, etc)
>
Vernon Mauery <[EMAIL PROTECTED]> writes:
> Putting a restraint that says /boot/grub must be a separate
> partition doesn't sound like a good idea. It just clutters the
> partition table with another small partition.
For the apple this was always the case already. It is something we
can not cha
Hollis Blanchard <[EMAIL PROTECTED]> writes:
> The grub ELF file must live on a firmware-native filesystem. When run,
> it can find out what partition it was booted from, so that is a
> natural place to load grub.cfg from as well (and why not modules while
> we're at it?). Thus this is the value o
On Tuesday 05 April 2005 02:38 am, Hollis Blanchard wrote:
> Can we have a shortcut to avoid specifying that "(hd,7)/" part
> repeatedly? I think that was the "root" command in GRUB Legacy, which
> was replaced by the "prefix" environment variable? But as I mentioned,
> "prefix" doesn't have the me
Hollis Blanchard wrote:
> I've been thinking about how to install grub2 on an Open Firmware
> system. Here's one possibility:
> /boot -- Linux-native filesystem (e.g. ext3)
> holds kernels, initrd, etc
> /boot/grub -- firmware-native filesystem (on Mac HFS+, on others
> FAT, etc)
>
I've been thinking about how to install grub2 on an Open Firmware
system. Here's one possibility:
/boot -- Linux-native filesystem (e.g. ext3)
holds kernels, initrd, etc
/boot/grub -- firmware-native filesystem (on Mac HFS+, on others FAT,
etc)
holds grub executable, grub.cfg, modules
The
27 matches
Mail list logo
