On Wed, Feb 08, 2023 at 11:39:48AM +0100, Cyril Brulebois wrote:
>
> Spotted via debian-installer tests: grub-install fails with “unknown
> filesystem” when trying to run a simple `grub-install /dev/sda` with
> an all-default installation.
The fix for this issue landed in the grub2 repository on June 11,
2021:
commit 7fd5feff97c4b1f446f8fcf6d37aca0c64e7c763
Author: Javier Martinez Canillas <javi...@redhat.com>
Date: Fri Jun 11 21:36:16 2021 +0200
fs/ext2: Ignore checksum seed incompat feature
This incompat feature is used to denote that the filesystem stored its
metadata checksum seed in the superblock. This is used to allow tune2fs
changing the UUID on a mounted metdata_csum filesystem without having
to rewrite all the disk metadata. However, the GRUB doesn't use the
metadata checksum at all. So, it can just ignore this feature if it
is enabled. This is consistent with the GRUB filesystem code in general
which just does a best effort to access the filesystem's data.
The checksum seed incompat feature has to be removed from the ignore
list if the support for metadata checksum verification is added to the
GRUB ext2 driver later.
Suggested-by: Eric Sandeen <esand...@redhat.com>
Suggested-by: Lukas Czerner <lczer...@redhat.com>
Signed-off-by: Javier Martinez Canillas <javi...@redhat.com>
Reviewed-by: Lukas Czerner <lczer...@redhat.com>
Reviewed-by: Daniel Kiper <daniel.ki...@oracle.com>
Unfortunately, this just missed the last grub release, since grub 2.06
was tagged on June 8, 2021. <Sigh>
There are two ways we can fix this. One is we can disable the
checksum seed feature in the Debian release of mke2fs.conf. Or we can
land this above-mentioned commit into the grub2 package. Since the
hard freeze is almost upon us, I'm happy to handle this either way.
If we *are* going to backport some grub2 patches, may also make a plug
for this one, which is also in the upstream grub2 git repo:
commit 2e9fa73a040462b81bfbfe56c0bc7ad2d30b446b
Author: Theodore Ts'o <ty...@mit.edu>
Date: Tue Aug 30 22:41:59 2022 -0400
fs/ext2: Ignore the large_dir incompat feature
Recently, ext4 added the large_dir feature, which adds support for
a 3 level htree directory support.
The GRUB supports existing file systems with htree directories by
ignoring their existence, and since the index nodes for the hash tree
look like deleted directory entries (by design), the GRUB can simply do
a brute force O(n) linear search of directories. The same is true for
3 level deep htrees indicated by large_dir feature flag.
Hence, it is safe for the GRUB to ignore the large_dir incompat feature.
Fixes: https://savannah.gnu.org/bugs/?61606
Signed-off-by: Theodore Ts'o <ty...@mit.edu>
Reviewed-by: Daniel Kiper <daniel.ki...@oracle.com>
Otherwise, what can happen is that users may choose to enable the
large_dir feature, and if they do it on the root file system, they can
end up making their system unbootable. I've had some Arch and Gentoo
users get bitten by this....
> The “e2fsprogs gets a new upstream release and new flags” hypothesis was
> confirmed by building d-i with e2fsprogs-udeb_1.46.6-1_amd64.udeb
> rebranded as 1.48, which made the problem disappear.
Alternatively, I can apply this patch to e2fsprogs:
diff --git a/misc/mke2fs.conf.in b/misc/mke2fs.conf.in
index b7fc95df7..ff47bdb39 100644
--- a/misc/mke2fs.conf.in
+++ b/misc/mke2fs.conf.in
@@ -11,7 +11,7 @@
features = has_journal
}
ext4 = {
- features =
has_journal,extent,huge_file,flex_bg,metadata_csum,metadata_csum_seed,64bit,dir_nlink,extra_isize,orphan_file
+ features =
has_journal,extent,huge_file,flex_bg,metadata_csum,64bit,dir_nlink,extra_isize,orphan_file
}
small = {
blocksize = 1024
Which will kind of suck, since the reason for enabling
metadata_csum_seed is to be able to reliably change the label and file
system uuid on a mounted file system, which matters for certain cloud
workloads. Specifically, for Google's Cloud Optimized OS, which
attempts to update the file system UUID and resize the root file
system to fit the size of the cloud-emulated block device on two
separate, racing systemd unit files. This which works 99.9% of the
time, but when you launch a huge number of cloud images, that last
0.1% of the time is really noticeable.
But that's for COS; if we have to disable the metadata_csum_seed
feature on Debian file systems, I can live with that.
Cheers,
- Ted
