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
initramfs fsck read-only
New contributor
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.
add a comment |
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
initramfs fsck read-only
New contributor
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.
add a comment |
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
initramfs fsck read-only
New contributor
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
initramfs fsck read-only
New contributor
New contributor
New contributor
asked Nov 13 at 13:43
Saul Lubkin
21
21
New contributor
New contributor
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.
add a comment |
add a comment |
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
New contributor
add a comment |
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:~$
New contributor
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
add a comment |
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
New contributor
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
add a comment |
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
New contributor
add a comment |
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
New contributor
add a comment |
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
New contributor
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
New contributor
New contributor
answered 2 days ago
Saul Lubkin
21
21
New contributor
New contributor
add a comment |
add a comment |
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:~$
New contributor
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
add a comment |
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:~$
New contributor
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
add a comment |
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:~$
New contributor
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:~$
New contributor
edited yesterday
New contributor
answered 2 days ago
Stéphane COLIN
12
12
New contributor
New contributor
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
add a comment |
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
add a comment |
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
New contributor
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
add a comment |
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
New contributor
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
add a comment |
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
New contributor
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
New contributor
New contributor
answered yesterday
Saul Lubkin
21
21
New contributor
New contributor
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
add a comment |
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
add a comment |