the prefix path
(ie, /fonts/.pf2).
Signed-off-by: Chris Coulson
---
grub-core/font/font.c | 48 ---
1 file changed, 31 insertions(+), 17 deletions(-)
diff --git a/grub-core/font/font.c b/grub-core/font/font.c
index 24adcb35a..7c83467a3 100644
--- a/grub
: 37ddd94 (kern/efi/init: Log a console error during a stack check
failure)
Signed-off-by: Chris Coulson
---
grub-core/Makefile.core.def | 4
1 file changed, 4 insertions(+)
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 5212dfab1..98714c68d 100644
--- a/grub-core
ring up this specific firmware
menu though...
Thanks,
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
for the foreseeable future, and users
will have to use the UEFI firmware's built-in boot manager for this
use case?
This seems related to thread: "How to boot Windows when Bitlocker
enabled with key sealed in TPM External"
https://lists.gnu.org/archive/html/grub-devel/2022-02/msg00
enu, which causes GRUB to use --bootnext to do a
one-time boot using that UEFI boot entry, thus loading that distro's signed
shim+GRUB combo.
Or, is this just not a priority for the foreseeable future, and users will
have to use the UEFI firmware's built-in boot manager for this u
On Fri, Mar 25, 2022 at 5:00 PM Chris Murphy wrote:
>
> On Fri, Mar 25, 2022 at 2:32 PM Vladimir 'phcoder' Serbinenko
> wrote:
> >
> > On Fri, Mar 25, 2022 at 9:14 PM Chris Murphy
> > wrote:
> > >
> > > For all practical purposes, this
On Fri, Mar 25, 2022 at 2:32 PM Vladimir 'phcoder' Serbinenko
wrote:
>
> On Fri, Mar 25, 2022 at 9:14 PM Chris Murphy wrote:
> >
> > For all practical purposes, this is functionally the end to dual boot
> > in GRUB, if there is no work around, e.g. bootne
For all practical purposes, this is functionally the end to dual boot
in GRUB, if there is no work around, e.g. bootnext. Is that the
direction GRUB maintainers want to go in?
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https
such as W^X, call in to boot services
when an error occurs in order to log a message to the console before
automatically rebooting the machine.
Signed-off-by: Chris Coulson
---
grub-core/Makefile.core.def | 4 +++-
grub-core/kern/efi/init.c | 23 +--
2 files changed, 24
On Thu, Feb 10, 2022 at 12:29 PM Lennart Sorensen
wrote:
>
> On Thu, Feb 10, 2022 at 11:46:33AM -0700, Chris Murphy wrote:
> > On Thu, Feb 10, 2022 at 10:18 AM Lennart Sorensen
> > wrote:
> > >
> > > On Mon, Feb 07, 2022 at 04:48:43PM -0700, Chris Murph
On Thu, Feb 10, 2022 at 10:18 AM Lennart Sorensen
wrote:
>
> On Mon, Feb 07, 2022 at 04:48:43PM -0700, Chris Murphy wrote:
> > One idea I've heard floated is, having GRUB alter efivars such that
> > BootNext is changed to do a one time boot of Windows, instead of using
&
t;BootNext" for this use case? Or else I guess distros need to consider
removing the creation of a Windows menu entry, as there's no point
creating menu entries that don't work.
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.
be made unambiguous, I'm not
super fussy how that's done. The advantage of this is permitting
static creation of configuration files, less dependency on customized
configuration.
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
y will expand due
to the Windows 11 requirement that supporting hardware have TPM 2.0.
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Forgot to mention, I do see GRUB knows about "BIOS boot" partition
type guid, when it comes to the grub-install command. But I'm not sure
if GRUB as a concept of doing a search by arbitrary partition type
codes.
Thanks,
Chris Murphy
___
b.cfg much more generic and portable, searching
by partition types rather than by specific and unique file system or
partition UUIDs.
Thanks,
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Wed, 2021-11-03 at 17:38 +0100, Daniel Kiper wrote:
> On Fri, Oct 29, 2021 at 08:16:36PM +0100, Chris Plant wrote:
> > Daniel,
> >
> > I'm back home now and I have access to my PC again, so I can answer
> > more completely.
> >
> > On Tue,
Daniel,
I'm back home now and I have access to my PC again, so I can answer
more completely.
On Tue, 2021-10-26 at 14:51 +0100, Chris Plant wrote:
> Thanks for the detailed reply, I think I’ve got to the bottom of this
> now, I realised what I missed just after I sent this email.
&
Thanks for the detailed reply, I think I’ve got to the bottom of this now, I
realised what I missed just after I sent this email.
> On 26 Oct 2021, at 13:35, Daniel Kiper wrote:
>
> Hey,
>
>> On Thu, Oct 21, 2021 at 08:46:06PM +0100, Chris Plant wrote:
>> Hello,
>&
erated by usual means and runs fine otherwise.
Thanks,
Chris
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
se. Or even make it explicitly a GRUB
bootloader partition type GUID. It's better if each bootloader has its
own? Originally BIOS Boot wasn't "owned" by GRUB, any bootloader can
use it, but insofar as I'm aware it's the only bootloader that uses
this partition typ
From: Chris Vogel
When generating grub.cfg using grub-mkconfig and the scripts 10_linux and
20_linux_xen there is no way to add kernel command line parameters _only_ to
the recovery entries generated.
This is needed to e.g. start a debug shell in installations using systemd
using the kernel
From: Chris Vogel
When generating grub.cfg using grub-mkconfig and the scripts 10_linux and
20_linux_xen there is no way to add kernel command line parameters _only_ to
the recovery entries generated.
This is needed to e.g. start a debug shell in installations using systemd
using the kernel
le shouldn't see any difference.
Chris
diff --git a/docs/grub.texi b/docs/grub.texi
index f8b4b3b21..8b5482ee1 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -1411,6 +1411,14 @@ entry for recovery mode. This option lists command-line
arguments to add
only to the default menu ent
Hi,
Sorry for taking a while to look at this.
On 10/06/2021 12:55, Paul Menzel wrote:
> Dear Daniel, dear Chris,
>
>
> Am 02.03.21 um 19:01 schrieb Daniel Kiper:
>> From: Chris Coulson
>>
>> grub_parser_split_cmdline() expands variable names present in the
>
grubenv only for that purpose. I'd like to see
more consistency, fewer exceptions.
And that also means the old argument about the MBR gap. GRUB should
have its own partition here too.
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Thu, May 27, 2021 at 2:59 AM Michael Chang wrote:
>
> On Wed, May 26, 2021 at 08:36:05PM -0600, Chris Murphy wrote:
> > So is the next era going to be we recommend /boot on FAT?
>
> No. I meant a new partition type only for grubenv files and keep
> everything else as is.
On Wed, May 26, 2021 at 3:17 AM Michael Chang via Grub-devel
wrote:
>
> On Tue, May 25, 2021 at 04:58:23PM -0600, Chris Murphy wrote:
> > Hi,
> >
> > It's not possible for GRUB pre-boot environment to write to grubenv
> > when it's on Btrfs, ZFS, LVM,
On Wed, May 26, 2021 at 2:08 AM Konrad Rzeszutek Wilk
wrote:
>
> On Tue, May 25, 2021 at 04:58:23PM -0600, Chris Murphy wrote:
> > Hi,
> >
> > It's not possible for GRUB pre-boot environment to write to grubenv
> > when it's on Btrfs, ZFS, LVM, mdadm raid,
g
between the preboot and booted environments, which is the point of
grubenv, but it can't work much of the time due to the above
limitations.
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Add ARM64 relocator code to support multiboot2 loader
Signed-off-by: Chris plant
---
grub-core/lib/arm64/relocator.c | 267
grub-core/lib/arm64/relocator_asm.S | 57 ++
include/grub/arm64/relocator.h | 52 ++
3 files changed, 376 insertions
Enable multiboot2 support for arm64-efi target
Signed-off-by: Chris Plant
---
grub-core/Makefile.core.def | 6 ++
1 file changed, 6 insertions(+)
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index b5f47fc41..2c0bec83d 100644
--- a/grub-core/Makefile.core.def
Enable ARM64/aarch64 support in multiboot2 loader
Signed-off-by: Chris Plant
---
grub-core/loader/multiboot.c | 2 +-
grub-core/loader/multiboot_elfxx.c | 2 +-
grub-core/loader/multiboot_mbi2.c | 34 +++---
include/grub/arm64/multiboot.h | 56
Add ARM64 versions of the mmap functions to generate memory map for
multiboot2
Signed-off-by: Chris Plant
---
grub-core/mmap/arm64/uppermem.c | 72 +
include/grub/arm64/memory.h | 60 +++
2 files changed, 132 insertions(+)
create
Define MULTIBOOT2_ARCHITECTURE_AARCH64 to support AARCH64 architecture
+ Define MULTIBOOT2_TAG_TYPE_ELF64_SECTIONS and struct
multiboot_tag_elf64_sections as a version of elf_sections which
correctly aligns the elf section headers to a 64 bit boundary
Signed-off-by: Chris Plant
---
include
of ettique in the way these
patches are presented - I'm a bit new to this text patch process but
I've tried my best.
Signed-off-by: Chris Plant
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Tue, 2020-09-22 at 07:53 +0100, Chris Plant wrote:
> On Tue, 2020-09-22 at 08:33 +0200, Krystian Hebel wrote:
> > On 21.09.2020 21:14, Chris Plant wrote:
> > > On Sat, 2020-05-23 at 14:33 +0200, Hans Ulrich Niedermann wrote:
> > > > On Sat, 23 May 2020 12:21:27
Hello,
Might be a stupid question, but how do I submit/propose changes to the
multiboot specification itself?
Should I just update the texinfo source from the website and attach
that to my patch?
Thanks,
Chris
___
Grub-devel mailing list
Grub
On Tue, 2020-09-22 at 08:33 +0200, Krystian Hebel wrote:
> On 21.09.2020 21:14, Chris Plant wrote:
> > On Sat, 2020-05-23 at 14:33 +0200, Hans Ulrich Niedermann wrote:
> > > On Sat, 23 May 2020 12:21:27 +0100
> > > Chris Plant via Grub-devel wrote:
> > >
>
On Sat, 2020-05-23 at 14:33 +0200, Hans Ulrich Niedermann wrote:
> On Sat, 23 May 2020 12:21:27 +0100
> Chris Plant via Grub-devel wrote:
>
> > On Sat, 2020-05-23 at 12:43 +0200, Hans Ulrich Niedermann wrote:
> > > On Fri, 22 May 2020 17:23:35 +0100
> > >
t; wrote:
> >
> >
> >
> > On Mon, Jun 1, 2020, 15:21 Chris Coulson
> mailto:chris.coul...@canonical.com>>
> wrote:
> >>
> >> When a file is verified, the entire contents of the verified
> file are
> &g
treat
loopback images any differently to physical disk images, and skip
verification of them. Files opened from the filesystem within a loopback
image will still be passed to verifier modules where required.
Signed-off-by: Chris Coulson
---
grub-core/disk/loopback.c | 3 ++-
1 file chang
On Sat, 2020-05-23 at 12:43 +0200, Hans Ulrich Niedermann wrote:
> On Fri, 22 May 2020 17:23:35 +0100
> Chris Plant via Grub-devel wrote:
>
> > I'm continuing to work on Multiboot2 support on aarch64, and I'm
> > looking at the alignment of the ELF headers which
-byte chunks), or to change grub code to ensure that the
ELF headers are aligned on 8 byte boundaries and state that 8 byte
alignment is always the case?
I think logically that it should be 8 byte aligned so that's my
preference, but I thought
cpu_relocator code that is required.
With regards to the Multiboot2 specification for ARM64, I'll document
this within the patch, but it's very similar to the MIPS registers at
the moment.
Chris
On Mon, 2020-05-11 at 16:39 +0200, Daniel Kiper wrote:
> Adding Leif and Ard,
>
> On
oesn't seem to change any issue.
Does anyone have any experience with the ARM64-EFI target or the
multiboot2 code who could help me understand where the issue is?
Cheers,
Chris Plant
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists
volumes?
When I do 'ls (hdX)/' I consistently get an error from
efidisk.c:602:failure reading sector 0x80 for each of hd0, hd1, hd2,
hd3. For hd4 I get a different error which is fs.c:120:unknown file
system.
--
Chris Murphy
___
Grub-devel m
ce.
Photos of "lsefi" output
https://photos.app.goo.gl/pBxLJNdbzz6J9Vo56
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Sat, Nov 30, 2019 at 10:02 AM Chris Murphy wrote:
>
> Hardware:
> Macboo Pro 8,2 (2001)
> (1) Samsung SSD drive
> (1) internal DVD-ROM drive
> (2) USB 2, nothing external connected but built-in keyboard shows up
> as USB device
> (1) wired ethernet
> firmware,
[
On Sat, Nov 30, 2019 at 10:02 AM Chris Murphy wrote:
> SSD partition layout:
> 1 FAT32 EFI system partition (unused)
> 2 APFS (macOS)
> 3 HFS+ (used as ESP by Fedora)
> 4 Btrfs, sysroot
> 5 swap
> 6 Btrfs, sysroot
I goofed that up a bit:
1 FAT32 EFI system partition, unused
ernel to get it to support faster storage devices such as NVMe.
A possible use case would be resuming from a hibernation image.
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
ot either my Macbook Pro or my hp spectre (2016). I
have to MBR or GPT partition a USB stick, format it FAT32, and cp -a
the files onto it, that the HP will boot, still the Mac will not (that
2011 Mac will not USB boot with the CSM; CSM booting is only possib
.
Fedora ISO's use isohybrid and have multiple partitions on their ISOs:
MBR, GPT, and APM.
https://mjg59.dreamwidth.org/11285.html
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
more than the first 4 MiB are needed, let me know.
https://drive.google.com/open?id=1JgPv8EBHDn5A7hTEwewGK1MuFHvHbJnr
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Thu, Sep 27, 2018 at 10:38 AM, Daniel Kiper wrote:
> On Wed, Sep 26, 2018 at 04:45:51PM -0600, Chris Murphy wrote:
>> On Fri, Sep 21, 2018 at 12:35 PM, Daniel Kiper wrote:
>> > On Tue, Sep 18, 2018 at 01:40:06PM -0600, Chris Murphy wrote:
>> >> On Mon, Sep 17,
On Fri, Sep 21, 2018 at 12:35 PM, Daniel Kiper wrote:
> On Tue, Sep 18, 2018 at 01:40:06PM -0600, Chris Murphy wrote:
>> On Mon, Sep 17, 2018 at 10:59 PM, Chris Murphy
>> wrote:
>> > Hi,
>> >
>> > GRUB code can certainly read files that are on Btrfs,
On Mon, Sep 17, 2018 at 10:59 PM, Chris Murphy wrote:
> Hi,
>
> GRUB code can certainly read files that are on Btrfs, md devices,
> LUKS, LVM, and so on. But GRUB code can also write to the physical
> block for grubenv - but are there safe guards that prevent it from
> doing s
? This used to be safe, but now with reflink
support, grubenv could be reflink copied, meaning any overwrite is
disallowed and must be COW'd. How is that handled?
I'm pretty sure on Btrfs GRUB knows is can't write to grubenv, I'm
just curious about the other case
gt; contiguous 64-inode chunk. This way any files the grub tests add and
>> traverse would be in such a fragmented inode allocation. Tests passed,
>> but I'm not sure how to cleanly integrate that into the test harness.
>>
>> Signed-off-by: Eric Sandeen
>
> Eric,
On Tue, May 15, 2018 at 6:33 AM, Daniel Kiper wrote:
> Hi,
>
> On Mon, May 14, 2018 at 01:12:27PM -0600, Chris Murphy wrote:
>> Hi,
>>
>> xfsprogs 4.16.0 defaults to enabling "sparse inode" which is not
>> compatible with GRUB.
>>
>> Dow
pproximate time frame for getting this
fixed, to know whether for Fedora 29 /boot on XFS should be inhibited
until a proper tested patch for GRUB exists.
Thanks,
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
s a lot better
than nothing. I really don't think it's ok for grub-mkconfig to assume
something else is going to properly sync, unmount, or remount-ro whatever
file system the grub.cfg is being written to. grub-mkconfig needs to take
responsibility for its own action, and ensure complete and
paths are not really subvolumes. I hope that makes sense...
If grub-probe does not parse for subvol= then that's not likely the
problem here.
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Mon, Aug 7, 2017 at 9:09 AM, Vladimir 'phcoder' Serbinenko
wrote:
> Upstream doesn't use grub2 prefix. Please try with latest upstream and make
> sure it's compiled with libdevmapper
Same result with current git as of today.
[chris@f26wnuc grub]$ ./configure --
o as if whatever it finds there is not at
all helpful.
inside
< 693 225 0:6 / /dev rw,nosuid shared:22 - devtmpfs devtmpfs
rw,seclabel,size=3999060k,nr_inodes=999765,mode=755
outside
> 21 71 0:6 / /dev rw,nosuid shared:22 - devtmpfs devtmpfs
> rw,seclabel,size=3999060k,nr_ino
-. 1 root tty 4, 19 Aug 3 2017 tty19
crw--w. 1 chris tty 4, 2 Aug 3 2017 tty2
crw--w. 1 root tty 4, 20 Aug 3 2017 tty20
crw--w. 1 root tty 4, 21 Aug 3 2017 tty21
crw--w. 1 root tty 4, 22 Aug 3 2017 tty22
crw--w. 1 root tty
On Thu, Jan 7, 2016 at 4:10 PM, Filipe Manana wrote:
> On Thu, Jan 7, 2016 at 10:05 PM, Chris Murphy wrote:
>> On Thu, Jan 7, 2016 at 12:16 PM, Filipe Manana wrote:
>>> On Thu, Jan 7, 2016 at 7:11 PM, Andrei Borzenkov
>>> wrote:
>>>> As discussed on o
using by referring to MBR, which mainly
exists only at LBA 0. In the case of extended partitions, the EBR
(using the same MBR format) is still outside the LBA range for Btrfs
to apply fitrim ioctl. The VBR however, would be inside that range,
and it's that 64KiB boot
Are these two equivalent, or identical? And if so, which is preferred?
grub2-install --no-bootsector
grub2-install --grub-setup=/bin/true
Thanks,
--
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo
On Nov 3, 2014, at 9:50 PM, Michael Chang wrote:
> On Mon, Nov 03, 2014 at 01:04:33PM -0700, Chris Murphy wrote:
>>
>> Well, Btrfs raid1 might make sense for some of them but opensuse will
>> constrain people from multiple device btrfs. So you can just disallow them
>
On Nov 3, 2014, at 10:50 PM, Andrei Borzenkov wrote:
> В Mon, 3 Nov 2014 14:05:24 -0700
> Chris Murphy пишет:
>
>>
>> On Nov 3, 2014, at 1:29 PM, Andrei Borzenkov wrote:
>>
>>> В Mon, 3 Nov 2014 12:36:24 -0700
>>> Chris Murphy пишет:
>&g
On Nov 3, 2014, at 1:29 PM, Andrei Borzenkov wrote:
> В Mon, 3 Nov 2014 12:36:24 -0700
> Chris Murphy пишет:
>
>>
>> On Nov 2, 2014, at 10:36 PM, Andrei Borzenkov wrote:
>>
>>> В Sun, 2 Nov 2014 15:19:43 -0700
>>> Chris Murphy пишет:
>&g
placed on filesystem.
OK fine, but this just adds to the already complicated matrix of GRUB MBR
installations, to have yet another fallback for yet another special case. This
proves the primary case is broken that so many fallback methods are even
necessary. Already the ESP and BIOSboot workflows are vastly more reliable, and
completely consistent regardless of the filesystems being used. It's the MBR
gap workflow that's busted. If the primary use case is fixed, most use cases
will inherit the benefit with no additional work or testing.
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Nov 2, 2014, at 10:36 PM, Andrei Borzenkov wrote:
> В Sun, 2 Nov 2014 15:19:43 -0700
> Chris Murphy пишет:
>
>>
>> On Nov 1, 2014, at 11:37 PM, Andrei Borzenkov wrote:
>>>
>>> So far nobody suggested solution for grubenv on unwritable loca
On Nov 2, 2014, at 10:31 PM, Andrei Borzenkov wrote:
> В Sun, 2 Nov 2014 15:11:29 -0700
> Chris Murphy пишет:
>
>>
>> On Nov 1, 2014, at 11:27 PM, Andrei Borzenkov wrote:
>>
>>> В Sat, 1 Nov 2014 14:35:57 -0600
>>> Chris Murphy пишет:
>>&
On Nov 1, 2014, at 11:37 PM, Andrei Borzenkov wrote:
> В Sat, 1 Nov 2014 19:34:56 -0600
> Chris Murphy пишет:
>
>>
>> On Oct 30, 2014, at 6:42 AM, Andrei Borzenkov wrote:
>>>
>>> I still believe this is more flexible; in particular, /boot/grub on
On Nov 1, 2014, at 11:27 PM, Andrei Borzenkov wrote:
> В Sat, 1 Nov 2014 14:35:57 -0600
> Chris Murphy пишет:
>>
>> Why not have a dedicated partition with MBR type code for core.img,
>> equivalent to BIOSBoot currently used on GPT? freedesktop.org has a proposal
ate /boot on ext was fine as a short/medium term work around, but
/boot on btrfs has use case benefits so it really needs to work eventually.
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
is purpose (in part). The boot.img code in the MBR can
arbitrarily jump to any LBA, so 0xEA doesn't need to be a primary partition
does it?
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
er I run this command:
> #grub-install –boot-directory=/boot /dev/sda
On EFI just run grub-install with no options, it finds /boot/efi/EFI and if
necessary creates /boot/efi/EFI/grub and puts grubx64.efi there, and also
writes an entry in NVRAM so it should get used by def
On Oct 27, 2014, at 12:01 PM, Andrei Borzenkov wrote:
> В Mon, 27 Oct 2014 10:30:31 -0600
> Chris Murphy пишет:
>
>>
>> On Oct 27, 2014, at 1:39 AM, Andrei Borzenkov wrote:
>>
>>
>>
>>> It does not look like anything needs to
>>&g
On Oct 27, 2014, at 11:46 AM, Mike Gilbert wrote:
> ./configure --build=x86_64-pc-linux-gnu
OK so do ./configure --build=x86_64-pc-linux-gnu --platform=efi
?
Passing only --platform=efi did seem to work: it compiled and grub-install
works.
Chris Mur
otloader, so that the built-in firmware boot manager
displays it as a boot option at start up time (which it doesn't do if the EFI
binary is on the EFI System partition).
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Oct 26, 2014, at 10:06 PM, Chris Murphy wrote:
> OK I've got this working. The problem was user error. Explicitly setting root
> is necessary, and I've updated the bug.
> https://savannah.gnu.org/bugs/index.php?42954
>
> So the approach of chainloading Apple&#x
an it be used. By putting grubx64.efi on hfsplus, and tricking the firmware
into thinking it's an OS X bootloader, we get a prettier user friendly linux
boot experience on Macs.
[1] partitiontype GUID 426F6F74--11AA-AA11-00306543ECAC
[2] partitiontype GUID 484653
rm=efi ;;
I guess $target_vendor isn't getting set to apple and therefore platform
doesn't get set to efi.
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
and tab won't
autocomplete; whereas chainloader does tab autocomplete and I'm able to
navigate to the boot.efi file.
And I also note that Recovery HD (Apple Boot partition type GUID) contains two
bootloaders:
/System/Library/CoreServices/boot.efi
/com.apple.recovery.b
On Oct 24, 2014, at 12:50 PM, SevenBits wrote:
> On Friday, October 24, 2014, Chris Murphy wrote:
> We need to re-evaluate how GRUB will boot OS X for the following reasons:
>
> 1. Apple OS X 10.10 (just released) now by default converts for existing, and
> new installs, the p
rsion (?) but
isn't anymore and I'm not sure why.
https://savannah.gnu.org/bugs/?42954
https://bugzilla.redhat.com/show_bug.cgi?id=1128374
Once the Apple bootloader is chainloaded, it can of course read Core Storage
volumes, encrypted or not, and properly ask for user authenticatio
On Thu, May 22, 2014 at 02:35:44PM EDT, John Hupp wrote:
> On 5/22/2014 1:32 PM, Chris Jones wrote:
[...]
> Exporting to a png without interlacing solved the problem. Thanks for
> the help!
Any time... As to your other dilemma, the closest you'll get to a "grub
users
On Wed, May 21, 2014 at 06:14:42PM EDT, John Hupp wrote:
> I'm trying to design a theme, and I'm using a certain png file for
> both desktop-image and GRUB_BACKGROUND. After I update-grub and
> reboot, I get error: png: interlace method not supported.
[...]
Open the png in the Gimp and "export"
On Sun, May 18, 2014 at 01:33:15AM EDT, Z C wrote:
[..]
> If you are within one shell and you enter another shell, then if you want
> to quit the second shell and return back to the first shell, just simply
> type exit. All env variables and commands you previous typed in the first
> shell are co
ned grubx64.efi to each ESP, and
place a grub.cfg [1] on each ESP that forwards to the "real"
/boot/grub/grub.cfg on the md device. But how does upstream intend this to be
done with existing tools?
Chris Murphy
[1]
# forward to real config
search --no-floppy --fs-uuid --
On Jan 17, 2014, at 5:01 AM, joe faith wrote:
>
>>
>> - Original Message -
>> From: Chris Murphy
>> Sent: 01/16/14 11:55 PM
>> To: The development of GNU GRUB
>> Subject: Re: [RFC] Allow separate boot block and core.img location?
>>
>
On Jan 16, 2014, at 7:13 PM, joe faith wrote:
>
>>
>> - Original Message -
>> From: Chris Murphy
>> Sent: 01/16/14 04:04 PM
>> To: The development of GNU GRUB
>> Subject: Re: [RFC] Allow separate boot block and core.img location?
>>
LBA to load. If that's the case core.img could be
in an extended partition. And once GRUB is running, it doesn't care about
primary or extended partitions anyway, right?
Chris Murphy
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On Sun, Jan 12, 2014 at 08:25:48AM EST, Andrey Borzenkov wrote:
> I was rather shocked when I tried to use starfield theme. Theme itself
> and menu are very nice but command like and menu editing is near to
> unusable. See screenshot. Is it some local problem or others see the
> same?
Not sure if
On Jan 12, 2014, at 10:13 PM, Michael Chang wrote:
> 2014/1/10 Chris Murphy :
>>
>> On Jan 9, 2014, at 3:03 AM, Michael Chang wrote:
>>>
>>> cat < /boot/efi/EFI//grub.cfg
>>> search --fs-uuid --set=root `grub-probe --target=fs_uuid /boot/grub`
>
On Jan 9, 2014, at 3:03 AM, Michael Chang wrote:
> 2014/1/9 Chris Murphy :
>>
>> On Jan 7, 2014, at 10:55 AM, Chris Murphy wrote:
>>
>>>
>>> On Jan 1, 2014, at 10:17 PM, Michael Chang wrote:
>>>>
>>>> We snapshot /boot for
On Jan 7, 2014, at 10:55 AM, Chris Murphy wrote:
>
> On Jan 1, 2014, at 10:17 PM, Michael Chang wrote:
>>
>> We snapshot /boot for kernel and initrd, otherwise the rollback would
>> encounter problem of incompatible userland and kernel/kernel modules.
>> And w
1 - 100 of 259 matches
Mail list logo
