Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.

[Daniel Kiper]

Hey,

Adding Lidong...

Sebastian, Lidong is working on a fix for this issue.

Lidong, please keep Sebastain in the loop.

Daniel

On Sat, Sep 09, 2023 at 03:41:55PM +0200, Sebastian Andrzej Siewior wrote:
> Package: grub2
> Version: 2.12~rc1-9
> Severity: Serious
> control: forwarded -1 https://savannah.gnu.org/bugs/?64376
>
> I have a single XFS partition which contains the root filesystem and the
> boot partition. Since the recent upgrade to the 2.12 series I can't boot
> anymore because grub complains that it can't find normal.mod and remains in
> the rescue shell.
> The ls command kind of works. A ls in /boot/grub/i386-pc/ (where the
> normal.mod should be) shows a few files and then abort with the error
> message: 'error: invalid XFS directory entry'.
>
> I figured out that if I remove that directory and create a new one only
> with normal.mod then it was able to find it and complained about onother file.
> I then repeated the game until I had more files… The invocation of 
> grub-install
> copied all files and broke it again.
>
> I then looked at various places and stumbled uppon
> https://savannah.gnu.org/bugs/?64376 and this indeed matches what I see.
> I rebuilt the grub2 package with commit ef7850c757fb3 ("fs/xfs: Fix
> issues found while fuzzing the XFS filesystem") reverted, installed from
> a rescue system and voila it boots again.
>
> My xfs filesystem is a normal v5 as in:
> | # xfs_info /dev/sdb1
> | meta-data=/dev/sdb1  isize=512agcount=4, agsize=655360 blks
> |  =   sectsz=512   attr=2, projid32bit=1
> |  =   crc=1finobt=1, sparse=1, rmapbt=1
> |  =   reflink=1bigtime=0 inobtcount=0 
> nrext64=0
> | data =   bsize=4096   blocks=2621440, imaxpct=25
> |  =   sunit=0  swidth=0 blks
> | naming   =version 2  bsize=4096   ascii-ci=0, ftype=1
> | log  =internal log   bsize=4096   blocks=3693, version=2
> |  =   sectsz=512   sunit=0 blks, lazy-count=1
> | realtime =none   extsz=4096   blocks=0, rtextents=0
>
> Sebastian

Bug#1021846: [programmer11...@programist.ru: Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem]

[Daniel Kiper]

Adding Daniel Axtens...

On Tue, Nov 15, 2022 at 06:31:45PM +, Steve McIntyre wrote:
> Hi all!
>
> программист некто (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 can't run grub-install. He's done the work to
> determine that the patch that breaks things for him is
>
> 2d014248d540c7e087934a94b6e7a2aa7fc2c704 fs/f2fs: Do not read past the end of 
> nat journal entries
>
> The full thread of our discussion is at https://bugs.debian.org/1021846
>
> I don't have any knowledge of f2fs to go any further here. Help please! :-)
>
> - Forwarded message from программист некто 
>  -
>
> From: программист некто 
> To: sub...@bugs.debian.org
> Date: Sat, 15 Oct 2022 23:54:36 +0300
> Subject: Bug#1021846: grub-install is broken since 2.06-3: error: unknown 
> filesystem
> Message-Id: <3168731665867...@wf4nrjvtssjecb53.iva.yp-c.yandex.net>
>
> Package: grub-pc
> Version: 2.06-3~deb11u1
> Severity: critical
>
> Hello. Since version 2.06-3, grub-install is broken: it fails with "error: 
> unknown filesystem".
> I test command /usr/sbin/grub-install -v /dev/sda
> in some versions. Results in mail attachments.
> Versions older than 2.06-3 works without error (2.06-2 and lower).
> Tested versions: 2.04-20, 2.06-1, 2.06-2, 2.06-3~deb10u1, 2.06-3~deb11u1, 
> 2.06-4.
>
> Disk partitions:
>
> # fdisk --list-details
> Disk /dev/sda: 29,82 GiB, 32017047552 bytes, 62533296 sectors
> Disk model: TS32GSSD370S
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0xc7177f7e
>
> Device Boot Start End Sectors Id Type Start-C/H/S End-C/H/S Attrs
> /dev/sda1 2048 22763519 22761472 83 Linux 4/4/1 1023/254/2
> /dev/sda2 * 25866240 62531583 36665344 7 HPFS/ 1023/254/2 1023/254/2 80
>
> $ disktype /dev/sda1
> --- /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 -
> --
> Steve McIntyre, Cambridge, UK.st...@einval.com
>   Mature Sporty Personal
>   More Innovation More Adult
>   A Man in Dandism
>   Powered Midship Specialty

Bug#912846: grub2: stop depending on ttf-dejavu-core

[Daniel Kiper]

Hi,

In general I am OK with the patch. However, I want to ask you to respot
it using "git send-email". Additionally, please add proper commit message
and your SOB.

Daniel

On Sat, May 23, 2020 at 06:02:35PM +0200, Fabian Greffrath wrote:
> Control: forwarded -1 grub-de...@gnu.org
> Control: tags -1 upstream
>
> Hi grub devs,
>
> the attached patch adds /usr/share/fonts/truetype/dejavu to the DejaVu
> font search path in configure.ac. This is the directory where the
> fonts-dejavu-core package in Debian installs its fonts.
>
> Thanks!
>
>  - Fabian
>

> From a696233f623e9c2b480aa3ad10aed537c2890af6 Mon Sep 17 00:00:00 2001
> From: Fabian Greffrath 
> Date: Tue, 19 May 2020 12:19:26 +0200
> Subject: [PATCH] add /u/s/fonts/truetype/dejavu to the DejaVu fonts search
>  paths
>
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index b2576b0..41b8758 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1669,7 +1669,7 @@ fi
>
>  if test x"$starfield_excuse" = x; then
> for ext in pcf pcf.gz bdf bdf.gz ttf ttf.gz; do
> - for dir in . /usr/src /usr/share/fonts/X11/misc 
> /usr/share/fonts/truetype/ttf-dejavu /usr/share/fonts/dejavu 
> /usr/share/fonts/truetype; do
> + for dir in . /usr/src /usr/share/fonts/X11/misc 
> /usr/share/fonts/truetype/dejavu /usr/share/fonts/truetype/ttf-dejavu 
> /usr/share/fonts/dejavu /usr/share/fonts/truetype; do
>  if test -f "$dir/DejaVuSans.$ext"; then
>DJVU_FONT_SOURCE="$dir/DejaVuSans.$ext"
>break 2
> --
> 2.26.2

Bug#891773: [PATCH] ieee1275: Fix crash in of_path_of_nvme when of_path is empty

[Daniel Kiper]

On Thu, Mar 01, 2018 at 08:10:10PM -0700, Eric Snowberg wrote:
> > On Mar 1, 2018, at 3:34 PM, John Paul Adrian Glaubitz 
> >  wrote:
> >
> > The of_path_of_nvme function (commit 2391d57, ieee1275: add nvme
> > support within ofpath) introduced a functional regression:
> >
> > On systems which are not based on Open Firmware but have at
> > least one NVME device, find_obppath will return NULL and thus
> > trying to append the disk name to of_path will result in a
> > crash.
> >
> > The proper behavior of of_path_of_nvme is, however, to just
> > return NULL in such cases, like other users of find_obppath,
> > such as of_path_of_scsi.
> >
> > Signed-off-by: John Paul Adrian Glaubitz 
> > ---
> > grub-core/osdep/linux/ofpath.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/grub-core/osdep/linux/ofpath.c b/grub-core/osdep/linux/ofpath.c
> > index 1c30e7233..61806212e 100644
> > --- a/grub-core/osdep/linux/ofpath.c
> > +++ b/grub-core/osdep/linux/ofpath.c
> > @@ -389,8 +389,11 @@ of_path_of_nvme(const char *sys_devname 
> > __attribute__((unused)),
> > }
> >
> >   of_path = find_obppath (sysfs_path);
> > +
> > +  if (of_path)
> > +strcat (of_path, disk);
> > +
> >   free (sysfs_path);
> > -  strcat (of_path, disk);
> >   return of_path;
> > }
> >
> > --
> > 2.16.2
>
> Reviewed-by: Eric Snowberg 

Applied. Please CC me next time.

Daniel