Dear Ted,
On 16-02-2023 23:24, Theodore Ts'o wrote:
But, if the Debian Release team would like to override my position, my
suggestion would be to just change the default for /etc/mke2fs.conf
for *everyone* running Debian bookworm, and with the understanding
that this will be reverted in Debian
On Fri, Feb 17, 2023 at 09:28:59PM -0500, Theodore Ts'o wrote:
> On Fri, Feb 17, 2023 at 10:34:29PM +0200, Adrian Bunk wrote:
> >
> > The same general problem applies in various "building non-Debian
> > embedded Linux filesystem on Debian" situations where the target
> > chroot does not contain
On Fri, Feb 17, 2023 at 10:34:29PM +0200, Adrian Bunk wrote:
>
> The same general problem applies in various "building non-Debian
> embedded Linux filesystem on Debian" situations where the target
> chroot does not contain mkfs.ext4.
In practice, if the root file system is using ext4, the
On Fri, Feb 17, 2023 at 12:43:01PM -0700, Sam Hartman wrote:
>
> I am not entirely convinced that using current rather than guest
> tools for image building is an anti-pattern. You've been working on
> filesystems for a long time; I've been working on various image
> building projects since my
On Fri, Feb 17, 2023 at 02:08:28PM -0500, Theodore Ts'o wrote:
>...
> So enabling what may be
> convenient, but ultimately an anti-pattern is something that hopefully
> in the long-term Debian should be striving towards. Yes, it's
> annoying and and extra work. So is using build chroots if we
> "Theodore" == Theodore Ts'o writes:
Theodore> So enabling what may be convenient, but ultimately an
Theodore> anti-pattern is something that hopefully in the long-term
Theodore> Debian should be trying to *avoid*.
That's certainly true.
I am not entirely convinced that using
On Fri, Feb 17, 2023 at 02:08:28PM -0500, Theodore Ts'o wrote:
> So enabling what may be
> convenient, but ultimately an anti-pattern is something that hopefully
> in the long-term Debian should be striving towards.
Sigh, I managed to invert the sense of what I was trying to say. This
should
On Fri, Feb 17, 2023 at 08:51:33AM -0800, Russ Allbery wrote:
> Adrian Bunk writes:
>
> > The image creators could just set the features they enable to what they
> > copied from /etc/mke2fs.conf from the target distribution, a label with
> > a timestamp wouldn'tbring much benefit here.
>
>
Adrian Bunk writes:
> The image creators could just set the features they enable to what they
> copied from /etc/mke2fs.conf from the target distribution, a label with
> a timestamp wouldn'tbring much benefit here.
That's a very good point and I'm embarrassed it wasn't immediately obvious
to
On Thu, Feb 16, 2023 at 03:05:06PM -0800, Russ Allbery wrote:
>...
> Each time you change the defaults in a way that could be
> backward-incompatible, you could capture those new defaults in a
> permanently-fixed label of, say, 20230616, which is the defaults on that
> date. Probably in the
On Thu, Feb 16, 2023 at 05:24:04PM -0500, Theodore Ts'o wrote:
>...
> and that moving forward, we make it the image building tools
> problem if they want to support this highly dubious practice of using
> Debian N+X's mkfs to build images for Debian N.
>...
That's what they already have to do for
"Theodore Ts'o" writes:
> As a long-term solution, one could image changing the various image
> creation tools to do something like "mfks.ext4 -T grub2_dumbdown
> /dev/XXX", and then have something like the following in
> /etc/mke2fs.conf:
> [fs_types]
> grub2_dumbdown = {
>
On Thu, Feb 16, 2023 at 11:45:23AM -0800, Russ Allbery wrote:
>
> Yes, I'm probably understating the difficulty of making this change in
> practice inside image building software as it's currently constructed.
>
> My concern about changing mkfs options is that I worry that this would be
> a
On 2023-02-16 11:44:25 -0700, Sam Hartman wrote:
> > "Adrian" == Adrian Bunk writes:
>
> Adrian> On Thu, Feb 16, 2023 at 05:48:22PM +0100, Daniel Leidert wrote:
> >> Am Donnerstag, dem 16.02.2023 um 18:37 +0200 schrieb Adrian Bunk:
> >> > On Wed, Feb 15, 2023 at 12:05:41AM +0100,
On 2023-02-16 07:54:52 -0700, Sam Hartman wrote:
> > "Sebastian" == Sebastian Ramacher writes:
>
> Sebastian> To better understand the impact of this change, I was
> Sebastian> wondering which tools / image builders in the archive
> Sebastian> would be affected by this change.
On 2023-02-16 12:24:01 +0100, Michael Prokop wrote:
> * Sebastian Ramacher [Thu Feb 16, 2023 at 09:09:08AM +0100]:
> > On 2023-02-15 13:17:38 -0700, Sam Hartman wrote:
>
> > > But for example you're not leaving a lot of time for asking programs
> > > like vmdb2 or fai-diskimage to adjust how they
On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote:
>...
> Instead, turning on this feature should be postponed for the next release
> cycle
> where a proper transition can be done.
>...
On Thu, Feb 16, 2023 at 08:02:11PM +0100, Daniel Leidert wrote:
>...
> You completely miss the
> "Adrian" == Adrian Bunk writes:
Adrian> Below is my attempt to give an overview of the situation,
Adrian> feel free to amend/correct if anything is missing or wrong.
I believe your summary is correct and includes the issues I am aware of.
I believe I am following things enough
Replying off list, because I don't think it matters much for the RT
discussion.
> "Russ" == Russ Allbery writes:
Russ> Yes, I'm probably understating the difficulty of making this
Russ> change in practice inside image building software as it's
Russ> currently constructed.
Disclaimer:
Like everyone else except Sebastian who commented in this bug so far,
I am not a member of the release team.
Below is my attempt to give an overview of the situation,
feel free to amend/correct if anything is missing or wrong.
1. Image creation tools need special cases for older
On Thu, Feb 16, 2023 at 08:02:11PM +0100, Daniel Leidert wrote:
>...
> Most server providers have exctly *one*
> rescue system from where I can do a clean installation with deboostrap
> (and that even usually is a Debian). I cannot choose to use one that
> hasn't an e2fsprogs that has this
Sam Hartman writes:
> * Anyone could prepare patches to image building software to use mkfs
> options that will work with bullseye. You could also try to prepare
> patches to run mkfs out of a chroot or container of the guest OS for
> the image. I appreciate Russ strongly favors this
Am Donnerstag, dem 16.02.2023 um 20:10 +0200 schrieb Adrian Bunk:
[..]
> I am currently spending time trying to summarize the situation and open
> questions, and I am a bit underwhelmed by the inaccuracies and lack of
> technical detail in your emails.
Well, I didn't have weeks to prepare. I had
> "Adrian" == Adrian Bunk writes:
Adrian> On Thu, Feb 16, 2023 at 05:48:22PM +0100, Daniel Leidert wrote:
>> Am Donnerstag, dem 16.02.2023 um 18:37 +0200 schrieb Adrian Bunk:
>> > On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote:
>> > > ... > > Reasons: > > ...
On Thu, Feb 16, 2023 at 05:48:22PM +0100, Daniel Leidert wrote:
> Am Donnerstag, dem 16.02.2023 um 18:37 +0200 schrieb Adrian Bunk:
> > On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote:
> > > ...
> > > Reasons:
> > > ...
> > > - - the change makes it impossible to create filesystems
Am Donnerstag, dem 16.02.2023 um 18:37 +0200 schrieb Adrian Bunk:
> On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote:
> > ...
> > Reasons:
> > ...
> > - - the change makes it impossible to create filesystems with this version
> > of
> > e2fsprogs and then run a grub-install from a
On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote:
>...
> Reasons:
>...
> - - the change makes it impossible to create filesystems with this version of
> e2fsprogs and then run a grub-install from a target system that does not
> cope
> with that feature; basically breaking the
On Wed, Feb 15, 2023 at 07:39:28PM -0800, Russ Allbery wrote:
> It had never occurred to me before that the version of the system on which
> I run mke2fs would matter as long as I didn't pick a newer file system
> type (ext5 or something). Now I know! Until today, I had no idea ext4
> even *had*
> "Sebastian" == Sebastian Ramacher writes:
Sebastian> To better understand the impact of this change, I was
Sebastian> wondering which tools / image builders in the archive
Sebastian> would be affected by this change. I've cloned the bug to
Sebastian> vmdb2, but what about
* Sebastian Ramacher [Thu Feb 16, 2023 at 09:09:08AM +0100]:
> On 2023-02-15 13:17:38 -0700, Sam Hartman wrote:
> > But for example you're not leaving a lot of time for asking programs
> > like vmdb2 or fai-diskimage to adjust how they call fsck.
> > If you made this change a few months ago, it
On 2023-02-15 13:17:38 -0700, Sam Hartman wrote:
> > "Theodore" == Theodore Ts'o writes:
> the answer to your "how long" is that packages
> >> should also work with the kernel from the previous and the kernel
> >> from the next Debian release.
>
> Theodore> This isn't a problem
"Theodore Ts'o" writes:
> On Wed, Feb 15, 2023 at 04:06:55PM -0700, Sam Hartman wrote:
>> You argue about shared libraries for non-packaged binaries. I think we
>> mostly don't care about that, and again, I think that's at least a
>> generally recognized thing that came out of our focus on
On Wed, Feb 15, 2023 at 04:06:55PM -0700, Sam Hartman wrote:
>
> You argue about shared libraries for non-packaged binaries.
> I think we mostly don't care about that, and again, I think that's at
> least a generally recognized thing that came out of our focus on
> packages and package
> "Theodore" == Theodore Ts'o writes:
Theodore> On Wed, Feb 15, 2023 at 01:17:38PM -0700, Sam Hartman wrote:
>>
>> I.E. I think your question of "for how long" has a very simple
>> answer based on our history: if we care about stability in this
>> instance it's for +/-1
On Wed, Feb 15, 2023 at 01:17:38PM -0700, Sam Hartman wrote:
>
> I.E. I think your question of "for how long" has a very simple answer
> based on our history: if we care about stability in this instance it's
> for +/-1 Debian release.
>
> I'm struggling trying to figure out whether we should
> "Theodore" == Theodore Ts'o writes:
the answer to your "how long" is that packages
>> should also work with the kernel from the previous and the kernel
>> from the next Debian release.
Theodore> This isn't a problem with the kernel.
I don't think that was Adrian's point.
I
On Wed, Feb 15, 2023 at 11:47:08AM +0200, Adrian Bunk wrote:
>
> For normal library dependencies
> Depends: libc6 (>= 2.34)
> will do the right thing automatically.
Sure, but dependencies only apply if you are using building packages.
If you are not building packages, but just moving binaries
On Tue, Feb 14, 2023 at 08:46:53PM -0500, Theodore Ts'o wrote:
>...
> I will draw the analogy of building a program which links against
> glibc for Bookworm resulting in a binary that will not run on Buster.
> We expect that, and we tell people to use build chroots. This is not
> something which
There is more about this in the referenced bugs, but I dispute
Daniel's characterization of the issue.
I will draw the analogy of building a program which links against
glibc for Bookworm resulting in a binary that will not run on Buster.
We expect that, and we tell people to use build chroots.
Package: release.debian.org
Severity: serious
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
A week ago, Theodore Ts'o uploaded e2fsprogs 1.47.0 into Debian unstable. This
version contains a unannounced change that basically breaks grub2 (and
grub-install). This issue has been reported as
40 matches
Mail list logo
