* On 2/20/23 15:26, John Paul Adrian Glaubitz wrote:
> [...]
>>
>> These are standard macros, so if autoconf cannot find them, something really
>> weird must be going on. You'll probably have to strace autoreconf to figure
>> out
>> what it's reading. Unfortunately, debugging autotools is a nightm
* On 2/20/23 10:28, John Paul Adrian Glaubitz wrote:
> I wanted to start the current GRUB master branch on various architectures and
> it
> turns out that the bootstrap script currently fails on Debian unstable due to
> the autoconf syntax changes:
>
> running: AUTOPOINT=true LIBTOOLIZE=true auto
* On 2/9/23 01:05, Benjamin Herrenschmidt wrote:
> Stumbled upon this:
>
> /* The size of a disk cache in 512B units. Must be at least as big as the
>largest supported sector size, currently 16K. */
> #define GRUB_DISK_CACHE_BITS 6
> #define GRUB_DISK_CACHE_SIZE (1 << GRUB_DISK_CACHE_BITS)
* On 8/30/22 22:16, Robbie Harwood wrote:
> Philip Müller writes:
>
>>> What would be the best approach with older installations of grub via
>>> grub-install not having to reinstall grub to MBR as some users don't
>>> even know on how to install grub properly as that job a graphical
>>> installer
* On 5/4/22 2:54 AM, Oskari Pirhonen wrote:
> The existing `version_sort()` function in grub-mkconfig_lib.in uses the
> same logic for detecting the existence of `sort -V` with a fallback to
> `sort -n`. I don't think it adds any new hidden dependencies.
Right, there are fallbacks in both places f
Just a nit, feel free to ignore it...
* On 5/3/22 4:42 PM, Mathieu Desnoyers wrote:
> How does the following paragraph sound ?
>
>
> Here is the improved algorithm proposed:
>
> - Prepare a list with all the relevant information for ordering by a single
> sort(1) execution. This is d
* On 12/27/21 6:36 AM, youling 257 wrote:
> now, linux kernel ext4/f2fs filesystem can support casefold. i used this
> commond
> to format ext4 filesystem.
>
> mkfs.ext4 -F -O 64bit -L '' -E encoding=utf8 '/dev/block/nvme1n1p1'
>
> but grub can't found vmlinuz and initrd.img on casefold ext4 fil
* On 6/11/21 9:36 PM, Javier Martinez Canillas wrote:
> This incompat feature is used to denote that the filesystem stored its
> metadata checksum seed in the superblock. This is used to allow tune2fs
> to change the UUID on a mounted metadata_csum filesystem without having
> to rewrite all the dis
* On 4/15/21 3:59 PM, Vitaly Kuzmichev via Grub-devel wrote:
> Improve 'search' grub-shell command with functionality to search for
> a partition by PARTUUID string. This is useful on systems where FSUUID
> is not guaranteed to be constant, e.g. it is not preserved between
> system updates, and mod
* On 4/3/21 3:33 PM, Miguel Ángel Arruga Vivas wrote:
> Daniel Kiper writes:
> I have some doubts regarding this acryonym:
>
>> Could you add your SOB here?
>
> I added a description of the change there too instead of only making
> the reference to the manual, but certainly I don't know what SOB
* On 3/24/21 5:24 AM, Glenn Washburn wrote:
> Aside from the fact that this doesn't handle negative values of n, this
> would be fine.
Neither do the original version or grub_strncasecmp()... and if you *can* get n
to be negative, I'd be highly impressed!
Jokes aside, it's unsigned, so there's no
* On 3/23/21 2:30 AM, Aru Sahni wrote:
> This is my first attempted contribution to Grub. Please let me know if I need
> to
> make any revisions or updates.
SOB, git-patch format, correct list and the bug is still around on the master
branch... everything looks good. :)
Mihai
OpenPGP_signat
* On 3/21/21 9:06 PM, Glenn Washburn wrote:
> I have another version of grub_uuidcasecmp which is more efficient by not
> copying the UUID bytes to another buffer to strip out the dashes. [...]
At first, I didn't understand why you would need to copy the original UUIDs in
the first place, but then
* On 5/24/20 2:25 PM, Mihai Moldovan wrote:
> 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 know that these commits are m
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 +
nment variable seems to stick after loading the actual (menu)
config file.
V2:
- unbreak SPARC due to a very, very, very stupid typo
- fix a few typos in GPT code comments.
Mihai Moldovan (7):
biosdisk: autodetect hardware sector size (opt-in)
biosdisk: restore LBA mode after read/write fai
---
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 sys
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 au
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 native-sector-si
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 b/util/grub-i
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 w
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 a
nment variable seems to stick after loading the actual (menu)
config file.
Mihai Moldovan (7):
biosdisk: autodetect hardware sector size (opt-in)
biosdisk: restore LBA mode after read/write failures
setup: add support for native sector addressing w/ 512-bytes lengths
grub-install: hook up
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 w
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 native-sector-si
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 a
---
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 sys
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 +
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 au
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 b/util/grub-i
* On 3/10/20 1:23 PM, Vladimir 'phcoder' Serbinenko wrote:
> [...]
> diff --git a/include/grub/util/install.h b/include/grub/util/install.h
> index 2631b1074..982115f57 100644
> --- a/include/grub/util/install.h
> +++ b/include/grub/util/install.h
> @@ -193,13 +193,13 @@ grub_util_bios_setup (const
* On 7/12/19 12:27 AM, Didier Spaier wrote:
> didier[/data/GitHub/grub]$ grep Windows docs/osdetect.cfg
> menuentry "Windows Vista bootmgr (on $device)" $device {
> menuentry "Windows NT/2000/XP loader (on $device)" $device {
> menuentry "Windows 98/ME (on $device)" $device {
>
>
* On 5/20/19 6:52 PM, Thomas Schmitt wrote:
> in the course of a problem search between GRUB, Guix, and xorriso we found
> the trigger of a problem with some old Macbook EFI firmware in a gesture
> of mformat.
> Line 1375 of
>
> http://svn.savannah.gnu.org/viewvc/mtools/trunk/mformat.c?revision=
* On 12/27/18 3:23 PM, Jeff Norden wrote:
> Nothing is ever as simple as it seems, is it?
Never is.
> 1) Deleting the tr after the grep actually seems to break the patch. My
> apologies for not testing this more carefully in advance. It looks like
> the second tr masks grep's exit status, whic
* On 12/20/18 12:53 PM, Daniel Kiper wrote:
>> diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
>> index 4532266be..f2dea11e9 100644
>> --- a/util/grub.d/10_linux.in
>> +++ b/util/grub.d/10_linux.in
>> @@ -193,7 +193,14 @@ submenu_indentation=""
>>
>> is_top_level=true
>> while [ "x
* On 09/06/2018 07:36 PM, Vladimir 'phcoder' Serbinenko wrote:
> Grub partition get start returns in 512B blocks. Can I have more details like
> which partmap you use?
Yes, but this is a low-level function that expects sector sizes in HW sector
addressing mode.
Note that the whole sector convers
o the
disk's sector length.
Subsequent calculations were all wrong for devices that have a diverging
sector length and the functions eventually skipped to the wrong stream
location, reading invalid data.
Signed-off-by: Mihai Moldovan
---
grub-core/osdep/linux/hostdisk.c | 3 ++-
1 file
[resent to list, since I forgot to add a CC header]
* On 08/17/2018 06:11 PM, Vladimir 'phcoder' Serbinenko wrote:
> Sure. Any BIOS able to read CD supports 2K sectors.
> If you mean HDD then I have never seen one. I wrote support for non-512B
> sectors
> in GRUB but so far it's untested as I cou
Hi
Just a quick question: did anyone ever come up a BIOS firmware that supports
sector sizes higher than 512 bytes (say 4096 bytes)?
Mihai
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://
When reading data off a disk, sector values are based on the disk sector
length.
Within grub_util_fd_open_device(), the start of the partition was taken
directly from grub's partition information structure, which uses the
internal sector length (currently 512b), but never transformed to the
disk's
40 matches
Mail list logo
