Re: Dell BIOS issue reading Disk Extended data
On Fri, Jan 22, 2021 at 3:41 PM Limonciello, Mario wrote: > > > > > Hello Dell folks, I'm Guilherme Piccoli from Canonical - first of all, > > apologies for the out-of-nowhere communication. We've been investigating > > an issue that seems to date long time ago, and eventually we could > > narrow it to what appears to be a Dell BIOS bug. Notice I'm also looping > > a kernel x86 ML and grub-devel, just for the purpose of archiving such > > discussion in public lists, to help others that may find such an issue > > in the future. > > > > Since I don't have contacts of Dell representatives, I've just raised a > > list of people from Dell contributing to kernel in the last 2 years - > > maybe one of you could point me towards the path of a proper > > contact/channel to discuss such an issue. If not, I'm sorry for the noise. > > Let me detail the problem we're observing - notice all of this is about > > legacy BIOS mode, not UEFI. > > Most of the guys you CC'ed from Dell work on client related things, not > servers. So I'll move some of the client guys off of this thread into BCC. > @K, Narendra can you please raise this with the appropriate team? > Thanks Mario and K, Narendra - do we have any news about that? Cheers, Guilherme ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: i386/biosdisk - int 13h/service 48h response buffer issue?
Hi GRUB community, do we have any news about this one? Appreciate any advice. Cheers, Guilherme ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] arm/efi: fix ram base detection
On 32b Arm platforms, grub allocates memory for the initrd in the first
512MB of DRAM. To do so, the grub_efi_get_ram_base() function will be
called to compute the DRAM base. Currently this function returns the lowest
start address of all memory regions with attribute write-back.
However, if for example a small memory region with type reserved and
attribute write-back is present at the bottom of the memory map, it will be
chosen as DRAM base and initrd memory allocation will fail with:
error: out of memory.
Press any key to continue...
This is indeed the case with qemu arm machine virt when the secure world is
enabled and TF-A and OP-TEE are used. The secure world firmware will
reserve secure memory, resulting in the following EFI memory map:
Type Physical start - end #PagesSize Attributes
reserved 0e10-0eff 0f00 15MiB WB
conv-mem 4000-47ef9fff 7efa 130024KiB WB
ACPI-rec 47efa000-47f05fff 000c 48KiB WB
conv-mem 47f06000-6d4f9fff 000255f4 612304KiB WB
ldr-data 6d4fa000-6d4fafff 0001 4KiB WB
...
In this case, the DRAM base is computed as 0xe10, while it should be
0x4000 instead.
Fix this issue by considering only conventional memory with attribute
write-back for DRAM base computation.
This is similar to what is done by Peter Jones in commit 3c1a5d940be5
("arm/arm64 loader: Better memory allocation and error messages.") in
Fedora's grub[1]. This patch reduces the modifications to a minimum.
[1]: https://github.com/rhboot/grub2.git
Fixes: bad144c60f66 ("efi: Add grub_efi_get_ram_base() function for arm64")
Suggested-by: Grant Likely
Signed-off-by: Vincent Stehlé
Cc: Peter Jones
Cc: Leif Lindholm
---
grub-core/kern/efi/mm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
index 0cdb063bb..abf8772bc 100644
--- a/grub-core/kern/efi/mm.c
+++ b/grub-core/kern/efi/mm.c
@@ -677,7 +677,8 @@ grub_efi_get_ram_base(grub_addr_t *base_addr)
for (desc = memory_map, *base_addr = GRUB_EFI_MAX_USABLE_ADDRESS;
(grub_addr_t) desc < ((grub_addr_t) memory_map + memory_map_size);
desc = NEXT_MEMORY_DESCRIPTOR (desc, desc_size))
-if (desc->attribute & GRUB_EFI_MEMORY_WB)
+if (desc->type == GRUB_EFI_CONVENTIONAL_MEMORY &&
+desc->attribute & GRUB_EFI_MEMORY_WB)
*base_addr = grub_min (*base_addr, desc->physical_start);
grub_free(memory_map);
--
2.30.0
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: i386/biosdisk - int 13h/service 48h response buffer issue?
Most likely the issue is the BIOS giving wrong values. It's interesting that you get different values from Linux BIOS info but my guess is that Linux corrects wrong BIOS data by comparing with data reported by native driver. This being said If like to be proven wrong. I would modify Linux to save and/or print raw data or gets from BIOS to check this hypothesis Le ven. 12 mars 2021 à 17:18, Guilherme Piccoli a écrit : > Hi GRUB community, do we have any news about this one? > Appreciate any advice. > > Cheers, > > > Guilherme > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: i386/biosdisk - int 13h/service 48h response buffer issue?
Please try to print/save arguments and results as close to the calling site as reasonable. Maybe Linux passes some other argument differently Le ven. 12 mars 2021 à 19:00, Vladimir 'phcoder' Serbinenko < phco...@gmail.com> a écrit : > Most likely the issue is the BIOS giving wrong values. It's interesting > that you get different values from Linux BIOS info but my guess is that > Linux corrects wrong BIOS data by comparing with data reported by native > driver. This being said If like to be proven wrong. I would modify Linux to > save and/or print raw data or gets from BIOS to check this hypothesis > > Le ven. 12 mars 2021 à 17:18, Guilherme Piccoli > a écrit : > >> Hi GRUB community, do we have any news about this one? >> Appreciate any advice. >> >> Cheers, >> >> >> Guilherme >> >> ___ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel >> > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] minix: avoid mistakenly probing ext2 filesystems
From: Daniel Drake
ext2 (and ext3, ext4) filesystems write the number of free inodes to
location 0x410.
On a minix filesystem, that same location is used for the minix superblock
magic number.
If the number of free inodes on an ext2 filesystem is equal to any
of the four minix superblock magic values plus any multiple of 65536,
grub's minix filesystem code will probe it as a minix filesystem.
In the case of an OS using ext2 as the root filesystem, since there will
ordinarily be some amount of file creation and deletion on every bootup,
it effectively means that this situation has a 1:16384 chance of being hit
on every reboot.
This will cause grub's filesystem probing code to mistakenly identify an
ext2 filesystem as minix. This can be seen by e.g. "search --label"
incorrectly indicating that no such ext2 partition with matching label
exists, whereas in fact it does.
After spotting the rough cause of the issue I was facing here, I borrowed
much of the diagnosis/explanation from meierfra who found and investigated
the same issue in util-linux in 2010:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/518582
This was fixed in util-linux by having the minix code check for the
ext2 magic. Do the same here.
Signed-off-by: Daniel Drake
Reviewed-by: Derek Foreman
---
This bug fix was previously sent to the grub-devel list once before:
https://lists.gnu.org/archive/html/grub-devel/2020-05/msg00205.html
but received no response, so I'm bring it up again.
If my understanding is correct, the bytes in question overlap with the
"maximum file system size" field in the minix superblock, which will
never contain the ext2 magic byte pattern, so there shouldn't be any
unintended side effects.
grub-core/fs/minix.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/grub-core/fs/minix.c b/grub-core/fs/minix.c
index d0d08363c..db0a83feb 100644
--- a/grub-core/fs/minix.c
+++ b/grub-core/fs/minix.c
@@ -38,6 +38,8 @@ GRUB_MOD_LICENSE ("GPLv3+");
#define GRUB_MINIX_MAGIC_300x138F
#endif
+#defineEXT2_MAGIC 0xEF53
+
#define GRUB_MINIX_INODE_DIR_BLOCKS7
#define GRUB_MINIX_LOG2_BSIZE 1
#define GRUB_MINIX_ROOT_INODE 1
@@ -466,7 +468,22 @@ grub_minix_find_file (struct grub_minix_data *data, const
char *path)
static struct grub_minix_data *
grub_minix_mount (grub_disk_t disk)
{
- struct grub_minix_data *data;
+ struct grub_minix_data *data = NULL;
+ grub_uint16_t ext2_marker;
+
+ grub_disk_read (disk, 1 * 2, 56, sizeof (ext2_marker),
+ &ext2_marker);
+ if (grub_errno)
+goto fail;
+
+ /* ext2 filesystems can sometimes be mistakenly identified
+ * as minix, e.g. due to the number of free ext2 inodes being
+ * written to the same location where the minix superblock
+ * magic is found.
+ * Avoid such situations by skipping any filesystems that
+ * have the ext2 superblock magic. */
+ if (ext2_marker == grub_cpu_to_le16_compile_time (EXT2_MAGIC))
+goto fail;
data = grub_malloc (sizeof (struct grub_minix_data));
if (!data)
--
2.26.2
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
GRUB 2.06~rc1 released
Hi all, The GRUB maintainers are proud to announce the GRUB 2.06~rc1 that has been just released. We would like to thank all the people who have contributed to the project. The tarball is available at https://alpha.gnu.org/gnu/grub/grub-2.06~rc1.tar.xz and its signature at https://alpha.gnu.org/gnu/grub/grub-2.06~rc1.tar.xz.sig Release is signed with the following fingerprint: BE5C 2320 9ACD DACE B20D B0A2 8C81 89F1 988C 2166 It's also available as a signed grub-2.06-rc1 tag in official git repository. If you do not have xz support alternatively you may consider file https://alpha.gnu.org/gnu/grub/grub-2.06~rc1.tar.gz and its signature at https://alpha.gnu.org/gnu/grub/grub-2.06~rc1.tar.gz.sig If you want a binary version for Windows (i386-pc, i386-efi and x86_64-efi flavors) it is available under https://alpha.gnu.org/gnu/grub/grub-2.06~rc1-for-windows.zip and its signature at https://alpha.gnu.org/gnu/grub/grub-2.06~rc1-for-windows.zip.sig Translators can use http://alpha.gnu.org/pub/gnu/grub/grub-2.06~rc1.pot for translation. The pot signature is available at http://alpha.gnu.org/pub/gnu/grub/grub-2.06~rc1.pot.sig Please test this release candidate. If we do not spot major issues we are going to release 2.06 in a month or so. In the meantime we will be looking mostly at the patches fixing tests and documentation posted on grub-devel up until now. If time allows we will also be looking at the patches which introduces new interesting features which should be merged after 2.06 official release. Have a nice weekend, Daniel signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06~rc1 released
Erwin, can you upload new pot file please? Le ven. 12 mars 2021 à 21:02, Daniel Kiper a écrit : > Hi all, > > The GRUB maintainers are proud to announce the GRUB 2.06~rc1 that has > been just released. > > We would like to thank all the people who have contributed to the project. > > The tarball is available at > https://alpha.gnu.org/gnu/grub/grub-2.06~rc1.tar.xz > and its signature at > https://alpha.gnu.org/gnu/grub/grub-2.06~rc1.tar.xz.sig > > Release is signed with the following fingerprint: > BE5C 2320 9ACD DACE B20D B0A2 8C81 89F1 988C 2166 > > It's also available as a signed grub-2.06-rc1 tag in official git > repository. > > If you do not have xz support alternatively you may consider file > https://alpha.gnu.org/gnu/grub/grub-2.06~rc1.tar.gz and its signature at > https://alpha.gnu.org/gnu/grub/grub-2.06~rc1.tar.gz.sig > > If you want a binary version for Windows (i386-pc, i386-efi and x86_64-efi > flavors) it is available under > https://alpha.gnu.org/gnu/grub/grub-2.06~rc1-for-windows.zip > and its signature at > https://alpha.gnu.org/gnu/grub/grub-2.06~rc1-for-windows.zip.sig > > Translators can use http://alpha.gnu.org/pub/gnu/grub/grub-2.06~rc1.pot > for translation. > The pot signature is available at > http://alpha.gnu.org/pub/gnu/grub/grub-2.06~rc1.pot.sig > > Please test this release candidate. If we do not spot major issues we are > going > to release 2.06 in a month or so. > > In the meantime we will be looking mostly at the patches fixing tests and > documentation posted on grub-devel up until now. If time allows we will > also be > looking at the patches which introduces new interesting features which > should be > merged after 2.06 official release. > > Have a nice weekend, > > Daniel > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06~rc1 released
On 3/12/21 1:57 PM, Daniel Kiper wrote: Hi all, The GRUB maintainers are proud to announce the GRUB 2.06~rc1 that has been just released. Congratulations. For LFS, we do a very simple build in a sparse environment. Here are a few observations. We use: ./configure --prefix=/usr \ --sbindir=/sbin\ --sysconfdir=/etc \ --disable-efiemu \ --disable-werror That works cleanly. However there are two files that generate warnings: ./grub-core/script/parser.y:92.1-12: warning: deprecated directive: ‘%pure-parser’, use ‘%define api.pure’ [-Wdeprecated] 92 | %pure-parser | ^~~~ | %define api.pure ./grub-core/script/parser.y: warning: fix-its can be applied. Rerun with option '--update'. [-Wother] grub-core/lib/libgcrypt-grub/cipher/rijndael.c: In function ‘do_setkey’: grub-core/lib/libgcrypt-grub/cipher/rijndael.c:229:9: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] 229 | ; | ^ grub-core/lib/libgcrypt-grub/cipher/rijndael.c:352:21: warning: comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ [-Wsign-compare] 352 | for (i = 0; i < keylen; i++) | ^ It seems that the above is run twice by make, but the fixes are trivial. For make check, I get 43 failures. Many appear to be due to our sparse environment. In most cases I think these tests should be SKIP instead of FAIL, but I'll follow up with a more detailed report later. -- Bruce linuxfromscratch.org ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06~rc1 released
Hi Bruce, On Fri, 12 Mar 2021 15:30:01 -0600 Bruce Dubbs wrote: > On 3/12/21 1:57 PM, Daniel Kiper wrote: > > Hi all, > > > > The GRUB maintainers are proud to announce the GRUB 2.06~rc1 that > > has been just released. > > Congratulations. > > For LFS, we do a very simple build in a sparse environment. Here are > a few observations. > > We use: > > ./configure --prefix=/usr \ > --sbindir=/sbin\ > --sysconfdir=/etc \ > --disable-efiemu \ > --disable-werror > > That works cleanly. However there are two files that generate > warnings: > > ./grub-core/script/parser.y:92.1-12: warning: deprecated directive: > ‘%pure-parser’, use ‘%define api.pure’ [-Wdeprecated] > 92 | %pure-parser >| ^~~~ >| %define api.pure > > ./grub-core/script/parser.y: warning: fix-its can be applied. Rerun > with option '--update'. [-Wother] > > grub-core/lib/libgcrypt-grub/cipher/rijndael.c: In function > ‘do_setkey’: grub-core/lib/libgcrypt-grub/cipher/rijndael.c:229:9: > warning: suggest braces around empty body in an ‘if’ statement > [-Wempty-body] 229 | ; >| ^ > > grub-core/lib/libgcrypt-grub/cipher/rijndael.c:352:21: warning: > comparison of integer expressions of different signedness: ‘int’ and > ‘unsigned int’ [-Wsign-compare] >352 | for (i = 0; i < keylen; i++) >| ^ > > It seems that the above is run twice by make, but the fixes are > trivial. I'm curious, what compiler and version are you using? > For make check, I get 43 failures. Many appear to be due to our > sparse environment. In most cases I think these tests should be SKIP > instead of FAIL, but I'll follow up with a more detailed report later. I'm looking forward to the report. I think ideally the tests should use a very minimal common set of utilities (with some obvious exceptions like qemu and mkfs.*). The tests should only SKIP if its not an appropriate test for the configured target. More likely, they should ERROR to indicated that there was a failure to run the test, not a failure of what the test was testing. This lets the tester know that there's likely an environmental issue that needs to be fixed to get tests working as they should. Glenn >-- Bruce > linuxfromscratch.org > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2.06~rc1 released
On 3/12/21 5:25 PM, Glenn Washburn wrote: Hi Bruce, On Fri, 12 Mar 2021 15:30:01 -0600 Bruce Dubbs wrote: On 3/12/21 1:57 PM, Daniel Kiper wrote: Hi all, The GRUB maintainers are proud to announce the GRUB 2.06~rc1 that has been just released. Congratulations. For LFS, we do a very simple build in a sparse environment. Here are a few observations. We use: ./configure --prefix=/usr \ --sbindir=/sbin\ --sysconfdir=/etc \ --disable-efiemu \ --disable-werror That works cleanly. However there are two files that generate warnings: ./grub-core/script/parser.y:92.1-12: warning: deprecated directive: ‘%pure-parser’, use ‘%define api.pure’ [-Wdeprecated] 92 | %pure-parser | ^~~~ | %define api.pure ./grub-core/script/parser.y: warning: fix-its can be applied. Rerun with option '--update'. [-Wother] grub-core/lib/libgcrypt-grub/cipher/rijndael.c: In function ‘do_setkey’: grub-core/lib/libgcrypt-grub/cipher/rijndael.c:229:9: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] 229 | ; | ^ grub-core/lib/libgcrypt-grub/cipher/rijndael.c:352:21: warning: comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ [-Wsign-compare] 352 | for (i = 0; i < keylen; i++) | ^ It seems that the above is run twice by make, but the fixes are trivial. I'm curious, what compiler and version are you using? $ gcc --version gcc (GCC) 10.2.0 $ bison --version bison (GNU Bison) 3.7.5 For make check, I get 43 failures. Many appear to be due to our sparse environment. In most cases I think these tests should be SKIP instead of FAIL, but I'll follow up with a more detailed report later. I'm looking forward to the report. I think ideally the tests should use a very minimal common set of utilities (with some obvious exceptions like qemu and mkfs.*). The tests should only SKIP if its not an appropriate test for the configured target. More likely, they should ERROR to indicated that there was a failure to run the test, not a failure of what the test was testing. This lets the tester know that there's likely an environmental issue that needs to be fixed to get tests working as they should. That's an interesting perspective. To my mind the failure of a test can be due to a problem with the grub code, the grub test, or the environment of the test system. In my case I'm sure that most of the failures, if not all, are due to the test environment. In my full environment, I only have qemu-system-x86_64, so I'll need to fix that. I should have everything else needed, but need to double check. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
