Much like on x86, we can work out if the system is running on top of
EFI firmware. If so, return "arm-efi". If not, fall back to
"arm-uboot" as previously.
Heavily inspired by the existing code for x86.
Signed-off-by: Steve McIntyre <93...@debian.org>
---
grub-core/o
Ping?
On Mon, Feb 11, 2019 at 02:42:34AM +, Steve McIntyre wrote:
>Much like on x86, we can work out if the system is running on top of
>EFI firmware. If so, return "arm-efi". If not, fall back to
>"arm-uboot" as previously.
>
>Heavily inspired by the exis
;completely preventing boot on systems without RAM below 4GB.
>
>Change the initial value to GRUB_EFI_MAX_USABLE_ADDRESS, as originally
>intended.
>
>Reported-by: Steve McIntyre <93...@debian.org>
>Signed-off-by: Leif Lindholm
Tested-by: Steve McIntyre <93...@debian.org
Hey Leif,
On Thu, Feb 21, 2019 at 11:41:10AM +, Leif Lindholm wrote:
>On Mon, Feb 11, 2019 at 02:42:34AM +0000, Steve McIntyre wrote:
>> Much like on x86, we can work out if the system is running on top of
>> EFI firmware. If so, return "arm-efi". If not, fall
system()
Signed-off-by: Steve McIntyre <93...@debian.org>
---
grub-core/osdep/basic/platform.c | 6 ++
grub-core/osdep/linux/platform.c | 46 +++-
include/grub/util/install.h | 3 +++
util/grub-install.c | 2 +-
4 files cha
On Thu, Feb 21, 2019 at 03:23:55PM +0100, dann frazier wrote:
>On Thu, Feb 21, 2019 at 12:42 PM Leif Lindholm
>wrote:
>>
>> Hi Steve,
>>
>> On Mon, Feb 11, 2019 at 02:42:34AM +, Steve McIntyre wrote:
>> > Much like on x86, we can work out if the system
t;> for.
>>
>> Could you address?
>
>Argh... Addressed. Sorry for the confusion. I took first email from
>the thread by mistake. Folks, next time please send new patches as
>not a reply to. Just create new threads.
ACK, will do!
--
Steve McIntyre, Cambridge, UK.
til/grub-install-common.c | 16 +
> util/grub-mkimage.c| 8 +--
> util/setup.c | 6 +++--
> 10 files changed, 90 insertions(+), 45 deletions(-)
LGTM
Reviewed-by: Steve McIntyre <93...@debian.org>
>
>diff --git a/grub-core/osd
case 'x':
>+ case 'X':
> case 'u':
> args->ptr[curn].type = UNSIGNED_INT + longfmt;
> break;
>@@ -900,6 +905,7 @@ grub_vsnprintf_real (char *str, grub_size_t max_len, const
>char *fmt0,
> c = 'x';
> /* Fall through. */
> case 'x':
>+ case 'X':
> case 'u':
> case 'd':
> {
>--
>2.17.1
Reviewed-by: Steve McIntyre <93...@debian.org>
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
required executable `%s'
>- isn't found. */
>- grub_util_error (_("%s: not found"), "efibootmgr");
>-}
>-
>- /* On Linux, we need the efivars kernel modules. */
>-#ifdef __linux__
>- grub_util_exec ((const char * []){ "modprobe"
On Fri, Mar 22, 2019 at 11:29:15PM +, Colin Watson wrote:
>On Wed, Mar 13, 2019 at 01:07:20AM +0000, Steve McIntyre wrote:
>> On Mon, Mar 11, 2019 at 03:05:46PM +, Colin Watson wrote:
>> >+/* Boot option attributes. */
>> >+#define LOAD_OPTION_ACTIVE 0x0
_args
>*args,
> switch (c)
> {
> case 'x':
>+ case 'X':
> case 'u':
> args->ptr[curn].type = UNSIGNED_INT + longfmt;
> break;
>@@ -900,6 +902,7 @@ grub_vsnprintf_real (char *str, grub_size_t max_len, cons
NULL });
>-}
>-
>- free (line);
>- return rc;
>-}
>-
> int
> grub_install_register_efi (grub_device_t efidir_grub_dev,
> const char *efifile_path,
> const char *efi_distributor)
> {
>- const c
VM and on a Beaglebone Black. Leif's
aware and promised me he'd look when he's back from his travels.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess
The
>relevant code part can found here [1], the relevant message text here
>[2].
>
>I haven't analyzed the code in detail yet so I'm not sure why it
>triggers in your case. I will perform a test installation inside a
>SPARC T5 LDOM to find out.
That's code I adde
case 'u':
> args->ptr[curn].type = UNSIGNED_INT + longfmt;
> break;
>@@ -900,6 +902,7 @@ grub_vsnprintf_real (char *str, grub_size_t max_len, const
>char *fmt0,
> c = 'x';
> /* Fall through. */
> case '
resting
>parties too.
>
>If you have any questions please do not hesitate to ask us here or
>in private.
Are you planning a meetup to talk about Grub development again this
year, please?
--
Steve McIntyre, Cambridge, UK.st..
On Fri, Jan 10, 2020 at 02:50:59PM +0100, Daniel Kiper wrote:
>Hi Steve,
>
>On Fri, Jan 03, 2020 at 06:23:34PM +0000, Steve McIntyre wrote:
>> Hi Daniel!
>>
>> On Mon, Nov 25, 2019 at 11:19:52AM +0100, Daniel Kiper wrote:
>> >
>> >Some of you may alrea
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
left on device
Installation finished. No error reported.
and then potentially unbootable systems. If efibootmgr fails,
grub-install should know that and report it!
Signed-off-by: Steve McIntyre <93...@debian.org>
---
grub-core/osdep/unix/platform.c | 24 +++-
i
Anybody interested in reviewing this?
On Mon, Jan 30, 2017 at 07:04:51PM +, Steve McIntyre wrote:
>Code is currently ignoring errors from efibootmgr, giving users
>clearly bogus output like:
>
>Setting up grub-efi-amd64 (2.02~beta3-4) ...
>Installing for x86_
On Thu, Feb 09, 2017 at 09:52:40PM +0300, Andrei Borzenkov wrote:
>30.01.2017 22:04, Steve McIntyre пишет:
>> Code is currently ignoring errors from efibootmgr, giving users
>> clearly bogus output like:
>>
>> Setting up grub-efi-amd64 (2.02~beta3-4) ...
>&
Hi folks,
It would be nice to see this clear bug fixed for the upcoming release
- any chance of getting it reviewed please?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I&#
More than happy to help with that - it's something I've been wanting
for a while.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"I used to be the first kid on the block wanting a cranial implant,
now I want to be the first with a cranial firewall
left on device
Installation finished. No error reported.
and then potentially unbootable systems. If efibootmgr fails,
grub-install should know that and report it!
We've been using this patch in Debian now for some time, with no ill
effects.
Signed-off-by: Steve McIntyre <93...@de
On Mon, Jan 29, 2018 at 06:57:51PM +0100, Daniel Kiper wrote:
>On Mon, Jan 29, 2018 at 02:04:54PM +0000, Steve McIntyre wrote:
>>
>> diff --git a/grub-core/osdep/unix/platform.c
>> b/grub-core/osdep/unix/platform.c
>> index a3fcfcaca..fdd57a027 100644
>> ---
left on device
Installation finished. No error reported.
and then potentially unbootable systems. If efibootmgr fails,
grub-install should know that and report it!
We've been using this patch in Debian now for some time, with no ill
effects.
Signed-off-by: Steve McIntyre <93...@de
On Tue, Jan 30, 2018 at 06:44:05PM +0100, Daniel Kiper wrote:
>On Mon, Jan 29, 2018 at 06:54:23PM +0000, Steve McIntyre wrote:
>>
>> diff --git a/grub-core/osdep/unix/platform.c
>> b/grub-core/osdep/unix/platform.c
>> index a3fcfcaca..b3a617e44 100644
>> ---
left on device
Installation finished. No error reported.
and then potentially unbootable systems. If efibootmgr fails,
grub-install should know that and report it!
We've been using this patch in Debian now for some time, with no ill
effects.
Signed-off-by: Steve McIntyre <93...@de
Apologies for the delayed response - just found this in the archives
but for some reason I never got it in my inbox. Weird... :-/
On Tue, Feb 06, 2018 at 04:29:23PM +0100, Daniel Kiper wrote:
>On Wed, Jan 31, 2018 at 09:49:36PM +0000, Steve McIntyre wrote:
>> Code is currently ignori
ack to the kernel type as before.
Signed-off-by: Steve McIntyre
---
grub-core/osdep/linux/platform.c | 38 +-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/grub-core/osdep/linux/platform.c b/grub-core/osdep/linux/platform.c
index 4b9f6ef..5668a
On Wed, Jan 28, 2015 at 06:42:01AM +0300, Andrei Borzenkov wrote:
>В Wed, 28 Jan 2015 00:56:30 +0000
>Steve McIntyre пишет:
>
>>
>> =
>> Some platforms might be capable of running a 64-bit Linux kern
ather than
just the size of the kernel, there is now an extra EFI sysfs file to
describe the underlying firmware. Read that if possible, otherwise
fall back to the kernel type as before.
Signed-off-by: Steve McIntyre
---
grub-core/osdep/linux/platform.c | 39
On Wed, Jan 28, 2015 at 11:42:14PM +, Steve McIntyre wrote:
>
>v2 coming shortly.
Hi! Any comments on v2?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait: http://www.debian.org/CD/free-linux-cd
Debian does NOT ship free CDs. Ple
8115 [0c03] USB Controller
00:1d.2 8086:8116 [0c03] USB Controller
00:1d.7 8086:8117 [0c03] USB Controller [PI 20]
00:1f.0 8086:8119 [0601] ISA Bridge
00:1f.1 8086:811a [0101] IDE Controller [PI 80]
bus/pci.c:92: bus 0x2
02:00.0 10ec:8136 [0200] Ethernet Controller
bus/pci.c:92: bus 0x
27;d appreciate confirmation from affected folks that
>this is enough to make things boot. If it is, we can perhaps avoid
>worrying about the rest; otherwise, we'll have to get more creative.
Just tested on Jo's laptop now, and the new version works exactly as
h
pc *really* don't get to dictate things in Debian
terms.
As Daniel Axtens has been finding out, the HFS code is terrible in
terms of security. If you still need it for old/semi-dead machines,
maybe you should fork an older grub release and stay with that?
--
Steve McIntyre, Cambridge, UK.
build-time tests to fail.
Signed-off-by: Steve McIntyre
---
tests/util/grub-fs-tester.in | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/util/grub-fs-tester.in b/tests/util/grub-fs-tester.in
index 43f6175c3..6d70967e6 100644
--- a/tests/util/grub-fs-tester.in
+++ b/tests/util/gr
On Thu, Sep 22, 2022 at 07:18:50PM +0200, Daniel Kiper wrote:
>On Sun, Sep 18, 2022 at 11:12:02PM +0100, Steve McIntyre wrote:
>> In some filesystem utils like mksquashfs, they will silently change
>> behaviour and cause timestamps to unexpectedly change. Build
>> environme
-- /dev/sda1
Block device, size 10.85 GiB (11653873664 bytes)
F2FS file system (version 1.14)
$ disktype /dev/sda2
--- /dev/sda2
Block device, size 17.48 GiB (18772656128 bytes)
NTFS file system
Volume size 17.48 GiB (18772652032 bytes, 36665336 sectors)
- End forwarded message -
--
not read past the end of nat journal entries
>
>https://git.savannah.gnu.org/cgit/grub.git/patch/?id=4bd9877f62166b7e369773ab92fe24a39f6515f8
It's exactly the same patch, just the commit hash is different when
pulled into our 2.06 tree.
Cheers,
Steve
--
Steve McIntyre, Cambridge, UK.
rse we don't support signing modules yet
anyway... :-)
Thoughts??
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"I used to be the first kid on the block wanting a cranial implant,
now I want to be the
Hi Daniel!
On Sat, Dec 03, 2022 at 01:41:51AM +1100, Daniel Axtens wrote:
>Steve McIntyre writes:
>>
>> программист некто (in CC) reported this bug a few weeks back in
>> Debian. Since I applied the bundle of filesystem bounds-checking fixes
>> a few months back, he c
other file that does will (incorrectly) also
fail to open that second file.
Let's fix that.
Signed-off-by: Steve McIntyre
---
grub-core/kern/file.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/grub-core/kern/file.c b/grub-core/kern/file.c
index 8d48fd50d..668b149c3 100644
--- a/grub-c
robably makes more sense if we want to go this way. I'm not
sure we do personally, but...
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Dance like no one's watching. Encrypt like everyone is.
- @torproject
thanks for confirming!
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
ability to read or write anything that is longer than one hundred and sixty
character
We're running with this patch in Debian builds right now and it's
working well...
Reviewed-by: Steve McIntyre <93...@debian.org>
Tested-by: Steve McIntyre <93...@debian.org>
(whichever you prefer!)
On Wed, Apr 26, 2023 at 12:06:52PM +0200, Chris Coul
on keeping their old machines alive for the
sake of it, then at some point they also will have to accept staying
on old software too.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
“Changing random stuff until your program works
I've seen this before when hacking on the Debian packaging too. IIRC
it's because the po build does not use separated-out build dirs like
the binary builds, and that would the right way to fix this.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
&qu
49 matches
Mail list logo
