Re: Need help with a weird kernel update panic.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



All it takes is one systemd bug, or any number of other conditions
that prevent a proper umount.

I have seen various kernel bugs cause it, I have seen the hw operating
the disks stop working.

In general using ext4+journal and/or xfs under the exact wrong
conditions can result in an unbootable system.

And those exact wrong conditions happen way too often, the hardware is
not perfect, VM datastores fill up, arrays and storage controllers go
offline randomly, nodes crash and/or power off and/or lose power
and/or overheat suddenly from both kernel bugs and bad hardware and/or
missed alarms.  If you design a system to fail too often in these
cases eventually the system will be abandoned for more robust setups.
  Saying worked as designed too many times for common conditions
results in a system that is not robust, and results in no one wanting
to use a given system.

On Tue, May 12, 2020 at 7:02 PM Samuel Sieb <samuel@xxxxxxxx> wrote:
>
> On 5/12/20 4:38 PM, John Mellor wrote:
> > Hi Samuel,
> > But that's the point.  A default install uses LVM, and therefore
> > constructs a separate /boot partition running EXT4 with a journal.  You
> > may of course decide to do your own partitions, but that setup is highly
> > unusual and rare.  Most people will have the default partitioning, and
> > therefore have the kernel upgrade bug.
>
> Except that I've never heard anyone complain about that.  It should not
> happen with ext4.  If it does, there's a problem.  Apparently btrfs is a
> little more lax about flushing the journal which has caused problems,
> but ext4 is not.  If you unmount or remount RO an ext4 filesystem, it
> will flush the journal before finishing.  So if you're finding that the
> journal has not been flushed, then you had an unclean unmount and need
> to find out why that's happening.
> _______________________________________________
> users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux