I zeroed into this problem and it's repeatable. It's the partition
table + reiserfs. Works fine except when the disk partition contains 2 or more
physical partitions and an extended partitions.
Hello. I've discovered and fixed a floating bug with symptoms matching
yours. Can you retest?
Use f
On 06.12.2011 10:42, Jeremy Kerr wrote:
Currently, grub_cmd_delroute will crash when deleting the last route.
In the deletion code, we remove the matching route from the route list:
*prev = route->next
- route->next being NULL to mark the end of the list. We then process
the for loop's itera
Committed, thanks. Next time please include Changelog entry and make
sure that your patch isn't word-wrapped by your mailer.
On 28.11.2011 10:08, Lukas Anzinger wrote:
Hi,
it looks to me that the patch which removes the usage of "local" in
scripts (http://lists.gnu.org/archive/html/grub-devel/2
Hi,
Is there any way to obtain the path info from which a standalone
grub.efi was launched. In case of grub-mkimage uisng --prefix="" results in
prefix being set to the dir from which the efi app was launched, but in the
standalone grub.efi the prefix is (memdisk)/boot/grub . In
(memdisk)/boot/
On 23.12.2011 16:48, Keshav P R wrote:
Hi,
Is there any way to obtain the path info from which a standalone
grub.efi was launched. In case of grub-mkimage uisng --prefix=""
results in prefix being set to the dir from which the efi app was
launched, but in the standalone grub.efi the prefix
On Nov 25, 2011, at 5:31 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 09.11.2011 06:25, Seth Goldberg wrote:
>> Hi,
>>
>> The multiboot2 spec currently says the following regarding memory map
>> entries (tag type 6 in the multiboot2 info tag stack):
>>
>> +
Hi,
On Sat, Dec 24, 2011 at 3:01 PM, Seth Goldberg wrote:
>> On 09.11.2011 06:25, Seth Goldberg wrote:
>>> The proposal is to add an additional type (value = 6) that denotes runtime
>>> memory that some firmware marks as required to be mapped to take advantage
>>> of services after the end of b
Hi,
In a perfect world, I agree that would be enough, but sometimes an is needs
to know, specifically, the UEFI-defined map itself to work around firmware
bugs. I see no reason why both your proposal and mine couldn't coexist.
--S
On Dec 23, 2011, at 10:37 PM, Brendan Trotter wrote:
> H
