Some buggy (usually older) system firmware always reports a sector size
of 512 bytes - the default one for a very long time.
Newer disk drives diverge from that with longer sector sizes (typically
4096 bytes) and sometimes provide an 512-bytes-emulation layer. If the
latter is not provided, grub
In order to successfully boot with non-512-bytes sector disks and
buggy/older system firmware, core.img must be written in a special way.
This means that:
- each part of core.img that needs to be directly addressable MUST
start on a hardware sector
- the addressing must be
This is a patch series enabling successful boots on machines with
old/buggy system firmware that always assumes that hardware is using
512-bytes sectors, but more modern disks (e.g., 4Kn disks).
I will not get into the details in that cover letter, since the commits
themselves are supposed to be
Falling back to the old-style CHS mode after read failures is a valid
error recovery technique, but read failures can just happen. One
prominent example of that is trying to read the (somewhat) inaccessible
end sectors on newer disks with old, buggy system firmware.
Restore LBA access mode after
The GPT parsing code includes some autodetection magic for non-default
sector sizes.
This is working fine if the underlaying disk abstraction uses the
default sector size of 512 bytes, but will return wrong information (and
read invalid data!) if it is not.
Fix this by skipping the sector size
Chances are that if you need the
native-sector-addressing-with-512-bytes-lengths feature, you will also
need grub to autodetect the native sector size later on.
---
util/grub-install.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/util/grub-install.c
---
docs/grub.texi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/docs/grub.texi b/docs/grub.texi
index 1ce9993a5..f071487d6 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -6433,6 +6433,21 @@ validate the contents of the bootloader embedding area,
or in more
modern
Knowing the disk is fine, but also knowing the partition number is even
better.
Also, add additional non-util debug messages while scanning for explicit
diskfilter types. It can't hurt to get the information in both modes.
---
grub-core/disk/diskfilter.c | 54
Some buggy (usually older) system firmware always reports a sector size
of 512 bytes - the default one for a very long time.
Newer disk drives diverge from that with longer sector sizes (typically
4096 bytes) and sometimes provide an 512-bytes-emulation layer. If the
latter is not provided, grub
Falling back to the old-style CHS mode after read failures is a valid
error recovery technique, but read failures can just happen. One
prominent example of that is trying to read the (somewhat) inaccessible
end sectors on newer disks with old, buggy system firmware.
Restore LBA access mode after
In order to successfully boot with non-512-bytes sector disks and
buggy/older system firmware, core.img must be written in a special way.
This means that:
- each part of core.img that needs to be directly addressable MUST
start on a hardware sector
- the addressing must be
This is a patch series enabling successful boots on machines with
old/buggy system firmware that always assumes that hardware is using
512-bytes sectors, but more modern disks (e.g., 4Kn disks).
I will not get into the details in that cover letter, since the commits
themselves are supposed to be
The GPT parsing code includes some autodetection magic for non-default
sector sizes.
This is working fine if the underlaying disk abstraction uses the
default sector size of 512 bytes, but will return wrong information (and
read invalid data!) if it is not.
Fix this by skipping the sector size
---
docs/grub.texi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/docs/grub.texi b/docs/grub.texi
index 1ce9993a5..f071487d6 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -6433,6 +6433,21 @@ validate the contents of the bootloader embedding area,
or in more
modern
Chances are that if you need the
native-sector-addressing-with-512-bytes-lengths feature, you will also
need grub to autodetect the native sector size later on.
---
util/grub-install.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/util/grub-install.c
Knowing the disk is fine, but also knowing the partition number is even
better.
Also, add additional non-util debug messages while scanning for explicit
diskfilter types. It can't hurt to get the information in both modes.
---
grub-core/disk/diskfilter.c | 54
When booting on an ARMv8 core that implements either CTR.IDC or CTR.DIC
(indicating that some of the cache maintenance operations can be
removed when dealing with I/D-cache coherency, GRUB dies with a
"Unsupported cache type 0x" message.
This is pretty likely to happen when running in a
17 matches
Mail list logo
