Bug 1851674 - Segfault when trying to convert ext4 partition
Summary: Segfault when trying to convert ext4 partition
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: btrfs-progs
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Josef Bacik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-06-28 05:30 UTC by Artem
Modified: 2020-07-21 16:37 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)

Description Artem 2020-06-28 05:30:27 UTC
Description of problem:
Conversion of current ext4 to BTRFS not possible due to segmentation fault in the end of process.


Version-Release number of selected component (if applicable):
e2fsprogs-1.45.5-3.fc32
btrfs-progs-5.6.1-1.fc32
kernel-5.6.18-300.fc32


How reproducible:
Try to convert ext4 partition from Fedora Workstation latest Live respin. Mine was dated 2020-06-15 (https://dl.fedoraproject.org/pub/alt/live-respins/F32-WORK-x86_64-LIVE-20200615.torrent).


Steps to Reproduce:
1. fsck /dev/sdX
2. btrfs-convert /dev/sdX


Actual results:
See screenshot https://atim.fedorapeople.org/Screenshot%20from%202020-06-27%2011-06-58.png


Expected results:
ext4 partition converted to BTRFS.


Additional info:
Fedora 32 (x86_64) [updated from F29->F30->F31->F32]

Partition scheme (non-LVM):
/dev/sda2           46G          29G   15G           66% /
/dev/sda3          112G          60G   46G           57% /home
/dev/sda1          248M          46M  203M           19% /boot/efi

Comment 1 Chris Murphy 2020-06-28 06:39:54 UTC
Could you try 'e2fsck -yfv /dev/sda2' and report back the results? And were there any kernel messages at the time of the segfault/failure?

Comment 2 Artem 2020-06-28 07:35:08 UTC
@Crhis:

sudo e2fsck -yfv /dev/sda2
e2fsck 1.45.5 (07-Jan-2020)
Pass 1: Checking inodes, blocks, and sizes
Inode 790986 extent tree (at level 2) could be narrower.  Optimize? yes

Inode 791012 extent tree (at level 2) could be narrower.  Optimize? yes

Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

fedora: ***** FILE SYSTEM WAS MODIFIED *****

      908080 inodes used (29.86%, out of 3041472)
        2728 non-contiguous files (0.3%)
        1265 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 719705/631/2
     7769578 blocks used (63.90%, out of 12158208)
           0 bad blocks
           2 large files

      550998 regular files
       83658 directories
           0 character device files
           0 block device files
           0 fifos
      398901 links
      273352 symbolic links (187671 fast symbolic links)
          63 sockets
------------
     1306972 files
[liveuser@localhost-live ~]$

Comment 3 Daniel Xu 2020-07-15 22:43:15 UTC
I tried but failed to reproduce the issue using

    https://dl.fedoraproject.org/pub/alt/live-respins/F32-WORK-x86_64-LIVE-20200701.iso

I installed using non-lvm disk layout (partitions + ext4) and seems like I managed to convert
both the boot and root partitions:
    
    [liveuser@localhost ~]$ sudo btrfs-convert /dev/sda3
    create btrfs filesystem:
    	blocksize: 4096
	nodesize:  16384
	features:  extref, skinny-metadata (default)
	checksum:  crc32c
    creating ext2 image file
    creating btrfs metadata
    copy inodes [o] [    160948/    159242]
    conversion complete

    [liveuser@localhost ~]$ sudo btrfs-convert /dev/sda1
    create btrfs filesystem:
    	blocksize: 4096
    	nodesize:  16384
    	features:  extref, skinny-metadata (default)
    	checksum:  crc32c
    creating ext2 image file
    creating btrfs metadata
    copy inodes [o] [       106/       408]
    conversion complete

    [liveuser@localhost ~]$ lsblk -f
    NAME        FSTYPE         FSVER           LABEL           UUID                                 FSAVAIL FSUSE% MOUNTPOINT
    [...]
    sda                                                                                                            
    ├─sda1      btrfs                                          a5ecf524-d462-4771-a5ec-d538ff22dce8                
    ├─sda2      swap           1                               782abc5e-f0c7-42c9-baaa-5cd333d5c8ab                [SWAP]
    └─sda3      btrfs                                          0d1bbdc1-66a8-484e-9933-be70c5987362                
    sr0         iso9660        Joliet Extensio F32-WORK-x86_64 2020-07-01-16-43-26-00                     0   100% /run/initramfs/liv
    [liveuser@localhost ~]$ uname -r
    5.6.19-300.fc32.x86_64
    [liveuser@localhost ~]$ rpm -q btrfs-progs
    btrfs-progs-5.6.1-1.fc32.x86_64

Did I miss anything? If you could send the virtual machine image somehow
it could probably help speed up repro.

Thanks,
Daniel

Comment 4 Artem 2020-07-16 06:20:50 UTC
> Did I miss anything? If you could send the virtual machine image somehow
> it could probably help speed up repro.

I waited for new respins with new kernel and new btrfs-progs. Also there is some interesting changes https://github.com/kdave/btrfs-progs/blob/master/CHANGES#L9

Also JFYI i am trying to convert on real machine, not VM. Or i just read it wrong? :) Anyway this is a good idea and maybe i can tar somehow my / and upload it somewhere...

Some additional info: since this time i converted two other partitions on this machine. One successfully and and one (/home) not, but i have different bug with /home, not this one.

Also i think i should freeing up more disk space next time when will try to convert again /. 66% (15G) could be not enough maybe?

Comment 5 Chris Murphy 2020-07-16 06:55:31 UTC
There's definitely a bug here, it shouldn't crash. While it should be reversible, I highly recommend backups. Maybe one day down the road we can  have a test day just for convert. A big challenge is getting enough aged (real world) file systems as examples.

btrfs-progs 5.7 should be available by update now, it's in the stable repo for all Fedora versions.

Can you try:

$ sudo e2fsck -fyv

And report those results.

Also check for a coredump.

$ coredumpctl

If there's a coredump for btrfs listed, and the coredump file is 'present' then it's possible to process a backtrace. It's a bit tedious but I think it's better than uploading a large file system somewhere. Basically you'll do:

$ coredumpctl gdb <pid>   ## where <pid> is the number in the 3rd column for the line your coredump appears in. This will generate some text and end with a gdb  prompt. Type exit to get out. But you and copy paste the recommended dnf debuginfo install command with the likely long list of debug info packages. In some cases, it'll take a few rounds of installing debug info packages, then back to 'coredumpctl gdb <pid>'. But eventually it won't ask for more debuginfos. And now at the gdb prompt type:

thread apply all bt full

that'll produce a page of backtrace, with an option at the bottom to press space or type c (enter) to continue with all the pages. I suggest taking all the output from this most recent gdb, stick it in a text file, and attach to the bug report.

Comment 6 Daniel Xu 2020-07-16 17:28:20 UTC
> Also JFYI i am trying to convert on real machine, not VM.

Ah got it, thought you were testing stuff on a VM.

I guess having a core file would be pretty useful, like Chris said.

Comment 7 Artem 2020-07-21 09:12:56 UTC
(In reply to Chris Murphy from comment #5)

@Chris, some news here: now i tried to convert again this partition today. I used:

- This respin https://dl.fedoraproject.org/pub/alt/live-respins/F32-WORK-x86_64-LIVE-20200715.torrent
- Kernel: 5.7.8
- btrfs-progs-5.7.0-1.fc32
- i freed up more disk space, this time 59% used

**No segfault this time but still failed:**

[liveuser@localhost-live ~]$ uname -a
Linux localhost-live 5.7.8-200.fc32.x86_64 #1 SMP Thu Jul 9 14:34:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[liveuser@localhost-live ~]$ sudo e2fsck -fyv /dev/sda2
e2fsck 1.45.5 (07-Jan-2020)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

      819723 inodes used (26.95%, out of 3041472)
        3310 non-contiguous files (0.4%)
        1203 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 633459/567
     6810573 blocks used (56.02%, out of 12158208)
           0 bad blocks
           2 large files

      471075 regular files
       78256 directories
           0 character device files
           0 block device files
           0 fifos
      320516 links
      270320 symbolic links (185626 fast symbolic links)
          63 sockets
------------
     1140230 files

[liveuser@localhost-live ~]$ sudo btrfs-convert /dev/sda2
create btrfs filesystem:
	blocksize: 4096
	nodesize:  16384
	features:  extref, skinny-metadata (default)
	checksum:  crc32c
creating ext2 image file
ERROR: missing data block for bytenr 2555437056
ERROR: failed to create ext2_saved/image: -2
WARNING: an error occurred during conversion, filesystem is partially created but not finalized and not mountable

Comment 8 Chris Murphy 2020-07-21 16:37:45 UTC
Following this failure, what do you get for the same e2fsck command?

I think this bug may have been figured out, patch is pending.
https://lore.kernel.org/linux-btrfs/20200720125109.93970-1-wqu@suse.com/


Note You need to log in before you can comment on or make changes to this bug.