Announcement

Collapse
No announcement yet.

Debian 12.3 Delayed Due To An EXT4 Data Corruption Bug Being Addressed

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by V1tol View Post
    Rolling distro - bad, it has new possibly broken code.
    Stable distro - bad, they backport broken code.

    Only Windows is stable buggy, use that
    Yeah, no hate on stable distros like Debian Stable, but the mantra among those users is always that major regressions like this don't happen on stable distros, only on rolling releases.

    Comment


    • #22
      Originally posted by RealNC View Post

      Ext4 is fine, Debian just happened to break it.
      The article title is somewhat misleading. This isn't a Debian bug. It's not some special kernel build config they use that caused the problem. 6.1.64 / 6.1.65 straight from kernel.org suffers from this ext4 data corruption bug. Debian just happened to be using those kernel versions in an upcoming point release update.

      Comment


      • #23
        Originally posted by cynic View Post

        man, I was baking my own kernel when you were still in the cradle!

        fact is: no filesystem is safe, even with stable distro as Debian.

        and no, it doesn't matter if it is a bug of the fs itself or a wrong backport of the distro.


        Trolling much, old 70 years guy?? (assuming you were at least 10 years old when you compille your first unix kernel... oh yeah!! that's 1963, no kernel source or even unix back then! So i assume you compille using the nice punch-cards do you? (hint: I didn't, but i saw the machines in their final days // another hint ".dir 4").

        For the filesystem issue: Debian and Red Hat kernel maintainers (not the coders) are known to pick patches from RC's and backport to their stable branches when the fix have to be tested. Water is wet.

        Reading the mail, it seems the patch was picked by mistake, and thus, the kernel was boorked and nobody noticed until it was too late.

        So it's a Debian problem, in the end, not a Kernel people problem, so the damage is only in the Debian camp. Go figure.



        Comment


        • #24
          Originally posted by OneTimeShot View Post

          LOL Back at you I guess. I regularly work closely with Microsoft devs to address issues. It's called a support contract, which you get with a Microsoft support agreement. It includes 20 support incidents a year where you talk directly to the engineers working on software an area.

          Guess what: it's not just RedHat employees who are paid to fix bugs. Microsoft employees do it too.
          And so? It's not only Red Hat, but dozens of others including Linux kernel developers. You can have direct contact with core Linux kernel developers in case of issue (not only 20 times per year). I once had unbootable system with some Linux-rc version. And guess what? The issue was fixed in two days. Linux ecosystem development power is levels ahead of Microsoft or Apple. I wouldn't be surprised if some of the viruses from XP were still working in Windows 11. I'll have to check, because it will tell a lot about their responsibility. I've got the feeling Microsoft is only putting additional layers on top of the leaky operating system.

          Btw. another thing is there should be 'stable - security patches only' branch. There are sometimes hundreds of patches being backported into stable which rises concerns among some users.. I'm not sure if it was the same in the past.
          Last edited by Volta; 10 December 2023, 12:11 PM.

          Comment


          • #25
            Originally posted by stargeizer View Post

            So it's a Debian problem, in the end, not a Kernel people problem, so the damage is only in the Debian camp. Go figure.
            It is a kernel people / process problem. The bug exists in 6.1.64 and 6.1.65 straight from kernel.org. Anybody using / shipping those versions are impacted. Debian is only noteworthy because they happened to be preparing a point release update that includes one of those kernel versions.

            Comment


            • #26
              Originally posted by Vistaus View Post

              Yeah, no hate on stable distros like Debian Stable, but the mantra among those users is always that major regressions like this don't happen on stable distros, only on rolling releases.
              12.3 was delayed rather than damaging anyone's data precisely *because* Debian is not a rolling release distro. I think it further strengthens the argument on which approach I would rather choose for production.

              Comment


              • #27
                What should I do if I'm already running this kernel on a vserver?
                bookworm-backports would have kernel 6.5.10, but other than that?

                Comment


                • #28
                  Originally posted by kpedersen View Post

                  12.3 was delayed rather than damaging anyone's data precisely *because* Debian is not a rolling release distro. I think it further strengthens the argument on which approach I would rather choose for production.
                  While I agree that frequency wise you are more likely to run into problems with rolling releases, your point isn't really valid here. 12.3 ISO image generation was delayed. 6.1.64 did make it out to users.

                  linux-image-6.1.0-14-amd64/stable 6.1.64-1 amd64
                  Linux 6.1 for 64-bit PCs (signed)


                  Comment


                  • #29
                    Originally posted by Volta View Post

                    And so? It's not only Red Hat, but dozens of others including Linux kernel developers. You can have direct contact with core Linux kernel developers in case of issue (not only 20 times per year). I once had unbootable system with some Linux-rc version. And guess what? The issue was fixed in two days. Linux ecosystem development power is levels ahead of Microsoft or Apple. I wouldn't be surprised if some of the viruses from XP were still working in Windows 11. I'll have to check, because it will tell a lot about their responsibility. I've got the feeling Microsoft is only putting additional layers on top of the leaky operating system.

                    Btw. another thing is there should be 'stable - security patches only' branch. There are sometimes hundreds of patches being backported into stable which rises concerns among some users.. I'm not sure if it was the same in the past.
                    Where did I say otherwise? Didn't you say Microsoft don't provide any support and everything I wrote was garbage? I can get a Microsoft engineer on the phone when needed, just like I can a Red Hat engineer. I can also go on public forums and get help for any platform from Atari 2600 to Nvidia T4s just like anyone else...

                    As for a "leaky operating systems"... Well I can only sat that people who speak in absolutes and generalities are guaranteed to be wrong.

                    Comment


                    • #30
                      Originally posted by stargeizer View Post

                      Trolling much, old 70 years guy?? (assuming you were at least 10 years old when you compille your first unix kernel... oh yeah!! that's 1963, no kernel source or even unix back then! So i assume you compille using the nice punch-cards do you? (hint: I didn't, but i saw the machines in their final days // another hint ".dir 4").

                      For the filesystem issue: Debian and Red Hat kernel maintainers (not the coders) are known to pick patches from RC's and backport to their stable branches when the fix have to be tested. Water is wet.

                      Reading the mail, it seems the patch was picked by mistake, and thus, the kernel was boorked and nobody noticed until it was too late.

                      So it's a Debian problem, in the end, not a Kernel people problem, so the damage is only in the Debian camp. Go figure.
                      ok, well, maybe I underestimated for how long you remained in the cradle

                      what I wanted to say is this: people choosed ext4 because they think is unbreakable while, as we can see, it can break.

                      to the end user it has no importance if it was a kernel devel fault, a debian fault or something else.
                      to the end user what matters is that their filesystem may get corrupted.

                      Comment

                      Working...
                      X