On 29 Oct 2015 8:51 pm, "Andrei Borzenkov" wrote:
>
> 29.10.2015 18:12, Vladimir 'φ-coder/phcoder' Serbinenko пишет:
>
>>
>>> As you can see, it thinks /dev/sda6 a 'bfs' partition, causing script
>>> 83haiku to fail.
>>>
>> 12 befs|befs_be) debug "$partition is a BeFS partition" ;;
>> Looks l
29.10.2015 18:25, Vladimir 'φ-coder/phcoder' Serbinenko пишет:
+if [ "x$machine" != xaarch64 ]; then
+ multiboot_cmd="multiboot"
+ module_linux_cmd="module"
+ module_initrd_cmd="module --nounzip"
+else
+ multiboot_cmd="xen_hypervisor"
+ module_linux_cmd="xen_linux"
+
29.10.2015 18:12, Vladimir 'φ-coder/phcoder' Serbinenko пишет:
As you can see, it thinks /dev/sda6 a 'bfs' partition, causing script
83haiku to fail.
12 befs|befs_be) debug "$partition is a BeFS partition" ;;
Looks like this is a simple one-line change. befs|befs_be is a name used
by old
On 2015-10-29 08:49, Vladimir 'phcoder' Serbinenko wrote:
-a already means "all". Having to indicate usb0 manually is already a
proof that you have an unmarked cryptocontainer. Moreover this line
exactly illustrates my point: what is usb0 depends on other plugged
device and even his fast they are
> +if [ "x$machine" != xaarch64 ]; then
> + multiboot_cmd="multiboot"
> + module_linux_cmd="module"
> + module_initrd_cmd="module --nounzip"
> +else
> + multiboot_cmd="xen_hypervisor"
> + module_linux_cmd="xen_linux"
> + module_initrd_cmd="xen_initrd"
> +fi
> +
Please do not
> As you can see, it thinks /dev/sda6 a 'bfs' partition, causing script
> 83haiku to fail.
>
12 befs|befs_be) debug "$partition is a BeFS partition" ;;
Looks like this is a simple one-line change. befs|befs_be is a name used
by old driver which had to be removed
signature.asc
Description
On Mon, Oct 26, 2015 at 05:43:36PM -0400, Eric Snowberg wrote:
> Within commit: 87ec3b7fa9061f470616ed927fc140e995831c00 -
> "Don't continue to query block-size if disk doesn't have it.???
> a dangling pointer was introduced.
>
> Fix dangling pointer issue in grub_ofdisk_open where devpath is freed
On 14.10.2015 17:39, Seth Goldberg wrote:
>
>
>> On Oct 14, 2015, at 4:08 AM, Daniel Kiper wrote:
>>
>>> On Wed, Oct 14, 2015 at 05:19:32AM +, Ye, Ting wrote:
>>> Hi all,
>>>
>>> If I understand the issue correctly, I don't quite agree that UEFI
>>> spec is imprecise about SNP constraints de
Committed without the xen_module command. Its argument parsing was
non-trivial and I don't quite get what its intent is. Can you resubmit?
On 23.07.2015 07:16, fu@linaro.org wrote:
> From: Fu Wei
>
> grub-core/loader/arm64/xen_boot.c
>
> - This adds support for the Xen boot on ARM specific
On 23.07.2015 07:16, fu@linaro.org wrote:
> From: Fu Wei
>
> Add accessor functions of "loaded" flag in
> grub-core/loader/arm64/linux.c.
>
> Export accessor functions of "loaded" flag and
> grub_linux_get_fdt function in include/grub/arm64/linux.h.
>
> Purpose: Reuse the existing code of d
Yes, it happens when booting from grub from UEFI firmware: I tested it
on X-Gene.
Cheers,
Stefano
On Thu, 29 Oct 2015, Fu Wei wrote:
> Hi Stefano,
>
> I have tried my grub on Foundation model, but I did not get this
> error, I guess that is the UEFI problem ?
>
> On 1 October 2015 at 00:00, St
On 29 Oct 2015 6:24 am, wrote:
>
> Actually, plain dm-crypt has one distinct advantage to LUKS, and that is
one of plausible deniability. In some countries, you can be court-ordered
to decrypt the contents of a device if it can be proven that encrypted
contents exist. With LUKS, there is no denyin
12 matches
Mail list logo
