Hello, I recently discovered a bug.
When using the serial module in the grub shell, there was no response from the
grub shell, and it is initially suspected to be a core dump.
Through debugging analysis of grub-core/kern/acpi.c, grub2 crashed after
grub_memcmp (tbl ->signature, sig
On Thu, May 16, 2024 at 12:04:21PM GMT, Michael Chang wrote:
> On Wed, May 08, 2024 at 05:48:15PM GMT, Daniel Kiper via Grub-devel wrote:
> > Adding Marta...
> >
> > On Mon, May 06, 2024 at 03:18:45PM -0500, Glenn Washburn wrote:
> > > From: Rogier
> > >
> > > When handling a regular LVM volume,
On Wed, May 08, 2024 at 05:48:15PM GMT, Daniel Kiper via Grub-devel wrote:
> Adding Marta...
>
> On Mon, May 06, 2024 at 03:18:45PM -0500, Glenn Washburn wrote:
> > From: Rogier
> >
> > When handling a regular LVM volume, Grub can fail with the message:
> > error: disk
Adding Marta...
On Mon, May 06, 2024 at 03:18:45PM -0500, Glenn Washburn wrote:
> From: Rogier
>
> When handling a regular LVM volume, Grub can fail with the message:
> error: disk `lvmid/**------
> /**------**' not found.
>
> If the
From: Rogier
When handling a regular LVM volume, Grub can fail with the message:
error: disk `lvmid/**------
/**------**' not found.
If the condition which triggers this exists, grub-probe will report the
error mentioned above. Similarly,
o this
(I suppose I nor many others have a VG that has been changed more than
220 times). I'll submit a proper patch to the list to get the ball
moving on this.
Glenn
>
> ---
> Index: grub2-2.02+dfsg1/grub-core/disk/lvm.c
> =
the issue tracker saying that patches will not be looked at
> unless they are sent to this list for review.
>
> Would you be willing to submit the patch to the list so it can be
> reviewed?
OK, here is the patch from bug #61620 as supplied by
https://savannah.gnu.org/users/rogier777
On Wed, 3 Apr 2024 10:23:59 +0200
Horst Prote wrote:
> Hi,
>
> could the patch supplied in bug #61620
> (https://savannah.gnu.org/bugs/?func=detailitem_id=61620) please be
> reviewed and applied.
Unfortunately, the issues tracker is mostly unused. Patches are
exclusively reviewed on this list.
Hi.
I have some doubts about language sorurce strings syntax
Starting lowercase (instead uppercase) with multiline strings. Ex
other software is using the embedding area, and there is not enough room for
core.img. Such software is often trying to store data in a way that avoids
Hi,
could the patch supplied in bug #61620
(https://savannah.gnu.org/bugs/?func=detailitem_id=61620) please be
reviewed and applied.
Thanks,
Horst Prote
--
Horst Prote, FMI__o Systemadministration Abt. ALG und TI
Universitaet Stuttgart `\<,Tel: +49 711 685-88348, FAX:
Hi all,
This patch set contains a bundle of fixes for various security flaws discovered
in the GRUB2 NTFS driver code recently. The most severe ones, i.e. potentially
exploitable, have CVEs assigned and are listed at the end of this email.
Details of exactly what needs updating will be provided
Hi,
Anyone teach me how grub 2 build from source but all utilities binary
file will prefixed with grub2-*,
e.g /usr/bin/grub-mkimage will installed as /usr/bin/grub2-mkimage,
yes, Fedora did it.
I've checked some web pages especially
"https://src.fedoraproject.org/rpms/grub2/tree/ra
On Tue, Sep 26, 2023 at 12:56 PM document via Grub-devel
wrote:
>
> Hi,
>
> Anyone teach me how grub 2 build from source but all utilities binary file
> will prefixed with grub2-*,
> e.g /usr/bin/grub-mkimage will installed as /usr/bin/grub2-mkimage, yes,
> Fedora did it.
Hi,
Anyone teach me how grub 2 build from source but all utilities binary file will
prefixed with grub2-*,
e.g /usr/bin/grub-mkimage will installed as /usr/bin/grub2-mkimage, yes, Fedora
did it.
I've checked some web pages especially
"https://src.fedoraproject.org/rpms/grub2/tree/ra
used:
>
> - cat /etc/os-release
>
> NAME="Fedora Linux"
> VERSION="38 (Sway)"
> .
> PRETTY_NAME="Fedora Linux 38 (Sway)"
> ANSI_COLOR="0;38;2;60;110;180"
> .
> VARIANT="Sway"
> VARIANT_ID=sway
>
> - The install pi
PRETTY_NAME="Fedora Linux 38 (Sway)"
ANSI_COLOR="0;38;2;60;110;180"
.
VARIANT="Sway"
VARIANT_ID=sway
- The install picked up old Fedora boot setups which show up in
/boot/grub2/grub.conf like this:
menuentry 'Fedora Linux 37 (KDE Plasma) (on /dev/sde3)' --class
gnu
abnormal traffic before it happens via
tcpdump, nothing suspicious in tftp log, though i might have not been
trying/checking hard enough. According to grub variables everything is
setup correctly, so there is no issue with dhcp traffic ?
The exact loop grub2 is entering is permacycling over
https
On Tue, Jan 17, 2023 at 12:50 PM Daniel Kiper wrote:
>
> On Tue, Jan 03, 2023 at 01:15:46AM +, Immolo via Grub-devel wrote:
> > Using Gentoo with clang on a MBR system I have come across an extra string
> > the
> > content /lib/ld-linux.so.2 is being added to
> >
On Tue, Jan 03, 2023 at 01:15:46AM +, Immolo via Grub-devel wrote:
> Using Gentoo with clang on a MBR system I have come across an extra string the
> content /lib/ld-linux.so.2 is being added to
> /usr/lib/grub/i386-pc/diskboot.img
> and /usr/lib/grub/i386-pc/boot.img taking it over 512 bytes
When building grub, the files boot.img and diskboot.img are generated from ELF
reference images and have the expectation that they will be 512 bytes inside
each. However, when GRUB is built with clang, these files become bigger than
512-bytes because the name of the ELF interpreter is appended to
Can you upload diskboot.exec and boot.exec somewhere? Did you see any
errors? Ideally we should have errored out if those files are not 512 bytes
On Tue, 3 Jan 2023 at 09:09, Immolo via Grub-devel
wrote:
> Using Gentoo with clang on a MBR system I have come across an extra string
> the content
On Tue, Jan 03, 2023 at 01:15:46AM +, Immolo via Grub-devel wrote:
> Using Gentoo with clang on a MBR system I have come across an extra string the
> content /lib/ld-linux.so.2 is being added to
> /usr/lib/grub/i386-pc/diskboot.img
> and /usr/lib/grub/i386-pc/boot.img taking it over 512 bytes
Using Gentoo with clang on a MBR system I have come across an extra string
the content /lib/ld-linux.so.2 is being added to
/usr/lib/grub/i386-pc/diskboot.img and /usr/lib/grub/i386-pc/boot.img
taking it over 512 bytes meaning it can't be used on a MBR system.
You can use truncate to remove the
On Tue, Nov 15, 2022 at 07:00:20PM +0100, Daniel Kiper wrote:
> Hi all,
>
> This patch set contains a bundle of fixes for various security flaws
> discovered
> in the GRUB2 font code during last few months. The most severe ones, i.e.
> potentially
> exploitable, have CVEs as
Hi all,
This patch set contains a bundle of fixes for various security flaws discovered
in the GRUB2 font code during last few months. The most severe ones, i.e.
potentially
exploitable, have CVEs assigned and are listed at the end of this email.
Details of exactly what needs updating
Hello folks.
Thank you for this. I a incurring the same problem, can’t boot into Xen.
Did anyone implement the grub2 patch? Is there any way around this?
I have posted it on stackexchange with more details and the config files:
https://unix.stackexchange.com/q/710400/375983
Hi,
This is a resend of my [PATCH v3].
Thank you.
Best Regards,
Zhang Boyang
===
Changes in [PATCH RESEND V3]:
Rebased to latest git head.
Changes in [PATCH V3]:
1/2: To avoid interger overflow during scaling, this patch intruduces
GRUB_FONT_MAX_DIMENSION and GRUB_FONT_MAX_SCALE. The font
Hi all,
This patch set contains a bundle of fixes for various security flaws discovered
in the GRUB2 during last year. The most severe ones, i.e. potentially
exploitable,
have CVEs assigned and are listed at the end of this email. Additionally, the
list
of CVEs contains a CVE assigned
d translates to GRUB2. I've tried `linux` and `linux16`, but those don't
> work. I've found some examples of using `multiboot`, but that just hangs. I
> tried chainloading the ISO as well as the `syslinux_source` and
> `syslinux_configfile` (which is not the way I'd like to go in the end
I'm trying to convert a syslinux/isolinux config from the VMware ESXi
installer ISO for PXE booting and I'm trying to figure out how the syslinux
'kernel' command translates to GRUB2. I've tried `linux` and `linux16`, but
those don't work. I've found some examples of using `multiboot
On 01.12.21 20:24, Shaun Reitan wrote:
Hi Daniel thanks for your reply! You mentioned finding a new LZ4
library but grub2 already looks to support lz4 compressed kernels. The
issue is that they don't look to be supported under the Xen platform
with a target of x86_64.
Grub does "su
Hi Daniel thanks for your reply! You mentioned finding a new LZ4
library but grub2 already looks to support lz4 compressed kernels. The
issue is that they don't look to be supported under the Xen platform
with a target of x86_64.
I'm going to poke around on this today and see what I can
On Tue, Nov 30, 2021 at 07:21:42AM +0100, Juergen Gross via Grub-devel wrote:
> On 30.11.21 00:25, Shaun Reitan wrote:
> > I currently use XEN to boot PV (paravirt) virtual server instances for
> > our customers. Grub2 introduced support for booting a xen kernel
> > direct
On 30.11.21 00:25, Shaun Reitan wrote:
I currently use XEN to boot PV (paravirt) virtual server instances for
our customers. Grub2 introduced support for booting a xen kernel
directly from a guests disk image which has worked great for years. We
use the following command to build our image
st to Xen PVH mode. The Grub2 PVH
image can boot LZ4-compressed kernels and all versions of Ubuntu
that use LZ4 kernels also support booting as a PVH mode guest
without any change to the guest.
grub-mkimage -O i386-xenpvh -o /opt/grub/lib/pvhgrub.bin …
I am not sure that you will find anyone to wo
I currently use XEN to boot PV (paravirt) virtual server instances for
our customers. Grub2 introduced support for booting a xen kernel
directly from a guests disk image which has worked great for years. We
use the following command to build our image
grub-mkstandalone -O x86_64-xen -o grub2
Hi，
Currently, when changing the GRUB2 password, the old password is not verified
and the password complexity is not checked. As a result, the GRUB2 password may
be cracked by brute force. Does the community have any development plans for
this? Recently I have been trying to develop code
Hi,
On Fri, Jul 30, 2021 at 08:55:06PM +0400, Movses Tovmasyan wrote:
> Package: grub2
> Version: 2.02~beta3-5+deb9u2
> Tags: patch
>
> grub2 uses the obsolete version of minilua
> (single-file port of Lua) which has CVE-2014-5461
> Patch attached below.
Thanks for the re
Package: grub2
Version: 2.02~beta3-5+deb9u2
Tags: patch
grub2 uses the obsolete version of minilua
(single-file port of Lua) which has CVE-2014-5461
Patch attached below.
patch
Description: Binary data
___
Grub-devel mailing list
Grub-devel@gnu.org
CC-ing Vladimir.
On Mon, Jul 26, 2021 at 05:24:17PM +, Roma Jam via Grub-devel wrote:
> Dear Grub-devel Subscribers,
>
> Hi everyone!
>
> Is there any option to get information of disks in system from grub2?
>
> I'm looking for disk parameters such as name, pro
Dear Grub-devel Subscribers,
Hi everyone!
Is there any option to get information of disks in system from grub2?
I'm looking for disk parameters such as name, product and serial which is
returned with INQUIRY scsi request.
Are there any other options but to use nativedisk with my own
adm to resolve the sysfs path for
> > >> a block device. That can be accomplished by stating the device node
> > >> and using the major/minor to follow the symlinks in /sys/dev/block/.
>
> > >> This cuts the execution time of grub2-mkconfig from 10s to 2s o
o resolve the sysfs path for
> > > > a block device. That can be accomplished by stating the device node
> > > > and using the major/minor to follow the symlinks in /sys/dev/block/.
> > > > This cuts the execution time of grub2-mkconfig from 10s to 2s on
> > >
gt; > > a block device. That can be accomplished by stating the device node
> > > and using the major/minor to follow the symlinks in /sys/dev/block/.
>
> > > This cuts the execution time of grub2-mkconfig from 10s to 2s on
> > > my system.
>
> >
e accomplished by stating the device node
> > and using the major/minor to follow the symlinks in /sys/dev/block/.
> >
> > This cuts the execution time of grub2-mkconfig from 10s to 2s on
> > my system.
>
> Petr, where you able to reproduce this issue? Could th
gt;> and using the major/minor to follow the symlinks in /sys/dev/block/.
>>
>> This cuts the execution time of grub2-mkconfig from 10s to 2s on
>> my system.
>>
>> Signed-off-by: Jeff Mahoney
>> [ pvorel: include grub/osdep/major.h ]
>> Signed-off-by: Petr
ating the device node
> >> and using the major/minor to follow the symlinks in /sys/dev/block/.
> >> This cuts the execution time of grub2-mkconfig from 10s to 2s on
> >> my system.
> >> Signed-off-by: Jeff Mahoney
> >> [ pvorel: include grub/osd
/sys/dev/block/.
>
> This cuts the execution time of grub2-mkconfig from 10s to 2s on
> my system.
>
> Signed-off-by: Jeff Mahoney
> [ pvorel: include grub/osdep/major.h ]
> Signed-off-by: Petr Vorel
> ---
> grub-core/osdep/linux/hostdisk.c | 8
> 1 file change
r/minor to follow the symlinks in /sys/dev/block/.
> > This cuts the execution time of grub2-mkconfig from 10s to 2s on
> > my system.
> Petr, where you able to reproduce this issue?
No, I'm sorry, I haven't even tried, because accessing sysfs seems to me as a
quickest way anyway.
/.
This cuts the execution time of grub2-mkconfig from 10s to 2s on
my system.
Petr, where you able to reproduce this issue? Could the specifications
of Jeff’s system be added to the commit message?
Signed-off-by: Jeff Mahoney
[ pvorel: include grub/osdep/major.h ]
Signed-off-by: Petr Vorel
---
grub
From: Jeff Mahoney
sysfs_partition_path calls udevadm to resolve the sysfs path for
a block device. That can be accomplished by stating the device node
and using the major/minor to follow the symlinks in /sys/dev/block/.
This cuts the execution time of grub2-mkconfig from 10s to 2s on
my system
Hello Jan!
On 5/18/21 7:05 AM, Jan Nieuwenhuizen wrote:
>>> Sure, sent separately to bug-grub.
>>
>> I cannot find your updated patch.
>
> It's here:
>
> https://lists.gnu.org/archive/html/bug-grub/2021-05/msg9.html
>
>> May I ask you to send it using "git-send-email" to
Daniel Kiper writes:
Hello Daniel,
[..]
>> Sure, sent separately to bug-grub.
>
> I cannot find your updated patch.
It's here:
https://lists.gnu.org/archive/html/bug-grub/2021-05/msg9.html
> May I ask you to send it using "git-send-email" to grub-devel@gnu.org?
(waiting with this
Hi Jan,
On Thu, May 13, 2021 at 12:35:25PM +0200, Jan Nieuwenhuizen wrote:
> Daniel Kiper writes:
>
> Hello Daniel,
>
> > May I ask you to try latest GRUB master git branch [1]? The GRUB 2.04
> > release is a few years old. We are going to release 2.06 soon.
>
> Sure. The bug is still there (see
e `%rax'
lib/i386/relocator64.S:98: Error: bad register name `%rax'
lib/i386/relocator64.S:132: Error: bad register name `%rip)'
--8<---cut here---end--->8---
>> > lib/i386/relocator64.S:66: Error: unknown pseudo-op: `.code64'
>>
>> So, the working pat
Hello Mikhail!
On 5/13/21 9:19 AM, Mikhail B. WproxyM wrote:
> As expected, they do not want to include fix patch, because "The GRUB 2.04
> release is a few years old."
Since GRUB 2.06 will hopefully be released within the next weeks, you should
be able to upgrade to the new upstream release,
ice, but I am not sure that it will work.
> The patch was already ignored some time before by grub2 developers,
> because it is not included in upstream. I will try.
>
> --
> Best regards, Mikhail B.
>
> ср, 28 апр. 2021 г. в 14:44, Thomas Petazzoni <
> thomas.petazz...@bootlin.com>:
&
nch [1]? The GRUB 2.04
release is a few years old. We are going to release 2.06 soon.
> > lib/i386/relocator64.S:66: Error: unknown pseudo-op: `.code64'
>
> So, the working patch is attached. Please add it to grub2.
You can find a few comments below...
> From 270667540146f8ef9ea7a44258a
So, the working patch is attached. Please add it to grub2.
Please re-send your patch using git-send-email, see [1], for example.
Adrian
> [1] https://git-send-email.io/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glau
We are using binutils-2.35.2+ (later then 2.29.1), grub-2.04,
cross-compiling on recent buildroot under i386/i686 and getting error:
> lib/i386/relocator64.S:66: Error: unknown pseudo-op: `.code64'
So, the working patch is attached. Please add it to grub2.
Sources:
1) https://debbugs.gnu.
We are using binutils-2.35.2+ (later then 2.29.1), grub-2.04,
cross-compiling on recent buildroot under i386/i686 and getting error:
> lib/i386/relocator64.S:66: Error: unknown pseudo-op: `.code64'
So, the working patch is attached. Please add it to grub2.
Sources:
1) https://debbugs.gnu.
On Thu, Apr 01, 2021 at 08:43:46PM +0100, Andrew Cooper via Grub-devel wrote:
> On 01/04/2021 09:44, Roger Pau Monné wrote:
> > On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
> >> On 01.04.2021 03:06, Roman Shaposhnik wrote:
> >>> And the obvious next question: is my EVE usecase
On Thu, 1 Apr 2021 20:43:46 +0100
Andrew Cooper via Grub-devel wrote:
> On 01/04/2021 09:44, Roger Pau Monné wrote:
> > On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
> >> On 01.04.2021 03:06, Roman Shaposhnik wrote:
> >>> And the obvious next question: is my EVE usecase esoteric
On 06/04/2021 19:03, Roman Shaposhnik wrote:
> On Tue, Apr 6, 2021 at 10:51 AM Andrew Cooper
> mailto:andrew.coop...@citrix.com>> wrote:
>
> On 06/04/2021 09:19, Jan Beulich wrote:
> > On 01.04.2021 21:43, Andrew Cooper wrote:
> >> On 01/04/2021 09:44, Roger Pau Monné wrote:
> >>>
On Tue, Apr 6, 2021 at 10:51 AM Andrew Cooper
wrote:
> On 06/04/2021 09:19, Jan Beulich wrote:
> > On 01.04.2021 21:43, Andrew Cooper wrote:
> >> On 01/04/2021 09:44, Roger Pau Monné wrote:
> >>> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
> On 01.04.2021 03:06, Roman
On 06/04/2021 09:19, Jan Beulich wrote:
> On 01.04.2021 21:43, Andrew Cooper wrote:
>> On 01/04/2021 09:44, Roger Pau Monné wrote:
>>> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
On 01.04.2021 03:06, Roman Shaposhnik wrote:
> And the obvious next question: is my EVE
On Tue, Apr 6, 2021 at 1:19 AM Jan Beulich wrote:
> On 01.04.2021 21:43, Andrew Cooper wrote:
> > On 01/04/2021 09:44, Roger Pau Monné wrote:
> >> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
> >>> On 01.04.2021 03:06, Roman Shaposhnik wrote:
> And the obvious next question:
On 01.04.2021 21:43, Andrew Cooper wrote:
> On 01/04/2021 09:44, Roger Pau Monné wrote:
>> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
>>> On 01.04.2021 03:06, Roman Shaposhnik wrote:
And the obvious next question: is my EVE usecase esoteric enough that
I should just go
On 01/04/2021 09:44, Roger Pau Monné wrote:
> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
>> On 01.04.2021 03:06, Roman Shaposhnik wrote:
>>> And the obvious next question: is my EVE usecase esoteric enough that
>>> I should just go ahead and do a custom GRUB patch or is there a
On 01.04.2021 10:44, Roger Pau Monné via Grub-devel wrote:
On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
On 01.04.2021 03:06, Roman Shaposhnik wrote:
And the obvious next question: is my EVE usecase esoteric enough that
I should just go ahead and do a custom GRUB patch or is
On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
> On 01.04.2021 03:06, Roman Shaposhnik wrote:
> > And the obvious next question: is my EVE usecase esoteric enough that
> > I should just go ahead and do a custom GRUB patch or is there a more
> > general interest in this?
>
> Not sure
On 01.04.2021 03:06, Roman Shaposhnik wrote:
> And the obvious next question: is my EVE usecase esoteric enough that
> I should just go ahead and do a custom GRUB patch or is there a more
> general interest in this?
Not sure if it ought to be a grub patch - the issue could as well
be dealt with
Hi Andrew!
first of all -- thanks for pointing me in the right direction. So after
reading relevant sources: comments inline.
On Tue, Mar 30, 2021 at 12:08 PM Andrew Cooper
wrote:
> On 30/03/2021 19:28, Roman Shaposhnik wrote:
> > Hi!
> >
> > seems like I've run into an issue with multiboot2
On 30/03/2021 19:28, Roman Shaposhnik wrote:
> Hi!
>
> seems like I've run into an issue with multiboot2 and module2
> commands that I can't quite explain. Since it may be something
> super simply and silly -- I wanted to reach out here before I do
> a GRUB/Xen/LK source deepdive.
>
> So here's
On Thu, Mar 18, 2021 at 09:58:23AM +0100, Paul Menzel wrote:
> Dear Darren, dear Darren,
>
> Am 02.03.21 um 19:00 schrieb Daniel Kiper:
>
> Thank you very much for finding and fixing all these issues, and
> coordinating the publication.
>
> […]
>
> >
Dear Darren, dear Darren,
Am 02.03.21 um 19:00 schrieb Daniel Kiper:
Thank you very much for finding and fixing all these issues, and
coordinating the publication.
[…]
.../lib/gnulib-patches/fix-null-state-deref.patch | 12 +
.../gnulib-patches/fix-regcomp-uninit-token.patch | 15 +
On Tue, Mar 09, 2021 at 10:57:36AM -0500, Neal Gompa wrote:
> On Tue, Mar 2, 2021 at 4:08 PM Daniel Kiper wrote:
> >
> > Hi Adrian,
> >
> > On Tue, Mar 02, 2021 at 08:37:14PM +0100, John Paul Adrian Glaubitz wrote:
> > > Hi Daniel!
> > >
> > > On 3/2/21 7:00 PM, Daniel Kiper wrote:
> > > > The
On Tue, Mar 2, 2021 at 4:08 PM Daniel Kiper wrote:
>
> Hi Adrian,
>
> On Tue, Mar 02, 2021 at 08:37:14PM +0100, John Paul Adrian Glaubitz wrote:
> > Hi Daniel!
> >
> > On 3/2/21 7:00 PM, Daniel Kiper wrote:
> > > The BootHole vulnerability [1][2] announced last year encouraged many
> > > people
Hi Adrian,
On Tue, Mar 02, 2021 at 08:37:14PM +0100, John Paul Adrian Glaubitz wrote:
> Hi Daniel!
>
> On 3/2/21 7:00 PM, Daniel Kiper wrote:
> > The BootHole vulnerability [1][2] announced last year encouraged many
> > people to
> > take a closer look at the security of boot process in general
On 3/2/21 1:37 PM, John Paul Adrian Glaubitz wrote:
Hi Daniel!
On 3/2/21 7:00 PM, Daniel Kiper wrote:
The BootHole vulnerability [1][2] announced last year encouraged many people to
take a closer look at the security of boot process in general and the GRUB
bootloader in particular. Due to
Hi Daniel!
On 3/2/21 7:00 PM, Daniel Kiper wrote:
> The BootHole vulnerability [1][2] announced last year encouraged many people
> to
> take a closer look at the security of boot process in general and the GRUB
> bootloader in particular. Due to that, during past few months we were getting
>
hardware will be updated.
Updated GRUB2, shim and other boot artifacts from all the affected vendors will
be made available when the embargo lifts or some time thereafter. An updated
dbx from the various affected vendors will also ship, although possibly not at
the same time. The new Microsoft dbx
On Wed, Oct 14, 2020 at 03:37:32PM +0200, Daniel Kiper wrote:
>Hey,
>
>GRUB2 minisumit starts in November. CfP is open. More you can find here:
> https://twitter.com/3mdeb_com/status/1316057910816976899?s=20
Cool! Do you have a wiki page or similar to track things? :-)
--
St
Hey,
GRUB2 minisumit starts in November. CfP is open. More you can find here:
https://twitter.com/3mdeb_com/status/1316057910816976899?s=20
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Dear Grub-devel Subscribers,
Hi everyone.
Does anybody work on grub2 xhci implementation at the moment?
To speak briefly, we have an idea to use native drivers but we ran into the
problem that native drivers does not work properly on hosts with xhci.
I wonder is there any chance to connect
Hi Dimitri!
On 7/29/20 11:20 PM, Dimitri John Ledkov wrote:
> Disclosures were done to a subset of binary distributions that have a
> trust path to shims signed with Microsoft UEFI CA 2011 db key. Arch
> Linux does not provide shim-signed with keys controlled by Arch Linux
> and it doesn't
On Wed, 29 Jul 2020 at 21:20, John Paul Adrian Glaubitz
wrote:
>
> On 7/29/20 10:12 PM, Christian Hesse wrote:
> > This does not apply on top of grub 2.04. Will downstream maintainers have to
> > do their cherry-picking on its own or will a maintenance branch on top of
> > grub-2.04 (or what
On 7/29/20 10:12 PM, Christian Hesse wrote:
> This does not apply on top of grub 2.04. Will downstream maintainers have to
> do their cherry-picking on its own or will a maintenance branch on top of
> grub-2.04 (or what ever) be available?
> I would like to push updates to the Arch Linux
Daniel Kiper on Wed, 2020/07/29 19:00:
> I am posting all the GRUB2 upstream patches which fixes all security bugs
> found and reported up until now. Major Linux distros carry or will carry
> soon one form or another of these patches. Now all the GRUB2 upstream
> patches are in t
Hi all,
We have recently been made aware of a problem with GRUB2 by security research
firm Eclypsium that allows a bad actor to circumvent UEFI Secure Boot. Normally,
when Secure Boot is enabled, only modules [1] that have a valid signature can
be loaded. The bug allows this to be circumvented
Besides Jeff's patch, we had been using patch to have grub booting from
default subvolume with the path relative to it, rather than booting from
real root and using absoute path [1].
[1]
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=82591fa6e7941efe2723a23cb1d924dfe0641974
IMHO grub
Hello,
in order to answer questions why this feature is needed I'll re-post my
original feature request.
Grub is booting the default subvolume in BTRFS w/o any manual
modification in Grub configuration.
Current situation:
Booting a snapshot created with Snapper
On 7/11/20 7:09 AM, Vladimir 'phcoder' Serbinenko wrote:
> Why is this patch needed? Can't subvolumes be reached from real root?
> Isn't autogenerated grub.cfg use the names based on real root
We use it to boot from snapshots, which include the grub configs (though
not grub itself). It allows
Why is this patch needed? Can't subvolumes be reached from real root? Isn't
autogenerated grub.cfg use the names based on real root
On Sat, Jul 11, 2020, 05:52 wrote:
> From: Jeff Mahoney
>
> This patch adds the ability to specify a different root on a btrfs
> filesystem too boot from other
From: Jeff Mahoney
This patch adds the ability to specify a different root on a btrfs
filesystem too boot from other than the default one.
btrfs-list-snapshots will list the subvolumes available on the
filesystem.
set btrfs_subvol= and set btrfs_subvolid= will specify
which subvolume to use
Hi,
In general I am OK with the patch. However, I want to ask you to respot
it using "git send-email". Additionally, please add proper commit message
and your SOB.
Daniel
On Sat, May 23, 2020 at 06:02:35PM +0200, Fabian Greffrath wrote:
> Control: forwarded -1 grub-devel@gnu.org
> Control: tags
Control: forwarded -1 grub-devel@gnu.org
Control: tags -1 upstream
Hi grub devs,
the attached patch adds /usr/share/fonts/truetype/dejavu to the DejaVu
font search path in configure.ac. This is the directory where the
fonts-dejavu-core package in Debian installs its fonts.
Thanks!
- Fabian
On Sun, Apr 19, 2020 at 08:47:08PM +0800, 9. wrote:
> Hi, have you considered making grub2 support ecc, and if so, when?
> Thanks for reading and looking forward to your reply.
>
> I would like to add a few words to my question
> ECC is an algorithm for encryption——Elliptic c
Hi, have you considered making grub2 support ecc, and if so, when?
Thanks for reading and looking forward to your reply.
I would like to add a few words to my question
ECC is an algorithm for encryptionElliptic curve encryption algorithm
--Original--
From
Hi, have you considered making grub2 support ecc, and if so, when? Thanks for
reading and looking forward to your reply.___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
1 - 100 of 2256 matches
Mail list logo
