search

ventoy / Ventoy

A new bootable USB solution.
https://www.ventoy.net
GNU General Public License v3.0
61.68k stars 4.01k forks source link

[issue]: Unable to detect XFS partition (F2) #2494

Open polarathene opened 1 year ago

polarathene commented 1 year ago

Official FAQ

Ventoy Version

1.0.94

What about latest release

Yes. I have tried the latest release, but the bug still exist.

Try alternative boot mode

No. I didn't try these alternative boot modes.

BIOS Mode

UEFI Mode

Partition Style

GPT

Disk Capacity

500GB

Disk Manufacturer

Seagate

Image file checksum (if applicable)

None

Image file download link (if applicable)

No response

What happened?

Goal

I would like to boot an image from a separate partition, it's formatted as XFS.

An older Ventoy install can do this, but my newer one cannot. Possibly XFS filesystem was created with incompatibility for older kernel XFS drivers, may also affect Ventoy?

Background

Ventoy is installed to external USB SSD (Segate Firecuda 500GB) disk with Ventoy partition (part 1) as exFAT, there is also NTFS (VHD files) and XFS (vDisk .vtoy files) partitions added into the reserved space after Ventoy install.

I installed Ventoy to this disk when Ventoy 1.0.78 was the new release. I would have installed it from Windows. Everything worked fine except the XFS partition was not accessible.

Today I updated via the Linux GUI app with 1.0.94 release. No improvement. Deleted XFS partition, created new XFS partition and exFAT partition, copied .vtoy image to both. Only new exFAT partition was detected by Ventoy F2 menu, XFS missing.

On another disk with BTRFS partition, Ventoy would detect this (but is not supported).

Additional information

I have an older Ventoy install on a Samsung T7 500GB USB disk. It has a separate XFS partition as well but can detect and boot from XFS without issue. This was created around Feb 2022.

I have also noticed some older systems cannot mount XFS from newer systems. Perhaps an incompatibility introduced when XFS partition is created with newer kernels, as updating the older systems kernel it was able to mount my newer XFS partitions.

Ventoy uses GRUB, perhaps the XFS driver also has this issue and needs to be updated?

Environment

The current environment for Ventoy is Windows 11 host with VMWare Workstation Player 17.0.2, VM guest CachyOS (ArchLinux) with 6.4 kernel (VMX file modified to support EFI at OS install). Machine is laptop: ASUS Zephyrus G14 (2023).

Same experience booting Ventoy from UEFI of the laptop directly, or booting Ventoy from the VM guest UEFI.

Presumably, if I connect my older Ventoy (Samsung T7) disk, the new Ventoy (Seagate Firecuda) disk will detect the XFS partition on it and be able to access it.

polarathene commented 1 year ago

Confirmed (bigtime=1 not supported)

Verified that this is an issue with new XFS defaults for mkfs.xfs when creating XFS partition, since version 5.15 (April 2022).

$ xfs_info /old-xfs-partition-that-works

meta-data=/dev/sdb3              isize=512    agcount=4, agsize=19200000 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=0 inobtcount=0 nrext64=0
data     =                       bsize=4096   blocks=76800000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=37500, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

bigtime=1 and inobtcount=1 are new defaults since Kernel 5.10 which differ from my old XFS partition shown above.

bigtime=1 is what was preventing Ventoy from displaying the XFS partition to access in F2 menu. While with only inobtcount=1 I could still access the XFS partition still and load an ISO or .vtoy image.

I reformatted the XFS partition (/dev/sdx42) without bigtime feature enabled: sudo mkfs.xfs -m bigtime=0 -f /dev/sdx42, and now Ventoy is happy, detects the XFS partition and can successfully boot an ISO or vDisk image.

References

Bug report upstream: https://bugzilla.redhat.com/show_bug.cgi?id=1977236#c8

An answer stating bigtime=1 became a default mkfs.xfs option in 5.15 (April 2022). ArchWiki XFS page also confirms Kernel 5.10 (Dec 2020) introduced bigtime=1, which became default with xfsprogs 5.15 (April 2022).

In mid 2021, there was some patches for this sent to GRUB (Commit 1 made it into Grub 2.06 (June 2021), Commit 2 should be part of Grub 2.12).

Perhaps Ventoy would have to update to newer GRUB 2.12? (upcoming release that represents 2 years of development since Grub 2.06, should include the XFS fix?). I am not sure how likely that is, as I get impression that Ventoy has been patching GRUB quite a bit?

UPDATE: I see Ventoy is presently based off GRUB 2.04, so definitely missing this support 😅

JayaswalPrateek commented 1 week ago

I think @ventoy should consider adding support for bigtime=1 for future proofing XFS partitions beyond 2038.

It seems like it's still not supported.

If immediately bumping up to GRUB 2.12 isn't feasible at the moment, maybe provide an experimental option to build it with GRUB 2.12 which is needed for booting XFS partitions formatted after April 2022. If possible the necessary commits for booting XFS can also be back ported.

Otherwise the claim

From Ventoy-1.0.11, you can reformat the 1st partition with other filesystem, exFAT/FAT32/NTFS/UDF/XFS/Ext2/Ext3/Ext4 are supported.

Is misleading in https://www.ventoy.net/en/doc_disk_layout.html And so is

You can reformat the 1st partition with other filesystem, now exFAT/FAT32/NTFS/UDF/XFS/Ext2/Ext3/Ext4 are supported.

In https://www.ventoy.net/en/doc_disk_layout_gpt.html

polarathene commented 1 week ago

I assume that perhaps the project is perhaps heavily patched GRUB by this point, and that might be problematic for them to rebase to newer GRUB, so that may never happen. They would likely have to port the changes over manually.

It should be possible for UEFI image to boot and perform similar functionality AFAIK. There are EFI images for filesystem drivers like XFS, been a while since I thought about this, but an alternative might land some day that is simpler to keep modern 😅

JayaswalPrateek commented 1 week ago

I tried formatting with bigtime=0 but still couldn't make it work! I ran sudo mkfs.xfs -b size=4K -m bigtime=0 -m crc=1 -m finobt=1 -m inobtcount=1 -m rmapbt=0 -m reflink=0 -d agcount=8 -i size=1024 -i attr=2 -i sparse=1 -i align=1 -K -l lazy-count=1 -s size=1024 /dev/sda1 -f and here's the output for sudo xfs_info /dev/sda1:

meta-data=/dev/sda1              isize=1024   agcount=8, agsize=1787296 blks
         =                       sectsz=1024  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=0    bigtime=0 inobtcount=1 nrext64=1
data     =                       bsize=4096   blocks=14298368, 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=1024  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Any idea what's causing the issue?

UPDATE: Apart from bigtime=0, you also need nrext64=0 for XFS to boot properly. By default both are set to 1 and need to be explicitly disabled by setting them to 0. This seems to be working for me. I used sudo mkfs.xfs -b size=4K -m bigtime=0 -m crc=1 -m finobt=1 -m inobtcount=1 -m rmapbt=0 -m reflink=0 -d agcount=8 -i size=1024 -i nrext64=0 -i attr=2 -i spar se=1 -i align=1 -K -l lazy-count=1 -s size=1024 /dev/sdaX 

meta-data=/dev/sda1              isize=1024   agcount=8, agsize=1787296 blks
         =                       sectsz=1024  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=0    bigtime=0 inobtcount=1 nrext64=0
data     =                       bsize=4096   blocks=14298368, 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=1024  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0