On Monday 25 July 2005 14:15, Marco Gerards wrote:
> It's not *that* hard to write.
Not hard at all. It is a design problem but not an implementation problem.
> How is the correct stage1.5 selected in GRUB Legacy?
Very ugly. The function install_func includes a list of pairs, where each pair
co
On Monday 25 July 2005 18:35, Marco Gerards wrote:
> So an example of a boot process is:
>
> - The BIOS loads the GRUB2 (boot.img) as it is stored in the MBR
>
> - GRUB2 in the MBR loads that 31KB into memory and jumps to it
>
> - That 31KB consists of the kernel (kernel.img) and some raw modules
On Monday 25 July 2005 15:06, Vincent Pelletier wrote:
> ...while the choice could be completely overridden, and maybe making
> possible to choose manualy some modules.
Good idea.
> Good idea to add _linux.mod, if it (adding) can be disabled.
OK.
> I prefer that solution. I think grub-mkimage s
Hollis Blanchard <[EMAIL PROTECTED]> writes:
>> In case others don't know the reason for "31KB":
>>
>> As can be seen in the attached common linux disk layout diagram,
>> the optional DOS compatability region used by stage 1.5 is added by
>> default by most partition managers, and is there so that
On Jul 25, 2005, at 6:26 AM, [EMAIL PROTECTED] wrote:
Yoshinori K. Okuji wrote:
On Monday 25 July 2005 04:04, Hollis Blanchard wrote:
Is there a reason not to add all modules all the time?
I should have written more info in English. This is documented well,
but only in Japanese.
There are se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yoshinori K. Okuji wrote:
> When the user uses
> grub-install, I believe that they should be automatically determined.
...while the choice could be completely overridden, and maybe making
possible to choose manualy some modules.
> For now, pc.mod an
[EMAIL PROTECTED] wrote:
As can be seen in the attached common linux disk layout diagram,
sigh, that 16KiB in the diagram should be 32KiB.
Anyway you get the idea...
--
Pádraig Brady - http://www.pixelbeat.org
--
___
Grub-devel mailing list
Grub-de
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
> 3. Adding a new utility which detects an appropriate filesystem module for a
> given directory. This is not bad, but this sounds a bit overkill.
It's not *that* hard to write. Just probe the filesystem using
modules until one works. For that m
James Buchanan <[EMAIL PROTECTED]> writes:
Hi James,
> Like I said, I will have an Intel Itanium2 system arriving soon. I
> didn't know this when I bid on eBay -- but it's capable of 2 Itanium2
> CPUs (mine has one CPU installed) and it can take 24GB RAM. Wow.
> (Mine has 2GB installed). It ca
Yoshinori K. Okuji wrote:
On Monday 25 July 2005 04:04, Hollis Blanchard wrote:
Is there a reason not to add all modules all the time?
I should have written more info in English. This is documented well, but only
in Japanese.
There are several reasons. In the context of i386-pc:
- The si
Hi list,
Like I said, I will have an Intel Itanium2 system arriving soon. I
didn't know this when I bid on eBay -- but it's capable of 2 Itanium2
CPUs (mine has one CPU installed) and it can take 24GB RAM. Wow. (Mine
has 2GB installed). It can also take a 438GB of SCSI disk (mine has 2x
3
On Monday 25 July 2005 04:04, Hollis Blanchard wrote:
> Is there a reason not to add all modules all the time?
I should have written more info in English. This is documented well, but only
in Japanese.
There are several reasons. In the context of i386-pc:
- The size problem. We must keep the co
On Monday 25 July 2005 03:56, Hollis Blanchard wrote:
> It may encourage more casual development if the people who care about
> changelog formatting simply reformat submissions to their
> satisfaction...
Honestly, I do not understand why it is so difficult. When you write a patch
for a project, i
13 matches
Mail list logo
