Re: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Cyril Brulebois]

Theodore Ts'o  (2023-02-10):
> But that problem has already been solved by cloning the bug back to
> e2fpsrogs (#1030939) which will prevent e2fsprogs from transitioning
> to testing, no?  So what's the problem.

I never said there was a problem with the current state of things
(indeed, that's one of the two soltions I described as being equally
fine with me).

Instead, I've explained why your suggested “solution” wouldn't help,
with some context since you seemed unconvinced by previous answers from
others.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Theodore Ts'o]

On Fri, Feb 10, 2023 at 08:31:04AM +0100, Cyril Brulebois wrote:
> > Holding back file system development because grub2 uptsream is super
> > slow doesn't seem like a reasonable way forward, so I really don't
> > want to set this precedent.
> 
> The Bookworm freeze has started, we need to be able to install stuff, so
> we need a solution for the grub2/e2fsprogs situation *now*.
> 
> I really don't care about “setting a precedent”.

But that problem has already been solved by cloning the bug back to
e2fpsrogs (#1030939) which will prevent e2fsprogs from transitioning
to testing, no?  So what's the problem.

The fact that grub2 upstream is super-slow in doing releases is
already a pain in *ass that has caused much pain over the years.
Adding a conflict just adds more pain, without adding any additional
benefit.  So what's the point?

 - Ted

Re: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Cyril Brulebois]

Theodore Ts'o  (2023-02-09):
> On Thu, Feb 09, 2023 at 06:55:08PM +0100, Sven Joachim wrote:
> > That is not going to help, because IIUC grub-install is run from the
> > target system that you are installing, and there is no
> > grub2-common-udeb.
> 
> Right, but if the conflict in e2fsprogs-udeb prevents the installer
> from pulling in an overly new version of e2fsprogs-udeb, that woul be
> sufficient, no?

As Sven rightfully pointed out, there are two different environments:
 - installer, with anna and udebs (but that would be the same with apt
   and debs);
 - target.

There are no connections between both environments, so you can't have
package relationships in a cross-environment manner.

The installer uses whatever was available at build-time, or for
components that aren't built-in, whatever is available on the
installation image, or on the mirror. There's no “pulling in an overly
new version” that can be avoided. There's *one* version in the suite,
that's the one that's getting used, there's no alternative.

TL;DR: Some Conflicts, even if that were possible (which it is not)
   wouldn't achieve anything (except probably not offering any ext*
   option at the partioning step — not a huge win).

> The reason why I really don't want to add the conflicts with e2fsprogs
> 1.47 is because for people who are using sid, there is aboslutely
> nothing wrong with installing e2fsprogs 1.47.  It's only if they use
> the installer that sucks in e2fsprogs that there's a problem --- it's
> not an inherent conflict with grub per se.  If it were, then we
> shouldn't allow installation of e2fsprogs 1.46 because grub2 upstream
> is painfully slow in putting out releases --- and that's not
> reasonable.

*sigh* @ the heavy finger pointing in various parts of your mail.

> Now, what I *could* do is change the mke2fs.conf in e2fsprogs-udeb to
> remove the default use of the csum-seed feature  but is it worth
> it?  Hopefully the new version of grub2 will come out soon, at which
> point I would then need to revert the hacked mke2fs.conf --- and your
> dup'ing this bug should prevent the installer from picking up
> e2fsprogs 1.47 until the new version of grub gets released.

Right now what I'm most concerned with is getting grub2 fixed in
unstable, candidate for migration into testing. Until that happens,
e2fsprogs must be kept out of testing, so that the installer cannot get
a too-new e2fsprogs with a too-old grub2.

Whether we introduce a relationship between both packages making britney
wait on grub2's being ready to allow e2fsprogs to migrate alongside it,
or we keep an RC bug on e2fsprogs to keep it out of testing until grub2
gets fixed and migrated into testing… doesn't matter much to me.


I'll word it differently because I'd like to avoid more mails on this
thread: The installer pulls components for the target system from a
single distribution, there's no set of existing packages that can be
kept around (as that would be the case for existing systems using
testing or unstable), so we need packages in the distribution being
installed to be consistent.

Right now: unstable is broken; testing isn't.


[ snip stuff about grub design ]

> Holding back file system development because grub2 uptsream is super
> slow doesn't seem like a reasonable way forward, so I really don't
> want to set this precedent.

The Bookworm freeze has started, we need to be able to install stuff, so
we need a solution for the grub2/e2fsprogs situation *now*.

I really don't care about “setting a precedent”.

[ snip brainstorming ]


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Bastian Blank]

Hi

On Thu, Feb 09, 2023 at 03:16:15PM -0500, Theodore Ts'o wrote:
> Right, but if the conflict in e2fsprogs-udeb prevents the installer
> from pulling in an overly new version of e2fsprogs-udeb, that woul be
> sufficient, no?

No, it does not.  Conflicts have undefined behaviour for udebs.

Bastian

-- 
There are certain things men must do to remain men.
-- Kirk, "The Ultimate Computer", stardate 4929.4

Re: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Theodore Ts'o]

On Thu, Feb 09, 2023 at 06:55:08PM +0100, Sven Joachim wrote:
> >>
> >> Thanks from me as well :-).  To prevent e2fsprogs from migrating to
> >> testing before grub2 and breaking d-i, I am reassigning a copy of this
> >> bug back to e2fsprogs.  It may be closed once grub2 2.06-8 enters
> >> Bookworm.   Perhaps it would also be a good idea to add a versioned
> >> "Breaks: grub2-common (<< 2.06-8~)" to e2fsprogs.
> >
> > Perhaps we could just add a "Breaks: grub2-common (<< 2.06-8~)" to
> > e2fsprogs-udeb?
> 
> That is not going to help, because IIUC grub-install is run from the
> target system that you are installing, and there is no
> grub2-common-udeb.

Right, but if the conflict in e2fsprogs-udeb prevents the installer
from pulling in an overly new version of e2fsprogs-udeb, that woul be
sufficient, no?

After all, you can install e2fsprogs 1.47, and install a newer version
of grub, and there is no problem --- unless you enable the the
csum-seed function on an already installed system.  And you can't do
that, because you it's an incompat feature.

OTOH, with e2fsprogs 1.46 you can *ready* run the command "tune2fs -O
large_dir /dev/root" on a running system, and then when you reboot,
the system won't come back, because grub will see the large_dir
feature and freak out (unecessarily).  But adding an conflict with
1.46 and grub makes no sense, since it's not _that_ likely that user
will deploy that particular foot-gun.  (It happens with Arch and
Gentoo, but those users tend to be much more adventurous, aided and
abetted by Wiki pages that encourage users to help kernel developers
beta test new features.  :-)

The reason why I really don't want to add the conflicts with e2fsprogs
1.47 is because for people who are using sid, there is aboslutely
nothing wrong with installing e2fsprogs 1.47.  It's only if they use
the installer that sucks in e2fsprogs that there's a problem --- it's
not an inherent conflict with grub per se.  If it were, then we
shouldn't allow installation of e2fsprogs 1.46 because grub2 upstream
is painfully slow in putting out releases --- and that's not
reasonable.

Now, what I *could* do is change the mke2fs.conf in e2fsprogs-udeb to
remove the default use of the csum-seed feature  but is it worth
it?  Hopefully the new version of grub2 will come out soon, at which
point I would then need to revert the hacked mke2fs.conf --- and your
dup'ing this bug should prevent the installer from picking up
e2fsprogs 1.47 until the new version of grub gets released.

I'll note that grub is trying to use an independent implementation of
ext4, as opposed to using the upstream libraries such as libext2 for
ext2/3/4 and libxfs for XFS, combined with grub's very slow release
cycle, means that this kind of thing is going to be happening a *lot*.
It's something that I and Darrick Wong (the XFS maintainer) have
kvetched about a number of times on our weekly conference calls.

For example, recent grub commits that impact XFS that aren't in 2.06
include:

commit a4b495520e4dc41a896a8b916a64eda9970c50ea
Author: Erwan Velu 
Date:   Wed Aug 25 15:31:52 2021 +0200

fs/xfs: Fix unreadable filesystem with v4 superblock

The commit 8b1e5d193 (fs/xfs: Add bigtime incompat feature support)
introduced the bigtime support by adding some features in v3 inodes

Holding back file system development because grub2 uptsream is super
slow doesn't seem like a reasonable way forward, so I really don't
want to set this precedent.

Thinking about this some more, I'd much rather have some kind of
explicit scheme, such as:

   mkfs.xfs -T grub2-dumbdown /dev/XXX

Which disables various new file system features that aren't yet
supported by grub, but which users might very well want to use on
non-boot disks.  

This could be done by doing something as simple as adding to mke2fs.conf:

[fs_types]
 grub2-dumbdown = {
features = ^large_dir,^metadata_csum
 }

Then we could teach the Debian installer to use the file system usage
type "grub2-dumbdown".

Of course, moving forward we'd have to update mke2fs.conf as grub
finally learns new features, and since mke2fs.conf is a config file,
people would have to edit it by hand post-install if they have
customized it in any way.  Unless we add the above in
/etc/mke2fs.conf.d/grub2-dumbdown, and then teach mke2fs to understand
the /etc/mke2fs.conf.d directory...

  - Ted

Re: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Sven Joachim]

[Switching over to the cloned bug.]

On 2023-02-09 12:31 -0500, Theodore Ts'o wrote:

> On Thu, Feb 09, 2023 at 06:04:23PM +0100, Sven Joachim wrote:
>>
>> Thanks from me as well :-).  To prevent e2fsprogs from migrating to
>> testing before grub2 and breaking d-i, I am reassigning a copy of this
>> bug back to e2fsprogs.  It may be closed once grub2 2.06-8 enters
>> Bookworm.   Perhaps it would also be a good idea to add a versioned
>> "Breaks: grub2-common (<< 2.06-8~)" to e2fsprogs.
>
> Perhaps we could just add a "Breaks: grub2-common (<< 2.06-8~)" to
> e2fsprogs-udeb?

That is not going to help, because IIUC grub-install is run from the
target system that you are installing, and there is no
grub2-common-udeb.

> After all, it's not that e2fsprogs breaks
> grub2-common, per se, unless the *installer* happens to to use << grub
> 2.06-8~ and e2fsprogs 1.47.0-1.

I was also thinking of the cases where the /boot filesystem is
recreated, e.g. when transferring the installation to a different disk.

Cheers,
   Sven