Follow-up Comment #3, bug #65065 (group grub):
relevant stackoverflow:
https://unix.stackexchange.com/questions/780455/how-to-get-a-copy-of-libdevmapper-1-02-34-or-later?noredirect=1#comment1493540_780455
___
Reply to this item
Follow-up Comment #2, bug #65065 (group grub):
I emailed the mailing list about this and phcoder helped me out, thank you
phcoder! :) He said:
syminfo.lst is generated automatically. You don't need to supply it. Your
error means 2 things:
1) real error is earlier in the log
2) most likely you
URL:
<https://savannah.gnu.org/bugs/?65940>
Summary: Add netmask and dns IP address variables for use in
grub
Group: GNU GRUB
Submitter: papamoose
Submitted: Wed 03 Jul 2024 01:41:41 AM UTC
Category
Follow-up Comment #4, bug #65880 (group grub):
Hi,
belatedly i can report that the proposed change was committed to the
git repo of GRUB as
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=b53ec06a1d6f22ffc1139cbfc0f292e4ca2da9cd
I propose to close the bug now.
Have a nice day
URL:
<https://savannah.gnu.org/bugs/?65918>
Summary: dns queries are case sensitive (2.06, probably olded
grub too)
Group: GNU GRUB
Submitter: kasakoff
Submitted: Вт 25 июн 2024 07:29:30
Category: N
URL:
<https://savannah.gnu.org/bugs/?65909>
Summary: GRUB 2.12 should not use large model for compilation
on riscv64
Group: GNU GRUB
Submitter: jmontleon
Submitted: Sat 22 Jun 2024 03:45:03 PM UTC
Ca
Follow-up Comment #3, bug #65880 (group grub):
Hi,
the patch is now posted for review and testing at grub-devel:
https://lists.gnu.org/archive/html/grub-devel/2024-06/msg00163.html
Have a nice day :)
Thomas
___
Reply to this item
Hi,
Vladimir Serbinenko wrote:
> Thomas, savannah just butchers the patch.
Looking in my mailbox ... that line break before "argument" is not by me.
> Can you send it to ML?
I have it ready for grub-devel (git format-patch) and plan to post it
by "git send-email" thi
Follow-up Comment #2, bug #65880 (group grub):
Thomas, savannah just butchers the patch. Can you send it to ML?
___
Reply to this item at:
<https://savannah.gnu.org/bugs/?65880>
___
M
Follow-up Comment #1, bug #65880 (group grub):
Hi,
i can confirm that it happens on Debian 12 with the Debian amd64 package
grub-common (2.06-13+deb12u1) (plus grub-efi-amd64 , grub-efi-amd64-bin ,
grub-efi-amd64-signed , grub2-common) and also with a git clone of today.
The change at the end
URL:
<https://savannah.gnu.org/bugs/?65880>
Summary: heap-buffer-overflow in grub-mkrescue.c
Group: GNU GRUB
Submitter: vegorova
Submitted: Пт 14 июн 2024 11:13:08
Category: None
Severity:
short-name}.EFI.
While FAT < 32 filesystems are not case sensitive (which grub-mkrescue
creates
as a FAT12 image via mformat with a size of 2.88MiB), it seems that
some of Loongson's LoongArch-based firmware (namely those found on their
latest XA61200 boards) seems to treat this file system as
c
Thank you, I shall ask the os-prober maintainers instead, it sounds like
regular mount (or something else) would be better to use for that purpose after
perhaps testing it's available, I'd guess grub-mount might have been designed
to use in the minimal early boot environment with the limited
URL:
<https://savannah.gnu.org/bugs/?65746>
Summary: grub-probe fails to identify squashfs/zstd
Group: GNU GRUB
Submitter: orzel
Submitted: Tue 14 May 2024 07:09:59 PM UTC
Category: File
We don't maintain os-prober. As for grub-mount it was never meant to be
fast and certainly isn't
Le lun. 13 mai 2024, 22:47, stratus--- via Bug reports for the GRand
Unified Bootloader a écrit :
> Dear Grub maintainers, myself and others on the Artix forum have
> experienced problems w
Dear Grub maintainers, myself and others on the Artix forum have experienced
problems with os-prober running very slowly. The issue seems to occur in other
distros as well, and the same subject has come up before in the past:
https://forum.artixlinux.org/index.php/topic,6818.msg41493
It appears
Follow-up Comment #2, bug #60385 (group grub):
Also Bug #63796 and Bug #64291 look suspicious that they might be related to
this issue.
___
Reply to this item at:
<https://savannah.gnu.org/bugs/?60
Follow-up Comment #1, bug #60385 (group grub):
I've encountered this bug today, and unaware of taoky's solution I've created
a fix as well.
The problem is very well described in this ticket: the current parser is
unaware of any nested blocks when searching for the end of a segment.
My solution
Hi.
Distro: Debian 12
uname -a
Linux tm 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29) x86_64
GNU/Linux
Best regards.
=
GRUB 2.12: ./test-suite.log
=
# TOTAL: 86
# PASS: 26
# SKIP: 2
# XFAIL: 0
# FAIL: 51
# XPASS: 0
Some of our vSphere VMs are using vmnext3 networc cards.
Grub2.12 is downloaded via TFTP onto the VMs. An embedded grub.cfg downloads a
grub.cfg placed on a TFTP server.
However since Grub 2.12 this doesn't work anymore.
When executing the embeeded cfg the cursor stalls for a couple of seconds
Repost from help-grub:
https://lists.gnu.org/archive/html/help-grub/2024-03/msg4.html
I'm using grub-mkrescue in combination with the pgp --pubkey feature to
put grub into check_signatures=enforce mode, and to only have signed
data loaded and processed. Something like:
grub-mkrescue
URL:
<https://savannah.gnu.org/bugs/?65389>
Summary: GRUB 2.12 General Protection Exception
Group: GNU GRUB
Submitter: ormshaw
Submitted: Fri 01 Mar 2024 02:00:54 PM UTC
Category: Booting
Se
URL:
<https://savannah.gnu.org/bugs/?65250>
Summary: GRUB unable to PXE boot
Group: GNU GRUB
Submitter: century6
Submitted: Sun 04 Feb 2024 07:01:23 AM UTC
Category: Network
Severity:
to install grub inside a chrooted system:
# grub-install --target=i386-pc /dev/sdc
Installing for i386-pc platform.
grub-install: error: unknown filesystem
This error occurs exactly inside chroot and only when using the xfs file
system. Grub version is 2.06.
Is this a bug or has XFS support been removed
Follow-up Comment #1, bug#65151 (group grub):
The included patch fixes multi-device booting (at least the relevant parts for
GRUB; the initramfs still needs to understand root=UUID=foo). It does _not_
make GRUB capable of having /boot on bcachefs, but it fixes so that it
understands the /dev/foo
URL:
<https://savannah.gnu.org/bugs/?65162>
Summary: grub-install: does not detect required algorithm to
decrypt luks2
Group: GNU GRUB
Submitter: pva0xd
Submitted: Вс 14 янв 2024 19:19:36
Category: Instal
URL:
<https://savannah.gnu.org/bugs/?65151>
Summary: GRUB unable to work with bcachefs multidevice /
systems
Group: GNU GRUB
Submitter: immolo
Submitted: Thu 11 Jan 2024 08:02:03 AM UTC
Category: File
URL:
<https://savannah.gnu.org/bugs/?65113>
Summary: Add All Keyboard Layouts and Selector to Early GRUB
Core Image (grubx64.efi)
Group: GNU GRUB
Submitter: adrelanos
Submitted: Wed 03 Jan 2024 03:44:12
Hello,
actually, with grub-mkconfig, you can't use "sed -i /boot/grub/grub.cfg.new" in
one of /etc/grub.d/* script, due to the use of "exec > /boot/grub/grub.cfg.new"
method.
I propose to rewrite the output redirection in more standard way, to permit
usage of sed -i in /et
Follow-up Comment #2, bug#65072 (group grub):
I have attached two additional files:
output.genefi32.txtoutput of grub-mkimage for EFI 32 bit
output.genbios.txt output of grub-mkimage for non EFI
I noted that the __stack_chk_guard output entries are quite different in the
EFI 32 bit
Follow-up Comment #1, bug#65103 (group grub):
missing from the initial report:
1. using 2.12-rc1 debian package with argon2 patches from
https://gitlab.com/mattz7/pkgbuild-public
2. I use different keys for MOK and grub (RSA2048 vs RSA4096
URL:
<https://savannah.gnu.org/bugs/?65103>
Summary: no way to disable secure boot signature for images
to boot from grub
Group: GNU GRUB
Submitter: akallabeth
Submitted: Mon 01 Jan 2024 11:04:44 AM UTC
Ca
URL:
<https://savannah.gnu.org/bugs/?65074>
Summary: Installing grub to relative path causes installation
to 2 different locations
Group: GNU GRUB
Submitter: mexit
Submitted: Fri 22 Dec 2023 07:39:28
Follow-up Comment #1, bug#65065 (group grub):
It seems like the following commit has not been included in the 2.12 release:
commit 57059ccb62f91548dae8550dcf8d5cc45fcee9c5
Author: Oliver Steffen
Date: Thu Nov 16 16:37:39 2023 +0100
bli: Add explicit dependency on the part_gpt module
Follow-up Comment #1, bug#65072 (group grub):
I have also attached file output.genefi64.txt which is the console output of
the grub-mkimage command.
___
Reply to this item at:
<https://savannah.gnu.org/bugs/?65
Additional Item Attachment, bug#65072 (group grub):
File name: output.genefi64.txtSize:287 KB
<https://file.savannah.gnu.org/file/output.genefi64.txt?file_id=55479>
AGPL NOTICE
These attachments are served by Savane. You can download the corresponding
source code of
Additional Item Attachment, bug#65072 (group grub):
File name: grub-212-error.jpg Size:17 KB
<https://file.savannah.gnu.org/file/grub-212-error.jpg?file_id=55477>
File name: gen-image.bat Size:7 KB
<https://file.savannah.gnu.org/file/gen-image.ba
URL:
<https://savannah.gnu.org/bugs/?65072>
Summary: Grub version 2.12 for Windows grub-mkimage.exe
creates bad code
Group: GNU GRUB
Submitter: drummerdp
Submitted: Fri 22 Dec 2023 02:20:52 AM UTC
Category
URL:
<https://savannah.gnu.org/bugs/?65065>
Summary: extra_deps.lst not part of grub 2.12 release tarball
Group: GNU GRUB
Submitter: jpalus
Submitted: Wed 20 Dec 2023 08:15:28 PM UTC
Category: Compi
Follow-up Comment #1, bug#65038 (group grub):
Probably duplicate of https://savannah.gnu.org/bugs/?65039
I meant to say grub-mkrescue. Not grub-mkimage.
Sorry for the noise.
___
Reply to this item at:
<https://savannah.gnu.org/b
URL:
<https://savannah.gnu.org/bugs/?65039>
Summary: grub-mkrescue ISO Secure Boot / shim support
Group: GNU GRUB
Submitter: adrelanos
Submitted: Sat 16 Dec 2023 11:18:52 AM UTC
Category: B
URL:
<https://savannah.gnu.org/bugs/?65038>
Summary: grub-mkimage ISO Secure Boot / shim support
Group: GNU GRUB
Submitter: adrelanos
Submitted: Sat 16 Dec 2023 11:15:06 AM UTC
Category: B
Greetings,
I have a detailed conversation about my triple boot GRUB error on an MBR
system now solved at
https://bbs.archlinux.org/viewtopic.php?pid=2136569
Please be advised that I can always answer more queries.
Thank you,
Hikmat E Ustad
URL:
<https://savannah.gnu.org/bugs/?64950>
Summary: List grub-reboot MENU_ENTRY options
Group: GNU GRUB
Submitter: amunra
Submitted: Thu 30 Nov 2023 09:50:05 AM UTC
Category: User Int
quot; error.)
Kind regards
Am 17.11.23 um 05:24 schrieb ewnv:
Follow-up Comment #3, bug #64297 (project grub):
I still encounter this error running Arch with Grub version 2:2.12rc1-5.
I Had to destroy the pool and recreate one, then disable snapshotting on the
"boot"
Follow-up Comment #3, bug #64297 (project grub):
I still encounter this error running Arch with Grub version 2:2.12rc1-5.
I Had to destroy the pool and recreate one, then disable snapshotting on the
"boot" pool as a temporary
Follow-up Comment #2, bug #64297 (project grub):
Were these patches ever incorporated? I install using Gentoo, the build
and I believe it pulls in whatever is current in git. The bug is still
present.
___
Reply to this item
Follow-up Comment #1, bug #64821 (project grub):
Forgot to mention the actual version: grub-install (GRUB) 2.06-13
___
Reply to this item at:
<https://savannah.gnu.org/bugs/?64
URL:
<https://savannah.gnu.org/bugs/?64821>
Summary: grub-install reports "error: unknown filesystem."
Group: GNU GRUB
Submitter: greatsun
Submitted: Thu 26 Oct 2023 03:57:08 PM UTC
Catego
Follow-up Comment #6, bug #64475 (project grub):
It happened to me too and I'd like to receive notifications on this bug (I
didn't figure out another way besides leaving a comment).
___
Reply to this item at:
<https://savannah.gnu.
Follow-up Comment #8, bug #64376 (project grub):
I just posted an updated v3 to the mailing list:
https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00110.html
___
Reply to this item at:
<https://savannah.gnu.org/bugs/?64
Hello,
Jon DeVree upstream posted a new patch which may fix your issue. Maybe you can
give it a try?
<https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00059.html>
[PATCH] Fix XFS directory extent
parsing<https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00059.html>
l
Follow-up Comment #7, bug #64376 (project grub):
No one seemed to be looking into this so I posted a fix on grub-devel:
https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00059.html
___
Reply to this item at:
<ht
Vacation time, sorry for late reply...
Adding Lidong...
On Fri, Jul 28, 2023 at 09:27:33AM +, Steve wrote:
> Hello,
>
> Last reply from you guys was on the 13th, and we have yet to see issue
> addressed. I, as a Distro maintainer, had to create a new repo where I held
> gr
URL:
<https://savannah.gnu.org/bugs/?64514>
Summary: 'grub-emu-lite' failed to start 'normal' mode
(command 'normal' in module 'normal.mod') due to missing license informati
Group: GNU GRUB
Submitter: loplex
Submitted: Fri
Maybe this is not a bug, but why does grub-script-check not complain
about this script with intentional typos?
===
enuentry 'New Install' {
insmod part_msdos
ismod et2
st root='(hd0,msdos1)'
echo'Loading Linux New Install ...'
linux /boot/newinstall/vmlinuz
echo
After update:
# LANG=C update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-linux-lts
...
Found initrd image: /boot/intel-ucode.img /boot/amd-ucode.img
/boot/initramfs-linux.img
Found fallback initrd image(s) in /boot: intel-ucode.img amd-ucode.img
initramfs
Follow-up Comment #1, bug #64405 (project grub):
I have have the same issue. Grub version: 2.06-3~deb10u2. Motherboard:
Micro-Star International Co., Ltd B550-A PRO (MS-7C56).
A few interesting things:
1) the same issue happens in BIOS mode programs such as FreeDOS
2) (for me at least
impacting the start times of grub. When grub
is starting in a UEFI environment there are certain scenarios where it
could take multiple minutes for grub to show the grub menu. The reason
is that during initialization when invoking the function
"grub_efidisk_read" in disk/efi/efidisk.c, th
Follow-up Comment #24, bug #64471 (project grub):
One thing to ask? Did grub has any code related to reading / parsing paging
tables? Looks like it dosn't.
How to read physical memory? Is here grub_ method for that? Or should I switch
to some protected mode back and forth using asm code
Follow-up Comment #23, bug #64471 (project grub):
What I understand from Paging is that I had to request memory from efi using
allocate_pages then check if pages table contains this virtual address, so it
was mapped correctly by the efi.
page table located at physical address pointed by part
Hello,
Last reply from you guys was on the 13th, and we have yet to see issue
addressed. I, as a Distro maintainer, had to create a new repo where I held
grub back to r499 as a result of this, not really ideal now is it ?
Kindly update us on the situation and ETA for fix..
--
Best
Follow-up Comment #5, bug #64475 (project grub):
Hello, I used
"qemu-img create -f raw example.img 200M"
to created a 200Mb image file, and
"losetup /dev/loop0 example.img",
mounting example.img as a loop device.
Then I formatted the /dev/loop0 by mkfs.btrfs with default o
Follow-up Comment #4, bug #64475 (project grub):
[comment #2 comment #2:]
> Can you recreate this with a small image and send it to me? You can use
grub-fstest IMAGE cmp PATHINIMAGE PATHEXTERNAL to check if GRUB sees your
files correctly
When I try to create a 16Mb raw img file and mkfs.bt
Follow-up Comment #3, bug #64475 (project grub):
Here is the output of grub-fstest:
$ sudo grub-fstest /dev/nvme0n1p5 cmp /boot/amd-ucode.img
linux-firmware/src/amd-ucode.img
grub-fstest: error: unexpected end of file.
$ sha512sum /boot/amd-ucode.img
Follow-up Comment #22, bug #64471 (project grub):
Ok. I simplified the patch, now it does not change
grub_efi_allocate_pages_real. Wild guess does it fix a) issue, since
grub_efi_mm_add_regions only affecting grub_malloc?
I'm going to bed, I'll check paging later..
(file #54987
Follow-up Comment #21, bug #64471 (project grub):
[(Erreur - Introuvable)]
[comment #20 commentaire #20 :]
> Ok I understand now.
>
> a) I guess you didn't mention that allocating disk buffers from above 4GB
can corrupt the data? Otherwise why not let it fail during to disk
Follow-up Comment #19, bug #64471 (project grub):
[(Erreur - Introuvable)]
[comment #18 commentaire #18 :]
>
> [comment #17 comment #17:]
> >
> > [comment #16 commentaire #16 :]
> > >
> > > [comment #15 comment #15:]
> > > > Where do you check
Follow-up Comment #20, bug #64471 (project grub):
Ok I understand now.
a) I guess you didn't mention that allocating disk buffers from above 4GB can
corrupt the data? Otherwise why not let it fail during to disk operation if it
going to fail due to out of memory error?
b) No idea what is paging
Follow-up Comment #17, bug #64471 (project grub):
[(Erreur - Introuvable)]
[comment #16 commentaire #16 :]
>
> [comment #15 comment #15:]
> > Where do you check the page table?
>
> I do not understand. Can you view the smartmem.patch?
Yes, I've seen it. And you need to check
Follow-up Comment #18, bug #64471 (project grub):
[comment #17 comment #17:]
>
> [comment #16 commentaire #16 :]
> >
> > [comment #15 comment #15:]
> > > Where do you check the page table?
> >
> > I do not understand. Can you view the smartmem.patc
Follow-up Comment #16, bug #64471 (project grub):
[comment #15 comment #15:]
> Where do you check the page table?
I do not understand. Can you view the smartmem.patch?
___
Reply to this item at:
<https://savannah.gnu.org/bugs/
Follow-up Comment #12, bug #64471 (project grub):
When I said "no patches" I mean grub 2.06+argon2 patches+new grub2.12 memory
patches. no bigmem (4GB+) patches.
___
Reply to this item at:
<https://savannah.gnu.or
Follow-up Comment #15, bug #64471 (project grub):
[(Erreur - Introuvable)]
Where do you check the page table?
___
Reply to this item at:
<https://savannah.gnu.org/bugs/?64471>
___
M
Follow-up Comment #2, bug #64475 (project grub):
[(Erreur - Introuvable)]
Can you recreate this with a small image and send it to me? You can use
grub-fstest IMAGE cmp PATHINIMAGE PATHEXTERNAL to check if GRUB sees your
files correctly
Follow-up Comment #14, bug #64471 (project grub):
Desktop e820 with 32GB output.
dmesg | awk '/usable/ && /BIOS-e820/ && match($0, /mem
([0-9a-z]+)-([0-9a-z]+)/,aa){s=strtonum(aa[1]);e=strtonum(aa[2]);if(e-s>1*1024*1024*1024)printf("0x%x-0x%x
%dGB\n",s,e,((e-s)/1
Follow-up Comment #11, bug #64471 (project grub):
Without any patches (<4GB usage range). On desktop Grub corrupt screen when
trying to allocate a lot of memory. Looks like it touching the regions of
memory it should not touch. Photo attached.
(file #54
Follow-up Comment #1, bug #64297 (project grub):
[(Erreur - Introuvable)]
I have posted couple of zfs patches to mailing list recently. They look
similar. Can you test them?
___
Reply to this item at:
<https://savannah.gnu.org/b
Follow-up Comment #13, bug #64471 (project grub):
I made it work by adding smart memory patch as I described below in comment 9.
Here is a code. It working!
https://gitlab.com/axet/homebin/-/blob/debian/dbuild.d/bookworm/grub2/smartmem.patch
(file #54986
Follow-up Comment #10, bug #64471 (project grub):
I had to install 4GB into my machine here is a dmesg for 4GB.
Almost the same, only 1GB+ at 0x1
dmesg | awk '/usable/ && /BIOS-e820/ && match($0, /mem
([0-9a-z]+)-([0-9a-z]+)/,aa){s=strtonum(aa[1]);e=strtonum(aa[2])
Follow-up Comment #9, bug #64471 (project grub):
I guess we need smi-automatic GRUB_EFI_MAX_USABLE_ADDRESS variable.
If we have enough memory from low memory segment (<4GB), then use it. If we
have no memory and grub about to return out of memory error, instead crashing,
why not to try alloc
Follow-up Comment #8, bug #64471 (project grub):
base_addr = 0x0, length = 0x92000, available RAM
base_addr = 0x92000, length = 0xc000, available RAM
base_addr = 0x9e000, length = 0x1000, reserved RAM
base_addr = 0x9f000, length = 0x1000, available RAM
base_addr = 0x10, length = 0x1a21
Follow-up Comment #1, bug #64475 (project grub):
I mean, something wrong with grub btrfs module, sorry for my mistyping!
___
Reply to this item at:
<https://savannah.gnu.org/bugs/?64
URL:
<https://savannah.gnu.org/bugs/?64475>
Summary: grub failed to initrd /boot/amd-ucode.img in btrfs
partition with bees
Group: GNU GRUB
Submitter: watermelonrei
Submitted: Wed 26 Jul 2023 12:17:14
Follow-up Comment #7, bug #64471 (project grub):
[(Erreur - Introuvable)]
Can you post complete map from desktop as well?
___
Reply to this item at:
<https://savannah.gnu.org/bugs/?64
Follow-up Comment #6, bug #64471 (project grub):
On desktop the only memory segment larger than 1GB is at
0x1 - 0x7c000
which is equivalent to 31G
Desktop has no 1G+ blocks below 4GB (0x1)
___
Reply to this item
Follow-up Comment #5, bug #64471 (project grub):
I have secure boot disabled all the time. Since I compile grub manually for
argon2id
___
Reply to this item at:
<https://savannah.gnu.org/bugs/?64
Follow-up Comment #4, bug #64471 (project grub):
You are right. Not every EFI works with GRUB_EFI_MAX_USABLE_ADDRESS
0xffULL. My laptop won't boot if I change it. Grub simply unable to
open drive (ssd) and unlock the key. Not sure what is going on.
Laptop:
[0.00] BIOS-e820: [mem
Follow-up Comment #3, bug #64471 (project grub):
[(Erreur - Introuvable)]
It's not that simple. Some firmwares fail to map memory above 4GiB and attempt
to use it will lead to a bad crash. We need to parse mapping table to be sure
that those are safe to use. Can you attach your EFI memory map
Follow-up Comment #2, bug #64471 (project grub):
My laptop wont boot with GRUB_EFI_MAX_USABLE_ADDRESS 0xffULL (asus),
but desktop works fine (gigabyte).
Looks like we can detect how much memory we have.
Running simple script can show how much memory we have below 4GB mark and
above
Follow-up Comment #1, bug #64471 (project grub):
GRUB_EFI_MAX_USABLE_ADDRESS 0xffULL
make it work! Default for amd64 0x0x
___
Reply to this item at:
<https://savannah.gnu.org/bugs/?64
Additional Item Attachment, bug #64471 (project grub):
File name: lsmmap2.jpgSize:1732 KB
<https://file.savannah.gnu.org/file/lsmmap2.jpg?file_id=54969>
File name: lsmmap3.jpgSize:1835 KB
<https://file.savannah.gnu.org/file/lsmmap3.jp
URL:
<https://savannah.gnu.org/bugs/?64471>
Summary: grub efi memory allocation (efi/mm) does not work on
every machine
Group: GNU GRUB
Submitter: axet
Submitted: Tue 25 Jul 2023 06:04:05 PM UTC
Category: B
t;>
>> Sorry for posting this again there was a formatting issue (Whitext/White bg)
>>
>> I found a strange issue with XFS filesystem when used for `/boot`. Out of
>
> Could you tell us which version of the XFS tools, xfsprogs package, did
> you use to create this filesystem?
Hello
Thanks for the reply, version of xfsprogs that was used was latest
available on Arch repos at the time, 6.3.0-2 ...
> Hi, Adding Lidong and Marta... Steve, thank you for the report. Could you
> tell us which version of the XFS tools, xfsprogs package, did you use to
> create this
. Out of
Could you tell us which version of the XFS tools, xfsprogs package, did
you use to create this filesystem?
> <100%> it fails to install grub with the Calamares installer. However when the
> commit ef7850c757fb3dd2462a512cfa0ff19c89fcc0b1 (fs/xfs: Fix issues found
> whil
Follow-up Comment #6, bug #64376 (project grub):
Hello,
Due to a formatting error am posting again..
I found a strange issue with XFS filesystem when used for `/boot`. Out of
<100%> it fails to install grub with the Calamares installer. However when the
Hello
Sorry for posting this again there was a formatting issue (Whitext/White bg)
I found a strange issue with XFS filesystem when used for `/boot`. Out of
<100%> it fails to install grub with the Calamares installer. However when
the commit ef7850c757fb3dd2462a512cfa0ff19c89fcc0b1 (fs/xf
I found a strange issue with *XFS* filesystem when used for `/boot`.(error:
file '/grub/x86_64-efi/normal.mod' not found) Out of <100%> it fails to
install grub with the *Calamares* installer. However when the commit
*ef7850c757fb3dd2462a512cfa0ff19c89fcc0b1* (fs/xfs: Fix issues found
Follow-up Comment #5, bug #64376 (project grub):
I found a strange issue with XFS filesystem when used for `/boot`. Out of
<100%> it fails to install grub with the Calamares installer. However when the
commit ef7850c757fb3dd2462a512cfa0ff19c89fcc0b1 (fs/xfs: Fix issues found
while fuzzing t
1 - 100 of 5687 matches
Mail list logo