Hi,
This patch fixed the device.map handlers to accept any device name for grub
drives, rather than just BIOS-style "hd[0-9]" and "fd[0-9]". It makes
update-grub usable on OFW, Coreboot, etc.
Any comments?
--
Robert Millan
I know my rights; I want my phone call!
What good is a phone call…
Robert Millan wrote:
On Tue, May 27, 2008 at 08:23:09PM +0800, Bean wrote:
It's possible to create multiple arch image, but it requires some
extra work. We need to compile i386-efi and x86_64-efi separately,
then use a tool to merge them. This can't be done in a single step.
Why not just drop
On Wed, May 28, 2008 at 07:58:20PM +0300, Vesa Jääskeläinen wrote:
>
> I know that ppl here prefer to write code from scratch, but perhaps in
> this case it would be good idea to use another GNU project for
> additional code. Security is not the easiest topic in there to write
> properly.
I se
El Wednesday 28 May 2008 09:06:51 Robert Millan escribió:
> On Thu, May 22, 2008 at 06:52:02AM -0400, Pavel Roskin wrote:
> > On Wed, 2008-05-21 at 20:20 -0430, Isaac M. Marcos wrote:
> > > Today, I bump on this problem again on updating kernel. Because of this
> > > fault, update-initramfs reports
On Wednesday 28 May 2008 18:58:20 Vesa Jääskeläinen wrote:
> Michael Gorven wrote:
> > On Wednesday 28 May 2008 18:26:09 Vesa Jääskeläinen wrote:
> >> Michael Gorven wrote:
> >>> Numerous ciphers and hashes from libgcrypt: Copyright FSF and LGPL 2.1
> >>> AES cipher from Simon's patch: LGPL 2.1
> >
Michael Gorven wrote:
On Wednesday 28 May 2008 18:26:09 Vesa Jääskeläinen wrote:
Michael Gorven wrote:
Numerous ciphers and hashes from libgcrypt: Copyright FSF and LGPL 2.1
AES cipher from Simon's patch: LGPL 2.1
If we are to go with libgcrypt way... why you are not using AES from
there? (or
On Wednesday 28 May 2008 18:26:09 Vesa Jääskeläinen wrote:
> Michael Gorven wrote:
> > Numerous ciphers and hashes from libgcrypt: Copyright FSF and LGPL 2.1
> > AES cipher from Simon's patch: LGPL 2.1
>
> If we are to go with libgcrypt way... why you are not using AES from
> there? (or is it not a
Robert Millan wrote:
On Tue, May 27, 2008 at 08:23:09PM +0800, Bean wrote:
It's possible to create multiple arch image, but it requires some
extra work. We need to compile i386-efi and x86_64-efi separately,
then use a tool to merge them. This can't be done in a single step.
Why not just drop
Michael Gorven wrote:
Numerous ciphers and hashes from libgcrypt: Copyright FSF and LGPL 2.1
AES cipher from Simon's patch: LGPL 2.1
If we are to go with libgcrypt way... why you are not using AES from
there? (or is it not available for some reason?)
Two pieces of code I've used: GPL 2 or l
Javier Martín wrote:
drivemap-related functionality. Is there any site/document (apart from
the sources themselves) in which I can learn more about the internals
of GRUB2 and, specifically, the "boot" command sequence?.
GRUB 2 Wiki will serve the purpose for developer documentation:
http://gru
On Wed, May 28, 2008 at 9:54 PM, Robert Millan <[EMAIL PROTECTED]> wrote:
> On Tue, May 20, 2008 at 06:22:25PM +0800, Bean wrote:
>> Hi,
>>
>> For normal boot, the root device is passed to core.img in preloader.
>> However, if we load grub2 using linux header, there is no way to know
>> the root de
On Wed, May 28, 2008 at 10:20 PM, Robert Millan <[EMAIL PROTECTED]> wrote:
> gnu-efi is licensed under GPL 2 or later. There's no problem linking GRUB
> with it.
> Thourhg, if it's just a binary file converter license compatibility would
> probably not be required anyway.
It's nice to know, alth
On Wednesday 28 May 2008 16:07:09 Robert Millan wrote:
> On Thu, May 22, 2008 at 03:56:53PM +0200, Michael Gorven wrote:
> > 2. If I am to submit Simon's patch, what remaining issues are there with
> > it? If there is a problem with the license of the ciphers I can replace
> > them with suitable im
On Tue, May 27, 2008 at 11:59:22AM -0400, Pavel Roskin wrote:
>
> Again, I'd like to see the command name shortened, perhaps to "drivemap"
> or "map". It's not like users will need to distinguish BIOS and
> non-BIOS mappings.
But then we're occupping generic namespace with arch-specific features
On Sun, May 25, 2008 at 07:32:27PM +0800, Bean wrote:
> Hi,
>
> I just wonder if anybody is working on x86_64 EFI support ? If none,
> I'd like to add it soon, as it's essential for grub2 to work with
> Apple's 64-bit Intel Mac.
>
> BTW, I notice that grub-mkimage for efi convert elf to efi inter
On Tue, May 27, 2008 at 08:23:09PM +0800, Bean wrote:
>
> It's possible to create multiple arch image, but it requires some
> extra work. We need to compile i386-efi and x86_64-efi separately,
> then use a tool to merge them. This can't be done in a single step.
Why not just drop the -m32 and alw
On Mon, May 26, 2008 at 09:21:50AM -0400, Isaac Dupree wrote:
> Bean wrote:
> >>>BTW, I notice that grub-mkimage for efi convert elf to efi internally,
> >>>how about use the gnu-efi tool chain, this could make it more portable
> >>>between ia32 and x86_64.
> >>Is its license sufficiently compatibl
On Thu, May 22, 2008 at 03:56:53PM +0200, Michael Gorven wrote:
> Hi
>
> I am currently adding support for LUKS encrypted partitions to GRUB2.
> Although
> I'm far from finished, there are a few issues I'd like to address.
>
> 1. I am using the crypto patch submitted by Simon Peter[1][2]. Are t
On Tue, May 27, 2008 at 01:24:47PM +0200, Michael Gorven wrote:
> Here is an initial version of my LUKS patch. I still need to clean some
> things
> up, but I'd like to get some feedback regarding the design of the patch and
> things like coding style. I currently have the following ciphers, has
On Tue, May 20, 2008 at 06:22:25PM +0800, Bean wrote:
> Hi,
>
> For normal boot, the root device is passed to core.img in preloader.
> However, if we load grub2 using linux header, there is no way to know
> the root device. This patch add a new module findroot that can be used
> to scan the root d
On Thu, May 15, 2008 at 06:10:56PM -0400, Pavel Roskin wrote:
> On Mon, 2008-05-12 at 17:32 +0200, Robert Millan wrote:
>
> > > Also, I checked devices.txt from Linux, and I see a simple pattern
> > > there. If the device ends in a number, the partitions are made by
> > > adding "p" and the numbe
On Sat, May 24, 2008 at 11:23:14AM +0200, Marco Gerards wrote:
> > Of course I will adhere to the GRUB coding style. The snippet I posted
> > was just basically just quick pseudocode (not actually compiled) based
> > on 10 minutes of thought. I did not take time to format the code style
> > but s
No reply... if you're still interested in this, I suggest you contact
the people who set the current behaviour and involve them in the discussion,
to see if they have any objections to what you propose.
On Sun, May 11, 2008 at 10:36:38AM +0100, Ian Campbell wrote:
> Hi all,
>
> The version of u
On Thu, May 22, 2008 at 06:52:02AM -0400, Pavel Roskin wrote:
> On Wed, 2008-05-21 at 20:20 -0430, Isaac M. Marcos wrote:
> > Today, I bump on this problem again on updating kernel. Because of this
> > fault,
> > update-initramfs reports a failure. It can't find "/".
> >
> > grub-probe -t device
> The cooperation between modules is not hard, but I think
> map -first (hdx) will be more useful. Such command just swaps hd0 and hdx
> drives. This also covers the scenarios when we chainload something else
> than first sector of given partition.
>
> And maybe we can also consider following synta
25 matches
Mail list logo
