Ubuntu 18.04: 4.19.1 kernel: after closing the lid for the night (not logging out), root filesystem is...











up vote
0
down vote

favorite












I'm running Ubuntu 18.04, with linux kernel 4.19.1. My laptop is single boot ubuntu. When I close the lid for the night, without logging off, on reopening the lid the next morning, and trying to create a file, I get "read-only filesystem". On rebooting, initramfs requires a manual fsck (finds some bad inodes, other minor problems, fixes them). Then the system works well.
How to prevent this problem?
-- Saul










share|improve this question







New contributor




Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











put on hold as off-topic by Eric Carvalho, Charles Green, NickTux, Zanna, pomsky 10 hours ago


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Bug reports and problems specific to development version of Ubuntu should be reported on Launchpad so that developers can see, track and fix these issues." – Eric Carvalho, Charles Green, NickTux, pomsky

If this question can be reworded to fit the rules in the help center, please edit the question.

















    up vote
    0
    down vote

    favorite












    I'm running Ubuntu 18.04, with linux kernel 4.19.1. My laptop is single boot ubuntu. When I close the lid for the night, without logging off, on reopening the lid the next morning, and trying to create a file, I get "read-only filesystem". On rebooting, initramfs requires a manual fsck (finds some bad inodes, other minor problems, fixes them). Then the system works well.
    How to prevent this problem?
    -- Saul










    share|improve this question







    New contributor




    Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.











    put on hold as off-topic by Eric Carvalho, Charles Green, NickTux, Zanna, pomsky 10 hours ago


    This question appears to be off-topic. The users who voted to close gave this specific reason:


    • "Bug reports and problems specific to development version of Ubuntu should be reported on Launchpad so that developers can see, track and fix these issues." – Eric Carvalho, Charles Green, NickTux, pomsky

    If this question can be reworded to fit the rules in the help center, please edit the question.















      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      I'm running Ubuntu 18.04, with linux kernel 4.19.1. My laptop is single boot ubuntu. When I close the lid for the night, without logging off, on reopening the lid the next morning, and trying to create a file, I get "read-only filesystem". On rebooting, initramfs requires a manual fsck (finds some bad inodes, other minor problems, fixes them). Then the system works well.
      How to prevent this problem?
      -- Saul










      share|improve this question







      New contributor




      Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      I'm running Ubuntu 18.04, with linux kernel 4.19.1. My laptop is single boot ubuntu. When I close the lid for the night, without logging off, on reopening the lid the next morning, and trying to create a file, I get "read-only filesystem". On rebooting, initramfs requires a manual fsck (finds some bad inodes, other minor problems, fixes them). Then the system works well.
      How to prevent this problem?
      -- Saul







      initramfs fsck read-only






      share|improve this question







      New contributor




      Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      share|improve this question







      New contributor




      Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      share|improve this question




      share|improve this question






      New contributor




      Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked Nov 13 at 13:43









      Saul Lubkin

      21




      21




      New contributor




      Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.




      put on hold as off-topic by Eric Carvalho, Charles Green, NickTux, Zanna, pomsky 10 hours ago


      This question appears to be off-topic. The users who voted to close gave this specific reason:


      • "Bug reports and problems specific to development version of Ubuntu should be reported on Launchpad so that developers can see, track and fix these issues." – Eric Carvalho, Charles Green, NickTux, pomsky

      If this question can be reworded to fit the rules in the help center, please edit the question.




      put on hold as off-topic by Eric Carvalho, Charles Green, NickTux, Zanna, pomsky 10 hours ago


      This question appears to be off-topic. The users who voted to close gave this specific reason:


      • "Bug reports and problems specific to development version of Ubuntu should be reported on Launchpad so that developers can see, track and fix these issues." – Eric Carvalho, Charles Green, NickTux, pomsky

      If this question can be reworded to fit the rules in the help center, please edit the question.






















          3 Answers
          3






          active

          oldest

          votes

















          up vote
          0
          down vote













          I should supply more detail.



          The highest kernel currently supported by Ubuntu is linux 4.15.0-39. That is a signed kernel (meaning, I think, that it is currently supported by Ubuntu).



          linux 4.19.1 is not currently supported by Ubuntu -- so how did I get it, and how did I get it to operate my Ubuntu 18.04 laptop?



          Answer: I used the ukuu tool -- it enables you to download, and use the most recent, or any other, kernel



          I used ukuu to download linux 4.19, the (then) most recent linux kernel. It produced a MUCH faster system -- so I found it, in all ways but one, vastly superior to linux 15.0-39. The one minor negative: On booting, the error message "failed to connect to lvmetad". This minor problem slightly slowed the boot process -- but, as I've noted, everything else was so much faster that it was a no-brainer which is better.



          I thought that, possibly the next linux kernel would fix the minor problem.



          The next linux kernel was 19.1 -- which I promptly downloaded and installed using ukuu. Unfortunately, linux 19.1 is VERY buggy; as noted in my previous post, it resulted in repeated corruption of the root file system.



          So i posted to this forum.



          i also decided to go back to linux 19 and see if linux 19 had the same damning problem as linux 19.1 -- i was sure it would.



          Happily, I seem to have been wrong -- I've gone back to linux 19, and have deleted the linux 19.1 kernel. i've been running for over a day, with closing the laptop overnight and many other times -- no "currupt root filesystem" problems.



          So i have a really fast, great linux 19 system. knock on wood, it stays that way.



          (Bottom line: if you install a more recent kernel than the ones supported by Ubuntu, say by using ukuu, DON'T choose linux 19.1! It's buggy.



          -- Saul






          share|improve this answer








          New contributor




          Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.

























            up vote
            0
            down vote













            On my side , I am using « 18.04.1 LTS », I have installed 4.19.1 mainline build and 4.19.2 mainline build and it end to an ETX4 filesystem corrupt randomly.



            By randomly, I mean, it occur randomly during usage, without any special case, with this kind of message :



            [12397.773762] EXT4-fs error (device dm-0): ext4_iget:4831: inode #9043981: comm DOMCacheThread: bad extra_isize 58853 (inode size 256)
            [12397.775122] Aborting journal on device dm-0-8.
            [12397.776011] EXT4-fs (dm-0): Remounting filesystem read-only
            [12397.776755] EXT4-fs error (device dm-0): ext4_journal_check_start:61: Detected aborted journal
            [12397.777617] EXT4-fs error (device dm-0): ext4_journal_check_start:61: Detected aborted journal


            I have to reboot in « maintenance » mode to fsck the volume and fix errors manually, to be able to reboot with read-write volume



            When I revert to the latest 4.18 version, EXT4 filesystem corruption disappear...



            bigbob@bigbob-UX31A:~$ uname -a
            Linux bigbob-UX31A 4.18.17-041817-generic #201811040932 SMP Sun Nov 4 14:34:07 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
            bigbob@bigbob-UX31A:~$ lsb_release -a
            No LSB modules are available.
            Distributor ID: Ubuntu
            Description: Ubuntu 18.04.1 LTS
            Release: 18.04
            Codename: bionic
            bigbob@bigbob-UX31A:~/Vrac$


            BTW, it look like since 4.19 there is many EXT4 updates in the kernel : EXT4 & XFS File-System Updates Submitted For Linux 4.19



            Update (15/11/2018) :



            I am using the 4.19 from v4.19 mainline build on another computer with same Ubuntu release (Bionic).



            It look like this version does not suffer from same EXT4 corruption BUG...



            So, it look like at least sticking to v4.19 mainline build is safe and BUG was introduced since v4.19.1 mainline build.



            bigbob@bigbob-ThinkPad-X201:~$ uname -a
            Linux bigbob-ThinkPad-X201 4.19.0-041900-generic #201810221809 SMP Mon Oct 22 22:11:45 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
            bigbob@bigbob-ThinkPad-X201:~$ lsb_release -a
            No LSB modules are available.
            Distributor ID: Ubuntu
            Description: Ubuntu 18.04.1 LTS
            Release: 18.04
            Codename: bionic
            bigbob@bigbob-ThinkPad-X201:~$





            share|improve this answer










            New contributor




            Stéphane COLIN is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.


















            • I am seeing similar with 4.19.x
              – Mark
              2 days ago










            • I am currently running 4.19.1 kernel, and facing the same issue.. Now there is a update to 4.19.2. is this issue solved in 4.19.2 version or can i revert back to 4.18?
              – Rubanraj Ravichandran
              2 days ago










            • If you look at the diffs between v4.19 and v4.19.1, there were no ext4 changes, and no storage related changes that I could see. Looking that the files that changed, the deltas between 4.19.1 and 4.19 are in Sparc architecture support, changes in some networking drivers and the networking stack, and a one-line change to the crypto subsystem.
              – Theodore Ts'o
              yesterday


















            up vote
            -1
            down vote













            So far, 4.19 has not produced any filesystem problems on either of my 2 laptops or on my desktop. 4.19,1 has consistently produced the curupt filesystem problem on the one laptop that I tried it on.



            -- Saul






            share|improve this answer








            New contributor




            Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.


















            • This looks like a comment on or an update to your other answer. In that case post a comment below the answer or edit the answer and add the update. Please don't unnecessarily post a new answer. If these are intended to just supply more info for the problem, then edit the question instead. Ask Ubuntu is not like other forums.
              – pomsky
              10 hours ago












            • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. - From Review
              – abu_bua
              8 hours ago


















            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            0
            down vote













            I should supply more detail.



            The highest kernel currently supported by Ubuntu is linux 4.15.0-39. That is a signed kernel (meaning, I think, that it is currently supported by Ubuntu).



            linux 4.19.1 is not currently supported by Ubuntu -- so how did I get it, and how did I get it to operate my Ubuntu 18.04 laptop?



            Answer: I used the ukuu tool -- it enables you to download, and use the most recent, or any other, kernel



            I used ukuu to download linux 4.19, the (then) most recent linux kernel. It produced a MUCH faster system -- so I found it, in all ways but one, vastly superior to linux 15.0-39. The one minor negative: On booting, the error message "failed to connect to lvmetad". This minor problem slightly slowed the boot process -- but, as I've noted, everything else was so much faster that it was a no-brainer which is better.



            I thought that, possibly the next linux kernel would fix the minor problem.



            The next linux kernel was 19.1 -- which I promptly downloaded and installed using ukuu. Unfortunately, linux 19.1 is VERY buggy; as noted in my previous post, it resulted in repeated corruption of the root file system.



            So i posted to this forum.



            i also decided to go back to linux 19 and see if linux 19 had the same damning problem as linux 19.1 -- i was sure it would.



            Happily, I seem to have been wrong -- I've gone back to linux 19, and have deleted the linux 19.1 kernel. i've been running for over a day, with closing the laptop overnight and many other times -- no "currupt root filesystem" problems.



            So i have a really fast, great linux 19 system. knock on wood, it stays that way.



            (Bottom line: if you install a more recent kernel than the ones supported by Ubuntu, say by using ukuu, DON'T choose linux 19.1! It's buggy.



            -- Saul






            share|improve this answer








            New contributor




            Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.






















              up vote
              0
              down vote













              I should supply more detail.



              The highest kernel currently supported by Ubuntu is linux 4.15.0-39. That is a signed kernel (meaning, I think, that it is currently supported by Ubuntu).



              linux 4.19.1 is not currently supported by Ubuntu -- so how did I get it, and how did I get it to operate my Ubuntu 18.04 laptop?



              Answer: I used the ukuu tool -- it enables you to download, and use the most recent, or any other, kernel



              I used ukuu to download linux 4.19, the (then) most recent linux kernel. It produced a MUCH faster system -- so I found it, in all ways but one, vastly superior to linux 15.0-39. The one minor negative: On booting, the error message "failed to connect to lvmetad". This minor problem slightly slowed the boot process -- but, as I've noted, everything else was so much faster that it was a no-brainer which is better.



              I thought that, possibly the next linux kernel would fix the minor problem.



              The next linux kernel was 19.1 -- which I promptly downloaded and installed using ukuu. Unfortunately, linux 19.1 is VERY buggy; as noted in my previous post, it resulted in repeated corruption of the root file system.



              So i posted to this forum.



              i also decided to go back to linux 19 and see if linux 19 had the same damning problem as linux 19.1 -- i was sure it would.



              Happily, I seem to have been wrong -- I've gone back to linux 19, and have deleted the linux 19.1 kernel. i've been running for over a day, with closing the laptop overnight and many other times -- no "currupt root filesystem" problems.



              So i have a really fast, great linux 19 system. knock on wood, it stays that way.



              (Bottom line: if you install a more recent kernel than the ones supported by Ubuntu, say by using ukuu, DON'T choose linux 19.1! It's buggy.



              -- Saul






              share|improve this answer








              New contributor




              Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
              Check out our Code of Conduct.




















                up vote
                0
                down vote










                up vote
                0
                down vote









                I should supply more detail.



                The highest kernel currently supported by Ubuntu is linux 4.15.0-39. That is a signed kernel (meaning, I think, that it is currently supported by Ubuntu).



                linux 4.19.1 is not currently supported by Ubuntu -- so how did I get it, and how did I get it to operate my Ubuntu 18.04 laptop?



                Answer: I used the ukuu tool -- it enables you to download, and use the most recent, or any other, kernel



                I used ukuu to download linux 4.19, the (then) most recent linux kernel. It produced a MUCH faster system -- so I found it, in all ways but one, vastly superior to linux 15.0-39. The one minor negative: On booting, the error message "failed to connect to lvmetad". This minor problem slightly slowed the boot process -- but, as I've noted, everything else was so much faster that it was a no-brainer which is better.



                I thought that, possibly the next linux kernel would fix the minor problem.



                The next linux kernel was 19.1 -- which I promptly downloaded and installed using ukuu. Unfortunately, linux 19.1 is VERY buggy; as noted in my previous post, it resulted in repeated corruption of the root file system.



                So i posted to this forum.



                i also decided to go back to linux 19 and see if linux 19 had the same damning problem as linux 19.1 -- i was sure it would.



                Happily, I seem to have been wrong -- I've gone back to linux 19, and have deleted the linux 19.1 kernel. i've been running for over a day, with closing the laptop overnight and many other times -- no "currupt root filesystem" problems.



                So i have a really fast, great linux 19 system. knock on wood, it stays that way.



                (Bottom line: if you install a more recent kernel than the ones supported by Ubuntu, say by using ukuu, DON'T choose linux 19.1! It's buggy.



                -- Saul






                share|improve this answer








                New contributor




                Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.









                I should supply more detail.



                The highest kernel currently supported by Ubuntu is linux 4.15.0-39. That is a signed kernel (meaning, I think, that it is currently supported by Ubuntu).



                linux 4.19.1 is not currently supported by Ubuntu -- so how did I get it, and how did I get it to operate my Ubuntu 18.04 laptop?



                Answer: I used the ukuu tool -- it enables you to download, and use the most recent, or any other, kernel



                I used ukuu to download linux 4.19, the (then) most recent linux kernel. It produced a MUCH faster system -- so I found it, in all ways but one, vastly superior to linux 15.0-39. The one minor negative: On booting, the error message "failed to connect to lvmetad". This minor problem slightly slowed the boot process -- but, as I've noted, everything else was so much faster that it was a no-brainer which is better.



                I thought that, possibly the next linux kernel would fix the minor problem.



                The next linux kernel was 19.1 -- which I promptly downloaded and installed using ukuu. Unfortunately, linux 19.1 is VERY buggy; as noted in my previous post, it resulted in repeated corruption of the root file system.



                So i posted to this forum.



                i also decided to go back to linux 19 and see if linux 19 had the same damning problem as linux 19.1 -- i was sure it would.



                Happily, I seem to have been wrong -- I've gone back to linux 19, and have deleted the linux 19.1 kernel. i've been running for over a day, with closing the laptop overnight and many other times -- no "currupt root filesystem" problems.



                So i have a really fast, great linux 19 system. knock on wood, it stays that way.



                (Bottom line: if you install a more recent kernel than the ones supported by Ubuntu, say by using ukuu, DON'T choose linux 19.1! It's buggy.



                -- Saul







                share|improve this answer








                New contributor




                Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.









                share|improve this answer



                share|improve this answer






                New contributor




                Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.









                answered 2 days ago









                Saul Lubkin

                21




                21




                New contributor




                Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.





                New contributor





                Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.






                Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.
























                    up vote
                    0
                    down vote













                    On my side , I am using « 18.04.1 LTS », I have installed 4.19.1 mainline build and 4.19.2 mainline build and it end to an ETX4 filesystem corrupt randomly.



                    By randomly, I mean, it occur randomly during usage, without any special case, with this kind of message :



                    [12397.773762] EXT4-fs error (device dm-0): ext4_iget:4831: inode #9043981: comm DOMCacheThread: bad extra_isize 58853 (inode size 256)
                    [12397.775122] Aborting journal on device dm-0-8.
                    [12397.776011] EXT4-fs (dm-0): Remounting filesystem read-only
                    [12397.776755] EXT4-fs error (device dm-0): ext4_journal_check_start:61: Detected aborted journal
                    [12397.777617] EXT4-fs error (device dm-0): ext4_journal_check_start:61: Detected aborted journal


                    I have to reboot in « maintenance » mode to fsck the volume and fix errors manually, to be able to reboot with read-write volume



                    When I revert to the latest 4.18 version, EXT4 filesystem corruption disappear...



                    bigbob@bigbob-UX31A:~$ uname -a
                    Linux bigbob-UX31A 4.18.17-041817-generic #201811040932 SMP Sun Nov 4 14:34:07 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
                    bigbob@bigbob-UX31A:~$ lsb_release -a
                    No LSB modules are available.
                    Distributor ID: Ubuntu
                    Description: Ubuntu 18.04.1 LTS
                    Release: 18.04
                    Codename: bionic
                    bigbob@bigbob-UX31A:~/Vrac$


                    BTW, it look like since 4.19 there is many EXT4 updates in the kernel : EXT4 & XFS File-System Updates Submitted For Linux 4.19



                    Update (15/11/2018) :



                    I am using the 4.19 from v4.19 mainline build on another computer with same Ubuntu release (Bionic).



                    It look like this version does not suffer from same EXT4 corruption BUG...



                    So, it look like at least sticking to v4.19 mainline build is safe and BUG was introduced since v4.19.1 mainline build.



                    bigbob@bigbob-ThinkPad-X201:~$ uname -a
                    Linux bigbob-ThinkPad-X201 4.19.0-041900-generic #201810221809 SMP Mon Oct 22 22:11:45 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
                    bigbob@bigbob-ThinkPad-X201:~$ lsb_release -a
                    No LSB modules are available.
                    Distributor ID: Ubuntu
                    Description: Ubuntu 18.04.1 LTS
                    Release: 18.04
                    Codename: bionic
                    bigbob@bigbob-ThinkPad-X201:~$





                    share|improve this answer










                    New contributor




                    Stéphane COLIN is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.


















                    • I am seeing similar with 4.19.x
                      – Mark
                      2 days ago










                    • I am currently running 4.19.1 kernel, and facing the same issue.. Now there is a update to 4.19.2. is this issue solved in 4.19.2 version or can i revert back to 4.18?
                      – Rubanraj Ravichandran
                      2 days ago










                    • If you look at the diffs between v4.19 and v4.19.1, there were no ext4 changes, and no storage related changes that I could see. Looking that the files that changed, the deltas between 4.19.1 and 4.19 are in Sparc architecture support, changes in some networking drivers and the networking stack, and a one-line change to the crypto subsystem.
                      – Theodore Ts'o
                      yesterday















                    up vote
                    0
                    down vote













                    On my side , I am using « 18.04.1 LTS », I have installed 4.19.1 mainline build and 4.19.2 mainline build and it end to an ETX4 filesystem corrupt randomly.



                    By randomly, I mean, it occur randomly during usage, without any special case, with this kind of message :



                    [12397.773762] EXT4-fs error (device dm-0): ext4_iget:4831: inode #9043981: comm DOMCacheThread: bad extra_isize 58853 (inode size 256)
                    [12397.775122] Aborting journal on device dm-0-8.
                    [12397.776011] EXT4-fs (dm-0): Remounting filesystem read-only
                    [12397.776755] EXT4-fs error (device dm-0): ext4_journal_check_start:61: Detected aborted journal
                    [12397.777617] EXT4-fs error (device dm-0): ext4_journal_check_start:61: Detected aborted journal


                    I have to reboot in « maintenance » mode to fsck the volume and fix errors manually, to be able to reboot with read-write volume



                    When I revert to the latest 4.18 version, EXT4 filesystem corruption disappear...



                    bigbob@bigbob-UX31A:~$ uname -a
                    Linux bigbob-UX31A 4.18.17-041817-generic #201811040932 SMP Sun Nov 4 14:34:07 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
                    bigbob@bigbob-UX31A:~$ lsb_release -a
                    No LSB modules are available.
                    Distributor ID: Ubuntu
                    Description: Ubuntu 18.04.1 LTS
                    Release: 18.04
                    Codename: bionic
                    bigbob@bigbob-UX31A:~/Vrac$


                    BTW, it look like since 4.19 there is many EXT4 updates in the kernel : EXT4 & XFS File-System Updates Submitted For Linux 4.19



                    Update (15/11/2018) :



                    I am using the 4.19 from v4.19 mainline build on another computer with same Ubuntu release (Bionic).



                    It look like this version does not suffer from same EXT4 corruption BUG...



                    So, it look like at least sticking to v4.19 mainline build is safe and BUG was introduced since v4.19.1 mainline build.



                    bigbob@bigbob-ThinkPad-X201:~$ uname -a
                    Linux bigbob-ThinkPad-X201 4.19.0-041900-generic #201810221809 SMP Mon Oct 22 22:11:45 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
                    bigbob@bigbob-ThinkPad-X201:~$ lsb_release -a
                    No LSB modules are available.
                    Distributor ID: Ubuntu
                    Description: Ubuntu 18.04.1 LTS
                    Release: 18.04
                    Codename: bionic
                    bigbob@bigbob-ThinkPad-X201:~$





                    share|improve this answer










                    New contributor




                    Stéphane COLIN is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.


















                    • I am seeing similar with 4.19.x
                      – Mark
                      2 days ago










                    • I am currently running 4.19.1 kernel, and facing the same issue.. Now there is a update to 4.19.2. is this issue solved in 4.19.2 version or can i revert back to 4.18?
                      – Rubanraj Ravichandran
                      2 days ago










                    • If you look at the diffs between v4.19 and v4.19.1, there were no ext4 changes, and no storage related changes that I could see. Looking that the files that changed, the deltas between 4.19.1 and 4.19 are in Sparc architecture support, changes in some networking drivers and the networking stack, and a one-line change to the crypto subsystem.
                      – Theodore Ts'o
                      yesterday













                    up vote
                    0
                    down vote










                    up vote
                    0
                    down vote









                    On my side , I am using « 18.04.1 LTS », I have installed 4.19.1 mainline build and 4.19.2 mainline build and it end to an ETX4 filesystem corrupt randomly.



                    By randomly, I mean, it occur randomly during usage, without any special case, with this kind of message :



                    [12397.773762] EXT4-fs error (device dm-0): ext4_iget:4831: inode #9043981: comm DOMCacheThread: bad extra_isize 58853 (inode size 256)
                    [12397.775122] Aborting journal on device dm-0-8.
                    [12397.776011] EXT4-fs (dm-0): Remounting filesystem read-only
                    [12397.776755] EXT4-fs error (device dm-0): ext4_journal_check_start:61: Detected aborted journal
                    [12397.777617] EXT4-fs error (device dm-0): ext4_journal_check_start:61: Detected aborted journal


                    I have to reboot in « maintenance » mode to fsck the volume and fix errors manually, to be able to reboot with read-write volume



                    When I revert to the latest 4.18 version, EXT4 filesystem corruption disappear...



                    bigbob@bigbob-UX31A:~$ uname -a
                    Linux bigbob-UX31A 4.18.17-041817-generic #201811040932 SMP Sun Nov 4 14:34:07 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
                    bigbob@bigbob-UX31A:~$ lsb_release -a
                    No LSB modules are available.
                    Distributor ID: Ubuntu
                    Description: Ubuntu 18.04.1 LTS
                    Release: 18.04
                    Codename: bionic
                    bigbob@bigbob-UX31A:~/Vrac$


                    BTW, it look like since 4.19 there is many EXT4 updates in the kernel : EXT4 & XFS File-System Updates Submitted For Linux 4.19



                    Update (15/11/2018) :



                    I am using the 4.19 from v4.19 mainline build on another computer with same Ubuntu release (Bionic).



                    It look like this version does not suffer from same EXT4 corruption BUG...



                    So, it look like at least sticking to v4.19 mainline build is safe and BUG was introduced since v4.19.1 mainline build.



                    bigbob@bigbob-ThinkPad-X201:~$ uname -a
                    Linux bigbob-ThinkPad-X201 4.19.0-041900-generic #201810221809 SMP Mon Oct 22 22:11:45 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
                    bigbob@bigbob-ThinkPad-X201:~$ lsb_release -a
                    No LSB modules are available.
                    Distributor ID: Ubuntu
                    Description: Ubuntu 18.04.1 LTS
                    Release: 18.04
                    Codename: bionic
                    bigbob@bigbob-ThinkPad-X201:~$





                    share|improve this answer










                    New contributor




                    Stéphane COLIN is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.









                    On my side , I am using « 18.04.1 LTS », I have installed 4.19.1 mainline build and 4.19.2 mainline build and it end to an ETX4 filesystem corrupt randomly.



                    By randomly, I mean, it occur randomly during usage, without any special case, with this kind of message :



                    [12397.773762] EXT4-fs error (device dm-0): ext4_iget:4831: inode #9043981: comm DOMCacheThread: bad extra_isize 58853 (inode size 256)
                    [12397.775122] Aborting journal on device dm-0-8.
                    [12397.776011] EXT4-fs (dm-0): Remounting filesystem read-only
                    [12397.776755] EXT4-fs error (device dm-0): ext4_journal_check_start:61: Detected aborted journal
                    [12397.777617] EXT4-fs error (device dm-0): ext4_journal_check_start:61: Detected aborted journal


                    I have to reboot in « maintenance » mode to fsck the volume and fix errors manually, to be able to reboot with read-write volume



                    When I revert to the latest 4.18 version, EXT4 filesystem corruption disappear...



                    bigbob@bigbob-UX31A:~$ uname -a
                    Linux bigbob-UX31A 4.18.17-041817-generic #201811040932 SMP Sun Nov 4 14:34:07 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
                    bigbob@bigbob-UX31A:~$ lsb_release -a
                    No LSB modules are available.
                    Distributor ID: Ubuntu
                    Description: Ubuntu 18.04.1 LTS
                    Release: 18.04
                    Codename: bionic
                    bigbob@bigbob-UX31A:~/Vrac$


                    BTW, it look like since 4.19 there is many EXT4 updates in the kernel : EXT4 & XFS File-System Updates Submitted For Linux 4.19



                    Update (15/11/2018) :



                    I am using the 4.19 from v4.19 mainline build on another computer with same Ubuntu release (Bionic).



                    It look like this version does not suffer from same EXT4 corruption BUG...



                    So, it look like at least sticking to v4.19 mainline build is safe and BUG was introduced since v4.19.1 mainline build.



                    bigbob@bigbob-ThinkPad-X201:~$ uname -a
                    Linux bigbob-ThinkPad-X201 4.19.0-041900-generic #201810221809 SMP Mon Oct 22 22:11:45 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
                    bigbob@bigbob-ThinkPad-X201:~$ lsb_release -a
                    No LSB modules are available.
                    Distributor ID: Ubuntu
                    Description: Ubuntu 18.04.1 LTS
                    Release: 18.04
                    Codename: bionic
                    bigbob@bigbob-ThinkPad-X201:~$






                    share|improve this answer










                    New contributor




                    Stéphane COLIN is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.









                    share|improve this answer



                    share|improve this answer








                    edited yesterday





















                    New contributor




                    Stéphane COLIN is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.









                    answered 2 days ago









                    Stéphane COLIN

                    12




                    12




                    New contributor




                    Stéphane COLIN is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.





                    New contributor





                    Stéphane COLIN is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.






                    Stéphane COLIN is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.












                    • I am seeing similar with 4.19.x
                      – Mark
                      2 days ago










                    • I am currently running 4.19.1 kernel, and facing the same issue.. Now there is a update to 4.19.2. is this issue solved in 4.19.2 version or can i revert back to 4.18?
                      – Rubanraj Ravichandran
                      2 days ago










                    • If you look at the diffs between v4.19 and v4.19.1, there were no ext4 changes, and no storage related changes that I could see. Looking that the files that changed, the deltas between 4.19.1 and 4.19 are in Sparc architecture support, changes in some networking drivers and the networking stack, and a one-line change to the crypto subsystem.
                      – Theodore Ts'o
                      yesterday


















                    • I am seeing similar with 4.19.x
                      – Mark
                      2 days ago










                    • I am currently running 4.19.1 kernel, and facing the same issue.. Now there is a update to 4.19.2. is this issue solved in 4.19.2 version or can i revert back to 4.18?
                      – Rubanraj Ravichandran
                      2 days ago










                    • If you look at the diffs between v4.19 and v4.19.1, there were no ext4 changes, and no storage related changes that I could see. Looking that the files that changed, the deltas between 4.19.1 and 4.19 are in Sparc architecture support, changes in some networking drivers and the networking stack, and a one-line change to the crypto subsystem.
                      – Theodore Ts'o
                      yesterday
















                    I am seeing similar with 4.19.x
                    – Mark
                    2 days ago




                    I am seeing similar with 4.19.x
                    – Mark
                    2 days ago












                    I am currently running 4.19.1 kernel, and facing the same issue.. Now there is a update to 4.19.2. is this issue solved in 4.19.2 version or can i revert back to 4.18?
                    – Rubanraj Ravichandran
                    2 days ago




                    I am currently running 4.19.1 kernel, and facing the same issue.. Now there is a update to 4.19.2. is this issue solved in 4.19.2 version or can i revert back to 4.18?
                    – Rubanraj Ravichandran
                    2 days ago












                    If you look at the diffs between v4.19 and v4.19.1, there were no ext4 changes, and no storage related changes that I could see. Looking that the files that changed, the deltas between 4.19.1 and 4.19 are in Sparc architecture support, changes in some networking drivers and the networking stack, and a one-line change to the crypto subsystem.
                    – Theodore Ts'o
                    yesterday




                    If you look at the diffs between v4.19 and v4.19.1, there were no ext4 changes, and no storage related changes that I could see. Looking that the files that changed, the deltas between 4.19.1 and 4.19 are in Sparc architecture support, changes in some networking drivers and the networking stack, and a one-line change to the crypto subsystem.
                    – Theodore Ts'o
                    yesterday










                    up vote
                    -1
                    down vote













                    So far, 4.19 has not produced any filesystem problems on either of my 2 laptops or on my desktop. 4.19,1 has consistently produced the curupt filesystem problem on the one laptop that I tried it on.



                    -- Saul






                    share|improve this answer








                    New contributor




                    Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.


















                    • This looks like a comment on or an update to your other answer. In that case post a comment below the answer or edit the answer and add the update. Please don't unnecessarily post a new answer. If these are intended to just supply more info for the problem, then edit the question instead. Ask Ubuntu is not like other forums.
                      – pomsky
                      10 hours ago












                    • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. - From Review
                      – abu_bua
                      8 hours ago















                    up vote
                    -1
                    down vote













                    So far, 4.19 has not produced any filesystem problems on either of my 2 laptops or on my desktop. 4.19,1 has consistently produced the curupt filesystem problem on the one laptop that I tried it on.



                    -- Saul






                    share|improve this answer








                    New contributor




                    Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.


















                    • This looks like a comment on or an update to your other answer. In that case post a comment below the answer or edit the answer and add the update. Please don't unnecessarily post a new answer. If these are intended to just supply more info for the problem, then edit the question instead. Ask Ubuntu is not like other forums.
                      – pomsky
                      10 hours ago












                    • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. - From Review
                      – abu_bua
                      8 hours ago













                    up vote
                    -1
                    down vote










                    up vote
                    -1
                    down vote









                    So far, 4.19 has not produced any filesystem problems on either of my 2 laptops or on my desktop. 4.19,1 has consistently produced the curupt filesystem problem on the one laptop that I tried it on.



                    -- Saul






                    share|improve this answer








                    New contributor




                    Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.









                    So far, 4.19 has not produced any filesystem problems on either of my 2 laptops or on my desktop. 4.19,1 has consistently produced the curupt filesystem problem on the one laptop that I tried it on.



                    -- Saul







                    share|improve this answer








                    New contributor




                    Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.









                    share|improve this answer



                    share|improve this answer






                    New contributor




                    Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.









                    answered yesterday









                    Saul Lubkin

                    21




                    21




                    New contributor




                    Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.





                    New contributor





                    Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.






                    Saul Lubkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.












                    • This looks like a comment on or an update to your other answer. In that case post a comment below the answer or edit the answer and add the update. Please don't unnecessarily post a new answer. If these are intended to just supply more info for the problem, then edit the question instead. Ask Ubuntu is not like other forums.
                      – pomsky
                      10 hours ago












                    • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. - From Review
                      – abu_bua
                      8 hours ago


















                    • This looks like a comment on or an update to your other answer. In that case post a comment below the answer or edit the answer and add the update. Please don't unnecessarily post a new answer. If these are intended to just supply more info for the problem, then edit the question instead. Ask Ubuntu is not like other forums.
                      – pomsky
                      10 hours ago












                    • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. - From Review
                      – abu_bua
                      8 hours ago
















                    This looks like a comment on or an update to your other answer. In that case post a comment below the answer or edit the answer and add the update. Please don't unnecessarily post a new answer. If these are intended to just supply more info for the problem, then edit the question instead. Ask Ubuntu is not like other forums.
                    – pomsky
                    10 hours ago






                    This looks like a comment on or an update to your other answer. In that case post a comment below the answer or edit the answer and add the update. Please don't unnecessarily post a new answer. If these are intended to just supply more info for the problem, then edit the question instead. Ask Ubuntu is not like other forums.
                    – pomsky
                    10 hours ago














                    This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. - From Review
                    – abu_bua
                    8 hours ago




                    This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. - From Review
                    – abu_bua
                    8 hours ago



                    Popular posts from this blog

                    flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

                    Mangá

                    Eduardo VII do Reino Unido