Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
control: tags -1 patch fixed-upstream
On 2023-10-02 17:12:53 [+0200], Julian Andres Klode wrote:
> Being subscribed to the mailing list, grabbing the patch and applying
> it and shipping it isn't hard, but if you were wondering why it's
There are different views here. But Daniel was nice enough to Cc me so I
had all I needed to test it.
> not fixed, it hasn't been merged or received a Reviewed-By yet;
> and I don't really want to carry file system (parser) patches
> outside of upstream for security reasons, needing separate
> revocation if that is broken.
The following patches were merged into grub upstream:
ad7fb8e2e02bb ("fs/xfs: Incorrect short form directory data boundary check")
07318ee7e11a0 ("fs/xfs: Fix XFS directory extent parsing")
would you mind to cherry pick those for the next upload?
Sebastian
Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
Hi all, Reading the thread starting at [1] it seems that upstream there's convergence on the patch? Can we move this bug forward in Debian too? Paul [1] https://lists.gnu.org/archive/html/grub-devel/2023-10/msg00150.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
On Mon, Oct 02, 2023 at 16:51:30 +, Lidong Chen wrote: > The changes for the extent parsing looks good to me. But, I am not sure about > this change: > > > - if (filename + direntry->len - 1 > (char *) tail) > > + if (filename + direntry->len - 1 > (char *) end) > > Looking at the grub_xfs_next_de(), should the ‘+1’ be ‘+3’? > If you don't mind, I think this would be better discussed on grub-devel. I only posted the update here because my original patch was linked here. -- Jon Doge Wrangler X(7): A program for managing terminal windows. See also screen(1) and tmux(1).
Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
The changes for the extent parsing looks good to me. But, I am not sure about
this change:
> - if (filename + direntry->len - 1 > (char *) tail)
> + if (filename + direntry->len - 1 > (char *) end)
Looking at the grub_xfs_next_de(), should the ‘+1’ be ‘+3’?
grub_xfs_next_de(struct grub_xfs_data *data, struct grub_xfs_dir2_entry *de)
{
int size = sizeof (struct grub_xfs_dir2_entry) + de->len + 2 /* Tag */;
if (data->hasftype)
size++; /* File type */
return (struct grub_xfs_dir2_entry *)(((char *)de) + ALIGN_UP(size, 8));
}
Thanks,
Lidong
On Sep 27, 2023, at 6:45 PM, Jon DeVree wrote:
On Fri, Sep 15, 2023 at 23:43:28 +0200, Sebastian Andrzej Siewior wrote:
there's now a patch from Jon DeVree upstream, which might fix this for
you. Is it possible for you to test his patch?
https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00059.html
Yes it sovles the issue, the box boots.
I posted an updated v3 version of the patch:
https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00110.html
--
Jon
Doge Wrangler
X(7): A program for managing terminal windows. See also screen(1) and tmux(1).
Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
On Oct 2, 2023, at 9:51 AM, lidong.c...@oracle.com
wrote:
The changes for the extent parsing looks good to me. But, I am not sure about
this change:
> - if (filename + direntry->len - 1 > (char *) tail)
> + if (filename + direntry->len - 1 > (char *) end)
Sorry, I meant the change in v3:
- if (filename + direntry->len - 1 > (char *) tail)
+ if (filename + direntry->len + 1 > (char *) end)
Looking at the grub_xfs_next_de(), should the ‘+1’ be ‘+3’?
grub_xfs_next_de(struct grub_xfs_data *data, struct grub_xfs_dir2_entry *de)
{
int size = sizeof (struct grub_xfs_dir2_entry) + de->len + 2 /* Tag */;
if (data->hasftype)
size++; /* File type */
return (struct grub_xfs_dir2_entry *)(((char *)de) + ALIGN_UP(size, 8));
}
Thanks,
Lidong
On Sep 27, 2023, at 6:45 PM, Jon DeVree wrote:
On Fri, Sep 15, 2023 at 23:43:28 +0200, Sebastian Andrzej Siewior wrote:
there's now a patch from Jon DeVree upstream, which might fix this for
you. Is it possible for you to test his patch?
https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00059.html
Yes it sovles the issue, the box boots.
I posted an updated v3 version of the patch:
https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00110.html
--
Jon
Doge Wrangler
X(7): A program for managing terminal windows. See also screen(1) and tmux(1).
Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
On Fri, Sep 29, 2023 at 10:36:03PM +0200, Sebastian Andrzej Siewior wrote: > On 2023-09-27 21:45:03 [-0400], Jon DeVree wrote: > > I posted an updated v3 version of the patch: > > > > https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00110.html > > Just rebuilt grub with v3 of the patch and I can confirm that it works. > Thank you. > > Referencing the message-id or the link to lore > https://lore.kernel.org/all/20230928004354.32685-1-n...@vault24.org > > makes it easier to grab the patch. The GNU list archive contains html > encoding among other things which make it imposible… Being subscribed to the mailing list, grabbing the patch and applying it and shipping it isn't hard, but if you were wondering why it's not fixed, it hasn't been merged or received a Reviewed-By yet; and I don't really want to carry file system (parser) patches outside of upstream for security reasons, needing separate revocation if that is broken. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
On 2023-09-27 21:45:03 [-0400], Jon DeVree wrote: > I posted an updated v3 version of the patch: > > https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00110.html Just rebuilt grub with v3 of the patch and I can confirm that it works. Thank you. Referencing the message-id or the link to lore https://lore.kernel.org/all/20230928004354.32685-1-n...@vault24.org makes it easier to grab the patch. The GNU list archive contains html encoding among other things which make it imposible… Sebastian
Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
On Fri, Sep 15, 2023 at 23:43:28 +0200, Sebastian Andrzej Siewior wrote: > > there's now a patch from Jon DeVree upstream, which might fix this for > > you. Is it possible for you to test his patch? > > > > https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00059.html > > Yes it sovles the issue, the box boots. > I posted an updated v3 version of the patch: https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00110.html -- Jon Doge Wrangler X(7): A program for managing terminal windows. See also screen(1) and tmux(1).
Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
On 2023-09-15 15:51:51 [+0200], Felix Zielcke wrote: > Hi Sebastian, Hi Felix, > there's now a patch from Jon DeVree upstream, which might fix this for > you. Is it possible for you to test his patch? > > https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00059.html Yes it sovles the issue, the box boots. Sebastian
Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
Am Samstag, dem 09.09.2023 um 15:41 +0200 schrieb Sebastian Andrzej Siewior: > 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'. > Hi Sebastian, there's now a patch from Jon DeVree upstream, which might fix this for you. Is it possible for you to test his patch? https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00059.html
Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
Funny, I had this problem (unbootable system, couldn't find net.mod even though it was there ls on the grub_rescue prompt didn't see it) with a XFS V4 partition, and rebuilding that as V5 and copying everything over seemed to have fixed it... but maybe I just got lucky on the first try. Interestingly, once I've got grub actually able to load normal.mod it doesn't seem to have problems finding any files on the V4 partition. For the sake of comparison here's are the full details of the two (lvm) volumes in question: The partition that initially broke w/2.12~rc1-9: # xfs_db -r /dev/mapper/S-root xfs_db> version versionnum [0xb4b4+0xa] = V4,NLINK,DIRV2,ATTR,ALIGN,LOGV2,EXTFLG,MOREBITS,ATTR2,LAZYSBCOUNT # xfs_info /dev/mapper/S-root meta-data=/dev/mapper/S-root isize=256agcount=4, agsize=524288 blks = sectsz=512 attr=2, projid32bit=0 = crc=0finobt=0, sparse=0, rmapbt=0 = reflink=0bigtime=0 inobtcount=0 nrext64=0 data = bsize=4096 blocks=2097152, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=0 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 And the partition that seems to be working OK (but maybe it's just luck?): # xfs_db -r /dev/mapper/S-root23 xfs_db> version versionnum [0xb4a5+0x18a] = V5,NLINK,DIRV2,ALIGN,LOGV2,EXTFLG,MOREBITS,ATTR2,LAZYSBCOUNT,PROJID32BIT,CRC,FTYPE,FINOBT,SPARSE_INODES,REFLINK,INOBTCNT,BIGTIME # xfs_info /dev/mapper/S-root23 meta-data=/dev/mapper/S-root23 isize=512agcount=4, agsize=524288 blks = sectsz=512 attr=2, projid32bit=1 = crc=1finobt=1, sparse=1, rmapbt=0 = reflink=1bigtime=1 inobtcount=1 nrext64=0 data = bsize=4096 blocks=2097152, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=16384, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 Do we know if the breakage related to bigtime feature? -- Jamie Heilman http://audible.transient.net/~jamie/
Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
On 2023-09-12 15:43:34 [+0200], Daniel Kiper wrote: > Hey, Hi, > Adding Lidong... > > Sebastian, Lidong is working on a fix for this issue. ach great. > Lidong, please keep Sebastain in the loop. > > Daniel Sebastian
Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
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#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
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
