lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 23 May 2022 21:05:36 +0000
Subject: [Bug 216012] Data loss on VirtualBox VMs

Theodore Tso ( changed:

           What    |Removed                     |Added
             Status|REOPENED                    |RESOLVED
                 CC|                            |
         Resolution|---                         |INSUFFICIENT_DATA

--- Comment #3 from Theodore Tso ( ---
Error -30 is EROFS in this message:

EXT4-fs (dm-0): failed to convert unwritten extents to written extents --
potential data loss!  (inode 259291, error -30)

This typically means that *before* this point, the ext4 file system detected an
inconsistency, and the file system was set up to remount the file system
read-only when an Ext4.  So there would be an "EXT4-fs error" message.  For
example, you can trigger this behaviour like this:

root@...-xfstests:~# tune2fs -e remount-ro /dev/vdc
tune2fs 1.46.4-orphan-file-02827d06 (4-Nov-2021)
Setting error behavior to 2
root@...-xfstests:~# mount /dev/vdc /vdc
[   83.142333] EXT4-fs (vdc): mounted filesystem with ordered data mode. Quota
mode: none.
root@...-xfstests:~# echo test-corruption-handling >
[   91.189272] EXT4-fs error (device vdc): trigger_test_error:126: comm bash:
[   91.190375] Aborting journal on device vdc-8.
[   91.193756] EXT4-fs (vdc): Remounting filesystem read-only

Typically, when this happens, in 99.9999% of the time, it's caused by an I/O
error.   In a hypervisor situation, that includes a potential hypervisor bug.  
In any case, without any other evidence to the contrary, it's probably not an
ext4 bug.  And even if it was, unless you can replicate the bug on an upstream
kernel, the proper place to report it is with Canonical.    After all, that's
why you've paid $$$ for a support contract with Canonical for Ubuntu, right? 
:-)    And depending on Canonical's support contract, they might or might not
be willing to track down a Virtualbox bug unless you've paid for a more
comprehensive support contract.   In any case, upstream developers don't have
time to chase down something like this, especially since the probabilities are
extremely high that it's not an upstream kernel issue.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Powered by blists - more mailing lists